EBS Encryption support
EBS Encryption is supported in all EBS volume types
But not all EC2 instances support encryption
EBS Volume/Snapshot - Encryption keys
KMS - AWS Key management service
CMKs - Customer master keys
When you encrypt first EBS volume, AWS KMS creates default CMS key
After that, each newly encrypted volume is encrypted with a unique/separate AES256 bits encryption key
Sharing EBS Snapshots
Only account owner can create volume from snapshots
Encrypted snapshots cannot be shared, only un-encrypted are meant to be shared
But an Encrypted snapshot can be shared to a selected AWS account id, by making them private (with cross-account permissions)
Account A - with Key 1, has shared encrypted snapshot with Account B, Account B owner needs to create a copy of snapshot with his own key(Key 2) & create volumes
AWS will not allow you to share snapshots encrypted using default CMK key ****
Snapshots are stored in S3 (unknown location to us)
S3 SSE protects snapshot data in transit
Copy Snapshots
Copy snapshot to another to encrypt or to another region
user defined tags are NOT copied from original
5 copy requests per account in parallel
Instance Backed AMI vs EBS Backed AMI
When you create EC2 AMI, AWS automatically EBS volume(s) & Intance root volume snapshots are created
When snapshots attached to AMI, you cannot delete snapshots, you need to de-register AMI & delete snapshots
1) Instance Backed AMI
You need to register AMI (in Amazon market place)
You need to specify S3 bucket for storing snapshots
2) EBS Backed AMI
Registration of AMI happens automatically
You don't need to specify S3 bucket
When creating EMI, stop instance to ensure data consistancy and integrity
EBS Snapshots are point in time
How to ensure EBS data consistancy (stop EC2 instance is best)
1) Pause I/O operations on EBS from EC2
2) Unmount EBS volumes, create snapshot & mount again
RAID in EBS (Redundant array of independent disks)
Increase I/O performance/throughput of EC2
using EBS optimized EC2 instances
use RAID array of EBS volumes
RAID array is collection of multiple EBS volumes
Make sure EC2 max bandwidth >= Total I/O of EBS volume (or RAID)
RAID is not meant for root/boot volumes of EC2
RAID 0 - stripping
Fastest of all RAID types
Distributing data to be written over array of disks in parallel (without redundancy) - faster
If data fails in one volume, whole array of EBS volumes gets corrupted
RAID 1 - Mirroring
Cares about redundancy but not faster
Not able achieve I/O performance/throughput
RAID 10 - It has benefits of both RAID0 & RAID1
EBS Practice scenarios
EBS Encryption is supported in all EBS volume types
But not all EC2 instances support encryption
EBS Volume/Snapshot - Encryption keys
KMS - AWS Key management service
CMKs - Customer master keys
When you encrypt first EBS volume, AWS KMS creates default CMS key
After that, each newly encrypted volume is encrypted with a unique/separate AES256 bits encryption key
Sharing EBS Snapshots
Only account owner can create volume from snapshots
Encrypted snapshots cannot be shared, only un-encrypted are meant to be shared
But an Encrypted snapshot can be shared to a selected AWS account id, by making them private (with cross-account permissions)
Account A - with Key 1, has shared encrypted snapshot with Account B, Account B owner needs to create a copy of snapshot with his own key(Key 2) & create volumes
AWS will not allow you to share snapshots encrypted using default CMK key ****
Snapshots are stored in S3 (unknown location to us)
S3 SSE protects snapshot data in transit
Copy Snapshots
Copy snapshot to another to encrypt or to another region
user defined tags are NOT copied from original
5 copy requests per account in parallel
Instance Backed AMI vs EBS Backed AMI
When you create EC2 AMI, AWS automatically EBS volume(s) & Intance root volume snapshots are created
When snapshots attached to AMI, you cannot delete snapshots, you need to de-register AMI & delete snapshots
1) Instance Backed AMI
You need to register AMI (in Amazon market place)
You need to specify S3 bucket for storing snapshots
2) EBS Backed AMI
Registration of AMI happens automatically
You don't need to specify S3 bucket
When creating EMI, stop instance to ensure data consistancy and integrity
EBS Snapshots are point in time
How to ensure EBS data consistancy (stop EC2 instance is best)
1) Pause I/O operations on EBS from EC2
2) Unmount EBS volumes, create snapshot & mount again
RAID in EBS (Redundant array of independent disks)
Increase I/O performance/throughput of EC2
using EBS optimized EC2 instances
use RAID array of EBS volumes
RAID array is collection of multiple EBS volumes
Make sure EC2 max bandwidth >= Total I/O of EBS volume (or RAID)
RAID is not meant for root/boot volumes of EC2
RAID 0 - stripping
Fastest of all RAID types
Distributing data to be written over array of disks in parallel (without redundancy) - faster
If data fails in one volume, whole array of EBS volumes gets corrupted
RAID 1 - Mirroring
Cares about redundancy but not faster
Not able achieve I/O performance/throughput
RAID 10 - It has benefits of both RAID0 & RAID1
EBS Practice scenarios
- non-encrypt to encrypt
- copy ebs to another AZ
- make ebs volume public/private
- Encryption types
- customer specific encryption
- play in CMK & other encrypt patterns - customer managed keys
- copy snapshot to another region
- copy snapshot to another AWS account
- attach to EC2 & mount
- increase/decrease EBS volume size
- Root volume encrypt (work around)
- Do I need to turn off EC2 while taking backup?
