I'm trying to copy an encrypted EBS instance from one AWS account to another as part of a disaster recovery process.
I'm hoping someone has done this before, I'm basically looking for a clever way to approach it.
The big problem seems to with the encryption keys.
I've been able to create a k8s pod to do the "backup" automatically but when introducing encryption it seems to break because it can't find the key.
One more note, I've familiarized myself with the sharing process, that is the EBS is shared with a different account then form that account I would do the copy and so forth - found a few posts here but nothing similar to exactly what I'm looking for.
Advanced thanks.
When you create an encrypted EBS volume, you will want to specify an custom encryption key. The key can then be shared across regions/accounts.
You must use a custom key if you want to copy the snapshot to another account
When you start the copy operation you can specify a new key. According to AWS:
Using a new key for the copy provides an additional level of isolation
between the two accounts. As part of the copy operation, the data will
be re-encrypted using the new key.
Please review https://aws.amazon.com/blogs/aws/new-cross-account-copying-of-encrypted-ebs-snapshots/
You can find some additional information about how to copy encrypted EBS snapshot to another account in this link:
https://n2ws.com/how-to-guides/how-to-copy-encrypted-aws-snapshots.html
Another handy solution for AWS disaster recovery that we implemented in my company is to copy EBS snapshots from one region to another. It can be done by using the AWS Management Console or the AWS CLI.
Related
I am a beginner of AWS and I have a question about the EBS volume. I know that when we create an EBS volume, there is an option for enabling the encryption (default is unencrypted). With security concern, it is better to enable the encryption of EBS volume, why EBS is not force to be encrypted? What is the use cases/reasons for choosing unencrypted EBS volume?
My guess is that it would be because Amazon EBS encryption was not always available. It was a feature added at some point, so the ability to use a non-encrypted volume remains.
Encrypted volumes also make some tasks more difficult, such as sharing AMIs publicly or between Accounts. There's plenty of reason to offer non-encrypted volumes.
Therefore, it would not be a good idea to "force" encryption.
However, you are welcome to force encryption within your organization, but be aware that there may be times when you do not want it activated.
This is likely down to the fact that it might change the way in which users can interact with their resources (and is technically a breaking change as the previous default was unencrypted volumes), so a user should understand these changes before they actually start using encryption.
Encryption in AWS is actively encouraged but by enabling it for services such as EBS, it does change some flows for example snapshots will be encrypted. If you need to migrate these between regions (or accounts) for DR you have additional steps to allow this.
Regarding security, yes it is better for security primarily from the physical level of AWS. It means that should anyone gain physical access to the storage they will not be able to access the data without access to the key used to encrypt the volume. However, should someone SSH into your server it will behave like normal.
AWS has enabled a feature for users who was this to be the default, you need to Opt-In to default encryption to enable this.
Hi I am an AWS newbie and I am moving an AMI instance from one availability zone to another, and I was wondering if I need to select the encrypt EBS Snapshot option when copying an AMI from say Oregon to Virginia.
If I don't encrypt the snapshot, does that mean any hacker can see what is in my AMI enroute from one availability zone to another?
Thanks
The option to encrypt an EBS Snapshot provides encryption-at-rest. This is to prevent someone with access to the underlying hardware, like an Amazon employee, from being able to read the information on the disk.
Your concern that someone could see the data as it is transmitted between regions is covered by encyption-in-motion. AWS will automatically use SSL encryption to ensure that the data being transmitted will not be readable by anyone.
When copying data over a public network (including to a cloud) you should always use encryption. Amazon provides encryption for data at rest, data movements within AWS offerings and for any snapshots you create. When moving data they do recommend using a custom CMK, not your standard one, and then allowing individual users access to that key. Their documentation has more details: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html.
And since you can't directly change the encryption status of a volume, encrypting your snapshot is the way to go. Depending on your needs, you may decide to encrypt new volumes, or all snapshots -- regardless of availability zone.
If you'd like more information on managing EBS volumes, NetApp has a good article here.
I am using AWS to launch a EC2 instance. Fortunately I did it without problem.
What I need now is to make a backup of the data.
I think snapshot is a good way to do it. I have been doing some research and I found a good tool to do it automatically (https://github.com/colinbjohnson/aws-missing-tools/tree/master/ec2-automate-backup).
The problem is that I think it is not enough to make snapshots. In my opinion a copy of the last snapshot needs to be in another region, but I don't know how to do it automatically. I have been searching on internet and only found this:
http://docs.aws.amazon.com/cli/latest/reference/ec2/copy-snapshot.html. The problem is that I don't know the snapshot id (considering it is generated automatically by the first tool I mentioned).
The question is: Do you know any tool that can help me with this problem? If don't, do you know another approach to get a solution.
It is important to know that the service which is given doesn't need to be up 24 hs.
It is my first time using servers so I don't know how long a region in amazon can be down.
You do not need to know a volume ID to use copy-snapshot in the AWS CLI. When executing the command you provide a value to the --source-snapshot-id option. This specifies the ID of the snapshot you want to copy. A snapshot can be copied in the same region or to another region via the --destination-region option.
You can simply call create-snapshot and then copy-snapshot giving it the generated snapshot ID to copy the snapshot to another region. This could be automated via a cron job if necessary.
You can set up a cron job to invoke aws cli which can copy the snapshots to an S3 bucket 'A'. And, cross region bucket replication can be enabled from the source bucket 'A' in region 1 to destination bucket 'B' in region 2. Whenever a snapshot is uploaded to 'A', it'll get replicated to 'B' as well. So, in case first region becomes offline, you can restore volumes from the snapshots in 'B' bucket in region 2.
I was thinking what if My AWS Account get deleted/inaccessible one fine day? (may sound weird). Have anyone implemented any solution for this? Can we have back from one AWS account to another AWS account?
There are several things you can do, one is to make sure you have at least two administrator accounts, one that you use, and one that you store away in a safe place and only use for emergencies.
The second is to setup a completely seperate AWS account as a 'backup', with its own set of credentials. You can grant cross-account access from your primary account, to your backup account but only allow the primary account to 'put' or backup objects to the backup account, so that even if your primary account is compromised, the attacker can't do harm to the second account from the primary account.
The actual process to backup your services on one account to another is going to vary depending on which services you are using, but the concept is the same - backup the data to s3 and then copy the data from s3 in your primary account to s3 in the backup account - and make sure the primary account only has enough access to the second account to 'put' things, not delete. Nobody in your company should have access to both of those sets of credentials (assuming your company is not tiny).
You don't want to be this company that was put out of business when there account was compromised:
https://threatpost.com/hacker-puts-hosting-service-code-spaces-out-of-business/106761/
Also, this video, from AWS Reinvent 2015 (starting around 50 minutes in), listen to how AirBNB protects against these issues in just this way:
https://www.youtube.com/watch?v=eHg8LD5KNC0
Finally After lot of reasearch and help from Skeddly, I found a solution for Linux machines.
Via Skeddly we can copy EBS snapshots to another AWS account hassle free.It works brilliant.Now even if my Primary AWS account is compromised, I have all EBS snapshots to start with by BCP AWS account for linux machines ;)
Now am hunting for windows machine solution for which I already got an idea... ;)
We all know about what happened to Cold Spaces getting hacked and their AWS account essentially erased. I'm trying to put together recommendation on set of tools, best practices on archiving my entire production AWS account into a backup only where only I would have access to. The backup account will be purely for DR purposes storing EBS snapshots, AMI's, RDS etc.
Thoughts?
Separating the production account from the backup account for DR purposes is an excellent idea.
Setting up a "cross-account" backup solution can be based on the EBS snapshot sharing feature that is currently not available for RDS.
If you want to implement such a solution, please consider the following:
Will the snapshots be stored in both the source and DR accounts? If they are, it will cost you twice.
How do you protect the credentials of the DR account? You should make sure the credentials used to copy snapshots across accounts are not permitted to delete snapshots.
Consider the way older snapshots get deleted at some point. You may want to deal with snapshot deletion separately using different credentials.
Make sure your snapshots can be easily recovered back from the DR account to the original account
Think of ways to automate this cross-account process and make it simple and error free
The company I work for recently released a product called “Cloud Protection Manager (CPM) v1.8.0” in the AWS Marketplace which supports cross-account backup and recovery in AWS and a process where a special account is used for DR only.
I think you would be able to setup A VPC and then use VPC peering to see the other account and access S3 in that account.
To prevent something like coldspaces, make sure you use MFA authentication (no excuse for not using it, the google authentication app for your phone is free and safer than just having a single password as protection.
Also dont use the account owner but setup a separate IAM role with just the permissions you need (and enable MFA on this account as well).
Only issues is that VPC peering doesnt work across regions which would be nicer than having the DR in a different AZ in the same region.