AWS Reference Architecture, Subnet Sizes and Automation

Showing results for 
Show  only  | Search instead for 
Did you mean: 
Please sign in to see details of an important advisory in our Customer Advisories area.

AWS Reference Architecture, Subnet Sizes and Automation

L3 Networker

1. The AWS Reference Architectures (AWS - Palo Alto Networks) and associated automation libraries all use a /16 CIDR for the Security VPC and a /24 for each subnet - including those for the TGW attachments and GWLB endpoints. AWS recommend deploying these resources in the smallest subnet available, a /28 - as they use a single IP and should not host any other resources. In fact, the AWS reference architecture uses /28 for all subnets.


I understand these are for reference, and customers will be using their own subnets, but I can't imagine any deployment where a subnet larger than /28 would provide any benefit - even for (centralised) inbound flows as the ALB/NLB can only use the firewall's public IP and different ports for multiple apps, it does not support "floating IP" for the firewall to NAT in the way an Azure ALB does.


This being the case, should the reference architecture be updated to align to AWS best practices and use practical subnet sizes? And is there any reason to deploy subnets larger than /28 in a production security VPC?


2. The automation libraries appear to differ from the deployment guide in several areas, as far as the Terraform modules for Centralised Design Model are concerned...

Design / Deployment guide Automation Libraries My 2c
Single GWLBe is deployed in each AZ for both east/west and outbound Two GWLBe's are deployed in each AZ, one for east/west and the other for outbound I don't see the point in separation, especially with overlay routing enabled you're confusing admins with different source zones for the same source networks depending on the destination?
Subnet names (tags) are readable e.g. security-mgmt-2a, security-fw-2a Subnet names are concatenated e.g. mgmta, privatea and do not contain a user-defined prefix I prefer to use a common prefix for these names and a separator for the AZ per the guide - while the tfvars example allows a user-defined prefix for the VPC, the code does not apply this to the subnet names


With these in mind, how hard would it be for a consultant (i.e. me) to update the libraries to align to the design, reduce the subnet sizes and achieve a sensible naming convention for the resources?


Cloud engineers seem to be as lax about address consumption as they are were about security... /s


Sources: Transit gateway design best practices - Amazon VPCCentralized inspection architecture with AWS Gateway Load Balancer and AWS Transit Gateway | Network...


L3 Networker

Further to this, I was also hoping to clarify the requirement to host the GWLB, GWLBe and firewall private interfaces in different zones. Putting inbound flows aside...


The AWS architecture, even without overlay routing, achieves this with 3 subnets within each AZ (4 if you include mgmt):

1 for the TGW attachment

1 for the GWLBe (both outbound & east/west use a single endpoint), GWLB itself and the firewall private interface ("appliance subnet", a mere /28)

1 for the NAT gateway (or public interface, because we can use overlay routing)


The PAN reference architecture splits the GWLB, GWLBe and firewall private interfaces into separate subnets, resulting in 6 (including mgmt):

1 for the TGW attachment

1 for the GWLBe (both outbound & east/west)

1 for the GWLB

1 for the firewall private interface

1 for the public interface

1 for mgmt


The PAN automation libraries throw in another subnet for the east/west GWLBe making it 7 in total, add another 2 if you include the app and network load balancers to support inbound flows.


My question is, is it necessary to place the GWLBe, GWLB and firewall private interface in different subnets? I can't see any logical reason to, even without support for overlay routing or separation of outbound & east/west flows, because:

1. The route table for the east/west GWLBe must forward private subnets to the TGW attachment

2. The route table for the outbound GWLBe must forward private subnets to the TGW attachment (and to the NAT GW if no overlay routing)

3. The route table for the firewall private interface must forward private networks to the TGW attachment (centralised inbound)

4. The GWLB itself does not need to reach anything other than the firewall instances


Given the above, can we simplify the design to consolidate these components and remove unnecessary subnets, route tables and network hops? I'm all for flexibility and future proofing but in this case there doesn't appear to be any value in using separate subnets.



  • 1 replies
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!