Most Bedrock security conversations start and end with IAM. That is the right primary control, but network-layer controls add something IAM cannot: they constrain which machines can reach the Bedrock API, independent of what credentials happen to be on them. If a workload host is compromised, network controls limit where stolen credentials can even be exercised from. This article maps the three standard VPC tools — security groups, network ACLs, and VPC Flow Logs — onto a Bedrock deployment, assuming you route Claude traffic through a PrivateLink interface endpoint.
Security groups: the primary filter
A security group is a stateful virtual firewall attached to network interfaces. In a PrivateLink setup there are two placements that matter:
On the endpoint. The security group attached to the Bedrock interface endpoint controls which sources inside your VPC can open connections to it. Restrict inbound HTTPS (port 443) to the security groups of the specific application tiers that are approved to call Claude — reference source security groups rather than CIDR ranges where you can, so approval follows the workload rather than the subnet.
On the workloads. Egress rules on application security groups determine where those hosts may connect. Locked-down environments often deny general internet egress entirely; because a PrivateLink endpoint means Bedrock is reachable without an internet gateway or NAT (per AWS's PrivateLink documentation), you can allow HTTPS to the endpoint while leaving the "no internet" posture intact.
Network ACLs: the coarse backstop
Network ACLs (NACLs) are stateless allow/deny rules at the subnet boundary. They are blunter than security groups — no referencing other groups, and you must handle return traffic explicitly — so most teams use them sparingly: as a subnet-level backstop that blocks whole address ranges or enforces "this data subnet talks to these service subnets and nothing else." A reasonable posture is simple NACLs that encode broad segmentation, with the precise per-workload rules living in security groups. If a NACL and a security group disagree, traffic must pass both, which is exactly the point of layering.
VPC Flow Logs: seeing the traffic
VPC Flow Logs record connection metadata — source, destination, port, bytes, accept/reject — for traffic crossing network interfaces, including the interfaces of your Bedrock endpoint. Two uses stand out for Claude workloads:
Detecting unexpected callers. Flow logs on the endpoint's interfaces show every host that attempted to reach Bedrock, including rejected attempts. A rejected-connection spike from a subnet that should not be calling Claude is a cheap, early indicator of misconfiguration or probing.
Evidencing the private path. Auditors sometimes want proof, not architecture diagrams. Flow logs plus the endpoint configuration demonstrate that inference traffic flows to a private interface in your VPC rather than out through a NAT or internet gateway.
Keep expectations calibrated: flow logs see connection metadata only. Prompts and completions are inside TLS and never appear there. Content-level auditing is a different tool — Bedrock's model invocation logging — and identity-level auditing is CloudTrail, which records every Bedrock API call with the caller's identity and source IP. The three views complement each other; none substitutes for the others.
| Layer | Question it answers | Granularity |
|---|---|---|
| Security groups | Which workloads may open a connection to the endpoint? | Per network interface, stateful |
| NACLs | Which subnets may exchange traffic at all? | Per subnet, stateless |
| VPC Flow Logs | What connections actually happened (or were rejected)? | Connection metadata, no content |
Two boundary notes
First, cross-region inference does not break the private posture: AWS documents that traffic routed through cross-region inference profiles stays on the AWS network, never the public internet, and is encrypted in transit — and every cross-region request is logged in CloudTrail in the source region, with the processing region recorded in the event. Second, network controls only bind machines inside your network. A valid credential used from elsewhere bypasses all of this, which is why the identity-side rules in Bedrock IAM setup and the endpoint policy remain the primary control. These are defensive measures; treat this article as hardening guidance, not a compliance conclusion — confirm requirements with your provider and auditors.
Where to go next
For the observability half of the story, see CloudWatch alarms and metric filters and audit logging. The cross-platform view lives in VPC and private networking.