- You can back up the data on your Amazon EBS volumes to Amazon S3 by taking point-in-time snapshots. Snapshots are incremental backups, which means that only the blocks on the device that have changed after your most recent snapshot are saved. This minimizes the time required to create the snapshot and saves on storage costs by not duplicating data.
Encryption
- En/de-cryption happens on EC2 not on the attached EBS
- NEW: CAN encrypt root volume – specify this when creating EC2
- All EC2 families support volume encryption but NOT all EC2 instance types
- EBS encryption is not supported on Free tier EC2's
- All EBS volumes support encryption
- Snapshots is same as volume: encrypted volume = encrypted snapshot; not=not
- Can copy a snapshot and choose encryption for the copy. Use that to launch a new EBS instance.
- Data at rest:
§ can use 3rd party encryption tools
§ use encrypted EBS volumes
§ use encryption on OS level – encryption by OS plugins
§ encrypt data before transferring to volume
§ use encrypted file system on top of EBS volume
- Data in transit – since encryption takes place on EC2, in-transit data is encrypted
- To encrypt data off a non-encrypted volume:
§ Attach a new encrypted volume to same EC2
§ Copy data over
OR
§ Create an encrypted snapshot of un-encrypted volume
§ Use this snapshot to create a new EBS - which will be encrypted too
§ Attach it to EC2
- For the first encrypted volume KMS creates a default CMK. It is used to encrypt snapshots of this the volume and volumes created from these snapshots
- AWS will not allow sharing volumes encrypted with the default CMK. Copy, change encryption key and then share
- Subsequent encrypted volumes use unique/separate AES256 bits encryption key. Same key is used for snapshots etc. off each volume
- Can’t change the key used to encrypt an existing snapshot/volume – copy and specify the new key in process
- Other AWS lingo terms for EBS encryption:
§ AWS EBS Encryption
§ OS Level Encryption
§ 3rd party encryption tools
Sharing an
Encrypted Snapshot
- Use non-default Custom key (can’t share if default key is used)
- Create cross-account permissions to allow the access to the key used to encrypt the snapshot
- Make the snapshot private
- REGIONAL (NOT GLOBAL)
- Max 5000 EBS volumes per account, 10000 snapshots per account
- EBS snapshots are saved in S3, can’t access directly – only through API’s
- Instance-store snapshots are saved in your own S3 bucket, accessible
- EBS snapshots are region specific – accessible across region, can use in another AZ
- Can create/restore a snapshot to an EBS volume of same or larger size from which the snapshot was originally created
- You can access a non-root EC2 while the snapshot is being created (it will be slow). Only data already written to the instance when snapshot capture was initiated will be included
- Can make unencrypted snapshots public (visible to all of AWS) – or permit to a specific account
- CanNOT make encrypted snapshots public
- Can attach encrypted and unencrypted volumes to same EC2
- Snapshots are asynchronous – when EC2 writes an update to a volume, it doesn't mean that an existing snapshot is updated automatically
- To perform correct application-aware snapshot you should follow the simple rules below:
§ Stop EC2 instance before creating an EBS snapshot
§ Unmount and detach the EBS volume from the EC2 instance - only then take a snapshot
Issues:
- Can't export snapshot outside of AWS
- No snapshot deduplication capabilities
- No built-in snapshot scheduling mechanism – need to combine CloudWatch and cron
Copying
- Can copy snapshot into another region
- Can optionally encrypt along the way
- Can have up to 5 copy requests running at the same time
- Trying to copy a snapshot with no access to its encryption key – copy will “fail silently”, with no error message
- Tags don’t get copied over
- Can copy across regions: for expansion or disaster recovery or compliance
Creating
- Remains in 'Pending' status from when create command initiated until all data is transferred to snapshot on S3. Only after that is marked as 'Complete'
- Can still access the volume meanwhile (pending) – access will be slow, a lot of reads happening
- Anything post-‘Create command’ is not included in snapshot
- For a complete snapshot of a non-root (non-boot) volume:
§ Stop read/writes
§ Detach
§ Start snapshot
§ Re-attach the volume while snapshot is still being created
- For a complete snapshot of a root (boot) volume:
§ Stop the instance
§ Careful if there are any Instance-store attached volumes – data will be lost
Snapshots are Incremental
- Only changes are captured
- Low cost storage on S3
- You are paying for:
§ Data transfer to S3
§ Storage on S3
§ you need to maintain only the latest one, it is incremental and complete. Older snapshots can be archived or deleted.
- Max 5000 EBS volumes per account, 10000 snapshots per account
- EBS snapshots are saved in S3, can’t access directly – only through API’s
- Instance-store snapshots are saved in your own S3 bucket, accessible
- EBS snapshots are region specific – accessible across region, can use in another AZ
- Can create/restore a snapshot to an EBS volume of same or larger size from which the snapshot was originally created
- You can access a non-root EC2 while the snapshot is being created (it will be slow). Only data already written to the instance when snapshot capture was initiated will be included
- Can make unencrypted snapshots public (visible to all of AWS) – or permit to a specific account
- CanNOT make encrypted snapshots public
- Can attach encrypted and unencrypted volumes to same EC2
- Snapshots are asynchronous – when EC2 writes an update to a volume, it doesn't mean that an existing snapshot is updated automatically
- To perform correct application-aware snapshot you should follow the simple rules below:
§ Stop EC2 instance before creating an EBS snapshot
§ Unmount and detach the EBS volume from the EC2 instance - only then take a snapshot
Issues:
- Can't export snapshot outside of AWS
- No snapshot deduplication capabilities
- No built-in snapshot scheduling mechanism – need to combine CloudWatch and cron
Copying
- Can copy snapshot into another region
- Can optionally encrypt along the way
- Can have up to 5 copy requests running at the same time
- Trying to copy a snapshot with no access to its encryption key – copy will “fail silently”, with no error message
- Tags don’t get copied over
- Can copy across regions: for expansion or disaster recovery or compliance
Creating
- Remains in 'Pending' status from when create command initiated until all data is transferred to snapshot on S3. Only after that is marked as 'Complete'
- Can still access the volume meanwhile (pending) – access will be slow, a lot of reads happening
- Anything post-‘Create command’ is not included in snapshot
- For a complete snapshot of a non-root (non-boot) volume:
§ Stop read/writes
§ Detach
§ Start snapshot
§ Re-attach the volume while snapshot is still being created
- For a complete snapshot of a root (boot) volume:
§ Stop the instance
§ Careful if there are any Instance-store attached volumes – data will be lost
Snapshots are Incremental
- Only changes are captured
- Low cost storage on S3
- You are paying for:
§ Data transfer to S3
§ Storage on S3
§ you need to maintain only the latest one, it is incremental and complete. Older snapshots can be archived or deleted.
- En/de-cryption happens on EC2 not on the attached EBS
- NEW: CAN encrypt root volume – specify this when creating EC2
- All EC2 families support volume encryption but NOT all EC2 instance types
- EBS encryption is not supported on Free tier EC2's
- All EBS volumes support encryption
- Snapshots is same as volume: encrypted volume = encrypted snapshot; not=not
- Can copy a snapshot and choose encryption for the copy. Use that to launch a new EBS instance.
- Data at rest:
§ can use 3rd party encryption tools
§ use encrypted EBS volumes
§ use encryption on OS level – encryption by OS plugins
§ encrypt data before transferring to volume
§ use encrypted file system on top of EBS volume
- Data in transit – since encryption takes place on EC2, in-transit data is encrypted
- To encrypt data off a non-encrypted volume:
§ Attach a new encrypted volume to same EC2
§ Copy data over
OR
§ Create an encrypted snapshot of un-encrypted volume
§ Use this snapshot to create a new EBS - which will be encrypted too
§ Attach it to EC2
- For the first encrypted volume KMS creates a default CMK. It is used to encrypt snapshots of this the volume and volumes created from these snapshots
- AWS will not allow sharing volumes encrypted with the default CMK. Copy, change encryption key and then share
- Subsequent encrypted volumes use unique/separate AES256 bits encryption key. Same key is used for snapshots etc. off each volume
- Can’t change the key used to encrypt an existing snapshot/volume – copy and specify the new key in process
- Other AWS lingo terms for EBS encryption:
§ AWS EBS Encryption
§ OS Level Encryption
§ 3rd party encryption tools
- Use non-default Custom key (can’t share if default key is used)
- Create cross-account permissions to allow the access to the key used to encrypt the snapshot
- Make the snapshot private
-
Log into the receiving account
and make a copy re-encrypting with your own key. Can’t use the snapshot
immediately – need to make a copy.
No comments:
Post a Comment