hidekazu-konishi.com

VPC Encryption Controls - Auditing and Enforcing Encryption in Transit

First Published: 2026-08-12
Last Updated: 2026-08-12

The hardest control requirement to satisfy is not "encrypt the traffic." It is "demonstrate that no unencrypted traffic exists." The first is a configuration task. The second is a proof about a negative, across every flow in an environment that changes daily, and for years the honest answer was a spreadsheet: a list of resources, a column asserting that each one uses TLS, a review date, and a quiet hope that nobody launched anything since.

Amazon VPC Encryption Controls replaces that artifact with something a machine produces. It has two modes, a flow log field, an API that names the specific resources standing between you and enforcement, and a hard rule that you cannot skip the observation phase on an existing VPC. This article is about using those parts to build evidence rather than assertions, and about the ordering, exclusions, and service-specific limits that decide whether the rollout is uneventful or an outage.

Every fact below was verified against AWS official documentation on 2026-08-09, with the page linked at the point of use. Nothing here was measured or executed. No VPC was switched to enforce mode, no exclusion was created, and no flow log was captured, because every one of those actions is either irreversible in practice or capable of dropping production traffic. Where the AWS user guide and the AWS API reference disagree, both are shown and the one to build automation against is named. No pricing figures appear in this article, and the adoption argument below is made entirely in terms of audit requirements, remediation effort, and switching order.

Table of Contents

1. 1. Introduction: Proving a Negative About Your Own Network
2. 2. What "Encrypted in Transit" Means at Each Layer
3. 3. From Spreadsheets to Machine-Checkable Evidence
4. 4. Monitor Mode and the Flow Log Field
5. 5. Finding the Resources That Block Enforcement
6. 6. Enforce Mode and the Ordering Constraint
7. 7. Exclusions and Their Limits
8. 8. Gateways Under Enforcement
9. 9. Peering and Transit Gateway Scope
10. 10. Generational Transitions and Service-Specific Limits
11. 11. Scaling the Control to Accounts and Organizations
12. 12. A Rollout Plan That Does Not Break Production
13. 13. Producing Audit Evidence
14. 14. Failure Modes
15. 15. Frequently Asked Questions
16. 16. Summary
17. 17. References

1. Introduction: Proving a Negative About Your Own Network

The decision this article supports is concrete: you have been asked to demonstrate encryption in transit for everything inside a Region, and you have to decide how far to take VPC Encryption Controls and in what order. That is an evidence problem before it is a configuration problem, and the two failure directions are equally bad. Stop at documentation and you have assertions an auditor can only take on trust. Rush to enforcement and you drop traffic that was working, in a way that is awkward to reverse.

AWS describes VPC Encryption Controls as a security and compliance feature giving centralized authoritative control to monitor the encryption status of traffic flows, identify resources that allow cleartext communication, and enforce encryption in transit within and across VPCs in a Region. Notably, AWS also states that the feature extends the native hardware-layer encryption beyond modern Nitro instances to other AWS services, naming Fargate, Application Load Balancer, and Transit Gateway among them. That second property is what makes it a control rather than a report.

1.1 Scope

In scope: what encryption in transit means at each layer and which layer each mechanism addresses; the flow log field and how to read its values without over-claiming; identifying the resources that block enforcement; the ordering constraint and why it exists; the eight exclusions and what their finiteness implies for design; gateways under enforcement; peering and Transit Gateway scope; automatic and manual migration; account-level and organization-level rollout; a staged plan with rollback at each step; the evidence to retain; and the failure modes.

Out of scope, with delegation:

• What a network path does and does not guarantee. The separation of reachability, transport protection, and authorization is the foundation this article stands on and it is developed in The Boundaries of the AWS Global Network. Section 2 uses that separation rather than re-deriving it.
• How to design a network boundary. Segmentation, inspection, and identity-aware access are the subject of AWS Zero Trust Network Architecture Guide.
• General VPC design review. See VPC Design Review Checklist.
• Encryption at rest and key management. This article covers data in transit only. See AWS KMS Envelope Encryption and Data Key Caching Guide.
• Pricing. The feature is billable and the current terms are on the Amazon VPC pricing page. No figures appear here.

1.2 A note on Regional availability

AWS announced the feature as available in multiple commercial Regions, and Regional coverage for a capability this young changes. No Region list appears in this article, deliberately: any list would be a snapshot, and a stale snapshot in a compliance document is worse than no list. Check current availability in the AWS documentation and record the date next to the answer in your own design record.

2. What "Encrypted in Transit" Means at Each Layer

A claim about encryption is only usable if it names a layer. AWS operates several mechanisms with different scopes, and VPC Encryption Controls is built on top of two of them.

2.1 The physical layer

The Amazon EC2 data protection documentation states that all data flowing across AWS Regions over the AWS global network is automatically encrypted at the physical layer before it leaves AWS secured facilities, and that all traffic between Availability Zones is encrypted.

This is real protection and it is not evidence you can produce. You do not configure it, you cannot show it per flow, and it says nothing about traffic between two instances inside one Availability Zone. It is a floor, not an answer to the audit question.

2.2 The Nitro hardware layer

Some instance types use the offload capabilities of the underlying Nitro System hardware to automatically encrypt in-transit traffic between instances, using Authenticated Encryption with Associated Data algorithms with 256-bit encryption and no impact on network performance, per the same AWS documentation. Three conditions must all hold: both instances are among the supported types, they are in the same Region, and they are in the same VPC or peered VPCs with the traffic not passing through a virtual network device or service such as a load balancer or a transit gateway.

That third condition is why VPC Encryption Controls matters as an engineering feature and not merely as a reporting one. AWS extends hardware-layer encryption to services beyond instances, and Transit Gateway encryption support in section 9 exists precisely because the intermediate-hop condition would otherwise be violated by ordinary architectures.

2.3 The application layer

TLS terminated by your application or by an AWS service endpoint is the layer that survives intermediate hops, that you can demonstrate from the client side, and that remains your responsibility. AWS states that most services supported by PrivateLink, including Cross-Region PrivateLink, accept traffic encrypted at the application layer, and that AWS automatically drops any traffic that is not application-layer encrypted to those endpoints.

2.4 How the three map onto the control

VPC Encryption Controls combines the second and third layers. AWS states that the feature uses both application-layer encryption and the built-in encryption in transit capability of Nitro System hardware to ensure enforcement. The physical layer sits underneath all of it and is not something the feature reports on per flow.

The practical translation, and the sentence worth keeping: a resource is compliant when it always enforces encryption in transit at either the hardware layer or the application layer. That is AWS's own formulation, and it is why a single resource can be compliant by two entirely different routes, and why the flow log has a value meaning "both."

2.5 What the control deliberately does not do

It is worth being explicit about the two things enforcement leaves exactly as they were, because the name invites over-reading and because a compliance narrative that over-reads it will be corrected by someone else.

It does not change who can reach your resources. Enforce mode blocks the creation and attachment of resources that would allow cleartext traffic. It does not narrow a security group, it does not restrict a principal, and it does not make a permissive resource policy any less permissive. A fully enforced VPC containing a bucket policy that grants broad access is fully enforced and fully exposed.

It does not change where packets travel. The routing properties of the VPC are untouched. An enforce-mode VPC with an excluded internet gateway still sends traffic to the internet, encrypted by whatever the application does, and enforcement has said nothing about the path.

Those two sentences are the reachability and authorization axes from The Boundaries of the AWS Global Network, and this feature sits squarely and only on the transport-protection axis. Keeping the three apart is what lets you claim the transport axis strongly, which is the whole point of adopting the control.

There is one place where the axes touch, and it is worth flagging because it surprises people. AWS states that in enforce mode, PrivateLink endpoints hosted inside the VPC drop traffic that is not encrypted at the application layer. A transport-protection control is therefore capable of changing whether a flow succeeds, which is a reachability outcome. It is the exception rather than the rule, and it is the reason the rollout in section 12 is staged rather than flipped.

3. From Spreadsheets to Machine-Checkable Evidence

AWS positions the feature for environments where encryption is required for compliance standards, naming HIPAA, FedRAMP, and PCI DSS. Rather than working through any single framework, it is more useful to name the shape of the requirement, because the shape is what determines whether your evidence is acceptable.

Requirements of this kind ask for three things at once:

1. Coverage. A statement about all traffic, not a sample. A list of the systems you remembered is not coverage.
2. Currency. Evidence that reflects the environment now, not at the last review. An environment where anyone can launch an instance invalidates a point-in-time assertion the moment it is signed.
3. Non-circumvention. Something that prevents the non-compliant case from recurring, rather than detecting it afterward.

A spreadsheet fails all three, and it fails them structurally rather than through carelessness. It cannot enumerate flows, only resources. It is stale on creation. And it has no enforcement mechanism at all.

Mapping the three onto what the feature provides makes the adoption argument without any appeal to cost:

Requirement shape	What supplies it	What it does not supply
Coverage	The encryption-status field on flow logs, applied to all traffic in the VPC	Anything about VPCs where you did not enable the control
Currency	Continuous emission of the field, plus the blocking-resources API queried on a schedule	Protection against a resource created between two queries
Non-circumvention	Enforce mode, which blocks creation and attachment of non-compliant resources	Coverage of the eight excludable resource types, where the responsibility remains yours

The third column is the one to write into your own evidence package. Enforcement makes a claim about what can exist inside the boundary; it does not make a claim about what happens beyond it, and the exclusions in section 7 are exactly the places where the boundary ends.

4. Monitor Mode and the Flow Log Field

4.1 What monitor mode gives you

In monitor mode, AWS states that Encryption Controls provides visibility into the encryption status of traffic flows between resources inside and across VPCs, and helps identify VPC resources that are not enforcing encryption in transit. It changes nothing about what can be created.

Monitor mode also has a side effect that is easy to miss and important for planning, covered in section 10: several resource types begin migrating to encryption-capable hardware as soon as monitor mode is turned on, without any further action from you.

4.2 The encryption-status field and its five values

The VPC Encryption Controls documentation defines the encryption-status field for VPC Flow Logs with the following values, confirmed 2026-08-09:

Value	Meaning
0	Not encrypted
1	Nitro-encrypted, managed by VPC Encryption Controls
2	Application-encrypted
3	Both Nitro and application encrypted
-	Encryption status unknown, or VPC Encryption Controls is off

4.3 How value 2 is determined, and why it matters

This is the single most important qualification in the whole feature, and it needs to be read before anyone builds a compliance dashboard on the field.

AWS states that for interface and gateway endpoints, AWS does not look at packet data to determine encryption status and instead relies on the port used to assume encryption status. The documented cases for value 2 are flows on TCP port 443 for an interface endpoint to an AWS service, flows on TCP port 443 for a gateway endpoint, and flows to an encrypted Redshift cluster through a VPC endpoint. For specified AWS managed endpoints, AWS determines the status based on the requirement for TLS in the service configuration.

Two consequences follow, and both belong in your evidence narrative rather than being discovered by a reviewer:

• A value of 2 on an endpoint flow is a port-based inference, not a cryptographic observation. It is a reasonable and documented inference, and it is not the same claim as "this payload was encrypted."
• Conversely, an application that speaks TLS on a non-standard port to a destination that is not one of the documented cases will not be credited with value 2. The traffic may be perfectly well encrypted and still not appear that way in the log.

State the inference explicitly when you present the evidence. An auditor who discovers the qualification themselves will discount everything else you presented.

4.4 Turning the field on

AWS states two limitations that catch people out. The field is not added to existing flow logs automatically: you must create new flow logs that include it. And AWS recommends adding ${traffic-path} and ${flow-direction} for more detailed information. The documented example takes this form:

aws ec2 create-flow-logs \
--resource-type VPC \
--resource-ids vpc-12345678901234567 \
--traffic-type ALL \
--log-group-name my-flow-logs \
--deliver-logs-permission-arn arn:aws:iam::123456789101:role/publishFlowLogs
--log-format '${encryption-status} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${traffic-path} ${flow-direction} ${reject-reason}'

The general behavior of custom formats is documented in Flow log records, which also states the convention that a field that is not applicable or could not be computed displays a hyphen. That convention is why the "unknown" value and "the control is off" value are indistinguishable in the log: both render as -. If you need to tell them apart, the mode of the control is what tells you, not the log.

Reading these logs at scale is ordinary flow log work, and AWS VPC Network Troubleshooting Guide covers the query patterns.

5. Finding the Resources That Block Enforcement

5.1 The API that answers the question

AWS documents GetVpcResourcesBlockingEncryptionEnforcement, available in the console and as aws ec2 get-vpc-resources-blocking-encryption-enforcement, for identifying resources that are not enforcing encryption in transit.

This is the operation that converts the project from open-ended to finite. Before it, "make everything encrypted" is a research task across every team. After it, you have a list, and the list either shrinks or it does not.

5.2 What appears on the list, and what does not

The blocking-resources list is about resources whose underlying compute you choose. AWS states that certain VPC resources and services require you to select the underlying instance types, that all modern EC2 instances support encryption in transit, and that no change is needed if your services already use modern instances. The services AWS names in this category are EC2 instances, Auto Scaling groups, RDS including all databases and DocumentDB, ElastiCache Provisioned, Amazon Redshift Provisioned clusters, EKS, ECS on EC2 container instances, OpenSearch Provisioned, and EMR.

What does not appear is equally important. Resources that AWS migrates for you, listed in section 10, are not your problem. And the eight excludable resource types in section 7 are not remediated at all; they are decided.

The blocking-resources list is not a complete inventory of your encryption risk. It answers one question well: what stands between this VPC and enforce mode. Traffic leaving through an excluded gateway is outside its scope by design, and you have to account for that separately.

5.3 Making the query part of the loop

Run the query on a schedule from the beginning of the project, not once. Two things change under you. Teams launch resources, and the list grows in ways that are informative about which teams have not been reached. And AWS expands service support over time, which can move an item from the manual-migration column to the automatic one.

The result of each run is an artifact worth keeping, for the reason developed in section 13: a series of dated blocking-resource lists that shrinks to empty is a far better piece of evidence than a single screenshot of an empty list.

6. Enforce Mode and the Ordering Constraint

6.1 What enforce mode does

In enforce mode, AWS states that VPC Encryption Controls prevents you from using any features or services that allow unencrypted traffic within the VPC boundary, and specifically that it prevents you from creating or attaching unencrypted VPC resources such as older EC2 instances that do not support native built-in encryption, or internet gateways. To run a non-compliant resource in an encryption-enforced VPC, you must create an exclusion for it.

The mechanism is a control-plane block on creation and attachment. That is what makes it satisfy the non-circumvention property in section 3, and it is also what makes it capable of breaking a deployment pipeline that was previously fine.

6.2 The ordering constraint

AWS is unambiguous. Existing VPCs can only be enabled in monitor mode first. You cannot enable enforce mode directly on an existing VPC: you must turn on monitor mode, identify and modify non-compliant resources, and only then turn on enforce mode. New VPCs, by contrast, can be created with enforce mode on.

The constraint is a safety property rather than an inconvenience, and it is worth stating in those terms to whoever is asking why the project has a phase they did not budget for. Skipping observation on a live VPC would mean discovering the inventory by breaking things.

The asymmetry with new VPCs also suggests a strategy. For a greenfield workload, creating the VPC in enforce mode from the start avoids the entire remediation phase, because nothing non-compliant ever gets in. Where you have the choice, enforce from creation is dramatically cheaper than enforcing later, and that is an argument for making it the default in your VPC provisioning module rather than a migration project.

6.3 Modes and states, and which source to trust

The user guide and the API reference describe the state machine differently, confirmed 2026-08-09.

The user guide's "VPC Encryption Controls States" section lists creating, modify-in-progress, deleting, and available. The describe-vpc-encryption-controls CLI reference documents Mode with possible values monitor and enforce, and State with possible values creating, monitor-in-progress, enforce-in-progress, available, monitor-failed, enforce-failed, deleting, deleted, and delete-failed. Exclusion state has its own enum of enabling, enabled, disabling, and disabled.

Build automation against the API reference enum. It is more granular, it distinguishes which transition is in progress, and it includes the failure states that any real automation has to handle. A script that treats anything other than available as "still working" will hang forever on enforce-failed.

7. Exclusions and Their Limits

7.1 The eight, and only the eight

AWS's reasoning is worth stating before the list. Enforce mode requires that all resources in the VPC enforce encryption, which ensures encryption within AWS in a Region. But some resources, such as an internet gateway, a NAT gateway, or a virtual private gateway, allow connectivity outside AWS networks, where you are responsible for configuring and maintaining end-to-end encryption. An exclusion, in AWS's words, creates an auditable exception for resources where the customer is responsible for maintaining encryption, typically at the application layer.

AWS states that there are only eight supported exclusions, that they must be added when switching from monitor to enforce mode, and that no other resources are excludable. Confirmed 2026-08-09 from the VPC Encryption Controls documentation; this table reproduces the documented set in full rather than a selection.

Excludable resource	Why an exclusion exists
Internet Gateway	Connectivity outside AWS networks
NAT Gateway	Connectivity outside AWS networks
Egress-only Internet Gateway	Connectivity outside AWS networks for IPv6
VPC Peering connections to encryption un-enforced VPCs	The far side does not enforce, so encryption cannot be guaranteed
Virtual Private Gateway	Connectivity outside AWS networks
Lambda functions inside your VPC	Documented as excludable
VPC Lattice	Documented as excludable
Elastic File System	Documented as excludable

7.2 What finiteness implies

A closed list of eight is a much stronger design constraint than an open exception mechanism, and it changes how you plan.

Anything not on the list has exactly two outcomes: it becomes compliant, or the VPC does not go to enforce mode. There is no third option, and no amount of negotiation produces one. That means the resources named in section 5.2 are a hard remediation backlog, and the two service pairs in section 10 that are outright unsupported in enforce mode determine, on their own, whether a given VPC is a candidate at all.

The corollary is a planning technique: run the blocking-resources query early and check the result against the list of eight. Anything in the result that is not excludable is work. Anything unsupported in enforce mode means this VPC stays in monitor mode, and you should know that in week one rather than week ten.

7.3 Treat every exclusion as a documented handoff

AWS calls an exclusion an auditable exception, and the useful discipline is to make that literal. For each exclusion, record what traffic it covers, which team owns the encryption on the far side, what mechanism they use, and when the exclusion will be reviewed. An exclusion without an owner is the fastest way to turn an enforcement project into a compliance finding, because it converts an explicit gap into an invisible one.

8. Gateways Under Enforcement

Four of the eight exclusions are gateways, which means the boundary of enforcement is, in practice, drawn at the point where traffic leaves the AWS network. Designing that boundary is most of the work.

8.1 The responsibility shift

Excluding a gateway does not weaken enforcement inside the VPC. It states, in a form that can be inspected through the API, that traffic through this gateway is outside the control's guarantee and that you assert protection by other means.

For each excluded gateway, the honest evidence looks like this:

1. Which flows use it. The ${traffic-path} field recommended in section 4.4 exists to make this answerable from the logs rather than from a diagram.
2. What protects those flows. For an internet gateway or NAT gateway, this is normally application-layer TLS in the client. For a virtual private gateway, it is the IPsec tunnel of the VPN connection.
3. How you know it holds. A statement that the application uses TLS is an assertion. A configuration that fails closed when TLS cannot be established is evidence.

8.2 Reducing the number of exclusions rather than documenting them

The stronger design move is to need fewer gateways. Every AWS-service dependency reached through an interface endpoint instead of a NAT gateway is a flow that stays inside the enforcement boundary, and AWS states that PrivateLink endpoints in an enforce-mode VPC drop traffic that is not application-layer encrypted, which turns the endpoint into an additional enforcement point rather than a gap. The endpoint design work itself is covered in AWS PrivateLink and VPC Endpoints Complete Guide, and the choice between connectivity options in AWS VPC Connectivity Decision Guide.

This is worth doing before enforcement rather than after. Removing a NAT gateway dependency from a workload is an ordinary change when it is planned, and an emergency when it is discovered during a cutover.

8.3 Deciding each gateway rather than excluding all four

The four gateway exclusions are not equivalent, and treating them as one checkbox loses information the reviewer will ask for. Each answers a different question about what is on the other side.

Excluded gateway	What is on the far side	The protection you are asserting	The question to answer first
Internet Gateway	Arbitrary internet destinations, inbound and outbound	Application-layer TLS in each client and server that uses it	Which workloads actually need inbound reachability, and can the rest move behind a different path
NAT Gateway	Arbitrary internet destinations, outbound only	Application-layer TLS in each client	How many of these destinations are AWS services that could be reached through an interface endpoint instead
Egress-only Internet Gateway	Arbitrary IPv6 destinations, outbound only	Application-layer TLS in each client	Same as NAT Gateway, applied to the IPv6 path
Virtual Private Gateway	Your own network over a VPN connection	The IPsec tunnel, plus whatever the applications add	Is the far side operated by you, and who attests to the tunnel configuration

The virtual private gateway case is the one most often waved through, on the reasoning that the far side is your own data center. That reasoning is fine and it still needs an owner, because "our own network" is a claim about an environment that a different team operates under a different change process.

8.4 A note on IPv6

An egress-only internet gateway is separately excludable, which means a dual-stack VPC can require two gateway exclusions where a single-stack one requires one. If your addressing plan is still being decided, IPv6-First VPC Design on AWS is the place that treats the addressing consequences properly.

9. Peering and Transit Gateway Scope

This is where the guarantee gets its sharpest edges, because the control is per VPC and traffic is not.

9.1 Peering

AWS states that to ensure encryption in transit with VPC peering between two VPCs, the two VPCs must reside in the same Region and have encryption controls turned on in enforce mode without any exclusions. You must create a peering exclusion to peer an encryption-enforced VPC with a VPC that is in a different Region or that does not have encryption controls in enforce mode without exclusions.

Then comes the trap, stated plainly in the documentation and easy to walk into: if two VPCs are in enforce mode and peered with each other, you cannot change the mode from enforce to monitor. You must create a peering exclusion first, and only then modify the mode.

Read that as an operational constraint on your rollback plan rather than as trivia. The obvious rollback from enforce mode is "switch back to monitor," and in exactly the configuration you were most proud of achieving, that rollback is blocked until you take another action first. Section 12 puts this on the plan explicitly.

9.2 Transit Gateway

AWS states that you must explicitly enable encryption support on a Transit Gateway to encrypt traffic between VPCs that have encryption controls turned on. Enabling encryption on an existing Transit Gateway is non-disruptive to existing traffic flows, and migration of VPC attachments to encrypted lanes happens seamlessly and automatically.

The scope statement is precise and should be quoted in your design rather than paraphrased loosely. Traffic between two VPCs in enforce mode without exclusions, through the Transit Gateway, traverses fully encrypted lanes. Transit Gateway encryption also lets you connect VPCs that are in different Encryption Controls modes, and AWS gives the intended use directly: use it when you want to enforce encryption controls in a VPC that is connected to a non-encryption-enforced VPC.

And then the limit. In that mixed case, AWS states that traffic between a resource in the enforce-mode VPC and a resource in the monitor-mode VPC is encrypted up to the Transit Gateway, using the encryption offered by Nitro System hardware, and that beyond that point the encryption status depends on the resources in the non-enforced VPC and is not guaranteed. All VPCs must be in the same Region.

9.3 How to state this to an auditor

The temptation is to describe a hub-and-spoke estate with Transit Gateway encryption enabled as "encrypted." The accurate statement has a boundary in it, and the boundary is per pair of endpoints rather than per network.

A defensible formulation: traffic between any two enforce-mode VPCs without exclusions is encrypted end to end across the Transit Gateway; traffic to a VPC that is not in that state is encrypted as far as the Transit Gateway and unguaranteed beyond it; and the list of VPCs in each category, with a confirmation date, is attached. That is a longer sentence than "everything is encrypted," and it is the one that survives scrutiny.

10. Generational Transitions and Service-Specific Limits

10.1 What AWS migrates for you

AWS states that Network Load Balancers, Application Load Balancers, Fargate clusters, and the EKS control plane will automatically migrate to hardware that natively supports encryption once you turn on monitor mode, with no modification required from you and with AWS handling the migration.

This is a genuinely useful property and it has a planning implication that gets missed: turning on monitor mode is not a purely observational act. It starts infrastructure migrations underneath managed services. They are described as automatic and non-disruptive, and they should still be scheduled like a change rather than performed on a Friday afternoon during a freeze.

AWS also states that most services supported by PrivateLink, including Cross-Region PrivateLink, accept application-layer-encrypted traffic and require no changes, with Redshift called out as an exception.

10.2 What you migrate yourself

The manual-migration set from section 5.2 comes down to instance generations. AWS states that all modern EC2 instances support encryption in transit, so the remediation is an instance type change wherever an older generation is still running: EC2 instances, Auto Scaling groups, RDS across all databases and DocumentDB, ElastiCache Provisioned, Redshift Provisioned clusters, EKS, ECS on EC2 container instances, OpenSearch Provisioned, and EMR.

For most estates the long pole is not the technical change but the coordination. Each of those has a maintenance window, an owner, and a test plan.

10.3 Service-specific limits worth knowing before you commit

These are the constraints that decide whether a VPC is a candidate for enforce mode at all. All confirmed 2026-08-09 from the VPC Encryption Controls documentation.

Service	Constraint under enforce mode
Network Load Balancer	You cannot use a TLS listener to offload encryption and decryption to the load balancer. You can configure the targets to perform TLS encryption and decryption instead
Amazon Redshift Provisioned and Serverless	You cannot move a VPC with an existing cluster or endpoint to enforce mode. Provisioned clusters must be snapshotted and restored from the snapshot; Serverless namespaces must be snapshotted and restored onto the workgroup
Amazon MSK	Supported for new clusters on Kafka version 4.1 in their own VPC. The documented sequence enables the control on a VPC with no other MSK clusters, then creates the cluster with Kafka 4.1 on M7g
Gateway Load Balancer and AWS Network Firewall	Not supported with VPCs in enforce mode. If present, the VPC must run in monitor mode
Local Zone subnets	Not supported in enforce mode and must be deleted from the VPC

Two of these are decisive rather than inconvenient. A VPC containing a Gateway Load Balancer or AWS Network Firewall cannot go to enforce mode, which rules out the common centralized-inspection VPC entirely, and that is a fact to establish in week one. And the Redshift constraint means enforcement is gated on a snapshot-and-restore of a data warehouse, which is not a change anyone schedules casually.

The NLB constraint has an architectural consequence rather than just an operational one. Moving TLS termination from the load balancer to the targets changes where certificates live, how they are rotated, and what the targets have to do. If your current design depends on TLS offload, budget for that rather than treating it as a configuration flag. The trade-offs between load balancer types are covered in AWS Elastic Load Balancing Decision Guide.

11. Scaling the Control to Accounts and Organizations

Per-VPC configuration does not survive an estate of any size, and AWS provides two levels above it.

11.1 Account level

Account-level VPC Encryption Controls let you set the mode and resource exclusions that apply to all VPCs in the account, and AWS states that the account level supports the same eight resource exclusions as the VPC level.

The modes are named differently from the VPC-level modes, and the difference in naming is meaningful:

Account-level mode	Behavior
Unmanaged	VPC Encryption Controls remain in their current mode and can be managed at the VPC level
Attempt Monitor	Attempts to transition all VPCs in the account to monitor mode, identifying unencrypted resources without blocking creation
Attempt Enforce	Attempts to transition all VPCs in the account to enforce mode, blocking creation of unencrypted resources

The word "attempt" is doing real work. A per-account instruction is a desired state applied to a heterogeneous set of VPCs, and some of them will not be able to comply. That is why the account-level states include a partial outcome, confirmed 2026-08-09: default-state, transitions-in-progress, transitions-partially-successful, transitions-failed, and transitions-successful.

Treat transitions-partially-successful as the normal outcome of the first attempt, not as an error. It is the account-level equivalent of the blocking-resources list, and the VPCs that did not transition are your backlog.

11.2 Organization level

AWS states that if you use AWS Organizations, you can use an Organizations declarative policy to enforce VPC Encryption Controls across the accounts in the organization.

Declarative policies are worth understanding as a distinct instrument rather than as another policy type. Declarative policies in AWS Organizations describes them as a way to centrally declare and enforce a desired configuration for a service at scale, with the property that the configuration is maintained even when the service adds new features or APIs, and it names enforcing encryption in transit for VPC traffic as one of its examples. That durability property is exactly what a compliance control needs and what an allow-list style guardrail struggles to provide.

Declarative policies are not a replacement for service control policies and resource control policies, which restrict what principals and resources may do. The two solve different problems and are usually deployed together; AWS Organization Guardrails with SCP and RCP covers the permission-boundary side.

11.3 Choosing the level

A workable division: use the organization level to state the intent so that new accounts inherit it, use the account level to move whole accounts through monitor, and keep VPC-level configuration for the exceptions that need their own exclusion set. Applying enforcement organization-wide before the blocking-resource backlog is empty produces a large number of partial transitions and very little insight, so sequence the levels rather than turning them all on at once.

12. A Rollout Plan That Does Not Break Production

Each stage below states what to do, how to tell it worked, and how to get back. The rollback column is the part that is usually missing, and section 9.1 is the reason it cannot be assumed.

Before anything: two go or no-go checks. Does the VPC contain a Gateway Load Balancer or AWS Network Firewall, and does it contain a Redshift cluster or endpoint? The first makes enforce mode impossible and the VPC stays in monitor mode permanently. The second makes enforcement conditional on a snapshot-and-restore. Both are cheaper to learn now.

Stage 1: Enable monitor mode

Create the encryption control in monitor mode on a non-production VPC first. This is not purely observational: per section 10.1, load balancers, Fargate clusters, and the EKS control plane begin migrating to encryption-capable hardware at this point. Schedule accordingly.

Verification: the control reaches state available with Mode of monitor.

Rollback: delete the encryption control. There is no peering interlock at this stage.

Stage 2: Create flow logs carrying the field

Create new flow logs including ${encryption-status}, plus ${traffic-path} and ${flow-direction}. Existing flow logs will not acquire the field.

Verification: records appear with values in the documented set rather than uniformly -.

Rollback: delete the new flow logs. This has no effect on the control.

Stage 3: Establish the baseline

Let the logs run long enough to cover the real duty cycle, including batch windows, month-end processing, and disaster recovery exercises. A week that excludes your monthly job is not a baseline.

Verification: you can name, for each 0 value in the logs, which resource produced it.

Rollback: not applicable.

Stage 4: Enumerate and remediate

Run GetVpcResourcesBlockingEncryptionEnforcement on a schedule and drive the list down. Sort the result into three buckets: AWS migrates it, you migrate it, or it is one of the eight excludable types.

Verification: the list contains only excludable resource types.

Rollback: instance type changes revert individually in the normal way.

Stage 5: Decide the exclusions

For each remaining item, write the handoff record from section 7.3. This is a decision point with a named owner, not a formality.

Verification: every exclusion has an owner, a stated protection mechanism, and a review date.

Rollback: not applicable.

Stage 6: Enforce, in the right order

Switch to enforce mode with the exclusions configured. Do the least connected VPC first.

Verification: state available with Mode of enforce, and no new denials in deployment pipelines.

Rollback, and read this before stage 6: switching back to monitor is normally available, but if this VPC is peered with another enforce-mode VPC, you must create a peering exclusion first. Rehearse that sequence in non-production. A rollback plan whose first step fails is not a rollback plan.

Stage 7: Raise the level

Once a representative set of VPCs is stable, move to account level with Attempt Monitor, then Attempt Enforce, expecting transitions-partially-successful and treating the residue as the next backlog. Then express the intent as an Organizations declarative policy so new accounts inherit it.

Verification: account state reaches transitions-successful for the accounts in scope.

Rollback: set the account-level mode back to Unmanaged, which returns control to the VPC level.

Do not enable enforce mode on a production VPC as a test. It blocks creation and attachment of non-compliant resources immediately, and the rollback is conditional on the peering topology.

13. Producing Audit Evidence

Everything above exists to produce a package someone else can check. Four artifacts carry most of the weight.

The dated series of blocking-resource lists. Each run of GetVpcResourcesBlockingEncryptionEnforcement is a point on a curve. A curve that reaches empty demonstrates a process; a single empty list demonstrates one query.

Flow log evidence with the inference stated. Report the distribution of encryption-status values over a defined window, and include the qualification from section 4.3 in your own words: that values of 2 on endpoint flows are port-based inferences documented by AWS rather than payload inspection. Volunteering the limitation is what makes the rest credible.

The exclusion register. The eight types, which are in use, who owns the far side of each, what protects it, and when it is next reviewed. AWS calls an exclusion an auditable exception, and this register is what makes that true in your environment rather than only in the API.

The configuration history. Mode changes, exclusion changes, and the state transitions the control passed through. Continuous evaluation of these as configuration rules is a natural fit for AWS Config Rules, Conformance Packs, and Remediation Guide, and the retention and aggregation side is covered in AWS Centralized Logging and Audit Architecture Guide.

One framing point about scope. This control is per Region, and the flow log evidence covers the VPCs where you enabled it. Say so. An evidence package that implies Region-wide or organization-wide coverage it does not have is a finding waiting to happen, and the fix costs one sentence.

13.1 How often the package has to be refreshed

Evidence has a shelf life, and different artifacts age at different rates. A workable cadence, stated as a property of the artifact rather than of the calendar:

1. The blocking-resource list ages fastest, because anyone can launch a resource. Query it at least as often as your fastest deployment cycle, and treat any non-empty result on an enforce-mode VPC as an alert rather than a report, since it means something was created that the control now has to block.
2. The flow log distribution should cover a window that includes the full duty cycle rather than the last seven days by default. The right window is whatever period contains your least frequent recurring workload.
3. The exclusion register ages by ownership rather than by time. Re-confirm it whenever a team reorganizes, not only on the review date, because the failure mode is an exclusion whose owner has left.
4. The mode and state history does not age, but it does need to be retained long enough to cover the audit period, which is usually longer than a default log retention setting.

The reason to write the cadence down is that it is itself evidence. A reviewer who asks how you know the environment is still compliant is asking for the refresh process, and "we run the query weekly and here are the last twelve results" is a materially different answer from a current screenshot.

14. Failure Modes

14.1 Treating monitor mode as a no-op

Monitor mode triggers automatic migration of load balancers, Fargate clusters, and the EKS control plane to encryption-capable hardware. Teams that enable it during a change freeze on the grounds that it "only observes" are enabling infrastructure migrations they did not schedule. Announce it as a change.

14.2 Reading the flow log field as cryptographic proof

Value 2 on an endpoint flow is an inference from the port, documented as such. Building a dashboard that reports it as verified encryption, and then having an auditor read the AWS documentation, costs more credibility than the finding itself. State the inference up front.

The mirror-image error is treating - as a problem. It means unknown or the control is off, and those are very different situations. Check the mode before investigating the flow.

14.3 Assuming rollback from enforce mode is always available

Two enforce-mode VPCs peered together cannot be moved back to monitor until a peering exclusion is created. Discovering this during an incident, when the plan says "switch back to monitor," is the worst possible time. Put the exclusion step in the runbook and rehearse it.

14.4 Letting exclusions become permanent

An exclusion is a documented handoff of responsibility. Without an owner and a review date it becomes a permanent invisible gap that reads, from the API, exactly like a deliberate design decision. Review the register on a fixed schedule and require a re-justification each time.

14.5 Discovering an unsupported service late

A Gateway Load Balancer or AWS Network Firewall in the VPC means enforce mode is not available, full stop. A Redshift cluster means enforcement requires a snapshot-and-restore. Both are week-one questions. Finding them at stage 6 invalidates the plan, not just the schedule.

14.6 Writing automation against the wrong state list

The user guide and the API reference describe the state machine differently. Automation written against the user guide's four states will not recognize monitor-failed or enforce-failed and will wait forever for a transition that already failed. Use the API reference enum and handle the failure states explicitly.

14.7 Confusing per-VPC scope with estate-wide coverage

The control is per VPC, per Region. A claim of complete coverage requires enumerating the VPCs in scope and the ones that are not, in every Region you operate. The account-level and organization-level features exist to make that enumeration tractable, and they do not make it automatic.

15. Frequently Asked Questions

Can I turn on enforce mode directly on an existing VPC?

No. AWS states that existing VPCs can only be enabled in monitor mode first, and that you must identify and modify non-compliant resources before turning on enforce mode. New VPCs can be created with enforce mode on.

Does enabling monitor mode change anything about my running resources?

Yes, more than the name suggests. AWS states that Network Load Balancers, Application Load Balancers, Fargate clusters, and the EKS control plane automatically migrate to hardware that natively supports encryption once you turn on monitor mode. AWS handles the migration, and you should still treat it as a scheduled change.

Why does my flow log show a hyphen for encryption status?

A hyphen means the encryption status is unknown or VPC Encryption Controls is off. The general flow log convention is that a field that is not applicable or could not be computed displays a hyphen. Check the mode of the control before investigating the flow itself.

Can I exclude a resource type that is not on the list of eight?

No. AWS states that there are only eight supported exclusions and that no other resources are excludable. Anything else either becomes compliant or the VPC does not reach enforce mode.

We use a centralized inspection VPC. Can it go to enforce mode?

Not if it contains a Gateway Load Balancer or AWS Network Firewall, which AWS states are not supported with VPCs in enforce mode. Such a VPC must run in monitor mode.

Do I have to give up TLS termination on my load balancer?

For a Network Load Balancer in an enforce-mode VPC, yes. AWS states that you cannot use a TLS listener to offload encryption and decryption to the load balancer, and that you can configure the targets to perform TLS encryption and decryption instead. Plan for the certificate management change that implies.

Is traffic through a Transit Gateway encrypted automatically?

No. You must explicitly enable encryption support on the Transit Gateway. Enabling it on an existing Transit Gateway is non-disruptive and attachment migration is automatic. Traffic between two enforce-mode VPCs without exclusions then traverses fully encrypted lanes, while traffic toward a non-enforced VPC is encrypted only up to the Transit Gateway.

Can I peer an enforce-mode VPC with a VPC in another Region?

Not without a peering exclusion. AWS states that guaranteeing encryption in transit over peering requires both VPCs to be in the same Region and in enforce mode without exclusions; anything else requires a peering exclusion.

How do I get back from enforce mode to monitor mode?

Normally by modifying the mode. But if the VPC is peered with another enforce-mode VPC, AWS states that you must create a peering exclusion first. Rehearse this in non-production before you need it.

What is the difference between a declarative policy and a service control policy here?

A declarative policy centrally declares a desired service configuration and maintains it even as the service adds features and APIs, which is why AWS offers it for VPC Encryption Controls. A service control policy restricts what principals may do. They address different layers and are normally used together.

Which states should my automation handle?

Use the API reference enum: creating, monitor-in-progress, enforce-in-progress, available, monitor-failed, enforce-failed, deleting, deleted, and delete-failed, plus the exclusion states enabling, enabled, disabling, and disabled. The user guide's shorter list omits the failure states.

16. Summary

The reason to adopt this feature is not that it encrypts things you could not encrypt before. It is that it converts an assertion into an artifact. The audit question is whether unencrypted traffic exists, and only a mechanism that observes all flows and blocks the non-compliant case can answer it.

Encryption in transit is layered, and the layer has to be named. Physical-layer encryption across Regions and between Availability Zones is a floor you do not configure. Nitro hardware encryption between instances holds only under three conditions, the third of which excludes intermediate network devices. Application-layer TLS is the layer that survives hops and that you can demonstrate. VPC Encryption Controls combines the hardware and application layers, and extends the hardware layer beyond instances to services including Fargate, load balancers, and Transit Gateway.

Monitor mode is mandatory first on existing VPCs, and it is not passive: it starts automatic hardware migrations for load balancers, Fargate, and the EKS control plane. It adds encryption-status to flow logs, with five values, and the value meaning "application-encrypted" on endpoint flows is a documented port-based inference rather than payload inspection. Say so in your evidence.

Enforce mode blocks creation and attachment of non-compliant resources. Exactly eight resource types can be excluded, and nothing else. Four of the eight are gateways, which places the enforcement boundary where traffic leaves the AWS network, and each exclusion should be recorded as a handoff with an owner and a review date.

The constraints that decide feasibility are best discovered in week one. Gateway Load Balancer and AWS Network Firewall rule out enforce mode entirely. Redshift requires snapshot and restore. Network Load Balancer loses TLS offload. Local Zone subnets must be removed. Two enforce-mode VPCs peered together cannot be rolled back to monitor until a peering exclusion exists, which is a constraint on your rollback plan and not a footnote. And for automation, the API reference state enum is the one to build against, because the user guide's shorter list omits the failure states your script will eventually meet.

17. References

• Enforce VPC encryption in transit - Amazon VPC User Guide
• Flow log records - Amazon VPC User Guide
• describe-vpc-encryption-controls - AWS CLI Command Reference
• Data protection in Amazon EC2 - Amazon EC2 User Guide
• Declarative policies in AWS Organizations - AWS Organizations User Guide
• Introducing VPC encryption controls - AWS News Blog
• The Boundaries of the AWS Global Network
• AWS Zero Trust Network Architecture Guide
• VPC Design Review Checklist
• AWS PrivateLink and VPC Endpoints Complete Guide
• AWS VPC Connectivity Decision Guide
• AWS VPC Network Troubleshooting Guide
• IPv6-First VPC Design on AWS
• AWS Elastic Load Balancing Decision Guide
• AWS KMS Envelope Encryption and Data Key Caching Guide
• AWS Config Rules, Conformance Packs, and Remediation Guide
• AWS Centralized Logging and Audit Architecture Guide
• AWS Organization Guardrails with SCP and RCP
• AWS Networking Glossary

References:
Tech Blog with curated related content