Preamble
This blog is not going to teach you how to be a Network Engineer. It will not teach you how to setup your cloud networking environment and it will not teach you how to subnet or how to configure routing protocols. For a useful resource to learn about those topics see the Networking Immersion Day Labs:
https://catalog.workshops.aws/networking/en-US
In this blog, you will learn is about a cool new service AWS has released called Amazon VPC Route Server. See the announcement below:
https://aws.amazon.com/about-aws/whats-new/2025/04/amazon-vpc-route-server/
Overview
In the world of AWS networking, there are many ways to achieve a desired outcome. This includes VPC route tables (static, dynamic and local routes), Virtual Private Gateways (VGW), Transit Gateways, AWS CloudWAN, VPC Peering, Direct Connects, VPN’s, AWS Network Firewall, multi-region connectivity, as well as virtual appliances from many partners. The choice can be overwhelming.
Every decision has a trade-off and this can result in unnecessary complexity and/or administrative overhead. Cloud networking in AWS is not a simple thing to master (just ask anyone who has the AWS Advanced Networking Specialty Certification – myself included). The goal is to keep things as simple as possible and leverage dynamic routing wherever you can.
Enter Amazon VPC Route Server – a simple solution to an otherwise complex problem when working with virtual appliances (such as VPN concentrators or SD-WAN head-end appliances).
The problem
Let’s say you have a virtual appliance, such as a VPN concentrator, where you have networks only reachable via the appliance. In the VPC, the route table does not know about those networks.
Let’s say the list of networks available via the virtual appliance is dynamic (growing and shrinking on demand) and being updated using the Border Gateway Protocol (BGP). The virtual appliance knows where to go as it is receiving those route updates via BGP on the appliance.
In that case, you would need to constantly update the VPC route table so resources in and beyond that VPC know how to reach those virtual appliance networks.
The solution
To get around this problem, many customers resorted to static routing or scripting to update the VPC route tables. Static routing has its own limitations in that each network beyond the virtual appliance needed to be summarised down to a contiguous block of CIDR ranges so the route tables would not exceed the available limits. There are limitations (quotas) to number of routes in a route table:
Name | Default | Adjustable | Comments |
Route tables per VPC | 200 | The main route table counts toward this quota. Note that if you request a quota increase for route tables, you may also want to request a quota increase for subnets. While route tables can be shared with multiple subnets, a subnet can only be associated with a single route table. | |
Routes per route table (non-propagated routes) | 50 | You can increase this quota up to a maximum of 1,000; however, network performance might be impacted. This quota is enforced separately for IPv4 routes and IPv6 routes. If you have more than 125 routes, we recommend that you paginate calls to describe your route tables for better performance. | |
Propagated routes per route table | 100 | No | If you require additional prefixes, advertise a default route. |
This is where Amazon VPC Route Server comes in. With BGP dynamically updating route tables in the VPC, you can simply configure an extra BGP peer between the virtual appliance and the Route Server Endpoints to dynamically update the VPC route tables. Simple.
Basic example
It works by creating endpoints in your VPC that you can peer to using BGP in the virual appliance. The VPC Route Server then takes those advertised routes over BGP and propagates the routes into your VPC route table. It is awesome!
Advanced example
Starting with the example above as a baseline, the example below shows a more detailed design, where both Device A and Device B advertise over BGP that they can accept any traffic with a destination IP in the range of 192.0.0.0/24 (from 192.0.0.0 to 192.0.0.255).
The MED (Multi-Exit Discriminator) attribute of 0 tells route server that Device A should be preferred over Device B. The route server receives the route and the MED attribute from Device A and installs that route in the subnet route tables with the network interface of Device A as the “next hop”. As a result, any traffic within the subnet with a destination IP in the 192.0.0.0/24 range is sent to Device A. Device A then processes the traffic and sends it onward. Traffic within either subnet (10.0.0.0/24 or 10.0.1.0/24) that is bound for 192.0.0.0/24 will be routed to Device A eni-abcd (10.0.0.1) as the next hop.
Failover Handling
This last example below shows how route server handles failover. While the higher MED attribute tells route server that Device B is less preferred than Device A, if Device A eni-abcd (10.0.0.1) goes down, route server updates the subnet route tables, and traffic to 192.0.0.0/24 is routed to Device B eni-efgh (10.0.1.1) as the next hop.
Limitations
The service is only available in these AWS regions at time of writing:
- US East (Virginia)
- US East (Ohio)
- US West (Oregon)
- Europe (Ireland)
- Europe (Frankfurt)
- Asia Pacific (Tokyo)
For more information, see the VPC Route Server documentation.
The following quotas apply to Route Servers:
Name | Default | Adjustable | Comments |
Route servers per VPC | 5 | Yes. To request an increase, open a service limit increase case using the AWS Support Center Console. | |
Route server endpoints per route server | 10 | Yes. To request an increase, open a service limit increase case using the AWS Support Center Console. | |
Peering sessions per network interface | 20 | Yes. To request an increase, open a service limit increase case using the AWS Support Center Console. | |
Route server endpoints per route server and subnet | 2 | No | You can only have two endpoints in the same subnet for the same route server for redundancy. |
Routes per route server peer | 100 | No | This is the number of routes that can be dynamically advertised over a route server peer |
Routes per route server | 100 | No | This is the number of routes that can be installed in the Forwarding Information Base (FIB) of a route server. |
Alternatives
If you want a cloud native SD-WAN support for most popular vendors – this is what AWS CloudWAN is for.
https://docs.aws.amazon.com/network-manager/latest/cloudwan/what-is-cloudwan.html
It negates the need for some virtual appliances for VPN and SD-WAN concentration. CloudWAN could replace Transit Gateway (now that it supports Direct Connect without a Transit Gateway) as Transit Gateway has never supported SD-WAN termination. CloudWAN is not a one size fits all solution. The VPC Route Server service fits a specific set of scenarios where virtual appliances are needed and those use cases could extend beyond pure SD-WAN applications.
Conclusion
Despite the service’s availability, this new capability is a valuable addition, transforming what would typically be a high-overhead task into a more efficient and streamlined process. This will undoubtedly have a significant impact on Cloud Networking and Operations teams. Another example of where AWS is reducing the impacts and adding value to reduce undifferentiated heavy lifting.
While we cannot destroy complexity, we can move it around. I am looking forward to deploying this with current customers here in Australia and cannot wait for the availability of this service in ap-southeast-2 (Sydney) and ap-southeast-4 (Melbourne) regions.
