AWS: Multi-Account Architecture
How many AWS accounts should I have? What would be the best architecture for my use-case? This is the first thing which comes in mind while setting up infra for your organization on AWS or any public cloud platform. This blog is to give you understanding of key areas to focus while finalizing the design.
Designing your cloud infrastructure is the most important and critical area where you must invest time in brainstorming and planning best approach that provides strong governance, caters for compliance needs because once you start deploying applications then there is no refactoring. Many a times, people end up having mess in their accounts, downtime by novice just because of poor architecture.
Let’s list down multiple factors which play key role in deciding the appropriate number of AWS account required for an organization -
- Resource isolation
- Security isolation
- Administrative isolation
- Cost allocation and billing
- AWS limit exhaustion
- Micro service or Monolithic applications
- Infrastructure-as-Code
- Number of environments required
- Business Unit separation
- Audit and Compliance
- Management strain
- Many teams or single team
Strategies of AWS Deployment
Single account model can be useful for an overhead perspective, its quite easy to manage. However as you start adding multiple projects, multiple applications, multiple development teams into a single account, the overhead get more and more complex. You need pretty complex IAM policies and robust tagging else you could have catastrophic results.
And using 1000’s of accounts off-course causes you to have lot of management overhead, however the security isolation between resources/ users is great and billing separation is very clean picture.
So none of the model is an ideal one, we need something in between both.
What accounts should I create?
There should be clear segregation of accounts as per roles/responsibilities of teams, this gives clean picture of account being used.
Billing Account
It allows to get holistic view of entire organization’s spending structure. This is primarily for finance team or Infra cost management team who barely knows the operations of cloud but bothers about the spending being done at BU or component level. It has -
— Consolidated billing
— No connection to data center
— Linked to all other AWS accounts
— No resources running
Security Account
Identity and Security accounts can be used to centrally manage AWS user accounts, allowing access to all other accounts via cross-account roles removing the need to create users in any other account. All security related tools can be provisioned here along with auditing of logs coming all other accounts. Various purpose of this account are-
— IAM: Single place for Cross-account access management
— Versioned S3 Buckets
— Centralized server audit logs
— Gather CloudTrail logs of all other AWS accounts
— Scanning tools
— CDN like CloudFront
— Antivirus services
— Other security tools like WAF or IPS
Shared Services Account
It makes sense from a security perspective to share services centrally rather than allowing a mesh of application inter-connectivity throughout many accounts. A shared services account is generally used to provide non-security related services to applications estate wide. We can also extend it for network integration like Direct Connect which can be leveraged by other accounts using virtual interfaces. There could be varied list of services like-
— Deployment tools
— RPM server
— LDAP services
— Route53 or other DNS services
— NTP services
— Artifactory
— Source Code repository manager or issue tracking tools
— Monitoring solutions
— Configuration Management software(Puppet, Ansible, Chef and Salt)
— Centralized log management (EFK)
— AMIs/patching
— Direct Connect
— And other DevOps tools
As per the categorization, central logging systems should exist in “Shared Services account” but for some it could be debatable because of high data transfer cost.
Non-prod Account
This is an application account which can have multiple non-prod environments like Sandbox, Dev, Test, Staging. These non-prod environments can be segregated by robust tagging or can be separated at highest level in an account ie VPC. You can have single or multiple non-prod accounts based on multiple factors like BU, multiple teams, AWS limits, Infrastructure-as-Code.
I would strongly suggest to have separate VPC per environment in non-prod account for the factors already listed above. No single should have or need access to any other environment in this non-prod account, this makes sure all environments are protected from the maximum levels of security and separation.
It is highly recommended to have non-prod account separated from prod application account due to security, administrative reasons.
Prod Account
It is an application account which hosts prod applications only. Similar to non-prod, there could be multiple Prod accounts separated by BU or other special cases of compliance like PCI, HIPPA where one could achieve regulations in same Prod account but we might need separate account to convince them. There should be very restrictive access to this account. It has-
— Connection with billing account for consolidating billing
— Connection with Security account to send audit logs
— Connection with Shared services account to consume services.
— No connection with Non-prod account
Infrastructure-as-Code
In the past few years, it has been observed Infrastructure-as-Code as the most productive way to describe and deploy applications. The biggest player in infrastructure-as-Code is Terraform, which describes all your resources and the connections between them. You write a single template that defines the application infrastructure and it deploys them in a repeatable fashion. Having a template means you can replicate the infrastructure without manual steps. This reduces errors and increases the speed of deployments.
With its rich features, it becomes an important factor while designing your Cloud infrastructure. Having separate VPC per environment is the reason I recommend, because you can replicate your environments very easily whenever required.
Let me give you a real life example- Suppose testing team asks you for a parallel test environment where everything needs to be replicated, then considering above design, imagine how easy it is to replicate that.
Feel free to share your experiences in multi-account approaches in comments!
You can also reach out to me at sanchitbansal26@gmail.com for any queries.
