In this course, you'll gain a solid understanding of the key concepts for Domain Two of the AWS Solutions Architect Professional certification: Costing.
By the end of this course, you'll have the tools and knowledge you need to successfully accomplish the following requirements for this domain, including:
- Demonstrate ability to make architectural decisions that optimize infrastructure and cost.
- Apply the appropriate AWS account and billing set-up options based on scenario.
- Ability to compare and contrast the cost implications of different architectures.
This course is intended for students seeking to acquire the AWS Solutions Architect Professional certification. It is necessary to have acquired the Associate level of this certification. You should also have at least two years of real-world experience developing AWS architectures.
As stated previously, you will need to have completed the AWS Solutions Architect Associate certification, and we recommend reviewing the relevant learning path in order to be well-prepared for the material in this one.
This Course Includes
- Expert-led instruction and exploration of important concepts.
- Complete coverage of critical Domain Two concepts for the AWS Solutions Architect - Professional certification exam.
What You Will Learn
- Billing models
- Instance types
- Cost optimization
About the Author
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.
Elastic Cloud Compute, or EC2, is usually one of the largest components of any AWS build, so it's the first place you need to look for ways to optimize and reduce costs. It's important to choose the right instance types and the right usage method. Pricing is per instance hour, consumed for each instance type. Partial instance hours consumed are billed as full hours. EC2 billing can be quite complex, so let's just step through this. When you terminate an instance, the state changes through shutting down or terminated, and you are no longer charged for that instance. When you stop an instance, it enters the stopping state, and then the stopped state, and you are not charged hour usage or data transfer fees for your instance after you stop it. But AWS does charge for the storage of any Amazon EBS volumes. Now each time you transition an instance from stopped to running, AWS charges a full instance hour, even if these transitions happen multiple times within a singe hour. When you reboot an instance, it doesn't start a new instance billing hour. Let's go through the differences between rebooting, stopping, staring and terminating. So in terms of the host, the instance stays on the same host when we reboot, but the instance may run on a new host computer when we stop or start, underline may. When we terminate there's no impact. In terms of public and private IP addresses, when we reboot the addresses stay the same, with EC2-Classic the instance gets a new private and new public IP address. With EC2-VPC, the instance keeps its private IP address, and the instance gets a new public IP address, unless it has an elastic IP address, an EIP, which doesn't change during a stop or start. With elastic IP addresses, the EIP remains associated with the instance when you reboot it. For instance store volumes, when we reboot the data is preserved, when we stop or start the data is erased. And when we terminate the data is erased. So remember that, with instance store volumes, data gone when you stop it or terminate it. The root device volume is preserved during a reboot, and volume is preserved during a stop or start event, but the volume is deleted, by default, during termination. And with billing, during a reboot, the instance hour doesn't change. Each time an instance transitions from stopped to running, AWS starts a new instance billing hour. When you terminate an instance, you stop incurring charges for that instance as soon as its state changes to shutting down. Okay, a couple of points to keep in mind for the exam, when an instance is rebooted the host computer stays the same. When an instance is stopped or restarted, the instance may run on a new host. EIP addressees, elastic IP addresses, the EIP remains associated with the host during a reboot. When we terminate an instance, the EIP is disassociated from the instance. Keep in mind too, that we can only stop and start EBS-Backed instances. There are four different cost models, make sure you do check the Simple Monthly Calculator for the latest available instance pricing. The instance families go like this, first there's On-Demand, with On-Demand pricing, you pay hourly for however long you run your EC2 instance, at a price set per instance type. If your EC2 instance does not run the full hour, you are still billed for the full hour. The second option is Spot Pricing. And Spot Pricing is market-placed pricing, based on supply and demand. You are bidding for unused AWS capacity, there is no guarantee that you will get a spot instance, when you do, there is no guarantee that you will have it for any length of time. Now this makes Spot Pricing useful in situations where jobs are not time-constrained, i.e., they can spin up and shut down without a negative impact on the system they're interacting with. Keep in mind, Spot Instances can be terminated. Reserved Instances, Reserved pricing offers discounted hourly rates per instance type with an up front commitment of either one year or three years. The up front commitment comes in the form of a one time payment, which offers the steepest hourly discount. A partial up front payment, or no up front payment at all. RIs suit predictable usage where you can safely explain or expect a certain level of compute will be required. Scheduled Instances are like Reserved Instances, however, you can reserve the capacity in advance, so that you know it is available when you need it. You pay for the time that the instances are scheduled, even if you do not use them. Scheduled Reserved Instances enable you to purchase capacity reservations that reoccur on a daily, weekly or monthly basis, with a specified start time and duration for a one year term. Scheduled Instances are a good choice for workloads that do not run continuously but do run on a regular schedule. For example, you can use Scheduled Instances for an application that runs during business hours or for a batch processing job that runs at the end of the week, as an example. In addition to the hourly pricing, EC2 instances are subject to data transfer charges. This varies per region, but essentially, data coming into the EC2 instance from the internet is not charged. Data sent out from the EC2 instance to the internet is charged per gigabyte in terabyte tiers. Check the Simple Monthly Calculator for the latest prices on all instance types. So let's look at these instance types. The t series can handle low traffic websites, development environments, et cetera, essentially any processes that do not require a ton of CPU power. You get burstable CPU via CPU credits that are obtained hourly, based on the size of the instance. Their max limits also are based on the size of the instance. The m series is perfect for small or medium sized databases, it accomplishes this with the right balance of memory, CPU and storage. It uses solid state drives with fast I/O performance. These features make it a very popular choice for many different types of systems, m3 instances are general purpose instances, and enable a higher number of virtual CPUs which provides higher performance. m3 instances are recommended if you are seeking general purpose instances with demanding CPU requirements. The compute optimized c series instance family offers the best price for pure CPU performance. The c4 instances use processes built specifically for AWS hardware and EC2 instances. This family works best for jobs that are CPU intensive, be it batch processing, video encoding or other workforce type tasks. Memory optimized instances offer the best price per gigabyte of RAM for all of the instance families. Think high performance databases or caching when considering this family of EC2 instances. Not only do you get a lot of memory, you get fast memory. The r series, or r3 instances, are designed for memory intensive applications such as high performance databases, distributed memory caches and memory analytics, large SAP deployments, SharePoint, and other enterprise applications. The GPU instance family offers a high performance video GPU with up to four gigabyte of video memory combined with a built in encoder that supports high definition and fully high definition video streams. The g series is ideal for server side graphics workloads, games streaming, 3-D application streaming and video encoding. Lastly, the storage optimized instance family brings the choice between low cost IOPS, or the best cost per gigabyte of storage. The i series delivers high IOPS at a low cost, these instances are designed for fast, random I/O performance that is ideal for no SQL databases like Cassandra and MongoDB. Scale out transactional databases, data warehousing, Hadoop and clustered file systems. d2 instances feature up to 48 terabytes of HDD-based local storage, deliver high disc throughput and offer the lowest price per disc throughput performance on EC2. So, what options to we have for network and storage optimized instances? For applications that benefit from low cost per CPU, you should try compute optimized instances first. For applications that require the lowest cost per gigabyte of memory, use memory optimized instances, the m or c classes. If you're running a database, you should also take advantage of the EBS optimization, or instances that support placement groups. For applications with high inter-node network requirements, you should choose instances that support enhanced networking. Placement groups, are a logical grouping of instances within a single availability zone that offer a low latency, 10 gigabit per second network. You can launch multiple EC2 instances into one placement group. Placement groups can enhance performance of clusters, the EC2 instances must be the same in a placement group, they must also be in the same AZ. Placement groups work with limited instance sizes, they do not support medium instances, for example. For the best performance, you should use instances with enhanced networking. The most common use for placement groups is EC2 instances that host applications requiring low network latency or high network throughput. There is no additional cost for using placement groups with your EC2 instances. Reviewing usage types should be a priority, reserved instances provide a cheaper buy price and will provide better economy as an option in most scenarios. However, you always need to be sure that any proposed instances meet the requirements as described. So let's just quickly review our use cases, Spot Instances suit applications that have flexible start and end times. Perhaps applications that are only going to be feasible if we get a very low compute price, like a large data crunching task that we need the information for, but it's not by a specific date. And Spot Instances really suit those users who have an urgent compute need where they need a lot of additional resource for number crunching or for large database migrations, perhaps. Reserved Instances suit applications with steady state or predictable usage, and they may require reserve capacity to meet demand over a predictable pattern. And one thing that really helps with Reserved Instances is having a clear idea of what that predictable pattern is. So if we've been running an application for a year or two, and we can see that between Monday and Friday, nine to five, we have a certain usage pattern that would make it possible to make an informed decision about making an up front payment to reduce our total computing costs by using a partial or fully up front one year Reserved Instance. And the other family is the On-Demand instances, which suit users who want the low cost and flexibility of EC2 without any up front payments or long term commitments, and that suits just about every use case. Any application with short term, spikey or unpredictable workloads suit On-Demand. Often it's blend of all three that gives you the best optimization, obviously the best flexibility comes from On-Demand, but the pricing difference and the optimization you're able to achieve with Reserved Instances and Spot Instances is well worth considering. Okay, so let's just think this through, let's envisage we've got a, let's say we've got a business app that's been running for a year, it's quite CPU bound. We've been using a fleet of m1.xlarges, we're up to nine presently, just trying to keep up with the current demand. It's likely that the demand is going to double over the next year. So we're thinking, what do we need to buy to keep our application running without maxing out of the 100%, which is what we've been seeing over the last month or two? Inside our fleet, let's say we've got a couple of more compute optimized instances. Let's say a c3.2xlarge, and let's say we bought two of those a month ago, and those are only running at 20% or 30% CPU utilization, compared to the 100% utilization we're getting from the m1.xlarges. So this may be a good opportunity to just shift into less instances, but make those instances compute optimized. And again, it's about making sure that your instance type matches your use case. So once you know that we've got a compute bound application or network bound, or if there's any particular constraint that you're seeing, or pattern that you're seeing, that can really help you shuffle things around. So it may be worth considering reducing the number of m1.xlarges and increasing the number of c3.2xlarges, because they're going to give us quite significantly better compute power. c3.xlarge has eight VCPUs versus four in the m1.xlarge, which equates to 28 units versus eight. So the c3.xlarge has significantly more CPU capacity. So while the actual unit price of the c3.xlarge is more than the m1.xlarge, over time, you're probably going to get a bit of ROI using the larger, more CPU optimized instance. Now if we looked at using Reserved Instances, we could lower our overall costs even further. If we, let's just use this anecdotally, these numbers don't reflect the current pricing. If you are looking at pricing, any solution, you need to check the Amazon Simple Monthly Calculator for the latest pricing. This is just for the sake of our discussion. Let's say that our On-Demand one yearly cost for our c3.2xlarges would equate to $3,689. If we were to use the same performance for a one year all up front Reserved Instance, it would be around $2,170, which would equate to a saving of $1,519, so $1,500 saving over a year. And of course, if we went further out front to a three year partial or all up front commit, we could be looking at saving up to $4,000 over three years. So that's a significant difference, so Reserved price is always going to be, or net us a better result. And another option to blend in here could be Spot Instances. So Spot Instances are perfect for processing that's not time dependent. Generally, the earlier generation machine types are cheaper, the Spot price is determined by demand, so you can do a quick summary report of what the current pricing looks like and what the last, or the trend in pricing is, over the last three months. But Spot pricing can reduce our costs even further, so we might use a blend of two c3.2xlarge RIs one year out front for our day to day processing, we add two c3.2xlarge to our On-Demand Instances to our order scaling group. And then we might also have an option to add one or two Spot Instances to handle regular monthly reports or the like. And that could give us a better result than the nine m1.xlarges that we're currently running. Okay, great, so how do we use Spot Instances with Auto Scaling? When you use Auto Scaling to launch Spot Instances, you set your bid price in the launch configuration. You can't use a single launch configuration to launch both On-Demand Instances and Spot Instances. You can change your bid price, however, you first must create a launch configuration with a new bid price, and then you associate it with your Auto Scaling group. Take note that the existing instances continue to run as long as the bid price specified in the launch configuration used for those instances is higher than the current Spot market price. If the market price for Spot Instances rises above your Spot bid price for a running instance in your Auto Scaling group, EC2 terminates your instance. If your Spot bid price exactly matches the Spot market price, whether you bid is fulfilled depends on a couple of factors, such as whether there is available Spot Instances. Keep in mind that Spot pricing changes frequently, it's based on demand and Spot Instances can be turned off at any point. So a Spot Instance only suits non-time critical processing jobs. You can use the Consolidated Billing feature to consolidate payment for multiple Amazon Web Services accounts, or multiple Amazon International Service accounts within your organization by designating one of them to be the payer account. With Consolidated Billing, you can see a combined view of AWS charges incurred by all accounts, as well as getting a cost report for each individual account associated with your payer account. The major benefit is you get to see things like S3 usage rolled up into one usage amount. How this is set up is quite unique, the payer sends an email request to the payee. So if you're the payer account and you want to link someone else's account, you send an email request to them, they accept the invitation, and then the payee account is added to your payer account. Now consolidated accounts are unrelated to hub and spoke peering or AWS connectivity. So Consolidated Billing is administrative only, it can't share access to other account network connections, for example, and Consolidated Billing doesn't, by default, grant IAM users to the Master account access. So if you consolidated two accounts under your own by inviting your development team manager and your SysOps manager in, you don't necessarily, by default, get to share IAM roles. Now you can do this, but you need to use cross-account roles. So say you have decided to have AWS accounts for your dev, test and production accounts, you have the one Master account, and you plan to link each of the dev, test and production accounts billed to your Master AWS account using Consolidated Billing. But you'd also like a bit more control over these accounts. So you'd like to be able to stop, start or terminate any of the instances in these other develop, test or production accounts. Now the best way to do this would be to create IAM users in the Master account, and then create cross-account roles that have full admin permissions, and then grant the Master account access.