c1.11 Isolate AI workloads across accounts with guardrails
Separate development, inference, and training into distinct accounts/OUs with SCPs and Config baselines, so blast radius is contained and governance is consistent.
Implementation guidance
How to implement on AWS
Establish a Generative AI OU with separate development, inference, and (where used) training accounts. Enforce SCPs (e.g. deny training actions in inference accounts), apply AWS Config conformance packs for a common baseline, and aggregate logs to a central log-archive account.
Contain blast radius with account boundaries
The strongest isolation boundary in AWS is the account. Separating development, inference/production, and model training/customization into distinct accounts (grouped into OUs) means a compromise or misconfiguration in one does not reach the others. AWS Organizations then lets you set service control policies (SCPs) — organization-wide guardrails that cap the maximum permissions any principal in an account can have, no matter how permissive their IAM policy is.
An SCP does not grant access; it sets the ceiling. You still grant day-to-day permissions with IAM.
Restrict which models can be used, org-wide
A common guardrail is to deny access to any foundation model except the ones your organization has approved and risk-assessed. The AWS-documented pattern uses NotResource so everything except the listed model ARNs is denied:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyUnapprovedBedrockModels",
"Effect": "Deny",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"NotResource": [
"arn:aws:bedrock:*::foundation-model/anthropic.claude-3-5-sonnet-20240620-v1:0",
"arn:aws:bedrock:*::foundation-model/amazon.titan-embed-text-v2:0"
]
}
]
}
Keep inference inside approved Regions
Pair the model restriction with a Regional guardrail so Bedrock can only be called in Regions you have approved for data-residency reasons:
{
"Sid": "RestrictBedrockToApprovedRegions",
"Effect": "Deny",
"Action": "bedrock:*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": ["us-east-1", "us-west-2"]
}
}
}
Add a Config baseline
SCPs set the permission ceiling; AWS Config confirms the reality. Deploy a Config baseline (ideally via a conformance pack across the OU) to detect drift — a Bedrock resource created without encryption, invocation logging turned off, or a guardrail removed — and alert or auto-remediate.
Note: SCPs never apply to the management account, and they only constrain — they cannot grant. Test a new SCP on a single OU before rolling it org-wide, since an over-broad Deny can lock out legitimate workloads.Acceptance criteria
AI workloads run in dedicated accounts under an OU with SCPs; Config baselines apply org-wide; logs aggregate centrally.
Practical implementation
How this control is implemented in each reference architecture:
A dedicated Generative AI OU with separate accounts, SCP guardrails, and org-wide Config baselines contains blast radius and enforces a consistent posture.
- Create the Generative AI OU with separate development, inference, and (where used) training accounts under AWS Organizations / Control Tower.
- Attach SCPs at the OU that enforce boundaries (e.g. deny training actions in inference accounts, deny disabling of logging/guardrails).
- Apply AWS Config conformance packs org-wide for a common baseline and aggregate all logs to the central Log archive account.
How to validate: AI workloads run in dedicated accounts under the OU; an SCP-denied action (e.g. training in an inference account) fails; Config baselines apply org-wide; logs aggregate centrally.
Avoid: Splitting only by IAM inside one account and calling it isolation. Account boundaries plus SCPs are what actually contain blast radius; use them for production AI.
This control is where the single-account variant reaches its limit: approximate isolation with IAM and environment separation, and treat graduation to the OU as the real fix.
- Separate development and production workloads with distinct IAM roles, tags, and (ideally) separate VPCs within the account, since account-level SCP isolation is not available here.
- Use AWS Config rules in-account for a consistent baseline and permission boundaries to cap what any role can do.
- Plan and schedule the graduation to a multi-account Generative AI OU before scale or a security review forces it; this is the primary reason to graduate.
How to validate: Dev and prod are separated by roles/tags/VPCs; Config rules and permission boundaries are in place; a documented graduation plan to the OU exists.
Avoid: Treating single-account as a permanent home for production AI. Logical separation cannot match account-level SCP isolation; graduate before the workload becomes critical.
Threats addressed
- A development mistake or poisoned dataset affecting production.
- Inconsistent security baselines across AI environments.
AWS services
Pricing
AWS Organizations and SCPs are free. AWS Config bills per configuration item recorded and per conformance-pack evaluation, so scope the recorder to the resource types you actually need to govern. See Example SCPs for Amazon Bedrock.
Framework mappings
OWASP GenAI/LLM Top 10 (2026)
- LLM05 Data and Model Poisoning
NIST AI Risk Management Framework (AI 100-1)
- GOVERN.1 Policies, processes, procedures and accountability structures
- GOVERN.4 Organizational culture that prioritizes risk awareness
- MANAGE.1 AI risks are prioritized, responded to and managed
AWS Well-Architected Generative AI Lens (Security)
- GENSEC03-BP01 Implement control plane and data access monitoring
Learning resources
References
- AWS SRA for AI — Capability 1, Multi-account architecture
AI Security Maturity Model