Skip to main content

Enterprise AWS Deployment Patterns

Profile architecture for enterprise environments spanning single-account setups to 60+ account AWS Landing Zones.

Prerequisites

  • Python 3.11+ with UV package manager
  • Docker
  • Taskfile (task --version)
  • AWS Identity Center (SSO) profiles configured

Multi-Account Profile Architecture

All ADLC tooling reads three environment variables. Set them once per organisation tier:

Tier 1: AWS Landing Zone (60+ Accounts)

export MANAGEMENT_PROFILE="org-admin-ReadOnlyAccess-<MANAGEMENT_ACCOUNT_ID>"
export BILLING_PROFILE="org-billing-ReadOnlyAccess-<BILLING_ACCOUNT_ID>"
export CENTRALISED_OPS_PROFILE="ops-ReadOnlyAccess-<OPS_ACCOUNT_ID>"

Separate management, billing, and operations accounts with SCP-enforced boundaries.

Tier 2: Mid-Size (10-30 Accounts)

export MANAGEMENT_PROFILE="admin-ReadOnlyAccess-<ACCOUNT_ID>"
export BILLING_PROFILE="billing-ReadOnlyAccess-<ACCOUNT_ID>"
export CENTRALISED_OPS_PROFILE="ops-ReadOnlyAccess-<ACCOUNT_ID>"

Tier 3: Single Account

export MANAGEMENT_PROFILE="single-account-admin"
export BILLING_PROFILE="single-account-admin"
export CENTRALISED_OPS_PROFILE="single-account-admin"

All three variables point to the same account. Same tools and workflows apply — only scope differs.

tip

For single-account setups, all three profile variables can reference the same profile name. The tooling is profile-agnostic — it calls the same AWS APIs regardless of whether the profiles resolve to one account or sixty.

Deployment

Standard (Taskfile)

git clone <repository-url> && cd <project-directory>
task install # UV + dependencies
task validate # Profile connectivity + permissions
task agile-workflow # Launch with approval gates

Containerised (Docker)

docker compose up -d  # Uses profiles from environment
task validate # Same validation, containerised execution

Validation

Use task commands — they wrap profile resolution, SSO refresh, and error handling:

task validate                              # Full profile + permission check
task sso-status # SSO session health
runbooks finops --profile $BILLING_PROFILE --dry-run # Cost Explorer access
runbooks inventory --profile $CENTRALISED_OPS_PROFILE # Resource inventory
warning

Never use long-term IAM access keys (AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY) with ADLC tooling. All profiles must be AWS Identity Center SSO profiles. Long-term keys bypass SCP enforcement and produce unbounded blast radius on credential compromise.

Quality Tiers

TierQuality GateDeploy SuccessExecution Target
Enterprise95%98%2s
Standard90%95%4s
Development80%90%6s

Security

PrincipleImplementation
Least-privilegeReadOnlyAccess profiles for all analysis operations
No stored credentialsAWS Identity Center SSO; env vars for local dev only
Account isolationTAG-based authorisation + SCP boundaries (see cost-explorer-access-patterns.md)

Account-Scoped Access Pattern

For organisations requiring account-level cost isolation, the centralised billing profile holds org-wide visibility while per-account profiles scope to a single team boundary. All profiles use the same runbooks CLI — only the visibility changes.

info

For detailed cost-isolation configuration including TAG-based authorisation and SCP boundary examples, see the FinOps Architecture guide at .claude/skills/finops/cross-validation-references/cost-explorer-access-patterns.md.

Details: .claude/skills/finops/cross-validation-references/cost-explorer-access-patterns.md


Origin: Enterprise deployment experience across Landing Zone, mid-size, and single-account AWS organisations. Adapted for ADLC framework-level guidance.