VPC Block Public Access: the simplest switch I’ve wanted for a decade

When you spend your days designing guardrails for large, multi‑account networks, you develop a sixth sense for “accidental internet.” A route left in place from a test, a dev subnet someone quietly flipped to “public,” a well‑intentioned change that opens a path through an Internet Gateway … I’ve seen all of them. What I’ve always wanted was a single, authoritative control to say: “This account’s VPCs don’t talk to the public internet—unless I explicitly make an exception”. That’s exactly what Amazon VPC Block Public Access (BPA) delivers. It’s a declarative, account‑level, per‑Region guardrail that authoritatively blocks VPC traffic to and from the internet whenever the path is through AWS‑provided internet gateways.

What it does

VPC BPA targets the two AWS‑managed “doors” between your VPCs and the internet:

• Internet Gateway (IGW): the bidirectional door; and
• Egress‑Only Internet Gateway (EIGW): the IPv6 egress‑only door.

When you enable BPA, traffic that would traverse those doors is dropped according to the mode you choose (more on modes next). It supersedes lower‑level VPC settings, so you don’t have to hunt through every route table and security group to be confident that nothing leaks to or from the public internet via IGW/EIGW.

Two modes you’ll actually use

BPA keeps the mental model refreshingly small:

1. Block‑bidirectional: Denies both ingress and egress internet traffic via IGW/EIGW for all VPCs and subnets in the account & Region (unless excluded). This is the “no internet here, full stop” posture.
2. Block‑ingress: Denies inbound internet traffic, but still permits egress (only when that outbound path is via NAT Gateways or Egress‑Only Internet Gateways). This fits the common “private subnets with NAT” design where workloads fetch updates or call external APIs without being publicly reachable.

You set the mode per Region on the account. In addition to account‑managed settings, the EC2 API surface shows BPA can also be governed by a declarative policy (useful for central enforcement at scale).

Exceptions, not the norm: Exclusions

There will always be legitimate cases for internet access. BPA handles those with exclusions:

• Scope: apply to a VPC or a single subnet.
• Exclusion modes:
  • allow-bidirectional (full in/out allowed)
  • allow-egress (outbound allowed, inbound blocked; only applicable when your account is in block‑bidirectional).

A neat operational detail: you can pre‑create exclusions even before enabling BPA so that turning it on doesn’t disrupt known‑good paths.

How it fits with the controls you already use

Think of BPA as a coarse, authoritative guardrail. It doesn’t replace your security groups, network ACLs, AWS Network Firewall, or Route 53 Resolver DNS Firewall; it sits above them and ensures that, by default, there is simply no public‑internet door to open. Your fine‑grained controls still matter for east‑west traffic, service‑to‑service flows, and application policy.

A pragmatic rollout playbook (what I recommend to clients)

1. Inventory & assess blast radius: List VPCs, note which ones currently rely on IGW/EIGW, and identify NAT‑only egress patterns.
2. Pre‑stage exclusions: For any VPCs/subnets that must remain public or require direct egress, create targeted exclusions with allow-bidirectional or allow-egress as appropriate. Tag them with owner and expiry where possible.
3. Enable BPA in a non‑prod Region first: Use block‑ingress to validate nothing breaks for private workloads using NAT/EIGW. Then progress to block‑bidirectional where your policy demands zero egress.
4. Observe & prove: Combine your usual network telemetry (e.g., VPC Flow Logs) with detective tooling to verify the absence of public paths and to spot workloads that think they need internet but don’t.
5. Standardize via automation: Bake BPA settings and exclusions into your pipelines (Terraform/Pulumi/CloudFormation) so posture isn’t a manual afterthought. The public APIs and provider resources are already there for you to codify.

Gotchas I’ve seen (so you don’t have to)

• “Why can my instances still reach the internet?”: If you set block‑ingress, outbound is still allowed only via NAT or EIGW. If your design included NAT, that’s expected; switch to block‑bidirectional if policy demands no egress at all.
• “Who’s allowed to create exclusions?”: Treat exclusions as privileged. BPA exposes state in EC2 APIs with a managedBy attribute, so you can align IAM boundaries accordingly.
• “Does BPA change my existing SG/NACL behavior?”: No. It sits above them, removing the IGW/EIGW door by default. Your existing controls still apply inside the VPC boundary and to non‑internet paths.

Why this matters for architects

For years we’ve pieced together preventative controls (organizational SCPs, Config rules, detective alerts) to avoid public exposure. BPA reduces that complexity with a single, explicit decision per Region: block all, or block inbound. It’s not a silver bullet, but it’s the cleanest “default deny to the internet” stance I’ve seen for VPCs, with just enough flexibility through exclusions to handle reality.

Final thoughts

Security programs live or die by clarity and consistency. VPC Block Public Access gives you both: a high‑leverage control you can explain in one sentence, automate in a few lines, and verify with your existing telemetry. Start where it’s easy (non‑prod, block‑ingress), pre‑stage exclusions, then raise the bar to block‑bidirectional wherever your data sensitivity demands it. In a world of ever‑expanding network paths, having a default deny to the public internet feels like oxygen.