Answers: <p>To my knowledge there are only Tag based Iam policies available to limit access to resources for certain users or user groups.</p>
  
  <p>Because of this, you should simply be able to tag an RDS snapshot both production and development for you to access it with your development user or group.</p>
  
  <p>There are a large number of security considerations to think through, so don't undermine the security setup. I would therefore expect that only manual tagging is appropriate for this specific use case</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-10-24T06:38:37.530Z
Answers: 2019-10-24T06:38:37.530Z
Answers: jdog
Body: <p>I'm using an AWS account which has different roles for the different environments we use. For example, we have a <code>Development</code> role for our development environment and a <code>Production</code> role for our production environment.</p>
  
  <p>At any point of time, we switch into or assume as one of the roles to access the services in the particular environment. Neither roles can see nor access each other's services and they function as though they are separate accounts.</p>
  
  <p>The problem now is, there are some application issues with an RDS instance in the production environment. The production database resides in the <code>Production</code> role. My intention is to clone the database in production over to the development environment for debugging reasons. However, since the environments are in different roles, they can't see each other's resources. The snapshots of the databases in one environment is not visible in another.</p>
  
  <p>Since the roles are technically not accounts, I can't use the "Share snapshot" feature too because that would require me to input an account number instead of a role name.</p>
  
  <p>Is it possible for me to allow the use of RDS snapshots across account roles so that I can clone the RDS instances? If so, how can I do it in the AWS console?</p>
  
Tags: <amazon-web-services><databases><amazon-rds><role-based-access-control>
Title: How to share RDS snapshots across account roles?
UserDisplayName: xenon
ThreadText: # How to share RDS snapshots across account roles?
  
  (Asked by: username_0 on 2019-10-24)
  
  I'm using an AWS account which has different roles for the different environments we use. For example, we have a `Development` role for our development environment and a `Production` role for our production environment.
  
  At any point of time, we switch into or assume as one of the roles to access the services in the particular environment. Neither roles can see nor access each other's services and they function as though they are separate accounts.
  
  The problem now is, there are some application issues with an RDS instance in the production environment. The production database resides in the `Production` role. My intention is to clone the database in production over to the development environment for debugging reasons. However, since the environments are in different roles, they can't see each other's resources. The snapshots of the databases in one environment is not visible in another.
  
  Since the roles are technically not accounts, I can't use the "Share snapshot" feature too because that would require me to input an account number instead of a role name.
  
  Is it possible for me to allow the use of RDS snapshots across account roles so that I can clone the RDS instances? If so, how can I do it in the AWS console?
  
  **Tags:** amazon-web-services, databases, amazon-rds, role-based-access-control
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2019-10-24. Score: 1
  
  To my knowledge there are only Tag based Iam policies available to limit access to resources for certain users or user groups.
  
  Because of this, you should simply be able to tag an RDS snapshot both production and development for you to access it with your development user or group.
  
  There are a large number of security considerations to think through, so don't undermine the security setup. I would therefore expect that only manual tagging is appropriate for this specific use case
  
  
  ---
  
  