AI Security Maturity Model·AWS v1.0.0

Drag to explore · pinch to zoom
Home / Reference architectures

Reference architectures

Two reference paths for hosting generative AI workloads on AWS. The Generative AI OU (multi-account) is the recommended target for enterprise workloads; the single-account variant is a valid entry point for smaller teams and proofs of concept, with a clear path to graduate to the OU.

Generative AI OU (multi-account) The default for enterprise AI workloads: it enforces controls through OU- and account-level SCPs and simplifies least-privilege by separating application from model services. Single account (entry point) A pragmatic starting point for small teams, a single business unit, or proofs of concept that do not yet have a multi-account landing zone. Treat it as a stage, not a destination: as the workload grows, graduate to the Generative AI OU to gain account-level isolation and SCP-enforced controls.

Generative AI OU (multi-account)

A Generative AI OU with an Application account and a Generative AI account (Amazon Bedrock and associated services), on top of the foundational accounts: Org Management, Security Tooling, Log Archive, Network, and Shared Services.

AWS Organizations Foundational accounts (AWS SRA core) Security tooling (delegated admin) Security Hub GuardDuty Config Macie Inspector Control Tower Log archive CloudTrail S3 WORM Central, tamper- resistant logs Network / inspection Net FW DNS FW Egress control & inspection Generative AI OU (dedicated) Application account Your traditional workload / UI Cognito WAF API GW Lambda Authenticates users, validates input, calls Bedrock via API. Private Link Generative AI account Amazon Bedrock + AgentCore Bedrock KMS Vectors Comprehend KB data Secrets CloudWatch SageMaker Guardrails on I/O, session isolation, private endpoints, least-privilege. Account separation enforces controls via OU- and account-level SCPs and simplifies least-privilege. A single Generative AI account with IAM roles is a valid smaller-scale variant.
Generative AI OU extending the AWS SRA Workloads OU.

When to use

The default for enterprise AI workloads: it enforces controls through OU- and account-level SCPs and simplifies least-privilege by separating application from model services.

Design principles

  • Separate the application account from the generative AI account.
  • Inherit foundational security accounts from the AWS SRA core.
  • Enforce guardrails and centralized governance in the Generative AI account.
  • Keep model and data access private through VPC endpoints.

AWS services

Amazon Bedrock AWS IAM AWS KMS Amazon Bedrock Guardrails AWS CloudTrail

Single account (entry point)

The application and the generative AI services (Amazon Bedrock, guardrails, knowledge bases) live in one AWS account, separated logically by IAM roles and policies rather than account boundaries. Logging stays in the same account via CloudTrail and CloudWatch, ideally exported to an access-controlled S3 bucket.

Single AWS account Application tier (IAM role) Your traditional workload / UI Cognito WAF API GW Lambda Authenticates users, validates input, assumes a scoped role to call Bedrock. IAM role Generative AI tier (IAM role) Amazon Bedrock + AgentCore Bedrock KMS Vectors Comprehend KB data Secrets GuardDuty SageMaker Guardrails on I/O, private endpoints, dedicated KMS keys, least-privilege. In-account logging (export to a controlled bucket) CloudTrail CloudWatch S3 (logs) No separate Log Archive account yet: centralize these logs when you graduate. Separation here is logical (IAM roles + resource policies), not account-level. This is a valid entry point; graduate to the multi-account Generative AI OU for SCP-enforced isolation as you scale.
Single account with application and generative AI tiers separated by IAM.

When to use

A pragmatic starting point for small teams, a single business unit, or proofs of concept that do not yet have a multi-account landing zone. Treat it as a stage, not a destination: as the workload grows, graduate to the Generative AI OU to gain account-level isolation and SCP-enforced controls.

Design principles

  • Separate application and model duties with distinct least-privilege IAM roles, not shared credentials.
  • Isolate data and model access with resource policies, VPC endpoints, and dedicated KMS keys.
  • Apply Amazon Bedrock Guardrails on inputs and outputs from day one.
  • Send CloudTrail and CloudWatch logs to an access-controlled bucket you can later centralize.
  • Plan the graduation path to a multi-account Generative AI OU before scale forces it.

AWS services

Amazon Bedrock AWS IAM AWS KMS Amazon Bedrock Guardrails Amazon CloudWatch AWS CloudTrail