Organizations

Last updated: Nov 4, 2026

---

Rationale

Fluid Attacks has one AWS account for its development and production resources. This agrees with the monorepo paradigm of the code.

These are the primary advantages of the approach with one account:

• It is compatible with the structure of the engineering team of Fluid Attacks. Fluid Attacks has one team in a horizontal hierarchy, without dedicated teams for test/QA, security, networking, or infrastructure.
• The monorepo of Fluid Attacks gives a centralized location with full observability. It is not necessary to split the related configuration.
• It has less complexity and management, primarily in networking and access policies.
• Account isolation is good, but Fluid Attacks implements authentication (Okta SAML) and authorization (IAM roles) correctly. Also, policies, and not isolation, prevent accidental deletion and unauthorized access.
• At this time, the tagging strategy of Fluid Attacks is sufficient to separate costs, and billing aggregation for more than one account could be hard.
• A change to more than one account is hard to undo.

Alternatives

• Establishing, designing and implementing a multi-account environment
• Implementing the recommended OUs and accounts
• Leveraging the services of AWS Control Tower and AWS Identity Center to make management easier

If Fluid Attacks had more teams or isolated products, a multi-account environment could possibly give these advantages:

• It is a recommended best practice for security and governance.
• With more than one account, Fluid Attacks can use more resources than the service limits and quotas of one account permit.
• It decreases the blast radius of a change or configuration error.
• Data residency, and thus GDPR compliance, through Control Tower guardrails.

Usage

Fluid Attacks uses one AWS account to host its AWS resources and their management:

• Cost management
• Access control
• Networking
• Compute
• Storage
• Security
• Logging