By default, a workload in your VPC (Virtual Private Cloud — your isolated network inside AWS) reaches Claude Platform on AWS over its regional public endpoint, https://aws-external-anthropic.{region}.api.aws. Traffic is encrypted with TLS and authenticated with SigV4 either way, but many enterprise network policies go further: no route to the public internet at all from production subnets. AWS PrivateLink is the standard answer, and the official documentation states that PrivateLink is supported for connecting a VPC to the Claude Platform on AWS endpoint. Here is what that means and how to approach the setup.
What an interface VPC endpoint actually does
An interface VPC endpoint is a set of elastic network interfaces that AWS places inside your subnets, each with a private IP address from your own address range. PrivateLink then carries traffic from those interfaces to the service — in this case, the Claude Platform on AWS gateway — across AWS's internal network. The practical consequences:
No internet path required. Subnets with no internet gateway, no NAT gateway, and no public route can still call Claude. That satisfies "private subnets only" architectures without punching exceptions into route tables.
Traffic stays addressable and controllable. The endpoint's network interfaces live in your VPC, so security groups apply to them (allow HTTPS from your application subnets, deny everything else), and your VPC flow logs see the traffic like any other internal flow.
DNS keeps your code unchanged. With private DNS enabled on an interface endpoint, the service's normal hostname resolves to the endpoint's private IPs inside the VPC. Your AnthropicAWS client configuration — region, workspace ID, credentials — does not change; the same request simply takes the private path.
Setting it up
The flow follows the standard interface-endpoint pattern in the VPC console (or Terraform/CloudFormation): create an interface endpoint, select the Claude Platform on AWS service in your region from the service list, choose the subnets that should host the endpoint interfaces, attach a security group allowing inbound HTTPS from your workloads, and enable private DNS. Consult the current official documentation for the exact PrivateLink service name to select — the sourced documentation confirms PrivateLink support but this guide won't guess at identifier strings that may change.
Two platform specifics to keep in view while you configure:
Region alignment is strict. A workspace is bound to a single AWS region and is only reachable through that region's endpoint, and the SigV4 signing region must match the endpoint region — a mismatch yields a generic signature-rejection error. Your VPC endpoint, your AWS_REGION setting, and your workspace must therefore all agree. Cross-region private access means the usual AWS answer: an endpoint in the workspace's region, reached over VPC peering or Transit Gateway per your network design.
The prerequisite still applies. The one-time aws iam enable-outbound-web-identity-federation account setup is about how the gateway authenticates to Anthropic server-side; a private network path does not remove it. If requests through the new endpoint fail with the federation-disabled error, that is the fix, not the endpoint.
Verifying the private path
After creation, verify three things from an instance in a private subnet: DNS resolution of the regional endpoint hostname returns private IPs from your VPC ranges; a test request via the SDK succeeds (proving security groups and endpoint policy allow it); and — the real test — the same request still succeeds after removing any NAT or internet route the subnet previously had. Pair the endpoint with your normal controls: security groups scoped to application subnets, and CloudTrail data-event logging if you need per-call audit records.
Where to go next
See private networking across platforms for the cross-platform view, Bedrock PrivateLink setup for the equivalent on Bedrock, and the Platform-vs-Bedrock decision guide if the data-processor distinction above matters to you.