n our ongoing exploration of AWS networking, we’ve already covered some exciting topics. Today, we’ll discuss a crucial aspect of AWS networking – the limitations of AWS Site-to-Site VPN connections and Virtual Private Gateways. Understanding these limitations is vital as they can have a significant impact on your hybrid networking goals.
Virtual Private Gateways and Their Limitations
- Not VPC Transitive: One of the primary limitations of Virtual Private Gateways (VGWs) is that they are not VPC transitive. But what does that mean? Recall that VPC peering allows two VPCs to communicate freely, as long as they are within the same AWS partition (e.g., public AWS vs. GovCloud). However, VGWs have no knowledge of the IP ranges associated with VPCs other than the one they are attached to. This limitation means that if you have a VPN connection to one VPC and want to access resources in another VPC, it won’t work. VGWs are tied to a specific VPC, and any other VPC’s IP ranges are unknown to them.
- VPN Throughput Cap: Another limitation of VGWs is that their VPN throughput is capped at 1.25 gigabits per second (Gbps) over all associated VPN connections. This cap applies regardless of the number of VPN connections you establish. This means that adding more VPN connections to the same VGW won’t increase your bandwidth; it merely throttles each line.
- Single Endpoint for Returning Traffic: VGWs always use a single endpoint when returning traffic to an IP network. AWS VPN connections are designed to connect to physical endpoints within an AWS region. By default, only one of these endpoints is used at a time. Even if your customer gateway device supports an “active-active” configuration, where traffic is divided across two VPN tunnels, the VGW will still use only one interface for returning traffic. This means that traffic from your on-premises location to AWS might be split across multiple lines, but the returned traffic will use only one of them.
- Single Pair of One-Way Security Associations: If you’re using a policy-based VPN, which contains multiple rule sets, and each rule set identifies specific traffic and security policies, you might encounter limitations. Each AWS VPN IPSec tunnel only supports a single pair of one-way security associations. If you have multiple rule sets and one pair of security associations is already in use, traffic from the rule sets not covered by the existing security associations won’t go anywhere. This limitation can be a challenge for organizations with complex security policies and multiple rule sets.
Workarounds and Considerations
Now that we’ve discussed these limitations, let’s explore some potential workarounds and considerations:
- Combine Traffic under a Single Security Policy: To work around the one-way security association limitation, consider creating a single security policy that matches all traffic that needs to use the VPN. This way, all traffic will use the same security associations.
- Switch to Route-Based VPN: Route-based VPNs don’t rely on complex policy configurations at the customer gateway device. Instead, they use destination networks to determine which VPN tunnel to use. This can simplify configurations and avoid security association limitations.
- Evaluate Transit Gateways: Some limitations of VGWs have been addressed with the introduction of Transit Gateways. These gateways offer more advanced routing and connectivity options, making them suitable for complex network architectures.
- Filter Traffic at the Customer Gateway: If you have specific traffic that you don’t want to send over the VPN, you may need to implement traffic filtering at the customer gateway device. This can help you control what traffic is sent to AWS.
- Consider Other AWS Networking Services: Depending on your networking requirements, you may want to explore other AWS networking services, such as AWS Direct Connect or AWS Transit Gateway, which can provide more flexibility and scalability.
In conclusion, while AWS Site-to-Site VPN connections and Virtual Private Gateways are powerful tools for connecting your on-premises network to the AWS cloud, they do have some limitations that you should be aware of. Understanding these limitations and exploring potential workarounds or alternative solutions can help you design a robust and reliable hybrid network architecture.
Stay tuned for more AWS networking insights in our upcoming lessons. See you there!