CloudAcademy
  1. Home
  2. Training Library
  3. Amazon Web Services
  4. Courses
  5. Creating a Highly Available Campaign Website - Scenario

Comparing Solution Costs / Choosing a Solution

play-arrow
Start course
Overview
DifficultyBeginner
Duration2h 7m
Students439

Description

 

 

In this group of live videos, we tackle a practical scenario to help you learn real-world cloud consulting skills.

This is a unique and engaging live video format where we join the Cloud Academy AWS, Azure, and Google Cloud Platform teams in a real-time work situation. The team listen to a customer brief, discuss and define technical requirements and then evaluate which of the public cloud platforms could best deliver on the customer requirements.

From this course, you will learn how cloud professionals go about solving real-world business problems with cloud solutions.

With this course, you will learn how cloud professionals tackle and solve a business problem with each of the three public cloud platforms. This course is highly recommended for anyone interested in learning how to become a cloud architect, specialist or consultant!

Learning how to use your cloud skills in real-world situations is an important skill for a cloud professional. Real life projects require you to be able to evaluate requirements, define priorities and use your knowledge of cloud services to come up with recommendations and designs that can best meet customers' requirements. As a cloud professional you often have to think on your feet, process information quickly and be able to demonstrate design ideas quickly and efficiently.

In this course, we work through a customer scenario that will help you learn how to approach and solve a business problems with a cloud solution. The scenario requires us to build a highly available campaign site for an online competition run by loungebeer.com - a "craft" beer launching a new product in to the market at the US Superbowl event.

In these interactive discussions we join the team as they evaluate the business requirements, define the project constraints, and agree the scope and deliverables for the solution. We then work through the technical requirements we will use to evaluate how each of the three cloud platforms - Google Cloud Platform, AWS and Microsoft Azure - could be used to meet the technical requirements.

We follow each of the platform teams as they define solution architectures for Google Cloud Platform, AWS and Microsoft Azure. We then regroup to run a feature and price comparison before the team builds a proof of concept for our solution design. 

This group of lectures will prepare you for thinking and reacting quickly,  prioritzing requirements, discussing design ideas and coming up with cloud design solutions.  

02/2018 - DynamoDB now supports encryption at rest so that would potentially influence our choice of database in thie scenario
https://aws.amazon.com/blogs/aws/new-encryption-at-rest-for-dynamodb/

For planning tools see
https://www.agilebusiness.org/content/moscow-prioritisation-0
http://www.allaboutagile.com/prioritization-using-moscow/

For more information on White Listing see
https://cloudacademy.com/course/understanding-aws-authentication-authorization-accounting/authorization-in-aws-1/

 

Transcript

- [Instructor] Okay, let's compare the costs of our three potential solutions. So the key assumptions that we'll use for this exercise is that the campaign will run for one month. We're looking at a total number of visitors of around the one million mark. And we'll estimate our total web download size to be three megabytes. Now, we could choose something a little higher here, 'cause some sites, like news sites, can be up to five megabytes in size. But thinking through this being a campaign site where there'll be quite a lot of visual imagery, as well as the form itself, I think three megabytes as a page size is a fair estimate. And we can put an average size of objects as well, which some CDNs will ask us for, and we'll calculate that to be 150 kilobytes. That would be for one image, for example. And so we're expecting an outbound traffic or egress traffic of around 3,000 gigabytes for that month period, which equates to three terabytes. Now, we calculated our data registration as being two kilobytes per record, and I think that's a fairly safe number to work to. We could go as high as 10 kilobytes if we were expecting to collect a lot of post data as well in our logging. We'll pitch our potential transactions per second at 20 transactions per second, which is reasonably high, and I think will cover our burst activity requirements. In data storage, we're looking at two gigabytes for the records stored as data posts. And let's also estimate two gigabytes for logging data. So, we'll use these metrics to calculate each of the solutions using the calculators that are provided. So, let's start with AWS first. Let's look at the AWS Simple Monthly Calculator. First, we'll calculate our storage cost. So, let's go for four gigabytes of storage. That's two gigabytes of raw data and two gigabytes of log data. We'll estimate two million requests or GET requests, and we'll give ourselves one million PUTs. So, that gives us a fairly low number. We're talking round about $5 for that storage per month. We did talk about using reduced redundancy storage. Considering how low the cost of storage is looking, I don't think that that's really necessary. We'll just go with the standard S3 cost. The good thing about the AWS calculator is it does give us lots of options for setting things like inter-region costs, et cetera. Now, we are going to use a CDN, so we'll calculate our CDN content delivery network cost as being a monthly volume of 3,000 gigabytes, as we talked about as our egress cost. We'll set an average object size of 150 kilobytes. We're using HTTPS. And what's interesting here is when we separate or segregate out the type of edge location traffic we're expecting, it makes quite a big difference to the calculated cost. So, we'll put 90% of our traffic coming from the U.S., and we'll also split out 5% from Europe and 5% from the APEC region, just to ensure that we cover all potential traffic types. Let's now calculate our Kinesis Streams. So, we'll just give that a name. We'll calculate it at 20 records per second with an average size of 10 kilobytes just to be on the very, very top end of what our cost could be. We'll set the extended retention period to yes. So, we're working with one shard, and that's looking at around $26 per month, which is very, very reasonable. Okay, so that's our CDN, our Kinesis, and our storage. I'm gonna add support in here, because I think it's a really useful feature if you're working on a business project. So, we'll choose the developer support plan, which is 29 per month. Now, we also need to manage our domain name service, so we're gonna add Route 53 services. We'll do two hosted zones. And we'll set the traffic flow, which is the rules that we'll create for those domains to be two, giving ourselves a million standard queries, which is look-ups. And we'll also bake in one million GeoDNS queries just in case we do need to use the service to route to a different region. Okay, so far our cost is looking at around $440 per month. That comprises our storage, our Route 53 domain name service, our CloudFront storage, which is our distribution network. Always an important factor to include your egress traffic. We've got our Kinesis service, and we've also added the support plan. Now, we also discussed having more dashboarding and reporting, so we'll factor in two CloudWatch dashboards using five standard custom events. And these aren't really necessary, but they just provide us with the opportunity to do more reporting should we need it. So we'll add one resource for monitoring Kinesis if we need to, and we'll have a couple of custom metrics in there. Again, these are just about putting in all the costs that you perceive as being likely so that you can make sure that your cost is not way below what you end up with a usage cost. Okay, so it's easy for us to save and share this estimate. We'll just give it a name, and then we can save it and we can send the link to our customer or to our partners. Easy. Okay, so let's look at our Microsoft Azure calculator and see what kind of costs we'd be up for for running our Azure solution. So, again, the calculator is really easy to use and very, very intuitive. We'll choose our functions first. So, for these, we'll set an execution memory size of 256 megabytes, which is an average size, with an execution time of one second. And we'll estimate two million transactions. Now, that's not going to be a massive cost. That's round about $1.80 per month for those function costs. But, again, we'll bake in a support plan. So, we'll use the developer support plan that's offered by Microsoft Azure, which is a $29 per month. Let's look at our database. So, we're using the Cosmos database. And we'll calculate that to be two gigabytes of record storage and two gigabytes of logs, so we'll give that a total of four gigabytes per month. And, again, we could set this higher. It's really quite a negligible cost in the calculation. We'll give ourselves four reserved instances running at 744 hours, which is 24 by seven. Let's add the Azure DNS service. We'll set two DNS zones. So, the other cost is our network traffic. We'll just calculate this again to be working to our page size. So, we'll set for our zone one, which is North America, Europe. It includes Europe. So we'll 2,900 gigabytes for our main zone, which is North America, but we'll also factor in 50 gigabytes across two other zones: APEC and, say, Australia, just so that we can be sure to catch any other traffic that we might experience so that we don't get caught out by the cost of traffic. We've got our functions, we've got our DNS, we've got our bandwidth. Just in terms of bandwidth, we've calculated a CDN cost, which is our content delivery network. Anything that's included in the CDN cost means that we don't have to pay for egress traffic out of our Azure storage. It's important to remember to calculate these numbers. If you're using a CDN, it makes it easy. If you're not using a CDN, then we do have to factor in egress or outbound traffic. Now, it's easy for us to save this calculator. It's downloaded as an XLS sheet. And we can go ahead and buy the whole package if we want to. So our total cost for Azure is calculating at 294, which is, again, including all the things we want. Hang on, though, we haven't added support, so let's just make sure we add the support plan, the developer one, so we've got apples for apples here. So our total cost for Azure would be 323, and that's with support, which is great. Okay, let's look at our Google Cloud Platform calculator and see how Google Cloud Platform lets us evaluate these costs. First we'll set our App Engine, and we're looking at using two App Engine instances, with a total outbound traffic of 3,000 gigabytes. For our storage for App Engine, we've talked about four gigabytes: two gigabytes for raw data and two gigabytes for logs, so let's add that to our calculation. Now let's factor in our Cloud Storage, which is essentially the CDN component of Google Cloud Platform. Our egress cost is showing up there in the panel on the right, and currently we've got a total of 359 for that egress traffic. All right, so I can use the Cloud DNS service, which is the Google Cloud Platform domain name service registry. And, again, we'll set two zones, and we'll set an outbound request level of two million or one million requests. So, our total cost at this stage is for our App Engine instances we're looking at $30, for our App Engine APIs and services we're looking at 350 odd, and we're looking at a very low Cloud Storage cost of around four cents. Now, we have to add the Stackdriver cost, so we'll just roughly calculate two monitoring instances for that. Because we'll be running two, it'll be between $14 and $20, I expect. So we'll add that. $16, there we are, for Stackdriver. Okay, so our total cost, let's think, is there anything else? Well, we're gonna add support, so we need to make sure we add a similar support plan as the one we've chosen for AWS and for Azure. So all three provide us with a basic support package, but because we're running a campaign and we wanna have as much coverage as possible so if there are any issues, we've got someone to help us. That's why I think it's well worth considering a developer or business level support for any cloud service that you're running. Now, if we set this to have one development support user, which gives us a support cost of $100 per month. All right, so that's a little higher than the other two, but overall our total platform cost is going to be a little bit more with Google Cloud Platform. Your actual cost could look different from this. Always remember that. All right, so let's just go to our comparison and see how we're looking. Wow, this has been such an interesting exercise. Trying to make a decision between these three great platforms on price alone is just not going to be enough. The prices are too close. And I think it would be arbitrary to say that a difference of $50 per month should be the reason why we go for one over the other. I think we all thought it was gonna be much easier than it is. So, if you find yourself in this type of situation where you have very similar feature sets, well, that's fine. Just go back to some common ground. Consider platform mastery rating versus development mastery rating. So, if it's easier for you to work with a platform that the environment's familiar, there's less complexity, and perhaps you have more options for a development team, then go with the platform of choice that best suits that. If, on the other hand, you find the development mastery rating to be of a key preference, then look at the language and the functionality that's supported by each of the platforms. So, those are the kind of decision points you can use if you get to that point. Some of the other ones that you can factor in can be cost, the environment, complexity, compliance if you need to have any specific reporting requirements. In our requirement here, we do need to have privacy maintained, but we don't need to go to the level of PCI DSS or HIPAA compliance. And if we did, than that could again influence what platform would be a best match for us. All right, so what we're gonna do is stand up one of these solutions. We're gonna stand up the AWS one next, just to show you how you could do it. But you're welcome to download any of the build code, which is available in the note section of this course. Okay, let's get into building.

About the Author

Students50638
Courses76
Learning paths28

Andrew is an AWS certified professional who is passionate about helping others learn how to use and gain benefit from AWS technologies. Andrew has worked for AWS and for AWS technology partners Ooyala and Adobe.  His favorite Amazon leadership principle is "Customer Obsession" as everything AWS starts with the customer. Passions around work are cycling and surfing, and having a laugh about the lessons learnt trying to launch two daughters and a few start ups.