### Slide 1:

![Slide 1](slide_1.png)

::: Notes


#### Instructor notes

#### Student notes

:::

### Slide 2:

![Slide 2](slide_2.png)

::: Notes


#### Instructor notes

#### Student notes

:::

### Slide 3:

![Slide 3](slide_3.png)

::: Notes

This scenario shifts focus to storage optimization as a cost management exercise: as cloud usage grows, unoptimized storage choices become a significant and often invisible cost driver. The requirement to classify data, establish lifecycle rules, and plan for backup and recovery reflects three distinct storage concerns — cost, compliance, and recoverability. Ask students to consider what data classification schemes they've encountered and how they would determine which storage tier is appropriate for each class.

#### Instructor notes

#### Student notes

As costs for cloud resources climb, you are asked to develop a plan to *optimize data storage* and data lifecycle management. This plan must include classifying data. You also need to establish lifecycle storage rules according to the data classification and plan for backup and recovery scenarios.

:::

### Slide 4:

![Slide 4](slide_4.png)

::: Notes


#### Instructor notes

#### Student notes

:::

### Slide 5:

![Slide 5](slide_5.png)

::: Notes


#### Instructor notes

#### Student notes

:::

### Slide 6:

![Slide 6](slide_6.png)

::: Notes

Instance store provides the highest-performance local storage available on EC2, but it's ephemeral: data is lost when the instance stops, terminates, or fails. This makes it unsuitable for persistent data, but ideal for workloads that need fast temporary storage and manage durability themselves — distributed systems that replicate data across multiple instances, caching layers, or temporary processing scratch space. The critical constraint is that instance store volumes cannot be detached or reattached, and they cannot be resized independently of the instance type.

#### Instructor notes

#### Student notes

An Amazon Elastic Compute Cloud (Amazon EC2) *instance store* provides temporary block-level storage for your instance. This storage is located on disks that are physically attached to the host computer. Instance store is ideal for temporary storage of information that changes frequently, such as buffers, caches, scratch data, swap files, pagefiles, and other temporary content. Instance store is also ideal for data that is replicated across a fleet of instances, such as a load balanced pool of web servers. An instance store consists of one or more instance store volumes exposed as block devices. The size of an instance store and the number of devices available varies by instance type. Although an instance store is dedicated to a particular instance, the disk subsystem is shared among instances on a host computer. For more information, see "Amazon EC2 Instance Store" in the Amazon EC2 User Guide for Linux Instances (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html).

:::

### Slide 7:

![Slide 7](slide_7.png)

::: Notes

Storage-optimized EC2 instances with NVMe interfaces provide significantly higher IOPS and lower latency than SATA-based instances because NVMe connects storage directly to the PCIe bus, bypassing the traditional storage controller bottleneck. Workloads that are storage I/O limited — high-frequency transaction processing, large-scale sorting, or log analytics — should be matched to storage-optimized instance types that use NVMe interfaces for maximum throughput. Understanding the interface type helps students make informed instance type selections based on workload I/O characteristics.

#### Instructor notes

#### Student notes

Some EC2 instance types can take

advantage of a further performance boost over traditional storage by
using the non-volatile memory express (NVMe) storage interface. Other
EC2 instance types rely on the more traditional Serial ATA (SATA)
storage-drive interface. Instance types that can take advantage of the
higher-performance interface include those in the storage-optimized EC2
instance type. For more information, see "Storage Optimized Instances"
in the Amazon EC2 User Guide for Linux Instances
(https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/storage-optimized-instances.html).

:::

### Slide 8:

![Slide 8](slide_8.png)

::: Notes


#### Instructor notes

#### Student notes

:::

### Slide 9:

![Slide 9](slide_9.png)

::: Notes

EBS volumes are the primary persistent block storage option for EC2 and are the key difference between instance store and durable storage: EBS volumes persist independently of the instance lifecycle. Volumes exist within a single Availability Zone, which means AZ selection is a design constraint — an EBS volume can only be attached to an instance in the same AZ. Multi-Attach extends this to allow concurrent access from multiple instances in the same AZ, which enables shared-disk cluster architectures.

#### Instructor notes

#### Student notes

Amazon Elastic Block Store (Amazon EBS) provides block-level storage volumes for use with Amazon EC2 instances. Amazon EBS volumes are highly available and reliable storage volumes that can be attached to any running instance in the same Availability Zone. EBS volumes that are attached to an EC2 instance are exposed as storage volumes that persist independently from the life of the instance. To allow a volume to be concurrently attached to multiple EC2 instances, enable the Multi-Attach option. For more information, see "What's the Difference Between an Instance Store and an EBS Volume?" in the AWS Knowledge Center (https://aws.amazon.com/premiumsupport/knowledge-center/instance-store-vs-ebs/).

:::

### Slide 10:

![Slide 10](slide_10.png)

::: Notes

Choosing the right EBS volume type requires understanding the workload's I/O profile: is the bottleneck the number of I/O operations per second (IOPS) or the total data throughput in MB/s? SSD volumes are optimized for small, frequent I/O operations typical of transactional workloads like databases; HDD volumes are optimized for large, sequential I/O operations typical of log processing or big data analytics. Using the wrong volume type for a workload wastes money: an HDD volume for a database or an SSD volume for a log ingest pipeline both represent suboptimal choices.

#### Instructor notes

#### Student notes

SSD-backed volumes are optimized for transactional workloads that involve frequent read/write operations with small I/O size, where the dominant performance attribute is I/O operations per second (IOPS). HDD-backed volumes are optimized for large streaming workloads where throughput (the total amount of data transferred per second) is more important than the number of IOPS. For more information, see "Amazon EBS Volume Types" in the Amazon EC User Guide for Linux Instances (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html).

:::

### Slide 11:

![Slide 11](slide_11.png)

::: Notes


#### Instructor notes

#### Student notes

SSD-backed volumes are optimized for transactional workloads that involve frequent read/write operations with small I/O size, where the dominant performance attribute is IOPS. For more information, see "Amazon EBS Volume Types" in the Amazon EC User Guide for Linux Instances (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html).

:::

### Slide 12:

![Slide 12](slide_12.png)

::: Notes

The gp2 burst credit model means that small volumes can temporarily exceed their sustained IOPS baseline, but sustained workloads that consistently exceed the baseline will deplete credits and experience performance degradation. This burst behavior is frequently the cause of intermittent performance issues that are difficult to diagnose: a workload runs fine initially as credits are consumed, then slows down after credits are exhausted. Monitoring the `BurstBalance` CloudWatch metric and sizing volumes to sustain their required IOPS without bursting prevents these surprises.

#### Instructor notes

#### Student notes

For General Purpose (gp2) volumes, the

performance is the number of IOPS that an EBS volume can deliver to an
instance. This performance depends on the size of the volume. The larger
the volume, the more operations per second it can process. All volumes
can handle a minimum average of 100 IOPS. Beyond that, average IOPS
capacity increases linearly with the size of the volume. General Purpose
volumes deliver a baseline performance of 3 IOPS per gigabyte (GB) to a
maximum of 16,000 IOPS. Additionally, General Purpose volumes smaller
than 1 terabytes (TB) can also occasionally burst up to a maximum 3,000
IOPS during peak performance demands. However, the duration that a
volume's performance can burst beyond its expected performance is
limited according to a burst credit allowance. Volume throughput
performance (the total amount of data that a volume can store per
second) for General Purpose volumes does not vary linearly with volume
size. Throughput performance can range from 128 MiBps to 250 MiBps,
depending on the volume size. Volumes smaller than 170 GiB deliver a
maximum throughput of 128 MiBps. Volumes larger than 170 GiB but smaller
than 334 GiB deliver a maximum throughput of 250 MiBps if burst credits
are available. Volumes larger than or equal to 334 GiB deliver 250
MiBps. For more information, see "General Purpose SSD (gp2) Volumes" in
the Amazon EC2 User Guide for Linux Instances
(https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/general-purpose.html#EBSVolumeTypes_gp2).

:::

### Slide 13:

![Slide 13](slide_13.png)

::: Notes

The gp3 volume type decouples IOPS and throughput from volume size, which was a key limitation of gp2. With gp3, you can provision a small volume with high IOPS for a workload that doesn't need much storage space but needs high performance — something that required an oversized gp2 volume or a more expensive io1 volume previously. The baseline performance included with gp3 is sufficient for most general-purpose workloads, and the ability to provision additional IOPS and throughput independently provides cost-efficient scaling.

#### Instructor notes

#### Student notes

General Purpose SSD (gp3) volumes offer

cost-effective storage that is ideal for a broad range of workloads.
These volumes deliver a consistent baseline rate of 3,000 IOPS and 125
MiBps, included with the price of storage. You can provision additional
IOPS (up to 16,000) and throughput (up to 1,000 MiBps) for an additional
cost. General Purpose SSD (gp3) volumes are the latest generation volume
type that offer better performance at a lower cost than the General
Purpose SSD (gp2) Amazon EBS volumes. For more information, see "General
Purpose SSD (gp3) Volumes" in the Amazon EC2 User Guide for Linux
Instances
(https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/general-purpose.html#gp3-ebs-volume-type).

:::

### Slide 14:

![Slide 14](slide_14.png)

::: Notes

Provisioned IOPS volumes (io1/io2) provide consistently high IOPS with guaranteed performance SLAs, making them appropriate for latency-sensitive workloads like relational databases that require predictable I/O. Unlike gp2, there is no burst model: io1/io2 volumes deliver the provisioned IOPS consistently regardless of workload pattern. The ability to independently set IOPS per GiB means you can right-size both storage capacity and performance, rather than being forced to overprovision one to get adequate levels of the other.

#### Instructor notes

#### Student notes

Provisioned IOPS EBS volumes (volume

types io1 and io2) also vary in their performance capacity according to
their size. However, instead of the volumes delivering an average of 3
IOPS per GiB of allocated storage, set the IOPS rate that you want
(minimum of 100) up to a maximum of 500 per GiB of storage space
allocated to the volume. As such, a 50-GiB volume can have its
performance level set anywhere between 100 IOPS and 25,000 IOPS.

:::

### Slide 15:

![Slide 15](slide_15.png)

::: Notes

HDD-backed volumes are optimized for throughput-intensive sequential I/O workloads, such as log processing, data warehousing, and analytics. The most important operational constraint is that they cannot serve as boot volumes — the root volume of an EC2 instance must be SSD-backed. st1 (Throughput Optimized HDD) provides higher throughput at moderate cost for frequently accessed workloads; sc1 (Cold HDD) is the lowest-cost option for infrequently accessed data, representing the block storage equivalent of cold archival tiers.

#### Instructor notes

#### Student notes

HDD-backed volumes can be a

cost-effective option for large streaming workloads where throughput
(measured in MiBps) is a more important performance measure than IOPS.
These volumes cannot serve as the root or boot volume of an instance.
Instead, create these volumes as secondary volumes after your instance
is running, and then attach them to your instance. For more information,
see "Hard Disk Drive (HDD) Volumes" in the Amazon EC2 User Guide for
Linux Instances
(https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html#hard-disk-drives).

:::

### Slide 16:

![Slide 16](slide_16.png)

::: Notes

Creating and attaching an EBS volume involves AZ-scoped placement and type selection decisions that affect both performance and cost. The requirement to use an EBS-optimized instance for high-performance volumes is important: without EBS optimization, network I/O for EBS and instance network traffic share the same bandwidth, which causes I/O contention that limits both. EBS encryption is applied at creation time and cannot be changed on an existing volume — another reason to plan encryption requirements before creating volumes.

#### Instructor notes

#### Student notes

You can create an Amazon EBS volume and

then attach it to any EC2 instance in the same Availability Zone. If you
create an encrypted EBS volume, you can attach it only to supported
instance types. If you are creating a volume for a high-performance
storage scenario, use a Provisioned IOPS SSD (io1 or io2) volume. Attach
this volume to an instance with enough bandwidth to support your
application, such as an EBS-optimized instance or an instance with 10-Gb
network connectivity. The same recommendation holds for Throughput
Optimized HDD (st1) and Cold HDD (sc1) volumes. For more information,
see "Create an Amazon EBS Volume" in the Amazon EC2 User Guide for Linux
Instances
(https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-volume.html).

:::

### Slide 17:

![Slide 17](slide_17.png)

::: Notes


#### Instructor notes

#### Student notes

New Amazon EBS volumes receive their

maximum performance the moment that they are available, and do not
require initialization. For more information, see "Make an Amazon EBS
Volume Available for Use on Linux" in the Amazon EC2 User Guide for
Linux Instances
(http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-using-volumes.html).

:::

### Slide 18:

![Slide 18](slide_18.png)

::: Notes

Resizing an EBS volume is a two-step process: increasing the volume size in AWS, then extending the file system inside the operating system to use the new space. The AWS operation is non-disruptive — you can resize a live volume without unmounting it. However, the OS-level resize requires file system commands (`growpart` and `resize2fs` or equivalent), which are easy to forget. The 6-hour wait before making additional modifications is a practical operational constraint that prevents cascading configuration changes before the previous one fully applies.

#### Instructor notes

#### Student notes

After you increase the size of an EBS volume, you must use file system-specific commands to extend the file system to the larger size. You can resize the file system at the operating system (OS) level as soon as the volume enters the optimizing state. After modifying a volume, wait at least 6 hours to make sure that the volume is in the *in-use* or *available* state before making additional modifications to the same volume. For more information, see the following resources in the Amazon EC2 User Guide for Linux Instances: "Request Modifications to Your EBS Volumes" (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/requesting-ebs-volume-modifications.html); "Extend a Linux File System after Resizing a Volume" (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html).

:::

### Slide 19:

![Slide 19](slide_19.png)

::: Notes

RAID on EBS at the software level enables striping (RAID 0) to combine multiple EBS volumes into a larger logical volume with higher aggregate throughput, which is useful when a single volume's performance ceiling is insufficient. The recommendation against RAID 5 and RAID 6 is counterintuitive: these modes add parity overhead that consumes IOPS, while EBS already provides hardware-level redundancy within an AZ. Using RAID 5/6 adds cost and reduces performance without improving durability over what EBS already provides.

#### Instructor notes

#### Student notes

Traditional redundant array of

independent disks (RAID) settings are typically applied at the hardware
controller level for an external array of multiple disks. RAID 5 and
RAID 6 are not recommended for Amazon EBS because the parity write
operations of these RAID modes consume some of the IOPS available to
your volumes. These will reduce performance and not improve redundancy
and availability over the levels already maintained by AWS at the
hardware level. Use only RAID 0. You can deploy this RAID setting at the
software layer and improve performance or availability. Use RAID 0 to
double the available throughput to a volume and increase the maximum
IOPS available. For more information, review the following:"RAID
Configuration on Linux" in the Amazon EC2 User Guide for Linux Instances
(https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/raid-config.html)"RAID
Configuration on Windows" in the Amazon EC2 User Guide for Windows
Instances
(https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/raid-config.html)

:::

### Slide 20:

![Slide 20](slide_20.png)

::: Notes

EBS Multi-Attach enables shared block storage for clustered applications that coordinate concurrent writes across multiple nodes — a common requirement for high-availability database clusters and distributed file systems. The critical constraint is that applications must use a clustered file system that understands concurrent access; using Multi-Attach with a standard file system like ext4 or NTFS will cause data corruption because these file systems are not designed for concurrent multi-writer access. Ask students what happens if two nodes write to the same block simultaneously without coordination.

#### Instructor notes

#### Student notes

Use Amazon EBS Multi-Attach to attach a single Provisioned IOPS SSD (io1) volume to up to 16 Nitro-based instances that are in the same Availability Zone. You can attach multiple Multi-Attach-enabled volumes to an instance or set of instances. Each instance to which the volume is attached has full read and write permission to the shared volume. Multi-Attach helps you to achieve higher application availability in clustered Linux applications that manage concurrent write operations. The instances attached must use a clustered file system for storage, such as General Parallel File System (GPFS), Microsoft Cluster Shared Volumes (CSV), or Global File System 2 (GFS2) for Linux. For more information, see the following in the Amazon EC2 User Guide for Linux Instances: "Attach a Volume to Multiple Instances with Amazon EBS Multi-Attach" (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes-multi.html); "Considerations and Limitations" (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes-multi.html#considerations). For more information about Multi-Attach with Provisioned IOPS Amazon EBS volumes, see Amazon EBS Multi-Attach Now Available on Provisioned IOPS io1 Volumes (https://aws.amazon.com/about-aws/whats-new/2020/02/ebs-multi-attach-available-provisioned-iops-ssd-volumes/).

:::

### Slide 21:

![Slide 21](slide_21.png)

::: Notes


#### Instructor notes

#### Student notes

:::

### Slide 22:

![Slide 22](slide_22.png)

::: Notes

EBS health status checks run every 5 minutes and determine whether a volume is behaving correctly. The Auto-Enable I/O attribute controls what happens when a potential consistency issue is detected: the default is to wait for operator review before resuming I/O, which protects data integrity; auto-enabling I/O prioritizes availability over consistency. This is a meaningful trade-off decision: for databases and other consistency-sensitive applications, operator review before enabling I/O is the safer choice; for caches or scratch data, immediate availability may be preferable.

#### Instructor notes

#### Student notes

By default, AWS issues health status checks every 5 minutes for each of your Amazon EBS volumes. You can find the current result within the Amazon EC2 console page for your EBS volumes. The Auto-Enabled IO volume attribute for the health status determines whether I/O operations continue for a volume that is determined to have issues. If the consistency of a particular volume is not a concern, and you prefer that the impaired volume be made available immediately, you can override the default behavior. You can override the default by configuring the volume to automatically enable I/O. If the *Auto-Enable IO* volume attribute is enabled, an event shows that the volume was determined to be potentially inconsistent but that its I/O was automatically enabled. For more information, see "EBS Volume Status Checks" in the Amazon EC2 User Guide for Linux Instances (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html#monitoring-volume-checks).

:::

### Slide 23:

![Slide 23](slide_23.png)

::: Notes

Provisioned IOPS volumes have an additional performance health check beyond the standard availability check — they are evaluated against their expected IOPS delivery. A status of 'degraded' or 'severely degraded' indicates that the volume is underperforming relative to its provisioned specification, which can be caused by a storage hardware issue on the underlying infrastructure. Understanding the distinction between the health check statuses (ok, warning, impaired) and the performance statuses (normal, degraded, severely degraded, stalled) helps operators determine whether an issue requires waiting or escalation to AWS Support.

#### Instructor notes

#### Student notes

In addition to the standard health

checks, Provisioned IOPS EBS volumes undergo a performance check to
compare actual performance to the expected performance. The standard
health check status return values are ok, warning, and impaired. The
performance health check for io1 and io2 volumes returns an additional
status of normal, degraded, severely degraded, stalled, or not
available.

:::

### Slide 24:

![Slide 24](slide_24.png)

::: Notes

CloudWatch metrics for EBS provide the data needed to assess whether a volume is correctly sized for its workload. `VolumeQueueLength` is particularly important: a consistently elevated queue length means that I/O requests are stacking up faster than the volume can service them, which indicates the volume's IOPS or throughput capacity is insufficient. `BurstBalance` dropping to zero on a gp2 volume indicates that the volume's sustained IOPS requirements exceed its baseline and must be addressed by resizing or upgrading to a volume type without burst credits.

#### Instructor notes

#### Student notes

In addition to health status checks, Amazon CloudWatch provides the following additional metrics by default. These metrics are collected in 1-minute intervals for all Amazon EBS volumes types.

* **VolumeReadBytes** : Number of bytes read over the 5-minute period
* **VolumeWriteBytes** : Number of bytes written over the 5-minute period
* **VolumeReadOps** : Number of read operations performed in the period
* **VolumeWriteOps** : Number of write operations performed in the period
* **VolumeTotalReadTime** : Seconds spent by all read operations in the period
* **VolumeTotalWriteTime** : Seconds spent by all write operations in the period
* **VolumeIdleTime** : Seconds in the period with no read or write operations
* **VolumeQueueLength** : Number of read and write requests queued in the period
* **VolumeThroughputPercentage** : Percentage of IOPS delivered of the total IOPS provisioned
* **VolumeConsumedReadWriteOps** : Number of read and write operations in the period
* **BurstBalance** : Percentage of I/O credits or throughput credits available

For more information, see "Amazon CloudWatch Metrics for Amazon EBS" in the Amazon EC2 User Guide for Linux Instances (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using_cloudwatch_ebs.html).

:::

### Slide 25:

![Slide 25](slide_25.png)

::: Notes


#### Instructor notes

#### Student notes

:::

### Slide 26:

![Slide 26](slide_26.png)

::: Notes

EBS snapshots provide crash-consistent point-in-time backups that use incremental storage: only changed blocks are stored after the first full snapshot, which makes frequent snapshots cost-effective. The data dependency chain between snapshots means that deleting an intermediate snapshot doesn't lose the data it contains — EBS consolidates the block references to ensure all remaining snapshots can still be restored. Ask students to reason through the 'test your knowledge' questions: what happens to referenced blocks when a snapshot in the chain is deleted?

#### Instructor notes

#### Student notes

Amazon EBS snapshots provide a low-cost method of backing up the data on your EBS volumes to Amazon Simple Storage Service (Amazon S3). Snapshots can then restore that data at a later point in time to a newly launched EC2 instance. You can create snapshots programmatically through the AWS API. You can also create snapshot schedules through the Amazon Data Lifecycle Manager. Snapshots copy block-level data to Amazon S3 infrastructure. Objects are redundantly stored and can sustain the concurrent loss of data in two facilities. The first snapshot is a full snapshot of the state of the disk at the time the snapshot was taken. All subsequent snapshots will capture only the deltas compared to the previous snapshot. If you add data to your Amazon EBS volume after copying your first snapshot and then create a second snapshot, the new blocks will be copied to Amazon S3. And the second snapshot will consist of a recipe to restore the volume consisting of the blocks from the first snapshot and all new blocks. Snapshots are based on deltas. Only the changes from previous snapshots have to be copied to Amazon S3. If you update blocks on your Amazon EBS volume and then create a third snapshot, only the blocks that have changed will be copied to Amazon S3, and the new recipe to restore will consist of the updated blocks and any remaining blocks still present on your Amazon EBS volume.

**Test Your Knowledge** — Question 1: If you delete snapshot 1, what will happen to blocks A, B, and C in the Amazon S3 bucket? Answer: Nothing will happen because snapshot 2 has a recipe to restore that contains blocks A, B, and C. Those blocks will remain even though snapshot 1 has been deleted. Question 2: If you delete snapshot 2, what will happen to blocks A, B, and C in the Amazon S3 bucket? Answer: Because blocks A and B are no longer required to restore any remaining snapshots, they will be deleted from Amazon S3. Because block C is still needed for snapshot 3, it will be retained.

:::

### Slide 27:

![Slide 27](slide_27.png)

::: Notes

Snapshot copy across regions is the standard mechanism for cross-region disaster recovery with EBS: copy a snapshot from the primary region to the DR region, then restore a new volume from it when needed. The fact that you cannot directly move or mount a volume across regions — only snapshot copies are transferable — means that cross-region recovery involves a restore step with associated time and cost. For RTO-sensitive scenarios, pre-copying snapshots to the target region before a disaster ensures that the recovery time is only the volume restore time, not the copy transfer time plus restore time.

#### Instructor notes

#### Student notes

You can use snapshots to move volumes across AWS Regions. Although you cannot copy a volume across Regions, you can take a snapshot of a volume and copy that snapshot to a new Region. The following are CLI commands for these actions:

```
aws ec2 create-snapshot --volume-id vol-1234567890abcdef0 --description "This is my root volume snapshot"
aws ec2 copy-snapshot --region us-east-1 --source-region us-west-2 --source-snapshot-id snap-1234567890abcdef0 --description "This is my copied snapshot"
```

For more information, see "Copy an Amazon EBS Snapshot" in the Amazon EC2 User Guide for Linux Instances (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-copy-snapshot.html).

:::

### Slide 28:

![Slide 28](slide_28.png)

::: Notes

Restoring a volume from a snapshot introduces a first-access latency penalty because blocks are loaded lazily from S3 as they are first accessed. This can cause significant performance degradation immediately after a restore — a production database restored from snapshot may perform poorly until all its data blocks have been loaded from S3. Fast snapshot restore eliminates this by pre-warming the volume, but at additional cost. For planned restores where initial performance matters, fast snapshot restore or manual pre-warming by reading all blocks should be considered.

#### Instructor notes

#### Student notes

While snapshots are stored in Amazon

S3, they are not directly accessible using the Amazon S3 utilities.
Instead, you must use the Amazon EBS tools to restore and manage
snapshots. A significant increase in latency occurs when you first
access each block of data on a new EBS volume that a snapshot created.
You can avoid this performance degradation through the initialization
process. You can also enable fast snapshot restore for a given
Availability Zone for an additional cost to avoid this penalty. Amazon
EBS Snapshots Archive is a new low-cost storage tier for long-term
retention of Amazon EBS snapshots. When you restore an archived
snapshot, you first need to retrieve the archived snapshot, which can
take 24--72 hours. After it is retrieved, the snapshot appears as a
regular snapshot on the account. For more information, see the following
in the Amazon EC2 User Guide for Linux Instances:"Amazon EBS Fast
Snapshot Restore"
(https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-fast-snapshot-restore.html)"Create
a Volume from a Snapshot"
(https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-volume.html#ebs-create-volume-from-snapshot)"Archive
Amazon EBS Snapshots"
(https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-archive.html)

:::

### Slide 29:

![Slide 29](slide_29.png)

::: Notes

Amazon Data Lifecycle Manager automates the snapshot lifecycle — creation, retention, and deletion — removing the operational burden of manual snapshot management. Without automation, backup schedules are often inconsistent or forgotten, and old snapshots accumulate and drive up storage costs. DLM policies define both the backup frequency and the retention rule, so every volume covered by a policy automatically has a compliant backup history. The combination with EventBridge and CloudTrail provides audit visibility into the backup lifecycle.

#### Instructor notes

#### Student notes

You can use Amazon Data Lifecycle

Manager to automate the creation, retention, and deletion of snapshots.
Automating snapshot management helps you do the following:Protect
valuable data by enforcing a regular backup schedule. Retain backups as
required by auditors or internal compliance. Reduce storage costs by
deleting outdated backups. When you combine Amazon Data Lifecycle Manager
with the monitoring features of Amazon EventBridge and AWS CloudTrail,
Amazon Data Lifecycle Manager provides a complete backup solution for
EBS volumes at no additional cost. For more information, see "Amazon Data
Lifecycle Manager" in the Amazon EC2 User Guide for Linux Instances
(https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html).

:::

### Slide 30:

![Slide 30](slide_30.png)

::: Notes


#### Instructor notes

#### Student notes

Provide the following information for

your policy, as needed:Target with these tags -- The resource tags that
identify the volumes or instances to back up. Schedule name -- A name
for the schedule. Frequency -- The interval between policy runs. You can
configure policy runs on a daily, weekly, monthly, or yearly schedule.
Alternatively, choose Custom cron expression to specify an interval of
up to 1 year. Starting at hh:mm UTC -- The time at which the policy runs
are scheduled to start. The first policy run starts within an hour after
the scheduled time. Retention type -- You can retain snapshots based on
the total count of snapshots or the age of each snapshot. For retention
based on the count, the range is 1--1000. After the maximum count is
reached, the oldest snapshot is deleted when a new one is created. For
age-based retention, the range is 1 day to 100 years. After the
retention period of each snapshot expires, it is deleted. The retention
period should be greater than or equal to the creation interval.

:::

### Slide 31:

![Slide 31](slide_31.png)

::: Notes

AWS Backup centralizes backup management across multiple AWS services — EBS, RDS, DynamoDB, EFS, and more — in a single policy framework. This cross-service coverage is the key advantage over service-specific backup mechanisms like EBS snapshots or RDS automated backups: a single backup plan can cover your entire data estate with consistent retention policies and compliance reporting. The Audit Manager integration enables organizations to demonstrate backup compliance to auditors without manually reviewing individual service configurations.

#### Instructor notes

#### Student notes

Use AWS Backup to automate the

scheduling and creation of snapshots. AWS Backup is a managed service
that helps create backup copies of various AWS data, such as Amazon
DynamoDB tables, Amazon Relational Database Service (Amazon RDS)
databases, and Amazon EBS volumes. With AWS Backup, you can create a
backup plan, assign AWS resources, and then centrally manage the backups
from Amazon S3. AWS Backup Audit Manager is a new feature within the AWS
Backup service that you can use to audit and report on the compliance of
your data protection policies. This helps you meet your business and
regulatory needs. With AWS Backup support for VMware, you can also
centrally protect your on-premises VMware environments along with the
AWS services supported by AWS Backup. For more information, see AWS
Backup Support for Vmware
(https://aws.amazon.com/backup/features/vmware/).

:::

### Slide 32:

![Slide 32](slide_32.png)

::: Notes

AWS Backup plan creation requires decisions about schedule frequency, backup vault location, and VSS enablement for Windows applications. The backup vault is not just a storage location — it's an access control and encryption boundary. Restricting who can delete backups from the vault is a key security control: an attacker who has compromised an account should not be able to delete all backups as part of a ransomware attack. Using a separate AWS account for backup storage, with vault lock policies, provides defense-in-depth for backup integrity.

#### Instructor notes

#### Student notes

To use AWS Backup, first create a

backup plan. Your backup plan will consist of one or more backup rules
to apply to resources assigned to the plan. To define a backup rule for
EBS volumes, specify the following settings:Set a schedule for how often
you want backup snapshots to be taken. Establish a backup vault (an
Amazon S3 repository). Specify whether you want to employ Volume Shadow
Copy Service (VSS) when taking your snapshots (if using Windows and
applications with VSS integration). For more information, see "Creating a
Backup Plan" in the AWS Backup Developer Guide
(https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup-plan.html).

:::

### Slide 33:

![Slide 33](slide_33.png)

::: Notes


#### Instructor notes

#### Student notes

You can centrally manage your snapshots

from the AWS Backup console for your backup vault. A backup vault
* is a
container that you organize your backups in. You can use backup vaults
to control access to your backups. You can also use it to set the AWS
Key Management Service (AWS KMS) encryption key that is used to encrypt
backups. From this console page, you can create, copy, delete, or
restore your Amazon EBS snapshots.

:::

### Slide 34:

![Slide 34](slide_34.png)

::: Notes


#### Instructor notes

#### Student notes

:::

### Slide 35:

![Slide 35](slide_35.png)

::: Notes

Amazon EFS provides shared POSIX-compliant file storage that automatically scales from gigabytes to petabytes without provisioning — in contrast to EBS volumes, which require pre-provisioned capacity. Multiple EC2 instances can mount the same EFS file system simultaneously, making it the appropriate choice for workloads that require shared read-write access across a fleet of instances, such as content management systems, shared configuration files, or machine learning training datasets. The NFS protocol dependency means that Linux-based workloads are the primary use case.

#### Instructor notes

#### Student notes

Amazon Elastic File System (Amazon EFS)

provides a simple, scalable, fully managed elastic Network File System
(NFS) for use with Amazon EC2, Amazon Elastic Container Service (Amazon
ECS), AWS Lambda, and on-premises resources. It is built to scale on
demand to petabytes without disrupting applications. It grows and
shrinks automatically as you add and remove files. You can access the
Amazon EFS file system concurrently from Amazon EC2 instances in your
virtual private cloud (VPC). Applications that scale beyond a single
connection can access a file system. EC2 instances that run in multiple
Availability Zones within the same Region can access the file system. As
a result, many users can access and share a common data source.Note the
following restrictions:You can mount an Amazon EFS file system on
instances in only one VPC at a time.Both the file system and VPC must be
in the same AWS Region.We recommend using a current generation Linux
NFSv4.1 client, such as those found in Amazon Linux and Ubuntu Amazon
Machine Images (AMIs). For some AMIs, you must install an NFS client to
mount your file system on your EC2 instance.For more information, see
the following resources in the Amazon Elastic File System User Guide:
"NFS Support"
(https://docs.aws.amazon.com/efs/latest/ug/mounting-fs-old.html#mounting-fs-nfs-info)"Installing
the NFS Client"
(https://docs.aws.amazon.com/efs/latest/ug/mounting-fs-old.html#mounting-fs-install-nfsclient)

:::

### Slide 36:

![Slide 36](slide_36.png)

::: Notes

Amazon FSx provides managed file systems for workloads that need a specific file system protocol beyond NFS. Workloads migrating from on-premises Windows file servers need SMB protocol and Windows ACLs (FSx for Windows File Server); HPC and machine learning workloads need the high throughput and low latency of Lustre (FSx for Lustre); storage administrators familiar with NetApp features like SnapMirror or tiering can use FSx for ONTAP. The key design question is matching the file system's specific capabilities to what the workload requires.

#### Instructor notes

#### Student notes

Amazon FSx is a cost-effective way to

launch, run, and scale feature-rich, high-performance file systems in
the cloud. It supports a wide range of workloads with its reliability,
security, scalability, and broad set of capabilities. Amazon FSx is
built on the latest AWS compute, networking, and disk technologies to
provide high performance and lower total cost of ownership (TCO). With
Amazon FSx, you can choose between four widely-used file systems: NetApp
ONTAP, OpenZFS, Windows File Server, and Lustre. This choice is
typically based on your familiarity with a specific file system or by
matching the file system's feature sets, performance profiles, and data
management capabilities to the requirements of your workload.All Amazon
FSx offerings support connecting with on-premises workloads using AWS
Direct Connect or a virtual private network (VPN) connection. For more
information about Amazon FSx, see Choosing an Amazon FSx File System
(https://aws.amazon.com/fsx/when-to-choose-fsx/). For more information
about using Amazon FSx for the various file systems, see the following:
"What Is Amazon FSx for NetApp ONTAP?"
(https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/what-is-fsx-ontap.html)"What
Is Amazon FSx for OpenZFS?"
(https://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/what-is-fsx.html)"What
Is FSx for Windows File Server?"
(https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)"What
Is Amazon FSx for Lustre?"
(https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)

:::

### Slide 37:

![Slide 37](slide_37.png)

::: Notes


#### Instructor notes

#### Student notes

:::

### Slide 38:

![Slide 38](slide_38.png)

::: Notes


#### Instructor notes

#### Student notes

:::

### Slide 39:

![Slide 39](slide_39.png)

::: Notes


#### Instructor notes

#### Student notes

:::

### Slide 40:

![Slide 40](slide_40.png)

::: Notes


#### Instructor notes

#### Student notes

:::

### Slide 41:

![Slide 41](slide_41.png)

::: Notes

This troubleshooting scenario illustrates a common pattern: a performance problem that is initially mysterious becomes clear once the relevant CloudWatch metrics are examined. The burst balance metric depleting to zero is the root cause — the workload was consuming more IOPS than the gp2 volume's sustained baseline. The solution options (larger volume for more baseline IOPS, or Provisioned IOPS for performance independent of size) reflect the different gp2 and io1/io2 performance models. Ask students how they would have detected this issue proactively using CloudWatch alarms.

#### Instructor notes

#### Student notes

ScenarioYour application is processing

a workload. The process is taking longer than expected. When
investigating the issue, you discovered the following metrics from the
EBS volume handling the workload. IssueWhat do you suspect is the
issue?The burst balance depleted, and Amazon EBS performance began to
degrade. SolutionWhat can you do to fix it?Upgrade to an EBS volume with
larger capacity or Provisioned IOPS.

:::

### Slide 42:

![Slide 42](slide_42.png)

::: Notes


#### Instructor notes

#### Student notes

:::

### Slide 43:

![Slide 43](slide_43.png)

::: Notes


#### Instructor notes 

#### Student notes

:::

### Slide 44:

![Slide 44](slide_44.png)

::: Notes


#### Instructor notes

#### Student notes

This lab takes you through the

following process:Subscribe to an Amazon SNS topic.Create a backup
plan.Add resources to a backup plan.Enable notifications for completed
backups and restores.Run backups. (A completed backup will invoke an AWS
Lambda function that validates data can be restored from the
backup.)Review CloudWatch Logs.

:::

### Slide 45:

![Slide 45](slide_45.png)

::: Notes


#### Instructor notes

#### Student notes

:::