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 (Non‐Volatile Memory Express) 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, “AWS Storage.”
The bottom line is that EBS volumes are likely to be the right choice for instances whose data needs to persist beyond a reboot and for working with custom or off‐the‐shelf AMIs. Instance store volumes are, where available, useful for operations requiring low‐latency access to large amounts of data that needn't survive a system failure or reboot. And non‐EC2 storage can work well when you don't need fantastic read/write speeds, but you wish to enjoy the flexibility and cost savings of S3.
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.
TABLE 2.5 The three IP address ranges used by private networks
| From | To |
|---|---|
| 10.0.0.0 | 10.255.255.255 |
| 172.16.0.0 | 172.31.255.255 |
| 192.168.0.0 | 192.168.255.255 |
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 connection 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 noted in the instance lifecycle discussion, the default public IP assigned to your instance is ephemeral and probably won't survive a reboot. Therefore, 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
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
Securing Your EC2 Instance
You are responsible for configuring appropriate and effective access controls to protect your EC2 instances from unauthorized use. Broadly speaking, AWS provides four tools to help you with this task: security groups, Identity and Access Management (IAM) roles, network address translation (NAT) instances, and key pairs.
Security Groups
An EC2 security group plays the role of a firewall. By default, a security group will deny all incoming traffic while permitting all outgoing traffic. You define group behavior by setting policy rules that will either block or allow specified traffic types. From that point on, any data packet coming into or leaving the perimeter will be measured against those rules and processed accordingly.
Traffic is assessed by examining its source and destination, the network port it's targeting, and the protocol it's set to use. A TCP packet sent to the SSH port 22 could, for example, only be allowed access to a particular instance if its source IP address matches the local public IP used by computers in your office. This lets you open up SSH access on your instance without having to worry about anyone from outside your company getting in.
Using security groups, you can easily create sophisticated rule sets to finely manage access to your services. You could, say, open up a website to the whole world while blocking access to your backend servers for everyone besides members of your team.
If necessary, you can update your security group rules and/or apply them to multiple instances.
IAM Roles
You can also control access to AWS resources—including EC2 instances—through the use of IAM roles. You define an IAM role by giving it permissions to perform actions on specified services or resources within your AWS account.
