AWS Bedrock vs Azure OpenAI Compliance Attestations (2026)

Both AWS Bedrock and Azure OpenAI are first-party managed services of their parent clouds. This is structurally important: when AWS or Microsoft are audited for SOC 2, ISO 27001, FedRAMP, PCI-DSS, or HIPAA, the in-scope services list explicitly includes (or excludes) each managed service. A service that is 'AWS HIPAA-eligible' means it has been added to the BAA-covered service list; a service that is 'in scope on Azure SOC 2' means the auditor observed it during the report period.

AWS publishes the authoritative in-scope-services matrix at aws.amazon.com/compliance/services-in-scope/. Bedrock appears across HIPAA, SOC 1/2/3, ISO 27001/27017/27018/27701/9001, IRAP, C5, FedRAMP (in GovCloud and certain commercial regions), PCI-DSS, and more. The matrix lists per-region scope: a service can be in scope in us-east-1 but not yet in scope in a newer region (eu-south-2, for example) until the auditor extends coverage.

Microsoft publishes the equivalent Azure matrix at learn.microsoft.com/azure/compliance/offerings/. Azure OpenAI is in scope across the equivalent set: SOC 1/2/3, ISO 27001/17/18/701, FedRAMP Moderate (commercial) and High (Government), IRAP, C5, HIPAA/HITECH, PCI-DSS, and more.

Practical implication for buyers: the attestation count is nearly identical, but per-region per-service scope differs. Always cross-reference (1) the model you want to use, (2) the region you need to deploy in, and (3) the attestation your auditor demands. The intersection is what matters — not the headline attestation count.

Both AWS and Microsoft sign a BAA covering their AI inference services. The mechanics differ slightly. AWS adds services to its BAA-eligible list (a single AWS BAA covers all eligible services in your account); Microsoft signs the BAA as part of the Online Services Terms which automatically covers Azure OpenAI in Azure subscriptions where the BAA is in force.

On AWS, the controlling document is the AWS BAA, signed once per AWS Organization (typically). Bedrock is on the eligible services list. The customer is responsible for using Bedrock in a HIPAA-compliant manner: encrypting inputs in transit (handled by Bedrock TLS), encrypting at rest (handled by AWS KMS — use customer-managed keys for any stored data), restricting access via IAM, and avoiding logging PHI to CloudWatch unless that log group is also under the BAA umbrella.

On Azure, the controlling document is the Microsoft Online Services Data Protection Addendum + HIPAA BAA. Azure OpenAI is in scope. Customer responsibilities mirror AWS: encrypt at rest with customer-managed keys where required, restrict access via Azure RBAC + Conditional Access, do not log inputs/outputs to non-BAA-covered destinations.

Specifically for Bedrock + Anthropic Claude: when you invoke Claude via Bedrock, you are calling AWS infrastructure that AWS audits, and AWS contracts with Anthropic as a sub-processor under terms that allow Bedrock to operate as a HIPAA-eligible inference path. Anthropic's own enterprise BAA is not required — your AWS BAA covers it. This is the cleanest path for HIPAA buyers who want Claude.

For Bedrock + Meta Llama: same structure — AWS handles the BAA-eligible inference, Meta does not have a separate contractual surface to the customer for the Bedrock-hosted model. For Bedrock + custom-imported models: confirm the upstream model provider's no-PHI-training terms before importing weights.

FedRAMP (Federal Risk and Authorization Management Program) is the US government's standardized cloud security assessment. Three impact levels: Low, Moderate, and High. Moderate is the bar for most federal civilian agencies; High is required for systems handling controlled unclassified information (CUI) with high impact, or for DoD impact levels 4 and 5.

Azure has FedRAMP High coverage in Azure Government — including Azure OpenAI Service as it rolled out in 2024-2025. This is currently the only frontier-model API path with FedRAMP High that is generally available to federal customers without a customized authorization.

AWS has FedRAMP High coverage in AWS GovCloud (US). Bedrock availability in GovCloud has been expanding — verify the current region scope on the AWS Bedrock GovCloud page. For commercial AWS regions, Bedrock inherits AWS's FedRAMP Moderate authorization for the services in scope; per-model coverage varies.

Practical guidance: federal buyers who already have an authorization to operate (ATO) on Azure Government should default to Azure OpenAI for AI workloads with frontier-model needs. Federal buyers on AWS GovCloud should verify per-model Bedrock availability before standardizing on a specific model family. For DoD impact level 5+, both clouds require additional customer-specific controls and security plan documentation.

Both Bedrock and Azure OpenAI are region-scoped services — your inference, your stored fine-tuning data, and your logs all stay in the region you provision the resource in. There is no implicit cross-region replication of inputs/outputs; Microsoft and AWS both document this explicitly.

AWS Bedrock regions (June 2026): US (us-east-1, us-west-2, us-east-2), EU (eu-west-1 Ireland, eu-central-1 Frankfurt, eu-west-3 Paris, eu-north-1 Stockholm, eu-west-2 London), APAC (ap-northeast-1 Tokyo, ap-southeast-1 Singapore, ap-south-1 Mumbai, ap-southeast-2 Sydney), and others. Per-model availability is uneven — Claude is broadly available; some Llama, Mistral, and Cohere SKUs are in narrower region sets. Check the Bedrock console region selector.

Azure OpenAI regions (June 2026): roughly 30 regions globally including East US (multiple), West US, Central US, the EU regions in the table above, UK South, Switzerland North (Swiss sovereign), Australia East, Japan East, Korea Central, South India, UAE North, Brazil South. Model availability is uneven — newest models (GPT-5 family) typically launch in a US region first then expand. Use the Models page in Azure Portal for current per-region availability.

For EU buyers specifically: if your DPA requires EU-only processing, pick from the in-EU region list above and verify the specific model you intend to use is GA in that region. For Schrems II transfer-impact assessments, both AWS and Microsoft provide template TIAs that you can adapt; AWS publishes its Schrems II / SCCs guidance in the GDPR Center, Microsoft publishes its in the Microsoft Trust Center.

For sovereign workloads: Azure has Sweden Central + Switzerland North as fully sovereign regions (data physically in-country, sovereign legal protections). AWS has European Sovereign Cloud launching in 2026 (Germany first) — check the current GA status before committing if you need full sovereign-cloud isolation.

Customer-managed keys let your encryption keys live in your own key management service (AWS KMS or Azure Key Vault), under your IAM/RBAC controls. The cloud provider can decrypt your stored data only when your key policy allows it — giving you a hard kill switch on access. CMK is often required for SOC 2 Confidentiality criterion mappings, HIPAA Security Rule, and many financial-services regulators.

On AWS Bedrock: stored fine-tuning data, custom model imports, and Knowledge Base S3 buckets can be encrypted with customer-managed KMS keys. Inference-time inputs/outputs are not persisted by default, so encryption-at-rest does not apply to them. If you opt in to CloudWatch invocation logging, those logs can be encrypted with KMS as well.

On Azure OpenAI: stored fine-tuning data, deployment metadata, and any opted-in inference logs (Azure Monitor) can be encrypted at rest with customer-managed keys via Azure Key Vault. Microsoft does not persist prompts/responses for inference calls outside of customer-opted-in logging.

Practical implication: for the inference path itself, CMK does not change much because there is no persistent customer data to encrypt. CMK matters for fine-tuning datasets, custom model artifacts, knowledge-base storage, and logs. Both platforms cover these surfaces; the differences are in the specific KMS/Key Vault integration details and rotation cadence. Both are sufficient for regulated buyers.

AWS Bedrock supports VPC endpoints via AWS PrivateLink. You create a Bedrock VPC endpoint in your VPC, and inference traffic from your application to Bedrock routes over AWS's private network without crossing the public internet. Combine with VPC security groups and AWS WAF for full network isolation. This is the standard pattern for HIPAA, PCI-DSS, and any internal-policy 'no internet egress' requirement.

Azure OpenAI supports Azure Private Link. You create a private endpoint for the Azure OpenAI resource in your VNet, and inference traffic flows over Microsoft's backbone without internet exposure. Combine with NSGs and Azure Firewall for network isolation.

Both platforms support disabling public network access entirely so that the inference endpoint is reachable only via the private link. This is the gold-standard configuration for regulated workloads and is recommended in both AWS's and Microsoft's well-architected guidance for AI workloads.

Note: private networking does not change the compliance attestation — it changes the network attack surface. Combine with the BAA / DPA / region selection for the full picture.

The biggest non-compliance differentiator: Bedrock is multi-model; Azure OpenAI is OpenAI-only. As of June 2026, Bedrock offers Anthropic Claude (Opus 4.7, Sonnet 4.6, Haiku 4.5), Meta Llama 4 (Maverick, Scout), Mistral (Large 3, Codestral), Cohere (Command R+, Rerank), AI21 (Jamba), Stability AI (SD 3.5, SD-XL Turbo), Amazon Titan + Nova, plus custom-imported model paths. Azure OpenAI offers the GPT-5 family, gpt-4.1 / 4o variants, OpenAI o1 / o3 reasoning models, GPT-image generation, and embedding models — but no Anthropic, Llama, or Mistral.

For a regulated buyer who needs Claude, Bedrock is the only managed-cloud path with full inheritance to AWS's compliance stack. For a regulated buyer who needs GPT or OpenAI's o-series reasoning, Azure OpenAI is the equivalent path with Microsoft inheritance. For buyers who need both, the practical pattern is to procure both — same DPA, same BAA, same region governance — and route per workload.

On compliance posture for the actual model output: both platforms vouch that their managed inference does not train on customer data and does not persist inputs/outputs outside of customer-controlled logging. The third-party model providers (Anthropic, Meta, Mistral, Cohere) are contracted via the cloud provider, not directly with the customer for Bedrock-hosted inference. This collapses the contracting graph to one vendor.

AWS contracting flow: the AWS Customer Agreement (or Enterprise Agreement) is the master contract. The AWS GDPR DPA is the data-protection addendum (standard EU SCCs included). The AWS BAA is a separate addendum for HIPAA. AWS Service Terms govern per-service specifics (Bedrock-specific terms appear in Section X of Service Terms). No separate Bedrock contract is required if you're already an AWS customer.

Microsoft contracting flow: the Microsoft Customer Agreement (or Enterprise Agreement / Microsoft Products & Services Agreement) is the master. The Online Services DPA is the data-protection addendum (standard EU SCCs included). The HIPAA BAA is built into the Online Services Terms — no separate signature is needed for healthcare customers under the standard Microsoft DPA. Azure OpenAI-specific terms appear in the Product Terms.

Practical implication: both flows are mature and well-understood. Most enterprises already have the master contracts and DPAs in place from existing AWS or Azure usage. Adding Bedrock or Azure OpenAI to the scope is a procurement-process change, not a new vendor relationship. This is one of the biggest reasons regulated enterprises pick Bedrock + Azure OpenAI over the smaller AI-only vendors — the contracting friction is near-zero.

If your enterprise is heavily on one cloud (say, AWS), defaulting to that cloud's AI service for compliance reasons is rational even when the other cloud has a slightly more attractive model. The contracting cost of standing up a second cloud-AI relationship plus its own DPA review is typically $50-200k in legal and procurement time — easily justifying paying 10-20% more for the in-cloud AI option.

Pick AWS Bedrock when: (1) you need Claude, Llama, Mistral, Cohere, or any non-OpenAI model in a regulated production workload; (2) you are already a heavy AWS shop and want one cloud BAA / DPA; (3) you need a multi-model strategy (different models for different workloads under one contract); (4) you need an AWS GovCloud FedRAMP High path for AI; (5) you need to combine inference with AWS Knowledge Bases (managed RAG on S3 + OpenSearch / pgvector).

Pick Azure OpenAI when: (1) you need GPT-5 family, gpt-4.1 / 4o, or OpenAI's o-series reasoning models in a regulated workload; (2) you are already a heavy Azure shop; (3) you need the broadest EU region footprint (6+ regions); (4) you need Azure Government FedRAMP High; (5) you need Microsoft's existing enterprise contracting surface for the cleanest HIPAA / GDPR onboarding.

Pick both when: (1) you need both model families in production; (2) cost optimization warrants per-workload model selection across both platforms; (3) vendor concentration risk mitigation matters (rare today but increasingly raised by board-level risk committees).

Avoid the trap: do not pick the cloud platform based on a single attestation that one has and the other doesn't. The attestation stacks are now near-identical. Pick based on model needs, existing contracting surface, and regional availability for your specific workloads.