Resource based policy

Imagine you have two AWS accounts, account A & account B. There are AWS resources in the account B which you want to share with account A. Let's say an S3 bucket for example.

This can be achieved as follows:

1. Create an IAM role in account B which can access that S3 bucket. Let the users from account A assume that role in account B and eventually access the S3 bucket in account B. The role acts as a proxy here. One of the disadvantages of this case is the user context is changed from account A's user to account B's role. That means when the context is changed to account B's role the user will not be able to access resources in account A anymore. This is a user based policy.

2. There are some resources in AWS you can attach the resource based policies to. You can mention the list of AWS accounts which can access this resource in this policy. The user will be able to access that S3 bucket in account B. At the same time, the user will also be accesing the resources in account A.

Comments

AWS Route53 - Private Hosted Zone

AWS - Error - An error occurred (ExpiredToken) when calling the DescribeStacks operation: The security token included in the request is expired

Error: An error occurred (ExpiredToken) when calling the DescribeStacks operation: The security token included in the request is expired. Reason: It occurred when I ran a MAKE command with a profile having expired token (security credentials) Fix: Generate new security credentials (aws sts assume-role) and run the command again

High availability (Multi-AZ) for Amazon RDS

There is something called failover technology in Amazon. AWS RDS's Multi-AZ deployment uses this technology. If you enable Multi-AZ for an RDS DB, say MySQL DB, RDS automatically creates a standby replica in a different AZ. If the primary DB instance is in AZ-1A, then RDS creates a standby replica in AZ-1B (for example). Suppose I add a new row to a table in the primary DB, then the same row is added, almost in the same time, in the standby replica. This is called as synchronous replication . Thus, standby replicas are useful during DB instance failure/ AZ disruption . How? Because, there is no need to create a backup later because the backup has already been created. This gives high availability during planned system maintenance. Normal backup operation - I/O activities are blocked in the primary database Automated backup operation (standby replica) - I/O activities are not blocked This standby replica is not similar to read replica (which is used for disaster recovery). S...

Ayyappu MK

Search This Blog