25. Volumes & Snapshots
Network drive attached to one EC2 instance at a time.
An EBS Volume is a network drive (not physical drive) you can attach to EC2 instances while they run. Means to communicate between EC2 instance and EBS volume it will be using the network. Since the network is used there will be a bit latency from one server to another. EBS volume because of their network drive, it can be detached from one EC2 instance and attach to another one quickly.
It allows EC2 instances to persist (continue to exist) data, even after the instance is terminated.
The EBS volumes can be mounted to one instance at a time (at the CCP level).
The EBS volumes are bound up/ linked/ tied to a specific AZs. An EBS volume in us-east-1a cannot be attached to us-east-1b. But if we do a snapshot then we are able to move a EBS volume across different availability zones.
We can think of EBS Volumes as ‘Network USB Stick’, where we dont physically put from one computer to another but it is attached through the network.
Free tier: 30GB of free EBS storage of type General Purpose (SSD) or Magnetic per month.
We can provision capacity in advance (size in GBs and IOPS). We get billed for all the provisioned capacity and we can increase the capacity of the drive over time, if we want to have a better performance or more size.
AZ 1 >> EC2 Instance 1 >> EBS Volume 1 attached
AZ 1 >> EC2 Instance 2 >> EBS Volume 2 and EBS Volume 3 are attached but EBS Volume 1 cannot be attached to EC2 Instance 2.
Similarly EBS Volume 1, 2 & 3 cannot be attached to another EC2 instance in AZ 2. However we can detach EBS Volume from an EC2 instance and leave them unattached.
We have an option ‘Delete on Termination’ to delete EBS volume when we create an EC2 instance. By default root volume will be deleted (attribute enabled) and any other attached EBS volume will not be deleted (attribute disabled). Use case: Preserve root volume when the instance is terminated.
While we say that EBS volumes cannot be attached to multiple instances, it is not true for io1 and io2 volume types: this is called the EBS Multi-Attach feature.
We can EBS Volumes and make a snapshot which is also called a Backup. Make a backup (snapshot) of EBS volume at any point of time. Even if the EBS volume is terminated, later on we could restore it from back up.
It is not necessary to detach volume to do snapshot but recommended just to make sure everything is clean on EBS volume.
We can copy snapshots across AZs or Regions.
AZ 1 >> EC2 Instance 1 >> EBS Volume 1 attached >> Stop (recommended) EC2 instance 2 and create a snapshot >> Restore EBS Volume 2 and attach to EC2 Instance 1 in AZ2
How is a volume selected (identified) when making an EBS Snapshot?
A. account id
B. volume id
What two methods are recommended by AWS for protecting EBS data at rest?
One company uses EC2 instances with EBS volumes as server infrastructure. The company’s system operations policy states that all data must be backed up efficiently.
Choose the cost-optimal EBS volume backup method.
A. Set up periodic snapshot acquisition for EBS
B. Use EBS volume encryption
C. Use the EC2 instance store
D. Configure mirroring for two EBS volumes
Option 1 is the correct answer. EBS snapshots allow you to back up data on Amazon EBS volumes to Amazon S3. Snapshots are incremental backups. That is, after the first snapshot, only the blocks on the device that have changed since the last time are saved. This minimizes the time required to take a snapshot and saves storage costs.
Option 2 is incorrect. EBS volume encryption is used for data protection and is not used for data backup.
Option 3 is incorrect. The EC2 instance store is used to store temporary data and is not relevant to this requirement.
Option 4 is incorrect. It is inefficient to have a mirroring configuration for the entire EBS volume. The mirroring configuration is not for backup, but for the redundancy of EBS volumes, allowing you to continue processing on another disk if one volume fails.
A company wants some EBS volumes with maximum possible Provisioned IOPS (PIOPS) to support high-performance database workloads on EC2 instances. The company also wants some EBS volumes that can be attached to multiple EC2 instances in the same Availability Zone.
As an AWS Certified Solutions Architect Associate, which of the following options would you identify as correct for the given requirements? (Select two)
A. Use io1/io2 volumes to enable Multi-Attach on Nitro-based EC2 instances
B. Use io2 volumes on Nitro-based EC2 instances to achieve a maximum Provisioned IOPS of 256,000
C. Use gp2 volumes to enable Multi-Attach on Nitro-based EC2 instances
D. Use gp3 volumes on Nitro-based EC2 instances to achieve a maximum Provisioned IOPS of 256,000
E. Use io2 Block Express volumes on Nitro-based EC2 instances to achieve a maximum Provisioned IOPS of 256,000
Answer: A & E
Use io2 Block Express volumes on Nitro-based EC2 instances to achieve a maximum Provisioned IOPS of 256,000
EBS io2 Block Express is the next generation of Amazon EBS storage server architecture. It has been built for the purpose of meeting the performance requirements of the most demanding I/O intensive applications that run on Nitro-based Amazon EC2 instances. With io2 Block Express volumes, you can provision volumes with Provisioned IOPS (PIOPS) up to 256,000, with an IOPS:GiB ratio of 1,000:1
Use io1/io2 volumes to enable Multi-Attach on Nitro-based EC2 instances
Amazon EBS Multi-Attach enables you to attach a single Provisioned IOPS SSD (io1 or io2) volume to multiple 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 makes it easier for you to achieve higher application availability in clustered Linux applications that manage concurrent write operations.
Use io2 volumes on Nitro-based EC2 instances to achieve a maximum Provisioned IOPS of 256,000 For io2, Provisioned IOPS SSD volumes can range in size from 4 GiB to 16 TiB and you can provision from 100 IOPS up to 64,000 IOPS per volume. You can achieve only up to 64,000 IOPS on the instances built on the Nitro System.
Use gp3 volumes on Nitro-based EC2 instances to achieve a maximum Provisioned IOPS of 256,000 – gp3 volumes cannot be used with Nitro-based EC2 instances. In addition, gp3 volumes support a maximum PIOPS of 16,000.
Use gp2 volumes to enable Multi-Attach on Nitro-based EC2 instances – gp2 volumes are not supported for Multi-Attach.
A junior DevOps engineer wants to change the default configuration for EBS volume termination. By default, the root volume of an EC2 instance for an EBS-backed AMI is deleted when the instance terminates.
Which option below helps change this default behavior to ensure that the volume persists even after the instance terminates?
• Set the TerminateOnDelete attribute to false
• Set the DeleteOnTermination attribute to false
• Set the TerminateOnDelete attribute to true
• Set the DeleteOnTermination attribute to true
Set the DeleteOnTermination attribute to false
An EC2 instance can be launched from either an instance store-backed AMI or an Amazon EBS-backed AMI. Instances that use Amazon EBS for the root device automatically have an Amazon EBS volume attached. By default, the root volume for an AMI backed by Amazon EBS is deleted when the instance terminates.<br/> The default behavior can be changed to ensure that the volume persists after the instance terminates. To change the default behavior, set the DeleteOnTermination attribute to false using a block device mapping.
Set the TerminateOnDelete attribute to true
Set the TerminateOnDelete attribute to false
Both these options are incorrect as there is no such attribute as TerminateOnDelete. These options have been added as distractors.
Set the DeleteOnTermination attribute to true – If you set the DeleteOnTermination attribute to true, then the root volume for an AMI backed by Amazon EBS would be deleted when the instance terminates. Therefore, this option is incorrect.