My previous blog on intra-VPC east-west patterns caught AWS’s attention. It seemed that I might be the first one digging into GWLB for intra-VPC inspections. I do not interpret it in a way that my use cases are rare. Instead, I firmly believe it is due to the lack of approved design patterns that are easy to operate for L7 inspections. Hopefully, my series of GWLB blogs would lead to more discussions for a more secure environment in AWS.
In this blog, I introduce another design option through my discussion with AWS teams.
Attempt #2a One GWLBE per AZ Pair
In Attempt #2 of my previous blog, a single GWLBE is used for the whole VPC. It can be considered a simple hub-and-spoke design. To address the single-point-failure concern from the single GWLBE, improvement should focus on the introduction of additional GWLBEs while maintaining routing symmetry.
AWS does not provide dynamic routing protocols for typical multi-hubs implementations. Figure 1 presents an idea that leverages static routes. Assuming there are N number of CDIR ranges created in #N AZs of a VPC. Bidirectional traffic between any two CIDR ranges needs to be inspected. In RT design, a pair of CIDRs/AZs are selected at a time. One GWLBE is designated for this pair.
| GWLBE | CIDR/AZ Pair |
| GWLBE1 | (CIDR1/AZ1, CIDR2/AZ2) (CIDR1/AZ1, CIDR3/AZ3) … (CIDR1/AZ1, CIDRn/AZn) |
| GWLBE2 | (CIDR2/AZ2, CIDR3/AZ3) … (CIDR2/AZ2, CIDRn/AZn) |
| … | |
| GWLBEn-1 | (CIDRn-1/AZn-1, CIDRn/AZn) |
Takeaways
The RT design is not as bad as it seems. The number of AZs in an AWS region is fairly small. I would limit it to three AZs/region even if a region offers more AZs. If you need to utilize all AZs in a region, then there are more complexities to deal with than RT here. What I would recommend though, is to carefully plan your IPAM. One way to break VPC CIDR is by AZ first, then by the function of the subnets. This IPAM scheme makes the RT design here cleaner. The other way to slice VPC CIDR is by subnet function first (ie Web, DB…), then by AZ. It might make it easier to construct security policies by using an aggregated range. However, more static routes are needed for RT in this design. I always consider AWS AZ as an on-prem data center. Thus my IPAM preference is the first approach. Either way, the AWS prefix list should be leveraged to benefit both routing and security management. Better yet, tags of VPC subnets should also be considered if the firewall vendor supports them.
