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.
This will, in most cases, destroy all data kept on the primary storage. The exception to this would be an Elastic Block Store (EBS) volume that has been set to persist after its instance is terminated.
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 I’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—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.
Also read this topic: Introduction to Cloud Computing and AWS -1
Service Limits
By default, each AWS account has limits to the number of instances of a particular service you’re able to launch. Sometimes those limits apply to a single region within an account, and others are global. If necessary, you can request AWS to raise your ceiling for a particular service. As examples, you’re allowed only five VPCs per region and 5,000 key pairs across your account. You can find up-to-date details regarding the limits of all AWS services at https://docs .aws.amazon.com/general/latest/gr/aws_service_limits.html.
EC2 Storage Volumes
Storage drives (or volumes as they’re described in AWS documentation) are for the most part virtualized spaces carved out of larger physical drives. To the OS running on your instance, though, all AWS volumes will present themselves exactly as though they were normal physical drives. But there’s actually more than one kind of AWS volume, and it’s important to understand how each type works.
Elastic Block Store Volumes
You can attach as many Elastic Block Store (EBS) volumes to your instance as you like and use them just as you would as you would hard drives, flash drives, or USB drives with your physical server. And as with physical drives, the type of EBS volume you choose will have an impact on both performance and cost. The AWS SLA guarantees the reliability of the data you store on its EBS volumes (promising at least 99.999 percent availability), so you don’t have to worry about failure. When an EBS drive does fail, its data has already been duplicated and will probably be brought back online before anyone notices a problem. So, practically, the only thing that should concern you is how quickly and efficiently you can access your data. There are currently four EBS volume types, two using solid-state drive (SSD) technologies and two using the older spinning hard drives (HDDs). The performance of each volume type is measured in maximum IOPS/volume (where IOPS means input/output operations per second).
EBS-Provisioned IOPS SSD
If your applications will require intense rates of I/O operations, then you should consider provisioned IOPS, which provides a maximum IOPS/volume of 32,000 and a maximum throughput/volume of 500 MB/s. Provisioned IOPS—which in some contexts is referred to as EBS Optimized—can cost $0.125/GB/month in addition to $0.065/provisioned IOPS.
EBS General-Purpose SSD
For most regular server workloads that, ideally, deliver low-latency performance, general-purpose
SSDs will work well. You’ll get a maximum of 10,000 IOPS/volume, and it’ll cost you $0.10/GB/month. For reference, a general-purpose SSD used as a typical 8 GB boot drive for a Linux instance would, at current rates, cost you $9.60/year.
Throughput-Optimized HDD
Throughput-optimized HDD volumes can provide reduced costs with acceptable performance where you’re looking for throughput-intensive workloads including log processing and big data operations. These volumes can deliver only 500 IOPS/volume but with a 500 MB/s maximum throughput/volume, and they’ll cost you only $0.045/GB/month.
Cold HDD
When you’re working with larger volumes of data that require only infrequent access, a 250 IOPS/volume type might meet your needs for only $0.025/GB/month.
EBS Volume Features
All EBS volumes can be copied by creating a snapshot. Existing snapshots can be used to generate other volumes that can be shared and/or attached to other instances or converted to images from which AMIs can be made. You can also generate an AMI image directly from a running instance-attached EBS volume—although, to be sure no data is lost, it’s best to shut down the instance first.
EBS volumes can be encrypted to protect their data while at rest or as it’s sent back and forth to the EC2 host instance. EBS can manage the encryption keys automatically behind the scenes or use keys that you provide through the AWS Key Management Service (KMS).
Exercise 2.4 will walk you through launching a new instance based on an existing snapshot image.
Exercise 2 . 4
Create and Launch an AMI Based on an Existing Instance Storage Volume
- If necessary, launch an instance and make at least some token change to the root volume. This could be something as simple as typing touch test.txt on a Linux instance to create an empty file.
- Create an image from the instance’s volume (you’ll access the dialog through the Actions pull-down menu in the Instances Dashboard).
- Launch an instance from the console and select the new AMI from the My AMIs tab.
- Log into the instance and confirm that your previous change has persisted.
Instance Store Volumes
Unlike EBS volumes, instance store volumes are ephemeral. This means that when the instances they’re attached to are shut down, their data is permanently lost. So, why would you want to keep your data on an instance store volume more than on EBS?
■■ Instance store volumes are SSDs that are physically attached to the server hosting your instance and are connected via a fast NVMe interface.
■■ The use of instance store volumes is included in the price of the instance itself.
■■ Instance store volumes work especially well for deployment models where instances are launched to fill short-term roles (as part of autoscaling groups, for instance), import data from external sources, and are, effectively, disposable.
Whether one or more instance store volumes are available for your instance will depend on the instance type you choose. This is an important consideration to take into account when planning your deployment.
Even with all the benefits of EBS and instance storage, it’s worth noting that there will be cases where you’re much better off keeping large data sets outside of EC2 altogether. For many use cases, Amazon’s S3 service can be a dramatically less expensive way to store files or even databases that are nevertheless instantly available for compute operations. You’ll learn more about this in Chapter 3, “Amazon Simple Storage Service and Amazon Glacier Storage.”
Accessing Your EC2 Instance
Like all networked devices, EC2 instances are identified by unique IP addresses. All instances
are assigned at least one private IPv4 address that, by default, will fall within one of the blocks shown in Table 2.5.
Out of the box, you’ll only be able to connect to your instance from within its subnet, and the instance will have no direct contact to the Internet. If your instance configuration calls for multiple network interfaces (to connect to otherwise unreachable resources), you can create and then attach one or more virtual Elastic Network Interfaces to your instance. Each of these interfaces must be connected to an existing subnet and security group. You can optionally assign a static IP address within the subnet range. Of course, an instance can also be assigned a public IP through which full Internet access is possible. As you learned earlier as part of the instance lifecycle discussion, the
default public IP assigned to your instance is ephemeral and probably won’t survive a reboot. Therefore, as mentioned, you’ll usually want to allocate a permanent elastic IP for long-term deployments. As long as it’s attached to a running instance, there’s no charge for elastic IPs.
I’ll talk about accessing an instance as an administrator a bit later within the context of security. But there’s a lot you can learn about a running EC2 instance—including the IP addresses you’ll need to connect—through the instance metadata system. Running the following curl command from the command line while logged into the instance will return a list of the kinds of data that are available:
$ curl http://169.254.169.254/latest/meta-data/
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
hostname
instance-action
instance-id
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
You’ll use the 169.254.169.254 IP for the command no matter what your
instance public or private IPs happen to be.
Entries ending with a trailing slash ( / ) contain further sublevels of information that can also be displayed by curl . Adding a data type to that curl command will then return the information you’re after. This example displays the name of the security groups used by the instance:
$ curl http://169.254.169.254/latest/meta-data/ security-groups launch-wizard-1
People also ask this Questions
- What is a defense in depth security strategy how is it implemented?
- What is AWS Solution Architect?
- What is the role of AWS Solution Architect?
- Is AWS Solution Architect easy?
- What is AWS associate solutions architect?
- Is AWS Solutions Architect Associate exam hard?
Infocerts, 5B 306 Riverside Greens, Panvel, Raigad 410206 Maharashtra, India
Contact us – https://www.infocerts.com
