“Encryption in transit” is no longer a “nice-to-have” — it’s a mandatory requirement for PCI-DSS, HIPAA, and modern Zero-Trust architectures. But how do you prove to an auditor that every packet in your VPC is encrypted?
You don’t do it with spreadsheets; you do it with VPC Flow Logs. By leveraging the new ${encryption-status} field and VPC Encryption Controls, you can audit, verify, and enforce hardware-level encryption across your entire infrastructure with a single click.
VPC Encryption Controls is a security and compliance feature introduced by AWS to provide centralized visibility and authoritative control over the encryption of data moving within and between your Virtual Private Clouds.
Historically, verifying that all “east-west” traffic (traffic between your internal instances, load balancers, and databases) was encrypted was a manual and complex task, often involving messy spreadsheets and custom auditing scripts. This feature automates that process by leveraging the AWS Nitro System hardware and application-layer metadata.
The Two Core Modes
To help you reach a fully encrypted state without breaking your existing applications, the feature operates in two phases:
Key Capabilities
Detailed Auditing: Adds a new ${encryption-status} field to VPC Flow Logs, showing you at a glance if traffic is encrypted via Nitro hardware (1), application-level TLS (2), both (3), or not at all (0).
Resource Identification: Provides a “To-Do” list in the AWS Console of specific resources (like older EC2 instances or HTTP listeners) that are preventing you from reaching an enforced security posture.
Seamless Upgrades: Automatically migrates managed infrastructure like Application Load Balancers (ALB) and Fargate tasks to Nitro-based hardware to ensure they meet encryption standards transparently.
Compliance Ready: Simplifies the proof required for regulatory frameworks like HIPAA, PCI DSS, and FedRAMP by providing an authoritative dashboard of encryption status.
Why use it?
If your organization follows a Zero Trust architecture, you can no longer assume that internal traffic is “safe” just because it’s inside the VPC. VPC Encryption Controls allow you to verify and mandate that every single packet is encrypted, providing a critical layer of defense-in-depth against internal threats or misconfigurations.
In this demo, I have created a VPC with below resources
Architecture diagram:
My application(static website) has four EC2 instances(webservers) behind an Application load balancer
Created VPC Encryption control in “Monitor” mode to first audit the encryption status of resources in my VPC
In simple terms, Monitor Mode is like a security camera for your network. It watches all the data moving around your VPC and takes notes on whether that data is “scrambled” (encrypted) or “plain text” (unencrypted).
Crucially, it does not block or change anything. Your website and apps will keep running exactly as they are while it gathers information
Below resources have been flagged as resources accepting unencrypted traffic
Internet Gateway
You can configure specific exclusions for resources such as internet gateways or NAT gateways, that don’t support encryption (because the traffic flows outside of the AWS network).
- Elastic Network interfaces include the four EC2 instances(t2.micro) and NAT Gateway
Moving to a Fully Encrypted VPC(Enforce mode)
Once you have identified unencrypted resources in Monitor Mode, you can begin migrating them to a secure state. Depending on the service type, this process is either automatic or requires a manual upgrade.
- Automatic Migration (No Action Required) Certain managed services will handle the transition for you. AWS will transparently move the underlying infrastructure to Nitro hardware — which provides automatic encryption — with zero service interruption:
Application Load Balancers (ALB)
Network Load Balancers (NLB)
AWS Fargate Tasks
- Manual Migration (Action Required) For resources that you manage directly, such as Amazon EC2 instances, you must take one of the following steps to achieve encryption compliance:
Upgrade Hardware: Switch from older, legacy instances (like t2 or m4) to modern Nitro-based types (like t3, m5, c6g, etc.).
Encrypt the App: If you cannot upgrade the hardware, you must configure TLS/SSL encryption (HTTPS) manually at the application level.
I created custom VPC flow logs to capture the encryption status
Sent traffic to my Webservers via Application Load Balancer(Note that I am accessing ALB using http and not https)
Then, I checked my VPC flow logs to identify the encryption status
Encryption Status Code:
For EC2 instances running on t2.micro instance type, the encryption status field is 0 meaning no hardware level or app level encryption was detected
After I manually migrated two of my EC2 instances to m8a.medium(Nitro based instance), the encryption status field in the flow logs is 1 for those specific instances indicating hardware layer encryption
After manual migration to Nitro based instance type, those instances also got removed from the unencrypted resources list and only the remaining two instances(t2.micro) are flagged
IMPORTANT CATCH:
🛑 The “Port 80” Catch: Why isn’t my ALB flagged?
If you are running an Application Load Balancer (ALB) on Port 80, you might be surprised to see it missing from the “Unencrypted Resources” list. It feels like a security hole, but it’s actually due to a “silent upgrade” AWS performs for you.
- The Transparent Nitro Migration When you enable Monitor Mode, AWS identifies that the ALB is a managed service. It then automatically and transparently migrates the ALB’s underlying infrastructure to Nitro hardware.
Because Nitro-based hardware has a dedicated security chip that scrambles data at the physical network layer, the ALB is now capable of hardware encryption. In the eyes of VPC Encryption Controls, it is no longer a “blocker” to security — even if your application is still using Port 80.
- Status 1: The “Invisible” Internal Shield Even if you haven’t set up an SSL certificate yet, the traffic moving inside your VPC (from the ALB to a modern EC2 instance) is often automatically encrypted by the Nitro chips on both ends.
What you’ll see in logs: An encryption-status of 1.
What it means: Your internal “East-West” traffic is protected by hardware-level AES-256 encryption, even over an unencrypted protocol like HTTP.
- The “False Sense of Security” Warning This is the most important part : VPC Encryption Controls only track the journey inside the VPC.
Inside the VPC (ALB → EC2): Safe (Status 1).
Outside the VPC (User → ALB): UNSAFE.
If a user sends a password to your ALB on Port 80 over the public internet, that password is sent in plain text. It only gets “scrambled” by Nitro hardware after it reaches the ALB. To truly be secure, you must still move to Port 443 (HTTPS) to protect the data during its journey across the internet.
The reason Internet Gateways (IGW) and NAT Gateways are flagged while your ALB is not comes down to one thing: The Destination of the Data.
- The “Off-Ramp” Problem VPC Encryption Controls are designed to ensure data is encrypted within the AWS network.
The ALB sends data to another resource inside your VPC (like an EC2 instance). Because both ends are inside AWS, AWS can use Nitro hardware to scramble that data.
Gateways are different. Their entire purpose is to send data outside your VPC to the public internet.
Once data leaves through an IGW or NAT Gateway, AWS no longer owns the “wires” it travels on. AWS cannot force the rest of the internet to use Nitro hardware encryption. Therefore, these gateways are marked as Unencrypted because they are essentially “leaks” where protected data turns into unprotected public data.
- Physical vs. Logical Limitations ALB/Fargate: These are “Software-Defined” managed services. AWS can simply update the “code” they run on to include Nitro capabilities. That’s why they are automatically moved to the “Encrypted” list. Gateways: These are architectural “edge” points. A NAT Gateway is a middleman. If you send it unencrypted data from an EC2 instance, it must pass that unencrypted data out to the internet. It cannot “Nitro-encrypt” a packet that is destined for a Google or Netflix server.
- They are “Blockers” by Design In your dashboard, “Unencrypted Resources” really means “Things that will stop you from enabling Enforce Mode.” If you tried to turn on Enforce Mode without addressing these gateways, AWS would have to drop all your internet traffic to stay “compliant” with your security policy.
To fix this, AWS doesn’t expect you to “encrypt” the gateway. Instead, you must Exclude them
The 3-Step Process:
Monitor (Watch): Turn on Monitor Mode to find out resources that allow unencrypted traffic.
Fix (Upgrade): For resources, such as the previous generation of Amazon Elastic Compute Cloud (Amazon EC2) instances, you will need to switch to modern Nitro based instance types or configure TLS encryption at application level.
Enforce (Lock): Once the monitor shows everything is green, you flip the switch to “Enforce Mode,” which will block any future unencrypted traffic from even starting.
Top comments (1)
"Transitioning to a Zero Trust architecture is usually a long road, but seeing hardware-level encryption status directly in VPC Flow Logs makes the 'verify' part of 'Never Trust, Always Verify' much easier.
I’m curious—how are others handling the 'Manual Migration' part of this? Are you using this as an excuse to finally deprecate those older instance types, or are you just wrapping everything in application-level TLS?"