over time and between regions.
TABLE 2.2 Pricing estimates comparing on‐demand with reserve costs
| Instance type | Pricing model | Cost/hour | Cost/year |
|---|---|---|---|
| t2.micro | On‐demand | $0.0116 | $102.00 |
| t2.micro | Reserve (three‐year term) | $38.33 | |
| g3.4xlarge | On‐demand | $1.14 | $9986.40 |
| g3.4xlarge | Reserve (three‐year term) | $4429.66 |
For workloads that can withstand unexpected disruption (like computation‐intensive genome research applications), purchasing instances on Amazon's spot market can save you a lot of money. The idea is that you enter a maximum dollar‐value bid for an instance type running in a particular region. The next time an instance in that region becomes available at a per‐hour rate that's equal to or below your bid, it'll be launched using the AMI and launch template you specified. Once up, the instance will keep running either until you stop it—when your workload completes, for example—or until the instance's per‐hour rate rises above your maximum bid. You'll learn more about the spot market and reserve instances in Chapter 13, “The Cost Optimization Pillar.”
It will often make sense to combine multiple models within a single application infrastructure. An online store might, for instance, purchase one or two reserve instances to cover its normal customer demand but also allow autoscaling to automatically launch on‐demand instances during periods of unusually high demand.
Use Exercise 2.3 to dive deeper into EC2 pricing.
Assess Which Pricing Model Will Best Meet the Needs of a Deployment
Imagine that your application will need to run two always‐on f1.2xlarge instances (which come with instance storage and won't require any EBS volumes). To meet seasonal demand, you can expect to require as many as four more instances for a total of 100 hours through the course of a single year. How should you pay for this deployment?
Bonus: Calculate your total estimated monthly and annual costs.
Instance Lifecycle
The state of a running EC2 instance can be managed in a number of ways. Terminating the instance will shut it down and cause its resources to be reallocated to the general AWS pool.
If your instance won't be needed for some time but you don't want to terminate it, you can save money by simply stopping it and then restarting it when it's needed again. The data on an EBS volume will in this case not be lost, although that would not be true for an instance volume.
Later in this chapter, you'll learn about both EBS and instance store volumes and the ways they work with EC2 instances.
You should be aware that a stopped instance that had been using a nonpersistent public IP address will most likely be assigned a different address when it's restarted. If you need a predictable IP address that can survive restarts, allocate an elastic IP address and associate it with your instance.
You can edit or change an instance's security group (which we'll discuss a bit later in this chapter) to update access policies at any time—even while an instance is running. You can also change its instance type to increase or decrease its compute, memory, and storage capacity (just try doing that on a physical server). You will need to stop the instance, change the type, and then restart it.
Resource Tags
The more resources you deploy on your AWS account, the harder it can be to properly keep track of things. Having constantly changing numbers of EC2 instances—along with accompanying storage volumes, security groups, and elastic IP addresses—all spread across two or three VPCs can get complicated.
The best way to keep a lid on the chaos is to find a way to quickly identify each resource you've got running by its purpose and its relationships to other resources. The best way to do that is by establishing a consistent naming convention and applying it to tags.
AWS resource tags can be used to label everything you'll ever touch across your AWS account—they're certainly not restricted to just EC2. Tags have a key and, optionally, an associated value. So, for example, you could assign a tag with the key production‐server to each element of a production deployment. Server instances could, in addition, have a value of server1, server2, and so on. A related security group could have the same production‐server key but security‐group1 for its value. Table 2.3 illustrates how that convention might play out over a larger deployment group.
TABLE 2.3 A sample key/value tagging convention
| Key | Value |
|---|---|
production‐server
|
server1
|
production‐server
|
server2
|
production‐server
|
security‐group1
|
staging‐server
|
server1
|
staging‐server
|
server2
|
staging‐server
|
security‐group1
|
test‐server
|
server1
|
test‐server
|
