Networking & Content Delivery

Enhanced security with DMZ architecture using Amazon VPC Block Public Access

As organizations scale their AWS environments across multiple accounts and Amazon virtual private clouds (VPCs), controlling internet access to cloud resources becomes challenging. With multiple accounts and network paths, maintaining secure network boundaries becomes a priority. A common security pattern is the demilitarized zone (DMZ) architecture, which isolates public-facing services from internal networks to reduce threat vectors.

AWS has launched a feature that simplifies this approach: Amazon VPC Block Public Access (BPA). This declarative control provides an authoritative way to block internet traffic to and from your VPCs, helping organizations maintain compliance with security requirements while reducing the risk of accidental exposure.

In this post, we walk through how to use VPC BPA to build centralized egress and ingress architectures for a DMZ. We also cover how to enforce VPC BPA across multiple accounts using declarative policies, and a brief comparison of VPC BPA with service control policies (SCPs) for controlling internet access.

Solution overview

VPC BPA authoritatively blocks incoming (ingress) and outgoing (egress) VPC traffic through AWS provided internet paths. With this feature, customers can comply with their organization’s security requirements by centrally blocking AWS provided internet access to resources in their VPCs. For full details on how VPC BPA works, refer to Block public access to VPCs and subnets.

VPC BPA offers two configuration modes:

  • Bidirectional block – Blocks traffic to and from internet gateways (IGWs) and egress-only internet gateways (EIGWs) in the selected AWS Region, except for excluded VPCs and subnets
  • Ingress-only block – Blocks inbound internet traffic to VPCs in the Region, except for excluded VPCs or subnets, while allowing outbound connections through NAT gateways and EIGWs

Prerequisites

Before you begin, make sure you have the following in place:

Create DMZ architecture with VPC Block Public Access

A traditional DMZ architecture in on-premises environments involves creating a separate network segment that sits between the public internet and the private internal network. In AWS, you can achieve a similar architecture using VPC BPA to control internet access for workloads that require strict isolation.When designing network architectures on AWS, organizations choose between centralized or decentralized approaches for internet connectivity. VPC BPA can strengthen security in both models. The following sections describe centralized egress and ingress architectures.

Implement centralized egress architecture with VPC Block Public Access

A centralized egress architecture uses a single, common inspection point for network traffic destined for the internet. This approach offers the following benefits:

  • Cost-efficiency – Reduces costs by alleviating the need to deploy NAT gateways in each VPC
  • Improved security – Limits exposure to externally accessible malicious resources, such as malware command and control infrastructure
  • Simplified management – Provides a single point for traffic inspection and policy enforcement
  • The following diagram illustrates the centralized egress architecture with VPC BPA.
Diagram showing Centralised egress architecture with VPC BPA with traffic flow

Figure 1. Centralized egress architecture with VPC BPA

Figure 1. Centralized egress architecture with VPC BPAThe following steps correspond to the architecture in Figure 1:

  1. Create a dedicated VPC containing public subnets with NAT gateways, private subnets for transit gateway attachments, and an internet gateway for outbound connectivity. For instructions, refer to Create a VPC.
  2. Create a transit gateway with multiple route tables to maintain VPC-to-VPC isolation while centralizing outbound traffic. For instructions, refer to Create a transit gateway in AWS Transit Gateway.
  3. Apply bidirectional block mode to spoke VPCs so they can’t access the internet directly. For instructions, refer to Enable VPC BPA bidirectional mode for your account.
  4. Configure an exclusion for the Egress VPC to allow it to communicate with the internet. For instructions, refer to Create and delete exclusions.
  5. Set up route tables in the spoke VPCs to send internet-bound traffic (0.0.0.0/0) to the transit gateway, which then routes it to the Egress VPC. For instructions, refer to Create a transit gateway route table in AWS Transit Gateway.

In this architecture, traffic from Amazon Elastic Compute Cloud (Amazon EC2) instances in spoke VPCs routes to the transit gateway through the default route. The transit gateway forwards this traffic to the Egress VPC, where it passes through NAT gateways before reaching the internet.

Implement centralized ingress architecture with VPC Block Public Access

For incoming traffic from the internet, a centralized ingress architecture provides a controlled entry point to your AWS environment.

Diagram showing Centralized ingress architecture with VPC BPA

Figure 2. Centralized ingress architecture with VPC BPA

The following steps correspond to the architecture in Figure 2:

  1. Create a VPC containing public subnets with an internet-facing Application Load Balancer (ALB) or Network Load Balancer (NLB), and private subnets for transit gateway attachments. For instructions, refer to Create a VPC.
  2. Set up route tables to direct traffic from the Ingress VPC to destination VPCs. For instructions, refer to Create a transit gateway route table in AWS Transit Gateway.
  3. Apply bidirectional block mode to application VPCs so the internet can’t reach them directly. Use the same procedure described in the centralized egress section (Step 3).
  4. Configure an exclusion for the Ingress VPC to allow it to receive traffic from the internet. Use the same procedure described in the centralized egress section (Step 4), replacing the VPC ID with your Ingress VPC ID.

In this architecture, traffic from the internet reaches the central Ingress VPC, where the ALB/NLB forwards requests to target groups in application VPCs through the transit gateway.

Enable VPC Block Public Access across multiple accounts using declarative policies

For organizations operating in a multi-account environment, AWS Organizations provides declarative policies to implement VPC BPA at scale. Unlike SCPs that control API authorization, declarative policies enforce configurations directly at the service level, providing a consistent security posture across your organization.

To deploy VPC BPA across multiple accounts, follow these steps:

  1. Create a declarative policy document. The following example enables bidirectional blocking with an exclusion for a specific VPC:
{
  "ec2_attributes": {
    "exception_message": {
      "@@assign": "Internet access blocked by organization policy. Contact security@example.com for assistance."
    },
    "vpc_block_public_access": {
      "block_mode": {
        "@@assign": "bidirectional"
      },
      "exclusions": {
        "@@assign": {
          "resource_id": "vpc-12345678",
          "allow_mode": "bidirectional"
        }
      }
    }
  }
}
  1. Create and attach the policy through the AWS Organizations console or the AWS CLI, targeting the organization root, specific organizational units (OUs), or individual accounts. For instructions, refer to Declarative policies.
  2. Use the account status report to monitor compliance and identify accounts with matching or non-matching configurations.

This approach provides the following benefits:

  • Centralized enforcement – You can apply consistent VPC BPA settings across your organization
  • Automatic inheritance – New accounts automatically inherit policies based on their OU membership
  • Simplified management – You can maintain security controls at scale without configuring each account individually
  • Flexible exclusions – You can define organization-wide exceptions for internet-facing resources that need connectivity.

For the full declarative policy syntax, refer to Declarative policy syntax and examples.

Comparing VPC BPA with SCPs

SCPs have been a traditional method to control internet access at the account level. VPC BPA provides a more granular approach. The following table summarizes the key differences relevant to DMZ architecture decisions.

Feature SCP Approach BPA Approach
Scope Account/OU level VPC/subnet level
Existing resources Doesn’t affect VPCs with existing IGWs Blocks traffic even in VPCs with pre-existing IGWs
Enforcement Prevents API actions (for example, creating IGWs) Actively blocks network traffic
Directional control All-or-nothing approach Supports bidirectional or ingress-only blocking
Exceptions Requires complex OU structures Granular exclusions per VPC/subnet
Onboarding legacy accounts Breaks existing internet-dependent workloads Maintains functionality while blocking unwanted traffic
Compliance Reactive (prevents configuration changes) Proactive (enforces traffic flow rules)

Best practices for VPC Block Public Access in DMZ architectures

To get the most out of VPC BPA in your network architecture, follow these recommendations:

  • Assess current internet exposure – Before you enable VPC BPA, identify which resources currently have internet access.
  • Plan your exclusions – Determine which VPCs or subnets need internet access and create exclusions for them.
  • Apply least privilege – Create exclusions only for VPCs or subnets that genuinely need internet access.
  • Monitor blocked traffic – Use VPC Flow Logs with the reject-reason field to monitor traffic blocked by VPC BPA. Enabling VPC Flow Logs has an associated cost.
  • Review exclusions regularly – Periodically review your exclusions to confirm they are still necessary and properly configured.
  • Use centralized egress for security-centric workloads – Implement a centralized egress architecture with VPC BPA to provide a single, controlled path to the internet.

Clean up

To avoid ongoing charges for the demo, delete the resources you created during this walkthrough:

  1. Remove VPC BPA exclusions that you created.
  2. Disable VPC BPA by setting the block mode to off.
  3. Delete the transit gateway attachments and the transit gateway.
  4. Delete NAT gateways, internet gateways, and release associated Elastic IP addresses.
  5. Delete the Egress VPC, Ingress VPC, and spoke VPCs.
  6. If you created declarative policies in AWS Organizations, detach and delete them.

Conclusion

In this post, we walked through how to use Amazon VPC Block Public Access to build a DMZ architecture with centralized ingress and egress patterns. We also covered how to enforce VPC BPA across accounts using declarative policies and how VPC BPA compares to SCPs for controlling internet access.VPC BPA gives you granular, proactive control over internet traffic at the VPC and subnet level. Combined with Transit Gateway and declarative policies, it provides a scalable approach to securing your network boundaries across multi-account environments.To learn more, refer to the following resources:


About the authors

Syed Wajid Kashani

Wajid is a Solutions Architect at AWS, based in India. He helps customers design, develop, and operate secure, scalable, and innovative solutions using the breadth and depth of AWS capabilities to deliver measurable business outcomes. He provides strategic technical guidance across the cloud journey from architecture reviews and migration planning to cost optimization and operational excellence.

Arun Kumar N C

Arun, an AWS Technical Account Manager specializing in cloud networking, Arun excels at building strategic customer relationships and providing expert guidance. He helps customers develop scalable, secure, and cost-effective cloud solutions, offering proactive support and tailored advice to optimize AWS environments and drive successful cloud adoption.

Debapriyo Jogi

Debapriyo, an AWS Technical Account Manager specializing in cloud networking, adeptly fosters strong customer relationships while offering expert technical guidance. He assists organizations in designing resilient, efficient, and adaptable cloud and network architectures. He provides strategic insights and tailored recommendations to optimize AWS usage, enhance network performance, and facilitate seamless cloud adoption.