Organizations
Rationale
We have a single AWS account to contain our development and production resources. This goes in line with the monorepo paradigm used in the code.
Note: A second account called Innovation is used as a Sandbox OU but is limited to be used as a playground.
The main benefits of using the single-account approach are the following:
- It is compatible with Fluid Attacks' engineering team structure. We are a single team in a horizontal hierarchy, with no dedicated teams for test/QA, security, networking or infrastructure.
- Our monorepo gives us a centralized place with complete observability. No need to split relevant configuration.
- There is less complexity and management, especially in networking and access policies.
- Although account isolation is desirable, authentication (Okta SAML) and authorization (IAM roles) are properly implemented. Besides, accidental deletion and unauthorized access is enforced via policies rather than isolation.
- Our tagging strategy is currently enough to segregate costs, and billing aggregation for multi-account could be difficult.
- A transition to multi-account is hard to undo.
Alternatives
- Establishing, designing and implementing a multi-account environment
- Implementing the recommended OUs and accounts
- Leveraging the services AWS Control Tower and AWS Identity Center to ease the management burden
Some possible benefits of changing to a multi-account environment, having more teams or isolated products, could be the following:
- It is encouraged as a security and governance best practice
- It enables exceeding service limits and quotas
- Limiting the blast radius in case of a change or configuration error
- Data residency, thus GDPR compliance, through Control Tower guardrails
Usage
We use a single AWS account for hosting our AWS resources and their management:
- Cost management
- Access control
- Networking
- Compute
- Storage
- Security
- Logging