The Inspection Carve-Out: What AWS's VPC Encryption Controls Actually Enforce

On 31 August 2026, AWS’s Networking & Content Delivery team published the deployment playbook for a control that had been building since a November 2025 preview: VPC Encryption Controls, a mechanism that does something almost nothing else labelled “compliance” in AWS actually does — it can refuse to let a non-compliant resource exist. Turn on enforce mode and AWS’s own documentation is blunt about what that means: it “prevents you from using any features or services that allow unencrypted traffic within the VPC boundary.” Not a dashboard finding. Not a report an auditor reads six months late. A blocked API call.

Read past the headline feature and a second sentence in AWS’s own compatibility notes changes the story: “Gateway Load Balancer and AWS Network Firewall are not supported with VPCs in enforce mode. If these resources are present in your VPC, you must run your VPC in monitor mode.” Not an exclusion — AWS ships exactly eight of those, individually configured and audited. A flat mode restriction. The one VPC that most centralised-inspection architectures are built around, specifically so every spoke’s traffic passes somewhere a human or a Suricata engine can actually look at it, is the one VPC that structurally cannot reach the mode that proves encryption is happening.

That’s not a bug report. It’s the shape of what “enforce” currently means, and it’s worth understanding precisely before a compliance team treats a green checkmark as the end of the conversation.

The problem: encryption you can’t prove is encryption you can’t audit

Much of AWS’s own network traffic has been encrypted for years without anyone having to ask for it: modern Nitro-based instances get 256-bit authenticated hardware encryption between them automatically, Direct Connect dedicated connections support MACsec, and Site-to-Site VPN is IPsec by definition. None of that was ever the gap. The gap was proof. Compliance frameworks that require encryption in transit — HIPAA, PCI DSS, FedRAMP, and per AWS’s own framing of this launch, CJIS and IRS 1075 — don’t accept “the architecture diagram shows TLS here” as evidence. They want a continuously verifiable state, and until this control shipped, nothing in AWS told you, per flow, whether a connection was actually encrypted — you reasoned about it from the design, not from telemetry.

VPC Encryption Controls closes that gap two ways. In monitor mode, a new encryption-status field on VPC Flow Logs classifies every flow: 0 not encrypted, 1 encrypted at the network layer by Nitro system hardware, 2 encrypted at the application layer (TLS on port 443, or a small set of AWS-confirmed managed endpoints), 3 both, and - when the control is off or the status can’t be determined. Alongside it, the GetVpcResourcesBlockingEncryptionEnforcement API names, resource by resource, exactly what would break if you flipped enforce mode on today. Both are auditable, both are queryable, and neither requires reading an architecture diagram to answer “is this encrypted.” That’s the actual product: not new encryption, but proof of the encryption that’s frequently already happening, plus a lever to make the rest happen.

Enforce mode is the lever. New VPCs can be created directly in enforce mode; an existing VPC has to pass through monitor mode first — AWS’s documentation states plainly that “you cannot enable Encryption Controls in enforce mode directly on your existing VPCs” — and every non-compliant resource has to be remediated or explicitly excluded before the switch goes through. Most of the load-bearing infrastructure moves for free: Application Load Balancers, Fargate, EKS control planes, and Network Load Balancers migrate to encryption-capable hardware automatically the moment monitor mode is on. Older EC2 instances, RDS, ElastiCache, Redshift, EKS and ECS-on-EC2 data planes, OpenSearch, and EMR don’t — those need an actual instance-class migration, because Nitro-system hardware encryption isn’t retrofittable onto older instance generations.

The challenge: only eight things get to opt out, and the busiest VPC in your account isn’t one of them

Enforce mode’s entire credibility rests on there being no silent escape hatch, and AWS built it that way: exactly eight resource types can be individually excluded from enforcement, each one an auditable, logged exception rather than a default — Internet Gateway, NAT Gateway, egress-only Internet Gateway, VPC peering to a VPC that isn’t itself enforcing, Virtual Private Gateway, Lambda functions inside the VPC, VPC Lattice, and EFS. Every one of them shares a property: it’s a boundary where AWS is explicit that responsibility for encryption passes to you, because traffic is leaving AWS’s own network or reaching a service AWS doesn’t control end to end. Everything else in an enforce-mode VPC has to actually be encrypted, or the resource simply doesn’t get created.

Some of that “actually be encrypted” work is routine but not free. Amazon Redshift can’t be migrated in place — AWS’s documentation is unambiguous that you cannot move an existing provisioned cluster or serverless namespace into an enforce-mode VPC; the only path is snapshotting it and restoring into a new one. Amazon MSK is narrower still: encryption support exists only for a fresh Kafka 4.1 cluster on M7g instances, in a VPC that has never hosted another MSK cluster. Network Load Balancer carries a quiet limitation of its own, unrelated to instance generations: no TLS listener can offload encryption to the load balancer under enforce mode — every target must terminate its own TLS, ruling out a common cost- and complexity-saving pattern for teams that centralise certificate handling at the load balancer.

None of that is the wall, though. The wall is the single sentence quoted above: Gateway Load Balancer and AWS Network Firewall are not supported in enforce-mode VPCs, full stop. Not excludable — a VPC containing either one is simply barred from enforce mode entirely, monitor mode only, no configuration path around it. It’s easy to read past this as one more line on a limitations page, but it lands exactly where a centralised-inspection architecture puts its highest-value VPC. The reason a Network Firewall or GWLB-fronted appliance fleet exists at all is to sit in the path and look at payloads — a job that is structurally in tension with a control whose entire premise is that every flow inside the VPC boundary should be provably encrypted end to end. AWS didn’t solve that tension; it drew a line around it. If your inspection VPC has a firewall in it — and in most estates built around centralised, transparent inspection, it does — that VPC’s encryption status stops at “we’re watching,” not “we can prove.”

The solution: enforce the spokes, and make the hub’s exception explicit rather than accidental

AWS’s own rollout sequence is deliberately linear, and skipping steps is the fastest way to lock yourself out of enforce mode with resources you can no longer touch: enable monitor mode, read the encryption-status field across a representative traffic window (AWS’s own advice is to add ${traffic-path} and ${flow-direction} to the flow log format for context), run GetVpcResourcesBlockingEncryptionEnforcement to get the concrete remediation list, migrate or exclude what it finds, and only then flip to enforce. Do that for every spoke VPC in a hub-and-spoke estate, and the inspection VPC’s exemption stops being an oversight and becomes a specific, deliberate configuration choice instead.

The tool that actually closes most of the resulting gap isn’t VPC Encryption Controls itself — it’s a separate, complementary control on the Transit Gateway. Encryption support on a Transit Gateway is enabled explicitly, migrates existing attachments to encrypted lanes automatically and non-disruptively, and — critically — works across VPCs that are in different Encryption Controls modes, as long as they’re all in the same region. An enforce-mode spoke VPC connected through an encryption-enabled Transit Gateway to a monitor-mode inspection VPC still gets a fully encrypted path for its own traffic all the way to the Transit Gateway attachment ENI. What happens after that, inside the inspection VPC itself, is AWS’s own qualification, not mine: encryption “depends on the resources… and is not guaranteed” once traffic is inside a VPC that isn’t in enforce mode. That’s an honest boundary, and it’s the one worth drawing on your own architecture diagram in red, rather than leaving unlabelled.

For teams where “the inspection VPC must be enforce-mode too” isn’t negotiable, AWS’s own alternative is architectural rather than a setting: move off Network Firewall and Gateway Load Balancer, run third-party firewall appliances on ordinary Nitro EC2 instances — which do support encryption — and use VPC Route Server to steer traffic to them by BGP instead of the GWLB data plane. It’s a bigger change than flipping a mode, trading a managed inspection service for one you operate yourself, but it’s the one documented route to an inspection VPC that both filters traffic and reaches enforce mode.

The hybrid half of the estate has an equivalent choice, and AWS’s 31 August deep-dive is explicit about which option actually reaches end-to-end encryption. Terminate Site-to-Site VPN — over the public internet, a Direct Connect public VIF, or, via Private IP VPN, a transit VIF — on an encryption-enabled Transit Gateway, and the hybrid segment is covered without a manual exclusion. Terminate the same VPN on a Virtual Private Gateway instead, the older and still-common pattern, and enforce mode requires a VGW exclusion: a logged admission that the hybrid segment’s encryption is now your responsibility, not something AWS is verifying for you. Direct Connect dedicated connections add a separate, physical-layer option on top of either path — MACsec, at 10, 100, or 400 Gbps, at select locations — and AWS Interconnect extends that same MACsec-encrypted posture automatically, only transmitting once an encryption session is active.

At estate scale, the same monitor/enforce choice exists three levels up. Account-level Encryption Controls has three states — Unmanaged, Attempt Monitor, Attempt Enforce — that sweep every VPC in an account at once. For anyone running AWS Organizations, a declarative policy launched 6 July 2026 does the same thing at account, OU, or whole-organisation scope, at no additional charge on top of Encryption Controls itself. That’s the mechanism that turns “the inspection VPC is a permanent, documented exception” into an actual governance artefact, rather than a setting one engineer remembered to skip on one VPC and nobody else can find a reason for two years later.

The footprint

This is a materially stronger control than anything AWS has previously shipped for encryption in transit, and it’s worth being precise about why: it blocks the creation of the non-compliant thing, rather than reporting on it after the fact. That’s a different category of guarantee than a Config rule or a Security Hub finding, and it’s the first time “our VPCs enforce encryption” can mean something an API call actually verifies rather than something an architecture review asserted.

But it’s not a single bit, and treating it like one is the mistake this piece is really about. Enforce mode has a specific, network-architecture-shaped set of exceptions — the eight named exclusions, an inspection VPC that can’t reach enforce mode at all, Local Zone subnets unsupported in it either, cross-region VPC peering that always needs an exclusion, an NLB that can’t offload TLS under it, and, per AWS’s own framing, AWS Cloud WAN’s core network traffic sitting outside its enforcement scope entirely. None of those are bugs to chase down; they’re the current shape of what “enforce” covers, documented well enough to design around deliberately. The failure mode this control genuinely prevents isn’t a sniffed cleartext packet — modern AWS-native traffic was mostly encrypted already. It’s an auditor, eighteen months from now, discovering that the “fully encrypted” VPC estate had one permanently-exempted VPC at its centre that nobody on the team could immediately name or justify. Run the account-level Attempt Enforce sweep, name the inspection VPC’s monitor-mode status as a policy decision instead of a gap, and that conversation becomes a five-minute answer instead of an incident.