Photo by Simon Wilkes on Unsplash
As a best practice, it is recommended to have sub-prod and prod environments in a separate AWS accounts. This solves multiple problems, but also causes some complexities as listed below.
How to create a hierarchy of AWS Accounts using AWS Organizations?
Where should the hosted zones for domain names be provisioned?
How will the requests be correctly redirected to sub-prod and prod environments, when hosted zones are being managed at a single place?
How to control developer access on prod to avoid accidental changes?
How to implement Terraform IaC pipelines to roll out changes for testing only in sub-prod environment? How to tackle access controls required by pipelines?
How to develop Terraform IaC to comprehensively contain common and environment specific code?
In this post, we will focus on the first point. The rest of the points deserve a post individually. This, and few more posts which follow, are important for anyone who is looking forward to get started with SaaS development on AWS, as it lays the tracks for smooth development operations - did I say DevOps?
AWS Orgs and Management account
Creating separate AWS accounts individually can be a cumbersome task in the long run. For example, we have to individually manage the billing for each account every month. At first, handling a few accounts may look manageable. But in reality, the list of AWS accounts can very well go beyond a handful.
AWS Organizations is a service that helps manage multiple AWS accounts through a single “management” account. In terms of billing, all the resource utilizations, billing, and auditing requirements are consolidated in the management account. The best part about this is that these accounts can be managed programatically.
The example used in this post is an extract of the lessons learnt this week while building my micro-SaaS service.
So to begin with, we need a management account. I prefer to call this as root account, from where all other AWS Accounts are created. There is a whole terminology aspect associated with this, but since we are working on a simple product, I would not prefer complicating the same. However, it is a recommended practice to be followed by bigger orgnizations. It offers granular control by creating organizational units, policy control, and user account restrictions.
Let us assume that our application development happens in 2 stages, and thus needs 2 environments - beta and prod. First, we create a root AWS account, a.k.a. management account. Create the same and navigate to AWS Organizations in the web console, to create child AWS accounts from the same console. So at this point, the hierarchy of our AWS accounts is quite simple as shown below.
Management Account
beta
prod
Please note that, if you already have an existing AWS account, but you don’t want it to be the management account, but would still want to continue as a dev/beta account, then it is possible to include the same by following the process of invitations.
When we create an account using AWS Organizations, an IAM role - OrganizationAccountAccessRole - is automatically created that provides full admin access to the root account. Any user in the root account that assumes this role can have full admin access over the member accounts. Use this role carefully.
In the next post, I will discuss my decisions to manage specific resources and entities in root and member accounts (beta and prod). The context of micro-SaaS is a major driving factor in most of these decisions, and hopefully they make sense. I am more than keen to know your thoughts on this as well as upcoming posts.
Thanks for reading Let's Do Tech! Subscribe for free to receive weekly updates on my solo journey.