AWS Organization Structure & Multi-Accounts for Environment Isolation

AWS Organization Structure & Multi-Accounts for Environment Isolation

Environments

Environment isolation refers to using separate, dedicated spaces for different stages of the software development lifecycle. This ensures that activities in one environment, such as development or testing, do not impact or interfere with other activities, such as production. It helps maintain stability, prevents unexpected errors, and allows for safe testing and deployment of new features or updates.


Figure 1: Environment Isolation


We can introduce the isolated environments below for different use cases widely accepted in the community.


Sandbox

An experimental space where developers can freely test code changes without affecting other environments. It’s often used for early-stage development and exploration.


Development (dev)

This is where developers integrate new code and features. It’s the first formal stage of the development process, primarily used for functionality testing.


Quality Assurance (qa)

An environment dedicated to rigorous testing. QA teams validate the new features against requirements to ensure they work as expected and are bug-free.


Staging (stg)

A pre-production environment that mirrors production as closely as possible. It’s used for final testing to catch any remaining issues before going live.


Production (prod)

The live environment where the application is released to end-users. It should be stable and secure, with any changes thoroughly tested in previous environments.


Administration (admin)

This environment is a specialized setup dedicated to managing and handling administrative tasks and common workloads that affect all other environments. It's used for centralized management of system configurations, user access controls, and global resources. This environment helps segregate administrative duties from development and operational activities, ensuring better security and control over the entire infrastructure.


+--------------------+--------+
| Environment        | Prefix |
+--------------------+--------+
| Development        | dev    |
| Quality Assurance  | qa     |
| Staging            | stg    |
| Production         | prod   |
| Administration     | admin  |
+--------------------+--------+
        


AWS Organization Structure

AWS Organization can be considered the logical structure of AWS Account which is organized in a hierarchy. An AWS organization consists of 3 main components.

  1. Organization Units (OUs) - OU is a logical structure that can be created to organize AWS accounts that relate to different business use cases. By default, Root OU is available and under that nested OUs can be created.
  2. AWS Accounts - In an organization there can be multiple AWS accounts which is organized under Root OU or nested OUs
  3. Management Account: The management account can be considered the root account, and this is a special account that manages the entire AWS Organization, and its structure as the central control panel. As mentioned in Figure 2 you can see a similar view in the management account if you have created an AWS Organization to manage your AWS accounts.


In our use case, we are trying to implement isolated environments as described above, and let's dive deep into that.


AWS Organization Structure
Figure 2: Organization Structure
Note: the "Tenant" OU can be considered an optional OU. Explicitly I included this to give an idea that parent OUs can be set after creating any OU. In addition to that if you are a multi-tenant service provider to implement silos multitenancy pattern this approach can be used to organize your AWS account structure

  • Administration OU: This can be used to isolate operational and administrative workloads like CI/CD pipelines, Central ECR repositories, and artifacts buckets.
  • Engineering OU: Most of the engineering operations are isolated into this OU
  • Production OU: Any production-related workloads are isolated into this OU


AWS Organizations, you can group accounts under Organizational Units (OUs) and apply Service Control Policies (SCPs) for centralized management. Environment isolation is achieved through separate production, staging, and development accounts, and network isolation via VPCs, security groups, and network ACLs. Data is isolated using dedicated S3 buckets and databases for each account.

Monitoring, logging, and cost management tools ensure security, compliance can be controlled from a central location.


Control Tower & IAM Identity Center Integration

AWS Control Tower and IAM Identity Center streamline the setup and management of multi-account environments and user access on AWS.

AWS Control Tower provides a centralized, automated way to set up and govern a secure, compliant multi-account AWS environment. It uses AWS Organizations to create and manage accounts, implementing guardrails to enforce governance, security, and compliance policies. This ensures that all accounts adhere to best practices and organizational standards from the outset.

IAM Identity Center (formerly AWS Single Sign-On) simplifies user access management across multiple AWS accounts. It provides centralized control over user identities and permissions, enabling single sign-on access to AWS accounts and applications. IAM Identity Center integrates with existing identity sources, like Active Directory or external identity providers, to manage user authentication and authorization seamlessly.

Together, AWS Control Tower and IAM Identity Center help organizations efficiently manage multiple AWS accounts and user access. Control Tower ensures a standardized, compliant multi-account setup, while IAM Identity Center provides streamlined user access management, enhancing security and operational efficiency.


Pros & Cons of the AWS Multi-Account Approach

Pros

Difference stages of any workload can be fully isolated

  • Easy to monitor and manage the cost
  • Easy access reduces the security risk
  • The risk of the cloud service providers' quotas can be ignored
  • Ideal for large-scale projects run by multiple teams


Cons

  • Administration can be complex for small projects since there are some additional configurations to add compared to a single account approach.

References

要查看或添加评论,请登录

Hashan Perera的更多文章

社区洞察

其他会员也浏览了