EC2 instance types
Image types are just one side of the EC2 coin. You also have to consider instance types — the types of virtual machines you can run in AWS. Instances vary by the amount of three types of compute resources:
✓ Processing power: Every instance has a certain number of EC2 compute units (ECU), which is a bench marked amount of processing power (the equivalent of the CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor). For example, the small instance in AWS has 1 EC2 computeunit, or 1 ECU.
✓ Memory: Every instance contains a given amount of memory, measured in gigabytes. A small instance has 1.7GB of memory.
✓ Storage: Every instance has a certain amount of disk storage. A small instance has 170GB of disk storage. Depending on the instance type, some of the disk storage associated with an instance may be provided in unformatted form — before it can be used, it must be formatted with a file system that’s usable by the operating system of the instance.
✓ Network connectivity: Every instance comes supplied with one virtual network interface card (NIC), which it uses to communicate with other devices or services. Every instance is given two IP addresses: one private address that’s used solely within AWS and one public address that’s used for Internet access to the instance. Not all instance types get only one NIC. Instances within the AWS VirtualPrivate Cloud (VPC) can have more than one NIC.
Description of the instance types:
✓ Micro: Very, very small; provides a limited amount of both CPU and memory, although Micro instance types can burst to 2 ECU for shortperiods. Use this type for lower-throughput applications and low-traffic websites. The Micro type is also available as part of the AWS Free UsageTier, which is useful for learning and experimentation.
✓ Standard: The “average” type and by far the most widely used; offers a balance of CU, memory, and disk that’s suitable for main stream applications.
✓ High CPU: Goes for higher CUs rather than memory and is well suited for processing-heavy applications. A number-crunching application is the canonical use case for high-CPU instances.
✓ High Memory: Bumps up memory rather than CPU. This type is well suited for database apps, analytics apps, and apps that rely on memory caching. If you run a caching tier product like memcached, this instance type is a good choice.
✓ High I/O: Provides high-throughput (input + output — I/O, in otherwords) and is well suited for applications that move a lot of data. It’sa good choice for running your own key-value storage service, like Cassandra or MongoDB, rather than using AWS’s DynamoDB service. High-I/O instances have high throughput connections (10 Gbps) and use solid-state drives to provide high disk performance.
✓ Cluster Compute: Provides a large number of ECUs along with highperformance networking (10 Gbps). This instance type, which is well suited for high-performance computing tasks (very large applicationsfor specialized number crunching, like oil field seismic analysis), runs on specialized hardware, with custom AMIs that use a different, more efficient type of virtualization as well as closely connected machines for better network performance.
✓ Cluster GPU: Analogous to Cluster Compute instances, but uses graphical processing units (think of the processor inside the graphics cardon your PC, if you’re a gamer) that are better suited for certain types of applications, including certain variants of high-performance computing (HPC) network analysis. Cluster GPU instances operate similarly to Cluster Compute instances, albeit with different CPU chips in the servers these instances run on.
EC2 image sizes
The original instance type (Standard) aims for a good mixture of resources to meet the requirements of, well, standard applications. The other instance types contain a larger amount of one type of resource in terms of the other resource types of the instance; one particular instance type can then better support a particular set of application requirements than another.
EC2 scope
Why would you want your instances to run in multiple regions?
✓ As protection against failure in an AWS availability zone (AZ) or region: If AWS suffered an outage in one portion of its service area, you can continue to operate your application in another availability zone orregion.
✓ To reduce latency when serving users located in specific geographicregions: By placing instances in, say, the Australia-based Asia Pacific region, you would reduce overall network transit time to users located nearby.
✓ So that you can operate a multiregion application to ensure the best possible performance to a user base spread throughout the world: Inaddition to the need to manage images in multiple locations, you may take advantage of two other AWS services: Route 53: Amazon’s distributed DNS service CloudFront: Amazon’s S3-based content delivery network
✓ To comply with national requirements for data privacy: Some countries impose restrictions on the locations where data related to their citizens or businesses resides. You may choose to run your applicationin multiple regions to comply with these restrictions.
EBS-backed images can be launched in any availability zone within the region where the image resides; this is different from the general EBS scoping limitation, which restricts the use of an EBS volume to the availability zone in which it’s located.
EC2 pricing and deployment options
In addition to the different types and sizes of the EC2 offerings, EC2 offers three deployment options. To say it another way, you can pay a different hourly rate for the same type and size instance, depending on how you choose to deploy it. Each deployment option affects pricing:
✓ On-demand: You start these instances when you choose. Here, you pay the standard rate for every hour they run.
✓ Reserved: You pay an upfront fee for these instances and in return receive a reduced rate for every hour they run.
✓ Spot: You offer a bid price for these instances — a price you’re willing to pay for every hour they run. Amazon runs a reverse auction for spare EC2 capacity and runs every spot instance for which bids have been received that meet or exceed the spot instance “clearing” price.
On-demand instances
The on-demand instance is the most straight forward deployment option: You choose when you want the instance to run, and AWS guarantees to run it at astandard, documented rate per hour. The default limitation is 20 instances per account, but the companyprovides an easy way to request additional instances and, to my knowledge,has never failed to offer more, if requested.
On-demand pricing varies according to instance type, size, and region. Microinstances, are available for free to a certain usage level: for the first year of a new account, users receive 750 hoursof Linux/Unix and 750 hours of Windows Micro instance use per month. After that, Micro instances cost $.02 to $.027 per hour, depending on which region the instance runs in. Other instance types and sizes range from M1.small, which runs from $.065 per hour (in the US East region) to $.115 per hour (South America São Paulo) to High I/O, Quadruple Extra Large, which ranges from $3.10 per hour (US East region) to $3.40 per hour (EU Ireland).
Reserved instances
Another instance-pricing option that Amazon provides is reserved instances. In essence, in exchange for a customer making an upfront financial payment, Amazon offers a lower hourly rate for instances. The term for reserved instance pricing can run either one or three years. The overall discount you receive depends on how many hours you run the instance, because you have to amortize the upfront payment across all the hours that you run the reserved instance at the lower price.
Spot-priced instances
Amazon also offers a deployment option called spot-priced instances, which allows AWS users to bid on unused AWS capacity to run their applications. If the spot-price is below the amount you’ve bid, don’t worry: You pay only the current spot-price. If the current spot-price for M1.Small is only $.01 perhour, for example, you pay that rate, not your $.02 bid.
Know the maximum price you’re willing to pay to run your spot-price instance, and bid only that price. During the holiday season in 2011, a time of high demand and low spot-price availability, a number of users who had thoughtlessly placed maximum bids of $99 per hour were blindsided when the spot-price matched their bids. Needless to say, most of them were unhappy because their applications weren’t critical at that price. Be sure to only bid the maximum amount you’re willing to pay for a spot instance.
When the spot-price increases beyond your bid, your instance is terminatedimmediately, which raises some obvious flags:
✓ Your application may be in the middle of performing work, even atransaction.
✓ If your spot-price instance is S3-backed, any data in the file system islost upon termination.
✓ If your spot-price instance is EBS-backed, it still loses any data that’splaced in the file system post-launch. Put another way, EBS-backed spotin stances are terminated, not stopped, and are launched, not started.
✓ Even if your application is architected to manage this kind of possible interruption, it still needs to be the kind of application that can handle having instances terminated at any time. Don’t run your company’s website running on spot-price instances.
On the other hand, according to Amazon, only about 4 percent of all spot-price instances are ever terminated unexpectedly, so the odds of your application running into problems because of termination are fairly low.There are some powerful arguments in favor of using spot-price instances:
✓ They can be quite cost effective. They’re typically offered at 50-percentto 66-percent discounts from the associated on-demand instance cost.
✓ For applications that don’t need to be always running, using them canbe a good approach. For example, if your application needs to processimages sometime during the next seven days, using spot-price instances would be a cost-effective approach with little downside.
✓ They can make a great deal of sense when combined with other instance payment options. You may want to have a certain amount of image processing capacity at all times (which is a good use case for reserved instances) but occasionally use additional capacity to workthrough any possible backlog (which is a good use case for spot-price instances).Spot-price instances are undoubtedly the least-often-used of the three instance deployment options, but this option provides real benefits because it offers the financial savings associated with reserved instances, matched bythe lack of commitment associated with on-demand instances.
