AWS: Elastic block storage 2nd part

SHARING EBS SNAPSHOTS:

By default, only the account owner can create volumes from the account snapshots.

You can share your unencrypted snapshots with the AWS community by making them public (modifying the snapshot permission to the public)

Also, you can share your unencrypted snapshots with a selected AWS account(s), by making them private then selecting the AWS accounts to share with

You can NOT make your encrypted snapshots public.

You can NOT make a snapshot of an encrypted snapshot public on AWS.

• However, you can share it with other AWS accounts if needed, but you need to mark it “private” then share it.

You can share your encrypted snapshots with specific AWS accounts as follows:

• Make sure that you use a non-default/Custom CMK key to encrypt the snapshot, not the default CMK key (AWS will not allow the sharing if default CMK is used).
• Configure Cross-account permission in order to give the account(s), with which you want to share the snapshot, access to the custom CMK key used to encrypt the snapshot.

* Without this, the other accounts will not be able to copy the snapshot, nor will be able to create volumes of the snapshot.

• Mark the snapshot private then enter the AWS accounts with which you want to share the snapshot.
• AWS will not allow you to share the snapshot encrypted using your default CMK key.
• For the AWS account(s) with whom an encrypted snapshot is shared,
• They must first create their own copies of the snapshots, Then they use that copy to restore/create EBS volumes.
• Recommended) They can also choose to encrypt the shared, encrypted snapshot during the copy process using one of their CMK keys to having full control over their copy of the shared snapshot.
• When you share your snapshot of a volume, you are actually sharing all the data on that volume used to create the snapshot.
• Changes made by the other account to their copies, do not impact the originally shared snapshot.

COPYING SNAPSHOTS

You can copy a snapshot within the same region, or from one region to another.

To move a snapshot to another region, you need to copy it to that region.

You can only make a copy of the snapshot when it has been fully saved to S3(its status shows as complete). and not during the snapshots pending status(when data blocks are being moved to S3).

Amazon S3’s Server-Side Encryption (SSE) encryption (SSE) protects the snapshot data-in-transit while copying (Since the snapshot and the copy are both on S3)

User-defined tags are NOT copied from the original snapshot to the copy

You can have up to 5 snapshot copy requests running in a single destination per account.

If you try to copy an encrypted snapshot without having permissions to the encrypted key, the copy process will fail silently.

• This is why “Cross account permissions” were required when sharing encrypted snapshots.
• If the accounts with which the snapshot is shared, do not have access to the encryption key, they will not be able to create copies nor will be able to use the shared snapshots.

USE CASES-COPYING A SNAPSHOT

Use cases for copying a snapshot

• Geographic expansion
• Disaster Recovery, backing up your data and logs in another region, restoring from that data/logs in case of a disaster
• Migration to another region
• Encryption of unencrypted volumes
• Data retention and auditing requirements

Copy data and logs to another AWS account for auditing

This also protects against account compromise

CREATING/REGISTERING AMIs

To create your own AMI, from an Instance store backed EC2 instance’s root volume, you need to:

• Launch an EC2 instance from an instance store backed AMI
• Update the root volume as you require( (software updates, patches, apps..etc)
• Create the AMI which will upload the AMI and updates as a bundle to S3

You need to specify the S3 bucket (User Bucket) to load the AMI/bundle to

• Register the AMI (Manually), such that AWS EC2 can find it to launch further EC2 instances
• The created AMI image of the instance store backed EC2 instance is stored in AWS S3.

Since your new AMI is stored in an AWS S3 bucket S3 charges apply until you de-register the AMI and delete the S3 stored objects.

For changes to the source AMI (stored in S3) to become in effect, you must deregister and reregister the AMI before the changes take effect.

LAUNCHING EC2 INSTANCES FROM INSTANCE STORE BACKED AMI

Instances launched from an Instance store backed AMI will have an instance store as the root device volume.

When an instance is launched using an instance store backed-AMI, the image (saved in S3) is copied from S3 to the instance’s root device volume.

• The root device volume is then used to boot the instance.

DEREGISTERING USER CREATED AMI’S

When you do not need an AMI any further, you can deregister it,

• If you do this, you will not be able to use it again to launch further instances (AWS will not find it)

Deregistering an AMI will not impact those instances created from the AMI while it was registered.

USER CREATED EBS BACKED AMI

For EBS Backed instances, when you create an AMI, stop the instance to ensure data consistency and integrity, then create the AMI.

For EBS backed Instances, AWS registers the created AMIs automatically.

During the AMI-creation process, Amazon EC2 creates snapshots of your instance’s root volume and any other EBS volumes attached to your instance.

• You are charged for storage costs as long as the snapshots are stored in S3.
• In EBS’s case, you do not need to specify one of your S3 buckets
• Once you do not need them anymore, delete them.

If any volumes attached to the instances are encrypted, the new AMI only launches successfully on instances that support Amazon EBS encryption.

CLEANING UP THE EBS BACKED AMI

To delete the snapshot of the EBS backed instance’s root device volume used by a registered AMI (The one that was created by AWS during the AMI creation process)

• You must de-register the AMI first

When you deregister the Amazon EBS backed AMI, it doesn't affect the snapshot that was created for the root volume of the instance during the AMI creation process.

• Then you can delete the snapshot.

EBS REDUNDANT ARRAY OF INDEPENDENT DISKS (RAID)

• Stripping means, distributing the data to be written over the array disks and writing to medical disks in parallel without redundancy.
• Mirroring means, writing the same data to multiple array disks for redundancy.
• RAID is accomplished at the OS level, EBS volumes are supported in any RAID array type.
• Be careful that the EC2 instance BW can handle the resulting array I/O performance to get the best I/O performance.
• Use EBS optimized instances or instances with a 10Gbps network interface.

RAID ARRAY TYPES

• RAID 0:

It has stripping and no mirroring.

Provides the best I/O performance among RAID types.

Resulting I/O is the sum of the individual disks I/O’s.

Failure of one EBS volume means the failure of the entire array.

• RAID 1:

Redundancy (writing the same data to multiple drives), no stripping

No I/O performance enhancement

• RAID 10:

Redundancy and Stripping ( combines both RAID 0 and RAID 1)

Good performance and Redundancy

As a rule of thumb, An EC2 instance’s max bandwidth needs to be greater or equal to the total I/O of EBS volume.

It is not recommended to use a RAID array as a root/boot volume of an instance.

In my next coming blog, I will start the blog with #ELB which is considered as one of the important topics in AWS. So, Kindly stay connected.

Thank you,

Bharathi.