Static routing is the practice of explicitly configuring a forwarding path for a destination network. A route identifies a destination prefix, such as 192.168.0.0/16, and a next-hop address, interface, or cloud resource target. Unlike dynamic routing, static routing does not use a protocol such as Border Gateway Protocol (BGP) to learn reachability from neighboring routers. Routes can be created through a console, API, or infrastructure-as-code tool; static describes how the route is supplied, not whether someone enters it manually.
Forwarding uses longest-prefix matching to select the most specific matching destination. For example, a route for 192.168.0.0/16 takes precedence over a default route of 0.0.0.0/0 when sending traffic to 192.168.10.20. A more specific route for 192.168.10.0/24 would take precedence over both. Default routes are useful for destinations without a more specific match, but they do not override narrower routes. IPv6 follows the same principle, with ::/0 representing the default route.
In cloud networks, static routes commonly direct traffic toward internet gateways, NAT gateways, private connectivity gateways, peering connections, transit gateways, or network appliances. Consider a cloud network using 10.20.0.0/16 and an on-premises network using 192.168.0.0/16. The cloud subnet route table needs a route for the on-premises prefix toward the hybrid connectivity gateway. The on-premises router also needs a return route for the cloud prefix through the appropriate connection. Routes alone are insufficient: firewall policies, security groups, network ACLs, tunnel configuration, and address translation must also permit the traffic.
Distinguish a connection's routing mode from the configuration of individual forwarding tables. AWS Site-to-Site VPN connections terminating on either a virtual private gateway or a transit gateway support static routing or dynamic routing with BGP. For a statically routed VPN attached to a transit gateway, engineers manually add the required destination routes to the transit gateway route table. A static VPC route pointing toward a transit gateway does not indicate whether the underlying VPN uses static routing or BGP. VPN equal-cost multipath routing through Transit Gateway requires dynamic routing with BGP and the appropriate ECMP configuration; static VPN routes do not provide that capability.
Static routing offers explicit control without requiring routing-protocol sessions. It suits small networks, stable destination sets, and deliberate traffic steering through inspection appliances. Its operational cost increases as the number of prefixes, sites, and alternate paths grows. Adding or removing an on-premises network may require coordinated changes across multiple routing tables. A broad summary route can reduce configuration, but it can also direct traffic toward destinations that the selected connection cannot actually reach.
An ordinary static route does not independently discover end-to-end failure or learn an alternate path. A route can remain configured while its destination is unreachable, causing traffic loss. Some routers support tracked static routes and floating static routes, while cloud platforms may provide managed target resilience or support health-driven automation. These mechanisms require explicit design and testing; configuring two possible targets does not by itself guarantee useful failover.
Dynamic routing uses advertisements and withdrawals to adapt routing information as reachability changes. BGP is therefore commonly preferred for larger hybrid networks and redundant connections, although it still requires correct policy and failure-detection configuration. AWS Direct Connect virtual interfaces require BGP; adding static routes to a VPC does not replace that requirement. Static routes and BGP-learned routes can coexist at different layers of the same architecture.
When identical destination prefixes have multiple route sources, preference rules depend on the platform. In AWS VPC route tables, a manually configured static route takes precedence over a propagated route for the same destination prefix. Do not assume that a static route automatically serves as a backup or that traditional router administrative-distance settings exist in every cloud routing table. During implementation, review route-table associations, propagation settings, overlapping prefixes, return paths, and appliance symmetry. Test both normal forwarding and connection failures before relying on the design.