Study guide

Technical reference and lesson notes

Purpose of This Lesson

This lesson provides hands-on practice launching and managing Amazon EC2 instances and Amazon EBS volumes through both the AWS Management Console and the AWS CLI in AWS CloudShell. The main workflow is to select an appropriate software image and hardware profile, configure access, resize an instance, create and attach an EBS volume, prepare it for Linux use, and clean up resources safely.

Key Concepts

Amazon EC2 instance types

An EC2 instance type defines the instance’s hardware profile, including:

vCPUs
Memory
Network configuration
Relative cost

Instance families group hardware profiles by intended workload. For example, compute-optimized instances provide a relatively high CPU-to-memory ratio, while memory-optimized instances provide substantially more memory relative to CPU. Choose the family and size based on workload requirements and observed utilization, not simply on the largest available configuration.

Amazon Machine Images (AMIs)

An AMI provides the software-side starting point for an EC2 instance. It determines the operating system and associated configuration, including the initial volumes attached to the instance. The lab uses the Amazon Linux 2023 64-bit x86 AMI, whose default login user is ec2-user.

The AMI ID is required when launching an instance through the CLI. AMIs and their initial EBS configuration are based on EBS snapshots. Snapshots are also point-in-time backups that can preserve an instance’s data and configuration after custom software, updates, and other changes have been made.

EBS volumes

Amazon EBS provides block storage for EC2. The root EBS volume contains the operating system. Additional EBS volumes can be created independently, attached to an instance, formatted with a filesystem, and mounted at a directory such as /data.

An independently created data volume is not automatically deleted when its EC2 instance is terminated. It must be detached or otherwise released and then deleted manually when it is no longer needed.

EC2 and EBS Lab Workflow

Launching an instance in the console

The core launch decisions are:

Select an AMI, such as Amazon Linux 2023.
Select an instance type, such as the lab’s eligible t2.micro.
Decide whether a key pair is needed. Instance Connect can be used in this lab without attaching a key pair; traditional SSH from a local computer generally requires a key pair and suitable network access.
Select the VPC and subnet or use the default VPC settings.
Select or create a security group.
Review the root storage configuration and launch the instance.

The lab uses an 8 GiB gp3 root volume. The selected security group, named Web Access in the console walkthrough, allows SSH. HTTP access may also be useful for later web-server exercises, but it is not required merely to launch the instance.

Changing an instance type

An EC2 instance must be stopped before its instance type can be changed:

Stop the instance.
Open Actions → Instance settings → Change instance type.
Select the replacement type.
Apply the change.
Start the instance again.

Changing to a smaller type can reduce cost when an instance is underutilized. A larger type may be appropriate when the workload is constrained by available CPU, memory, or another part of the hardware profile.

Stopping and starting also moves the instance to different underlying AWS hardware. This can be useful when AWS reports a hardware issue or schedules maintenance affecting the current host. The operation causes downtime, so it should be treated as an operational change rather than a casual troubleshooting step.

Launching with the AWS CLI

The lab uses AWS CloudShell and the aws ec2 command group. The workflow is:

Obtain the AMI ID for the selected Amazon Linux 2023 image.
Create a security group:

   aws ec2 create-security-group

The lab names the group Storage Labs.

Authorize inbound SSH access on TCP port 22:

   aws ec2 authorize-security-group-ingress

The demonstrated rule allows port 22 from 0.0.0.0/0, meaning any IPv4 source address. This is convenient for the lab but is broadly permissive and should be narrowed in a real environment.

Launch the instance with aws ec2 run-instances, supplying the AMI ID, the t2.micro instance type, the security group ID, and the us-east-1a Availability Zone used by the lab.

The security group ID is returned when the group is created and is then inserted into the launch command. After launch, validate the instance and its security group in the console or with appropriate CLI inspection commands.

Creating and attaching an EBS volume

The lab creates a 10 GiB gp2 EBS volume and tags it with Name=Test volume 1. The volume must be created in the same Availability Zone as the target EC2 instance. An EBS volume in another Availability Zone cannot be attached directly to that instance.

The console workflow is:

Open Elastic Block Store → Volumes.
Create a 10 GiB gp2 volume.
Select the instance’s Availability Zone.
Add the name tag.
Create the volume.
Select the volume and choose Actions → Attach volume.
Select the running instance and a device name.

Only compatible running instances in the same Availability Zone appear as attachment targets. The device name selected in the console does not necessarily appear under exactly the same name inside Linux; Linux applies its own device naming convention. In the lab, the attached device appears as /dev/xvdb.

Preparing the volume inside Linux

Before attachment, lsblk shows the root block device and its partitions, but no additional data disk. After attachment, run a non-loopback block-device listing again:

sudo lsblk

The new device appears as a disk without partitions. The lab then:

Creates a filesystem on the new device.
Creates the mount directory:

   sudo mkdir /data

Mounts the device at /data:

   sudo mount /dev/xvdb /data

Creates a test file on the mounted volume:

   sudo touch /data/test-file.txt

At this point, /data maps to the additional EBS volume rather than the root operating-system volume. Running lsblk again shows the new device mounted at /data.

A manual mount is not automatically persistent across a restart. To make the mount persistent, edit /etc/fstab and add the appropriate filesystem entry for the device and mount point. The lesson demonstrates using sudo nano /etc/fstab to add that entry.

Exam- or Assessment-Relevant Takeaways

The instance type controls the EC2 hardware profile and strongly influences cost; the AMI supplies the operating system and initial software/storage configuration.
To change an EC2 instance type, stop the instance first. A running instance does not permit this change in the demonstrated workflow.
Stopping and starting can relocate an instance to different underlying hardware, which may help address host hardware issues or scheduled maintenance.
An EBS volume and its EC2 instance must be in the same Availability Zone for direct attachment.
An attached EBS device is not immediately usable as a filesystem. It must be prepared, mounted, and optionally configured in /etc/fstab for persistence.
The root volume launched with the instance is removed by default when the instance is terminated in this lab. A separately created and attached data volume remains and requires manual deletion.
Security group ingress on TCP 22 controls SSH access. Allowing 0.0.0.0/0 means SSH is open to any IPv4 source and is a significant exposure outside a controlled lab.

Tool / Feature Decision Guide

Need	Appropriate choice	Decisive reason
Define CPU, memory, network profile, and cost	EC2 instance type	The instance type specifies the hardware configuration.
Define the operating system and initial instance software/storage	AMI	The AMI is the software-side launch template and includes the initial volume configuration.
Launch an identical customized instance later	Customized AMI	Capture the configured operating system, installed software, and relevant instance state as a reusable image.
Create a point-in-time backup	EBS snapshot	Snapshots preserve a point-in-time copy of EBS-backed instance storage.
Add storage independently of the root disk	Separate EBS volume	It can be attached, mounted at a dedicated path, and managed independently.
Change the hardware profile	Stop, change instance type, then start	The demonstrated instance-type change is unavailable while the instance is running.
Log in without attaching a key pair in this lab	EC2 Instance Connect	The walkthrough uses Instance Connect rather than a locally supplied key pair.
Automate resource creation	AWS CLI in CloudShell	Commands such as `create-security-group`, `authorize-security-group-ingress`, and `run-instances` reproduce the setup from the command line.

Common Traps / Misconceptions

AMI and instance type are interchangeable: They are not. The AMI primarily determines the software image; the instance type determines the hardware profile.
An EBS volume can be attached across Availability Zones: It cannot be directly attached to an instance in a different Availability Zone.
Creating an EBS volume makes it usable immediately: The volume still needs a filesystem and a mount point.
A manual mount survives a reboot automatically: It does not. Persistent configuration requires an appropriate /etc/fstab entry.
The console device name is guaranteed to match the Linux device name: Linux may expose the device using its own naming convention, such as /dev/xvdb.
Terminating an instance deletes every attached volume: Independently created data volumes can remain after termination and continue to incur storage costs until deleted.
Stopping an instance always means only downtime: It also causes relocation to different underlying hardware when the instance is started again.
SSH from anywhere is a safe default: 0.0.0.0/0 allows any IPv4 source. It is used in the lab for convenience, not as a generally preferred security posture.

Real-World Engineer / Analyst Notes

Use utilization evidence to right-size instances. Underutilization represents avoidable spend, while overutilization can indicate a need for a larger or differently optimized instance family.
Plan for downtime before stopping an instance for resizing or host remediation.
Keep operating-system storage and application/data storage separate when independent lifecycle management is useful.
Tag volumes at creation time. The lab uses a Name tag, which makes it easier to identify the volume during attachment and cleanup.
Before deleting a volume, confirm whether it contains required data. The lab’s test-file.txt illustrates that data on a separately managed volume is distinct from the root operating system.
Treat broad SSH ingress as temporary lab configuration. Restrict access to known source ranges in operational environments.
Verify the Availability Zone before creating the volume; correcting an AZ mismatch may require recreating the volume or relocating data rather than simply changing an attachment setting.
Clean up both EC2 instances and independently created EBS volumes. Terminating the instance alone is insufficient for the demonstrated data volume.

Quick Reference Summary

Hardware choice: EC2 instance type.
Software/image choice: AMI.
Lab AMI: Amazon Linux 2023, 64-bit x86; default user ec2-user.
Console lab root disk: 8 GiB gp3.
CLI lab security group: Storage Labs.
CLI lab SSH rule: TCP 22 from 0.0.0.0/0.
CLI lab placement: us-east-1a.
Additional data disk: 10 GiB gp2, tagged Test volume 1.
Resize sequence: Stop → change instance type → start.
Storage sequence: Create in the same AZ → attach → inspect with sudo lsblk → create filesystem → mount at /data → configure /etc/fstab if persistence is required.
Cleanup sequence: Terminate the instance, verify the root volume is removed, then detach/delete the separately created EBS volume.

Flashcards

Q: A workload has a high CPU requirement relative to its memory requirement. Which instance-family direction should you investigate, and why?

A: Investigate a compute-optimized family because it provides a relatively high CPU-to-memory ratio. The final size should still be based on measured workload needs and cost.

Q: Which EC2 launch choice determines the hardware profile, and which determines the operating system image?

A: The instance type determines vCPUs, memory, networking, and related hardware characteristics. The AMI determines the operating system and initial software/storage configuration.

Q: You need to reduce the cost of an underutilized EC2 instance by changing its instance type. What sequence should you use?

A: Stop the instance, use Actions → Instance settings → Change instance type, select the replacement, and start the instance again. The type change is not available while the instance is running in the demonstrated workflow.

Q: Why might an operator stop and start an instance even when no resizing is required?

A: Stopping and starting can move the instance to different underlying AWS hardware. This may help when the current host has an issue or AWS has scheduled maintenance affecting it.

Q: When can the lab use Instance Connect without attaching a key pair?

A: The lab uses Instance Connect to log in, so it does not attach a key pair. A conventional SSH connection from a local computer may require a key pair and an appropriate security-group rule.

Q: An EBS volume was created successfully but does not appear as an attachment option for an EC2 instance. What key placement detail should you check first?

A: Check whether the volume and instance are in the same Availability Zone. An EBS volume cannot be directly attached across Availability Zones.

Q: What does sudo lsblk show before and after the additional EBS volume is attached?

A: Before attachment it shows the root disk and its partitions. After attachment it also shows the new disk, which initially has no partitions or mounted filesystem in the lab.

Q: Why is an attached EBS disk not immediately available at /data?

A: Attachment exposes the block device, but the device still needs a filesystem and a mount point. The lab creates a filesystem, creates /data, and mounts /dev/xvdb there.

Q: What is the purpose of mounting /dev/xvdb at /data?

A: It makes the additional EBS volume accessible through /data, keeping its files separate from the root operating-system volume.

Q: What is the operational trap when relying only on sudo mount /dev/xvdb /data?

A: A manual mount is not automatically persistent after a restart. An appropriate entry must be added to /etc/fstab when the mount should return automatically.

Q: Why might the device name selected in the EC2 console differ from the name seen by Linux?

A: Linux applies its own device-naming convention. In the lab, the attached volume is identified inside Linux as /dev/xvdb regardless of the console-side selection.

Q: What is the difference between an EBS snapshot and a customized AMI in this workflow?

A: A snapshot is a point-in-time backup of EBS-backed storage. A customized AMI packages the configured instance state so new instances can be launched with the same operating system, installed software, and customizations.

Q: After terminating the lab instance, which volume requires explicit cleanup?

A: The separately created and attached data volume remains and must be deleted manually. The root operating-system volume is removed by default in the demonstrated cleanup behavior.

Q: What is the security concern with the lab’s authorize-security-group-ingress rule for TCP port 22?

A: A CIDR of 0.0.0.0/0 permits SSH from any IPv4 source. It may simplify a temporary lab but should be restricted in real deployments.

Practice Questions

Question 1

An EC2 instance is consistently underutilized, and the goal is to lower its running cost by selecting a smaller hardware profile. What should the operator do?

A. Change the AMI while the instance is running
B. Stop the instance, change its instance type, and start it again
C. Create an EBS snapshot and attach it to the same instance
D. Change the security-group ingress rule

Correct answer: B

Explanation: The instance type defines the hardware profile and must be changed while the instance is stopped in the demonstrated workflow.

Question 2

A 10 GiB EBS volume was created in us-east-1b, but the target EC2 instance is running in us-east-1a. The volume is not listed as an attachment option. What is the decisive issue?

A. The volume uses gp2 instead of gp3
B. The volume is not encrypted
C. The volume and instance are in different Availability Zones
D. The instance must be terminated first

Correct answer: C

Explanation: Direct EBS attachment requires the volume and target instance to be in the same Availability Zone.

Question 3

An engineer attaches a new EBS volume and can see it in lsblk, but attempts to write application files to it fail because it is not mounted. What should happen next?

A. Replace the AMI
B. Create a filesystem, create a mount directory, and mount the device
C. Change the instance type
D. Authorize HTTP traffic in the security group

Correct answer: B

Explanation: The new device must be prepared with a filesystem and mounted, such as at /data, before it can be used as a normal filesystem.

Question 4

A lab administrator terminates an EC2 instance and assumes all storage-related charges have stopped. A separately created EBS data volume still appears in the account. What action is required?

A. Delete the AMI only
B. Restart the terminated instance
C. Delete the independent EBS volume after confirming its data is no longer needed
D. Change the volume’s Availability Zone

Correct answer: C

Explanation: Independently created and attached data volumes persist after instance termination and must be cleaned up separately.

Question 5

A developer wants an attached EBS volume mounted at /data automatically after a reboot. Which additional configuration is required after the initial manual mount?

A. Add the appropriate mount entry to /etc/fstab
B. Create a second security group
C. Replace the instance’s AMI
D. Move the volume to another Availability Zone

Correct answer: A

Explanation: The lesson identifies /etc/fstab as the configuration used to make the mount persistent across system restarts.

WordPress Metadata

Suggested Slug:
launching-managing-ec2-ebs-volumes

Meta Description:
Study guide to selecting AMIs and instance types, resizing EC2 instances, creating and mounting EBS volumes, using the AWS CLI, and cleaning up lab resources.

Tags:
AWS EC2, Amazon EBS, AMI, EC2 instance types, AWS CLI, CloudShell, EBS snapshots, security groups, Linux storage, Amazon Linux 2023, fstab

Launching and Managing EC2 Instances and EBS Volumes: Console and CLI Lab Guide