What is Amazon Elastic Compute Cloud?

One of the first and most important services you’ll use in Amazon Web Services (AWS) is Amazon Elastic Compute Cloud (EC2) — virtual servers that come in various hardware footprints. Although the RAM and disk footprints are easy to understand, AWS uses the moniker of Elastic Compute Unit (ECU) for the CPU baseline. An ECU equates to a 2007 1.0–1.2 GHz Opteron or Xeon processor — an important fact to keep in mind if you’re trying to match existing server specs to EC2.

EC2s have two aspects to them: the instance type or “hardware footprint” and the Amazon Machine Image (AMI) or “software footprint,” which is the particular OS, applications (like Apache, JBoss or custom PHP or Python code), and all configuration. Instance types and AMIs are independent of each other. You can launch most AMIs into most instance types.

When deciding on an AMI, you definitely want to consult both the community AMI library as well as the AMI marketplace, because there’s a good chance that the exact software you want to deploy exists in one or the other. The only caveat to using either is to carefully vet the provider of the AMI. Make sure it comes from a reputable company or individual you trust.

AMIs from the marketplace are an excellent way to test drive both open-source and commercial software—you can spin up the servers in just a few minutes, use them for as little as an hour, and pay as little as a few pennies. As with nearly all AWS services, there is no up-front cost and you only pay for the hours that the software is kept running. You can also load your own applications and custom code into a base AMI (OS only), and then burn your own AMI, which now contains all your modifications and can be used to spin up exact copies of that server in minutes.

If you’re like most customers, when you start running AWS at scale, you’ll notice that 70 percent or more of your average monthly bill is attributed to EC2 costs alone. To rein in those costs, most customers use a combination of autoscaling (which is completely free and lets you expand and contract your EC2 farms based on real-time user demand) and alternative billing models like reservations and spot.

All AWS services that utilize resizable VMs (like EC2, RDS and Elasticache) can be paid for using “reservations.” A reservation functions a lot like a stock option: You pay an up-front fee for the option (but not obligation) to purchase a given VM for a lower nominal hourly cost than the “no-obligation” on-demand price. If your server demand is well known (reservations are for specific instance types in specific data centers), purchasing a one– or three-year reservation for your “always on” needs can save 30 percent or more over the entire term of the reservation.

A much more advanced use case involves spot instances. With spot instances, you’re bidding on unused EC2 capacity. You put in a bid for a specific instance, and if the spot price goes below your bid, you get the instance. The flip side of that is if the spot price goes above your bid, the instance is taken away from you without warning and given to other customers. Although that constraint makes spot appear unusable, there are many cases where it makes perfect sense: dev and test environments, batch processing architectures and offline data analysis, to name just a few.

It’s worth noting that whether you’re using on-demand, reserved, or spot instances, the underlying server is the exact same; the three billing models only dictate how you pay for that server (and in the case of spot, that it can go away at any time).

A very important aspect of EC2 instances is security. To help you manage security, AWS provides two important tools that you’ll want to use: security groups (SGs) and public/private EC2 key pairs.

AWS SGs can be applied to the same resources that support reserved billing models: EC2, RDS and Elasticache. SGs are point-and-click stateful firewalls that can be defined once and applied to many instances. A single instance can also have one or more SGs applied to it that can be modified at runtime to add and remove access to that server.

Like everything AWS does, SGs are locked down to “no access.” You’ll need to create a new SG (do NOT modify the “default” SG) for at least each tier of your application. Perhaps open port 80 and 443 to the world for the web servers and only port 8080 (from the web server’s SG) on the app tier servers.

In addition to SGs, AWS requires public-private key pairs for at least the first Secure Shell (SSH) access to your EC2 server. It’s highly recommended to leave this key pair authentication on and rotate key pairs at least every two to three months or when an employee leaves the organization.

This is an excerpt from the Global Knowledge white paper Tips and Tricks to Speed AWS Deployment.

Please support our Sponsors here :