AWS Egress Control Template: Block Unauthorized Data Flows

Your team built ingress controls months ago. You've got WAFs, identity policies, and perimeter defenses in place. But when an unauthorized party gets in, or when an AI agent runs code it shouldn't, what stops them from sending your data out?

Most teams leave egress wide open because closing it feels like breaking things. This template gives you a working AWS egress architecture you can deploy today, with domain filtering, DNS inspection, and centralized routing that works for both traditional workloads and AI agents.

What This Template Does

This configuration implements a hub-and-spoke egress control pattern using AWS Transit Gateway, AWS Network Firewall, and Amazon Route 53 Resolver DNS Firewall. All internet-bound traffic from your spoke VPCs routes through centralized inspection before reaching the internet.

The architecture blocks two common exfiltration paths:

• Network-layer exfiltration: Direct connections to unauthorized external servers
• DNS tunneling: Encoding sensitive data in DNS queries to bypass network inspection

You'll deploy this in a multi-account AWS environment where application workloads, including AI agents running on Amazon Bedrock, sit in spoke VPCs. When any workload tries to reach the internet, Transit Gateway forces that traffic through Network Firewall for inspection against your domain allow-lists and threat intelligence feeds.

Prerequisites

Before you start:

• AWS Organizations with at least two accounts (one hub, one or more spokes)
• Transit Gateway already deployed or permissions to create one
• VPC endpoint policies drafted for your AWS service access patterns
• Domain allow-list: Documented list of external domains your workloads legitimately need
• IAM permissions for creating Network Firewall resources, DNS Firewall rule groups, and Transit Gateway attachments

You'll need to know which workloads require outbound access and to which specific endpoints. For AI agents with code execution or tool-calling capabilities, list the exact APIs they invoke.

The Configuration Template

Step 1: Create the Inspection VPC

Deploy a dedicated inspection VPC in your hub account:

Inspection VPC CIDR: 10.200.0.0/16
  Subnet: Firewall-AZ1 (10.200.1.0/24)
  Subnet: Firewall-AZ2 (10.200.2.0/24)
  Subnet: TGW-Attach-AZ1 (10.200.10.0/24)
  Subnet: TGW-Attach-AZ2 (10.200.11.0/24)
  Subnet: NAT-AZ1 (10.200.20.0/24)
  Subnet: NAT-AZ2 (10.200.21.0/24)

Attach this VPC to your Transit Gateway. Configure the Transit Gateway route table to send all spoke VPC traffic destined for 0.0.0.0/0 to the inspection VPC attachment.

Step 2: Deploy AWS Network Firewall

Create a firewall policy with these rule groups:

Domain Allow-List Rule Group:

Rule Group Name: Approved-External-Domains
Capacity: 500

Domain List:
  - .amazonaws.com
  - .github.com
  - .pypi.org
  - api.yourvendor.com
  
Action: ALLOW matching domains
Default Action: DROP all other traffic

Threat Intelligence Rule Group:

Rule Group Type: Managed
Source: AWS Managed Threat Signatures
Action: DROP on match

Port and Protocol Enforcement:

Rule: Allow HTTPS outbound
  Protocol: TCP
  Destination Port: 443
  Action: PASS to domain filtering

Rule: Allow DNS
  Protocol: UDP
  Destination Port: 53
  Action: PASS

Rule: Block all other ports
  Action: DROP

Deploy the firewall endpoints in Firewall-AZ1 and Firewall-AZ2 subnets. Update the inspection VPC route tables so that traffic from the Transit Gateway attachment subnets routes to the firewall endpoints, and traffic from the firewall endpoints routes to NAT gateways in NAT-AZ1 and NAT-AZ2.

Step 3: Configure Route 53 Resolver DNS Firewall

Create DNS Firewall rule groups and associate them with every spoke VPC:

DNS Rule Group: Block-Tunneling-and-Threats

Rule 1: AWS Managed Aggregate Threat List
  Domain List: AWSManagedDomainsMalwareDomainList
  Action: BLOCK
  Block Response: NXDOMAIN

Rule 2: Enable DNS Firewall Advanced (if available)
  Features: DNS tunneling detection, DGA detection
  Action: BLOCK on detection

Rule 3: Approved Domains Only
  Domain List: [Your allow-list from Network Firewall]
  Action: ALLOW

Rule 4: Default Deny
  Action: BLOCK
  Block Response: NXDOMAIN

Associate this rule group with all spoke VPCs where workloads run.

Step 4: Spoke VPC Routing

In each spoke VPC, configure route tables:

Destination: 0.0.0.0/0
Target: Transit Gateway Attachment

This forces all internet-bound traffic through the Transit Gateway, which routes it to the inspection VPC for Network Firewall inspection.

How to Customize It

For AI Agent Workloads:

If you're running AI agents on Amazon Bedrock with tool-calling or code execution, add the specific API endpoints those agents invoke to your domain allow-list. Don't open broad categories. For example:

- api.weather.com
- maps.googleapis.com

Deploy Amazon Bedrock Guardrails alongside these network controls to filter prompt injection attempts before they reach the agent.

For Traditional Workloads:

If you have legacy applications that make outbound calls to many endpoints, start with logging mode. Configure Network Firewall to ALERT instead of DROP, collect flow logs for two weeks, then build your allow-list from actual traffic patterns.

Geographic Restrictions:

If your organization operates only in specific regions, add geographic IP filtering:

Rule: Block traffic to non-business regions
  Source: Any
  Destination: [IP ranges for restricted countries]
  Action: DROP

TLS Inspection:

For environments where you need to inspect encrypted traffic, enable TLS decryption in Network Firewall. You'll need to import your own certificate authority and configure workloads to trust it.

Validation Steps

After deployment, verify your controls work:

1. Test domain blocking: From an EC2 instance in a spoke VPC, attempt to curl a domain not on your allow-list. You should see connection timeout or DNS resolution failure.

2. Check DNS filtering: Run nslookup malicious-test-domain.com from a spoke instance. DNS Firewall should return NXDOMAIN if the domain is on the AWS Managed Aggregate Threat List.

3. Review flow logs: Enable Network Firewall flow logs and alert logs. After 24 hours, query CloudWatch Logs Insights for DROP actions. Investigate any unexpected legitimate traffic that was blocked.

4. Test AI agent constraints: If you deployed this for AI workloads, trigger an agent action that should invoke an approved API. Confirm it succeeds. Then attempt to invoke an unapproved endpoint and confirm it fails.

5. Monitor GuardDuty findings: Enable Amazon GuardDuty and watch for findings related to unauthorized DNS queries or unusual outbound traffic patterns. These indicate attempts that your egress controls blocked.

When CVE-2025-55182 (React2Shell) was disclosed in December 2025, exploitation attempts began within hours. Organizations with egress controls in place blocked the unauthorized outbound command-and-control traffic those exploits attempted to establish. Organizations without egress controls didn't detect the unauthorized access until much later, often during compliance audits or after customer complaints.

Your ingress defenses won't stop everything. When something gets through, egress controls become your last line of defense before data leaves your environment. Deploy this template, tune your allow-lists based on real traffic, and you'll have visibility into what's leaving your network, whether it's an application with unauthorized access or a manipulated AI agent trying to exfiltrate data through DNS tunneling.