I will discuss RAM (Resource Access Manager) and Service Quotas in this article. These two topics are largely unrelated, but, as I am doing with the other articles in this Solutions Architect Pro training, I want to make sure to publish my notes, re-written into blog articles, to help me solidify the concepts. These two topics stood alone, so I am putting them together in this article.
The RAM service allows you to share resources between AWS accounts. Some resources can be shared between any AWS accounts, and others can only be shared between AWS accounts in the same organization. However, not all AWS products support RAM, so the service must be compatible with RAM to use the tool.
One important note when working with RAM is that availability zones in AWS are not necessarily the same between accounts. For instance, the availability zone us-east-1 in one account may be labeled us-east-3 in another. RAM uses availability zone IDs, which are always consistent, to help reconcile this issue.
RAM allows an owner account to share a resource with other accounts. The owner account sets this up by creating and naming a Resource Share. The owner account retains full ownership of the resource and decides which principals (in this case, we are talking about AWS accounts, Organizational Units, or Organizations) where the resource will be shared.
In the case of organizations, the organization management account can turn off the feature of RAM that requires resources to be accepted by invited accounts. In all other cases, the resource group creation will generate an invitation that the member account must accept.
The participant accounts can use shared resources as if they were in the participant account, for the most part. But the participant account will have a ‘read only’ view of the resource. So, for instance, if subnets are shared, the participant accounts can launch EC2 instances into the subnets. Still, they cannot alter the route tables, gateways, or other subnet and VPC configurations.
In many cases, RAM is helpful to avoid having to set up peering, transit gateways, and other solutions to integrate networking between member accounts of an organization. It certainly simplifies that process.
Service Quotas are a simple concept within AWS that document and control how many of each resource an account may use, sometimes within a region and sometimes account-wide.
These service quotas limit the resources an account can deploy. There are two different types of service quotas.
- Service Quotas with hard Limits
- Service Quotas with limits that can be changed
If a service quota has a limit that can be altered, you can request a quota increase through the service quota service in the AWS console. You can also interact with the service quota systems in AWS using the command line - including using the command line to request increases in quotas.
There is also a facility to add Cloudwatch alerts based on utilization compared to service quotas using the console and the AWS command line.
When developing complex AWS solutions, it is crucial to consider the quotas for the accounts in your solution. Small increases happen quickly, but more significant increases may require more time and human involvement (as well as justification).