Networking, Identity & Private Connectivity

FIPS 140-3 Endpoints for Amazon Bedrock

Government and regulated workloads often can't just use "encryption" — they need encryption performed by validated cryptographic modules. Bedrock offers FIPS endpoint variants for that, but not for every API surface.

Claude 3P 101 · Updated July 2026 · Unofficial guide

FIPS 140-3 is the US and Canadian government standard for cryptographic modules — the software and hardware that actually performs encryption. Many public-sector contracts, and some regulated-industry policies modeled on them, require that data in transit be protected by cryptography that has been formally validated against this standard, not merely by "TLS." Cloud providers meet this by offering FIPS endpoints: alternative API endpoints where the TLS termination uses validated cryptographic modules.

Amazon Bedrock participates in this scheme. Its baseline transport security is already strong — all inter-network data in transit supports TLS 1.2, and AWS requires TLS 1.2 while recommending TLS 1.3 for API access — but for callers who must demonstrate validated cryptography, AWS documents FIPS 140-3 endpoints for Bedrock specifically.

Which FIPS endpoint services exist, and where

In its VPC interface endpoints documentation, AWS lists two FIPS endpoint service variants for Bedrock:

FIPS endpoint serviceCovers
bedrock-fipsThe Bedrock control plane (management APIs)
bedrock-runtime-fipsThe runtime/inference surface (InvokeModel, Converse)

Both are available in six regions: us-east-1, us-east-2, us-west-2, ca-central-1, us-gov-east-1, and us-gov-west-1. The list is exactly what you would expect for a US/Canada government standard: the major US commercial regions, Canada, and both AWS GovCloud (US) regions.

The gap: no FIPS variant for bedrock-mantle

Here is the detail that matters if you are adopting Claude through the current Messages-API surface. As explained in the bedrock-mantle endpoint article, "Claude in Amazon Bedrock" is served from its own endpoint service, com.amazonaws.{region}.bedrock-mantle, separate from bedrock-runtime. AWS's documented FIPS list covers bedrock and bedrock-runtime only — no FIPS variant of the bedrock-mantle endpoint service is documented.

What this means in practice: if your compliance regime requires FIPS-validated endpoints today, the documented path to Claude on Bedrock is the legacy bedrock-runtime surface (the AnthropicBedrock client, InvokeModel/Converse APIs) through bedrock-runtime-fips — not the newer Messages-API surface. Check the official AWS documentation for updates before designing around this, since endpoint offerings evolve.

That trade-off is real: the legacy surface uses ARN-versioned model IDs and AWS event-stream encoding, and some of the newest Claude models are only on the current surface. A government workload may have to weigh "newest model generation" against "validated endpoint," or consult AWS about roadmap. This guide can't make that compliance call for you — the requirement itself comes from your authorization framework, and you inherit your cloud provider's compliance posture, so confirm specifics with AWS.

When a workload actually needs FIPS endpoints

Roughly three situations, in decreasing order of certainty:

If none of these applies, the standard endpoints' TLS 1.2+ transport encryption is the normal choice, and you keep access to the full current-surface feature set.

What FIPS endpoints do not change

A FIPS endpoint validates the cryptographic modules used on the connection — it does not alter Bedrock's data handling, IAM model, or logging behavior. Encryption at rest, customer-managed KMS keys, and the Model Deployment Accounts architecture are separate topics, covered in the KMS scope article. Identity, endpoint policies, and PrivateLink wiring work the same way as on standard endpoints. And a FIPS endpoint is not itself a compliance certification for your workload — it is one control among many that your assessor will look at.

Where to go next

Pair this with the PrivateLink endpoint-service guide for the private-connectivity side, and compliance inheritance for how platform posture flows into your own audits.

Sources