Lab: EBS Storage Management
Lab Objective
In this lab, you will learn to manage EBS storage: creating volumes, attaching to instances, snapshots, and management best practices. This is an exercise in analysis and documentation.
Educational Approach
This lab combines theory and scenario analysis. You will document your answers and justifications.
Part 1: Fundamental Concepts
Reminder of EBS Volume Types
┌─────────────────────────────────────────────────────────────┐
│ EBS VOLUME TYPES │
├─────────────────────────────────────────────────────────────┤
│ │
│ TYPE │ USAGE │ IOPS │ COST │
│ ─────────────┼───────────────────┼───────────┼────────────│
│ gp3 │ General purpose │ 3,000-16K │ $0.08/GB │
│ gp2 │ General purpose │ 3,000 max │ $0.10/GB │
│ io2 │ I/O intensive │ 64,000 │ $0.125/GB │
│ st1 │ Big data, logs │ 500 │ $0.045/GB │
│ sc1 │ Cold archives │ 250 │ $0.025/GB │
│ │
│ Recommendation for beginners: │
│ • gp3 for all general use │
│ • st1 for logs/sequential data │
│ │
└─────────────────────────────────────────────────────────────┘
Exercise 1.1: Choosing the Volume Type
For each scenario, choose the appropriate EBS volume type and justify:
| Scenario | Your Choice | Justification |
|---|---|---|
| MySQL production database | ? | ? |
| Application logs (100GB) | ? | ? |
| Static web server | ? | ? |
| High-frequency trading application | ? | ? |
| Document archives (rarely accessed) | ? | ? |
💡 Solutions
| Scenario | Choice | Justification |
|---|---|---|
| MySQL production database | io2 | High and consistent IOPS needed |
| Application logs (100GB) | st1 | Sequential access, cost-optimized |
| Static web server | gp3 | Good cost/performance balance |
| High-frequency trading application | io2 | Critical minimal latency |
| Document archives | sc1 | Rare access, minimal cost |
Part 2: EBS Volume Lifecycle
Lifecycle Diagram
┌─────────────────────────────────────────────────────────────┐
│ EBS VOLUME LIFECYCLE │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ │
│ │ Create │ │
│ │ Volume │ │
│ └──────┬──────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ State: │ │ Attach │ │
│ │ available │───────►│ to EC2 │ │
│ └─────────────┘ └──────┬──────┘ │
│ ▲ │ │
│ │ ▼ │
│ ┌──────┴──────┐ ┌─────────────┐ │
│ │ Detach │◄───────│ State: │ │
│ │ from EC2 │ │ in-use │ │
│ └─────────────┘ └──────┬──────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ Snapshot │ │
│ │ (backup) │ │
│ └─────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ Delete │ │
│ │ Volume │ │
│ └─────────────┘ │
│ │
│ ⚠️ Warning: Deleting a volume erases all data! Always │
│ take a snapshot first. │
│ │
└─────────────────────────────────────────────────────────────┘
Exercise 2.1: CLI Commands
Match each action to the correct CLI command:
| Action | Command |
|---|---|
| Create a 100GB volume | ? |
| List all volumes | ? |
| Attach a volume to an instance | ? |
| Create a snapshot | ? |
| Detach a volume | ? |
💡 Solutions
# Create a 100GB volume
aws ec2 create-volume \
--size 100 \
--volume-type gp3 \
--availability-zone us-east-1a
# List all volumes
aws ec2 describe-volumes
# Attach a volume to an instance
aws ec2 attach-volume \
--volume-id vol-xxx \
--instance-id i-xxx \
--device /dev/sdf
# Create a snapshot
aws ec2 create-snapshot \
--volume-id vol-xxx \
--description "Backup before maintenance"
# Detach a volume
aws ec2 detach-volume --volume-id vol-xxx
Part 3: Practical Scenarios
Scenario A: Capacity Increase
Context: The root volume of your database server (20GB) is almost full (95%). You need to increase the capacity to 50GB without downtime.
Questions:
- What method would you use?
- What are the steps?
- Is there a risk of data loss?
💡 Scenario A Solution
Method: Volume Modification (EBS Elastic Volumes)
AWS allows you to modify the size of an EBS volume on the fly (without stopping the instance)!
Steps:
- Create a snapshot (precaution)
aws ec2 create-snapshot --volume-id vol-xxx --description "Before resize"
- Modify the volume size
aws ec2 modify-volume --volume-id vol-xxx --size 50
- Monitor the modification
aws ec2 describe-volumes-modifications --volume-id vol-xxx
# Wait for the state to be "completed"
- Extend the file system (on the instance)
# For ext4
sudo resize2fs /dev/xvda1
# For XFS
sudo xfs_growfs /
Risks:
- Minimal if snapshot taken before
- Volume remains accessible during modification
- File system extension is instantaneous
Scenario B: Data Migration
Context: You need to migrate a MySQL database from one EC2 instance (us-east-1a) to another instance in a different AZ (us-east-1b).
Questions:
- Can you simply detach and reattach the volume?
- What is the correct procedure?
- How to minimize downtime?
💡 Scenario B Solution
Answer 1: NO! An EBS volume can only be attached to instances in the same AZ.
Correct Procedure:
- Stop MySQL properly (minimize in-flight data)
sudo systemctl stop mysql
- Create a snapshot of the volume
aws ec2 create-snapshot --volume-id vol-xxx --description "Migration"
- Create a new volume from the snapshot in the new AZ
aws ec2 create-volume \
--snapshot-id snap-xxx \
--availability-zone us-east-1b \
--volume-type gp3
- Attach the new volume to the new instance
aws ec2 attach-volume \
--volume-id vol-new \
--instance-id i-new \
--device /dev/sdf
- Mount and start MySQL
sudo mount /dev/sdf /var/lib/mysql
sudo systemctl start mysql
Minimize downtime:
- Prepare the new instance in advance
- Use MySQL replication before migration
- Perform migration during a maintenance window
Scenario C: Recovery after Incident
Context: A developer accidentally deleted important files on a volume. The volume is 200GB and the last backup was yesterday.
Questions:
- How to recover the files?
- What is the procedure if the snapshot exists?
- How to prevent this problem in the future?
💡 Scenario C Solution
Recovery via Snapshot:
- Identify the most recent snapshot
aws ec2 describe-snapshots \
--filters "Name=volume-id,Values=vol-xxx" \
--query 'Snapshots[*].[SnapshotId,StartTime]' \
--output table
- Create a new volume from the snapshot
aws ec2 create-volume \
--snapshot-id snap-xxx \
--availability-zone us-east-1a \
--volume-type gp3
- Attach the recovery volume
aws ec2 attach-volume \
--volume-id vol-recovery \
--instance-id i-xxx \
--device /dev/sdg
- Mount and copy the missing files
sudo mkdir /mnt/recovery
sudo mount /dev/sdg /mnt/recovery
cp /mnt/recovery/path/to/files /path/to/restore/
- Clean up after recovery
sudo umount /mnt/recovery
aws ec2 detach-volume --volume-id vol-recovery
aws ec2 delete-volume --volume-id vol-recovery
Prevention:
- Automatic snapshots with Amazon Data Lifecycle Manager
- Regular backups (hourly for critical data)
- Restrictive permissions (IAM) to avoid accidental deletions
- Versioning for S3 if applicable
Part 4: Best Practices
EBS Management Checklist
┌─────────────────────────────────────────────────────────────┐
│ EBS BEST PRACTICES CHECKLIST │
├─────────────────────────────────────────────────────────────┤
│ │
│ SNAPSHOTS AND BACKUPS │
│ ☐ Automatic snapshots configured (DLM) │
│ ☐ Defined retention (7 days min for prod) │
│ ☐ Snapshots tested (restoration validated) │
│ ☐ Cross-region snapshots for DR │
│ │
│ PERFORMANCE │
│ ☐ Volume type suited to usage │
│ ☐ Provisioned IOPS if necessary (io2) │
│ ☐ CloudWatch monitoring enabled │
│ ☐ Alerts on usage > 80% │
│ │
│ SECURITY │
│ ☐ Encryption enabled (AES-256) │
│ ☐ KMS keys properly managed │
│ ☐ Restrictive IAM permissions │
│ │
│ COSTS │
│ ☐ Unused volumes deleted │
│ ☐ Old snapshots cleaned │
│ ☐ gp3 type preferred over gp2 (better cost ratio) │
│ │
│ TAGS │
│ ☐ Descriptive name │
│ ☐ Environment (prod/dev/test) │
│ ☐ Associated application │
│ ☐ Owner/team │
│ │
└─────────────────────────────────────────────────────────────┘
Data Lifecycle Manager (DLM)
┌─────────────────────────────────────────────────────────────┐
│ AMAZON DATA LIFECYCLE MANAGER │
├─────────────────────────────────────────────────────────────┤
│ │
│ Automates EBS snapshots │
│ │
│ Example policy: │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Name: daily-backup-policy │ │
│ │ │ │
│ │ Target: Volumes with tag "Backup=true" │ │
│ │ │ │
│ │ Schedule: │ │
│ │ • Frequency: Every day at 03:00 UTC │ │
│ │ • Retention: 7 snapshots (1 week) │ │
│ │ │ │
│ │ Options: │ │
│ │ • Cross-region copy: us-west-2 │ │
│ │ • Tags copied: Yes │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ CLI Configuration: │
│ aws dlm create-lifecycle-policy \ │
│ --description "Daily EBS backup" \ │
│ --state ENABLED \ │
│ --execution-role-arn arn:aws:iam::xxx:role/dlm-role \ │
│ --policy-details file://policy.json │
│ │
└─────────────────────────────────────────────────────────────┘
Part 5: Deliverable
Document to Produce
Create an "EBS Management Plan" document for a fictional application with:
-
Volume Inventory (table)
- Name, size, type, AZ, attached instance
-
Snapshot Policy
- Frequency by environment
- Retention
- Restoration tests
-
Documented Procedures
- Capacity increase
- Inter-AZ migration
- Recovery after incident
-
Monthly Cost Estimate
- Volumes
- Snapshots
- Provisioned IOPS (if applicable)
Evaluation Criteria
| Criterion | Points |
|---|---|
| Exercises 1-3 correctly completed | /40 |
| Volume inventory | /15 |
| Clear snapshot policy | /15 |
| Well-documented procedures | /20 |
| Cost estimate | /10 |
| Total | /100 |
Summary
| Concept | Key Points |
|---|---|
| Volume Types | gp3 by default, io2 for IOPS |
| Snapshots | Incremental, stored on S3 |
| AZ Constraint | Volume = 1 AZ only |
| Migration | Via snapshot + new volume |
| DLM | Backup automation |
Return: MODULE 4 Overview