<p>On top of protecting your root account as best as you can, you should be able to reduce the risk of such resource deletion if you have more than 1 resource to protect.</p>

<p>For example if all AWS resources you had to protect were 2 RDS database servers, you could create 2 other accounts that have access to only copy the snapshots of one of your database servers each - and no other access to any other resource. This setup would then require an intruder to hack both root accounts of your main and one backup account each, which should be significantly more difficult.</p>

<p>To copy snapshots from one account A (your current RDS account) to account B (your new account) you should need the following parts  (untested)</p>

<ul>
<li>Create a new IAM role in Account A, for access from account B:</li>
</ul>

<p><a href="https://i.sstatic.net/XrRGs.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/XrRGs.png" alt="enter image description here"></a></p>

<ul>
<li><p>Create a new policy for reading RDS snapshots from account A</p>

<pre><code>{
    "Version": "2012-10-17",
    "Statement": [
        {
        "Effect": "Allow",
        "Action":
            [
                "rds:CopyDbSnapshot",
                "rds:DescribeDbSnapshots"


            ],
        "Resource": "arn:aws:rds:::"
        }
   ]
}
</code></pre></li>
</ul>

<p>and assign it to the IAM role</p>

<ul>
<li><p>Check that the "trust policy" is enabled as described in this walk through for another cross account action: <a href="https://aws.amazon.com/blogs/database/setting-up-for-cross-account-native-backup-and-restore-in-amazon-rds-for-microsoft-sql-server/" rel="nofollow noreferrer">https://aws.amazon.com/blogs/database/setting-up-for-cross-account-native-backup-and-restore-in-amazon-rds-for-microsoft-sql-server/</a></p></li>
<li><p>Then in account B, you should be able to run copy-db-snapshot from account B: <a href="https://docs.aws.amazon.com/cli/latest/reference/rds/copy-db-snapshot.html" rel="nofollow noreferrer">https://docs.aws.amazon.com/cli/latest/reference/rds/copy-db-snapshot.html</a></p></li>
<li><p>To automate, I prefer to use Lambda functions, which can simply call AWS API calls, you can trigger them with a Cloudwatch Event</p></li>
</ul>

CC BY-SA 4.0
2019-05-04T23:58:21.083Z
This is what I was looking for details on. How do I go about setting up another account which can copy snapshots in an automated fashion?
Brad
CC BY-SA 4.0
2019-05-06T06:48:32.333Z
Have updated with more details
jdog
CC BY-SA 4.0
2021-03-23T21:21:19.633Z
Just a note that all of this is now part of AWSBackup
jdog
CC BY-SA 4.0
2019-05-04T08:31:20.557Z
2019-05-05T07:07:36.610Z
2019-05-05T07:07:36.610Z
jdog
<p>In terms of your root account, you should be very paranoid about the power it wields and protect it as thoroughly as possible.</p>

<p>I would suggest that you get yourself a Hardware Key Fob as listed in MFA devices on this page: <a href="https://aws.amazon.com/iam/details/mfa/" rel="nofollow noreferrer">https://aws.amazon.com/iam/details/mfa/</a></p>

<p>Having a physical factor means that you can be sure only people with access to the physical device could log in and do that kind of damage. You can even secure it in a physical safe.</p>

<p>If your root account is considerably secure, I would be of the opinion that is Good Enough for DB back-ups. If you're worried about those then s3 or other amazon services will have the same problems. While you could look at other storage options, realistically if your aws root account is compromised it might just be the end of days - I would focus on the security aspect personally.</p>

CC BY-SA 4.0
2019-05-03T15:12:17.663Z
2019-05-03T15:12:17.663Z
Max Colledge
<p>AWS Provides a great solution to provide point-in-time recovery backups within RDS. However, while we take every measure to protect the root account, I'm paranoid that if someone were to gain access they can wipe the entire AWS account including all backups and therefore take the whole company down. What are the best ways to handle this? Do you have 100% trust in your root account and policies to prevent someone malicious from wiping the database and all backups?</p>

<p>What are the best ways to handle an offsite backup to a different RDS account? Should we simply execute <code>mysqldump</code> periodically from a separate system, or is there a better way?</p>

<amazon-web-services><backup><mysql><amazon-rds>
How to handle AWS Offsite or cross-account RDS (mysql) backups?
Brad
# How to handle AWS Offsite or cross-account RDS (mysql) backups?

(Asked by: username_0 on 2019-05-03)

AWS Provides a great solution to provide point-in-time recovery backups within RDS. However, while we take every measure to protect the root account, I'm paranoid that if someone were to gain access they can wipe the entire AWS account including all backups and therefore take the whole company down. What are the best ways to handle this? Do you have 100% trust in your root account and policies to prevent someone malicious from wiping the database and all backups?

What are the best ways to handle an offsite backup to a different RDS account? Should we simply execute `mysqldump` periodically from a separate system, or is there a better way?

**Tags:** amazon-web-services, backup, mysql, amazon-rds


---

## 2 answers

### Answer by username_1 on 2019-05-04. Score: 2

On top of protecting your root account as best as you can, you should be able to reduce the risk of such resource deletion if you have more than 1 resource to protect.
For example if all AWS resources you had to protect were 2 RDS database servers, you could create 2 other accounts that have access to only copy the snapshots of one of your database servers each - and no other access to any other resource. This setup would then require an intruder to hack both root accounts of your main and one backup account each, which should be significantly more difficult.
To copy snapshots from one account A (your current RDS account) to account B (your new account) you should need the following parts  (untested)

Create a new IAM role in Account A, for access from account B:



Create a new policy for reading RDS snapshots from account A
{
    "Version": "2012-10-17",
    "Statement": [
        {
        "Effect": "Allow",
        "Action":
            [
                "rds:CopyDbSnapshot",
                "rds:DescribeDbSnapshots"


            ],
        "Resource": "arn:aws:rds:::"
        }
   ]
}


and assign it to the IAM role

Check that the "trust policy" is enabled as described in this walk through for another cross account action: https://aws.amazon.com/blogs/database/setting-up-for-cross-account-native-backup-and-restore-in-amazon-rds-for-microsoft-sql-server/
Then in account B, you should be able to run copy-db-snapshot from account B: https://docs.aws.amazon.com/cli/latest/reference/rds/copy-db-snapshot.html
To automate, I prefer to use Lambda functions, which can simply call AWS API calls, you can trigger them with a Cloudwatch Event

> **Comments:**
> **username_0**: This is what I was looking for details on. How do I go about setting up another account which can copy snapshots in an automated fashion?  
> **username_1**: Have updated with more details  
> **username_1**: Just a note that all of this is now part of AWSBackup  

---

### Answer by username_2 on 2019-05-03. Score: 0

In terms of your root account, you should be very paranoid about the power it wields and protect it as thoroughly as possible.

I would suggest that you get yourself a Hardware Key Fob as listed in MFA devices on this page: <https://aws.amazon.com/iam/details/mfa/>

Having a physical factor means that you can be sure only people with access to the physical device could log in and do that kind of damage. You can even secure it in a physical safe.

If your root account is considerably secure, I would be of the opinion that is Good Enough for DB back-ups. If you're worried about those then s3 or other amazon services will have the same problems. While you could look at other storage options, realistically if your aws root account is compromised it might just be the end of days - I would focus on the security aspect personally.


---

