# Route table

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/route-table

## Quick definition

A route table is like a GPS for data traveling across a network. Each entry in the table tells the network where to send packets based on their destination address. Without route tables, data would not know how to reach other networks or the internet. They are essential for both on-premises and cloud environments, and each subnet or virtual network is usually associated with its own route table.

## Simple meaning

Think of a route table as the master directory for a computer network. Every time a device sends a piece of data to another device, that data is broken into packets. Each packet carries a destination address, like a mailing address on a letter. The network needs to decide where to send each packet so it reaches the correct destination. The route table contains a list of destination address ranges and the next stop for each range, which is called the next hop. If the destination is on the same local network, the route table says to deliver the packet directly. If the destination is on a different network, the route table points to a router or gateway that can forward the packet toward its final destination. The table also includes a default route, often called the default gateway, which is used when no other more specific route matches. This default route usually points to an internet gateway or a VPN tunnel so that traffic destined for the wider internet or a remote corporate network can escape the local subnet. In cloud platforms like Amazon Web Services (AWS), route tables are associated with subnets inside a Virtual Private Cloud (VPC). Each subnet must have exactly one route table, though multiple subnets can share the same table. If a packet arrives that matches no route in the table, the network discards it. That is why a missing or misconfigured route is one of the most common causes of network connectivity problems. A simple way to imagine a route table is to compare it to a set of directions posted at a fork in the road. Each sign says “If you are going to this neighborhood, take this path.” If you do not see your destination on any sign, you follow a general “Anywhere else” sign that leads to the main highway. The route table works exactly like those signs, directing each packet to the proper next hop. Understanding route tables is crucial for anyone working with networks, whether it is for a home router, a corporate data center, or a cloud infrastructure. Misconfigurations can cause entire applications to become unreachable, and exam questions often test your ability to interpret or troubleshoot route table entries. A route table is the decision-maker for network traffic, and its simplicity or complexity depends on how many networks are involved. For beginners, the key points to remember are that there is usually one route table per subnet, that it contains a default route for traffic that does not match any other rule, and that adding or removing routes can enable or disable connectivity between parts of a network.

## Technical definition

A route table is a structured data structure, usually implemented as a forwarding information base or a routing information base, that contains a collection of route entries. Each route entry consists of at least a destination prefix (expressed in CIDR notation) and a next-hop target. The purpose of the route table is to enable a network device, such as a router, a Layer 3 switch, or a virtual router in a cloud VPC, to determine the outbound interface and next-hop IP address for any given packet. Route tables are fundamental to packet switching in IP networks and are used in both static and dynamic routing contexts.

In a standard TCP/IP network, when a host or router receives an IP packet, it extracts the destination IP address from the packet header. It then consults its local route table to find a matching route. The matching process uses the longest prefix match algorithm, which means the route with the most specific subnet mask wins. For example, if the route table contains a route for 10.0.0.0/16 and a route for 10.0.1.0/24, a packet destined to 10.0.1.5 will match the /24 route because it is more specific. If no specific route matches, the packet is forwarded to the default route, which is usually written as 0.0.0.0/0 (or ::/0 for IPv6). If there is no default route and no matching specific route, the packet is dropped and an ICMP Destination Unreachable message may be sent back.

In cloud environments like Amazon Web Services (AWS), a VPC route table is a resource that you can create and attach to subnets. Each VPC has a main route table, but you can create custom route tables for finer control. When you launch a resource into a subnet, the subnet’s associated route table governs all outbound traffic from that subnet. Important next-hop targets in AWS include internet gateways (igw-xxxxxxxx) for public internet access, NAT gateways (nat-xxxxxxxx) for private subnets to reach the internet while remaining private, virtual private gateways (vgw-xxxxxxxx) for VPN connections, VPC peering connections (pcx-xxxxxxxx), transit gateways (tgw-xxxxxxxx), and VPC endpoints. In AWS, each route table entry also has a target, and you cannot have overlapping destination CIDRs with different next hops unless the more specific route is used for a specific purpose like a local route.

On Microsoft Azure, route tables work similarly through user-defined routes or system routes. Each Azure subnet is automatically assigned a set of system routes that cover local VNet traffic, on-premises traffic (if connected via VPN or ExpressRoute), and internet traffic. You can override these system routes by creating custom user-defined routes in a route table resource and associating that table with a subnet. Azure uses the same longest-prefix-match algorithm, and the next hop can be a virtual appliance, a VPN gateway, or the internet. In Google Cloud Platform, the concept is called a network route or a VPC route, and you can create static routes that apply to all instances in a VPC network or to specific tagged instances. Google Cloud also supports dynamic routes from Cloud Router using BGP.

For on-premises networks, enterprise routers such as Cisco IOS routers maintain route tables that can be populated via static routes or dynamic routing protocols like OSPF, EIGRP, or BGP. Each routing protocol has its own administrative distance value, which is used when multiple routes to the same destination exist from different protocols. The route with the lowest administrative distance is installed in the global route table. For example, a static route often has an administrative distance of 1, while an OSPF-learned route may have a distance of 110. The routing table also stores the next-hop IP address and the outgoing interface. In Cisco IOS, you can view the route table with the “show ip route” command, which lists all known networks, their masks, next-hop addresses, and routing protocol origin.

Route tables are also a key component in software-defined networking (SDN). In SDN controllers, the route table is often a flow table that matches on multiple header fields, not just the destination IP. OpenFlow-based switches, for example, allow for very granular traffic steering based on source IP, destination IP, port numbers, and even packet payload fields. However, the core idea remains the same: a structured collection of rules that dictate the forwarding behavior of the network.

route tables are an essential building block of IP networking. They enable controlled traffic flow between different network segments, provide the mechanism for default gateways, and support complex topologies in both cloud and on-premises environments. Understanding how route tables work, how entries are matched, and how they interact with other networking components is critical for any IT professional, and it is tested heavily across vendor certifications including AWS, Azure, Google Cloud, Cisco, CompTIA, and others.

## Real-life example

Imagine you are the manager of a large shopping mall. The mall has multiple wings: the East Wing contains clothing stores, the West Wing has a food court, the South Wing has a cinema, and the parking garage is underground. Visitors come in through the main entrance and need clear directions to find their desired stores. You decide to put up a series of signboards at every intersection inside the mall. Each signboard lists a set of destinations and an arrow pointing to the correct corridor. One signboard near the main entrance shows: “To the East Wing-Turn right.” “To the Food Court-Walk straight ahead.” “To the Cinema-Turn left.” “For any other location-Exit the mall and take the outside walkway.” This signboard is exactly like a route table. Each destination sign is a route entry, and the arrow is the next hop. The default sign that says “Other” is the default route, which handles any visitor whose destination is not explicitly listed.

Now, suppose there is a special event in the East Wing that requires all visitors to that wing to first go to a security checkpoint. You update the signboard to read: “To the East Wing-First, go to Security Checkpoint B, then continue to the East Wing.” This change in the route entry modifies the path that packets of visitors take. In networking terms, you just updated the next hop for the East Wing subnet. If a visitor ignores the sign and goes directly to the East Wing, they may be turned away. Similarly, if a network packet bypasses the gateway specified in the route table, it may not reach its destination.

You also have a cleaning crew that needs to move from the West Wing to the South Wing after hours. You do not want them to disturb the food court, so you install a temporary sign: “To the South Wing-Take the service corridor behind the escalator.” This is like adding a specific route that overrides the default behavior, ensuring traffic takes a designated path.

If a signboard is missing or has a wrong arrow, visitors get lost and end up in the wrong areas. This is exactly what happens when a route table misconfiguration occurs, traffic goes to the wrong network, or it gets dropped because no matching route exists. In a large mall, you would also have multiple signboards at different intersections (different subnets). Each signboard is a separate route table associated with a particular section of the mall. Some wings might have their own side entrance, so they need a custom signboard (a custom route table) that might not include the main entrance. This mirrors cloud networking where each subnet has its own route table.

the mall with its directional signboards is a close analogy to how route tables work. The signs show the way, and the arrows represent the next hop. A well-planned set of signs keeps traffic flowing smoothly, while a single wrong sign can cause chaos. That is why network administrators spend a lot of time designing and verifying route tables, and why certification exams test your ability to read and troubleshoot them.

## Why it matters

Route tables matter because they are the traffic directors of every network, from small home networks to massive cloud infrastructures. Without route tables, data packets would have no way of knowing which path to take, and they would either loop endlessly or be dropped. In practical IT work, route table misconfiguration is one of the most common causes of network outages and connectivity issues. For example, if you build a new subnet in a cloud VPC and forget to add a route to an internet gateway, instances in that subnet cannot reach the internet. If you accidentally change the default route to point to a wrong target, all outbound traffic from that subnet will fail. Route tables also play a critical role in security. By controlling which subnets can reach which destinations, you can isolate sensitive resources, enforce network segmentation, and direct traffic through firewalls or inspection appliances. In a zero-trust architecture, route tables are used to enforce micro-segmentation by only allowing traffic between specific subnets. Route tables are fundamental to hybrid networking, where on-premises data centers connect to cloud VPCs via VPN or dedicated connections. You must configure routes correctly in both environments to ensure traffic flows bidirectionally. Even in a simple scenario like setting up a home Wi-Fi router, the route table contains the default route to the modem and possibly a static route for a secondary network. For IT professionals, understanding route tables is a non-negotiable skill. It appears in almost every networking exam and cloud certification. It is also something you will troubleshoot daily as a network administrator, cloud engineer, or support specialist. Therefore, mastering how route tables work, how to read them, and how to configure them will save you hours of diagnostic time and prevent costly mistakes.

## Why it matters in exams

Route tables are a heavily tested concept across many IT certification exams, and they appear in different forms depending on the exam. For the AWS Cloud Practitioner (CLF-C01), route tables appear in questions about VPC networking, default routes, and internet gateway connectivity. You may be asked to identify what happens if a subnet does not have a route to an internet gateway, or which component is responsible for routing traffic between subnets. For the AWS Solutions Architect Associate (SAA-C03), route tables are more deeply covered. You will see scenario questions about designing multi-tier architectures where public subnets have routes to an internet gateway and private subnets use a NAT gateway. You must understand when to use VPC peering, transit gateway, or VPC endpoints, and how routes propagate. Exam questions might ask you to configure a route table to enable communication between two peered VPCs, or to route traffic to a firewall appliance. For CompTIA Network+ (N10-009), route tables are part of Objective 4.4 (Given a scenario, use the appropriate network troubleshooting methodology). You may be asked to interpret the output of the “route print” command on Windows or “ip route” on Linux. Questions often present a routing table and ask which interface will be used for traffic to a specific destination, or what the default gateway is. In the CompTIA Security+ (SY0-701), route tables appear in the context of network segmentation and security. You might see questions about how to isolate guest traffic from corporate traffic using VLANs and route tables, or how to prevent traffic from leaving a subnet by removing the default route. For Cisco CCNA (200-301), route tables are a core topic. You must understand the “show ip route” output, distinguish between directly connected, static, and dynamic routes, and know the administrative distances of different routing protocols. CCNA questions may ask you to identify the next hop for a given destination IP, or to troubleshoot why a route is not appearing in the route table. For Microsoft Azure (AZ-104), route tables are covered in the networking section. You must understand system routes, user-defined routes, route propagation, and how to force tunnel traffic through a virtual appliance. Questions might ask you to configure routing to send traffic from a subnet through a firewall VM. For Google Cloud (ACE), you need to understand VPC network routes, static routes, and dynamic routes via Cloud Router. In the A+ core exams (220-1101 and 1102), route tables are less central but still appear in the context of troubleshooting network connectivity. You may be asked to use the “route” command to check the routing table, or to identify the effect of a missing default gateway. Across all these exams, the typical question types include: multiple-choice where you select the correct route table configuration for a given requirement; scenario-based where you diagnose a connectivity issue caused by a route table problem; and command-output interpretation where you read a routing table and answer questions about it. Understanding route tables thoroughly will give you a significant advantage in these exams, and it will also serve you well in real-world network management.

## How it appears in exam questions

In certification exams, route tables are tested through several distinct question patterns. One common pattern is the scenario-based design question. For example, you might be given a scenario: “A company has a VPC with two subnets. Subnet A contains web servers that need internet access. Subnet B contains database servers that should be private. What route table configuration is required?” The correct answer usually involves associating Subnet A with a route table that has a default route pointing to an internet gateway, and Subnet B with a route table that has a default route pointing to a NAT gateway or no default route at all. The distractors will often propose a route table that lacks the default route, or one that points the private subnet directly to an internet gateway. Another common pattern is the troubleshooting question. You might see a scenario where users report that they cannot reach a specific website or server. The question will present the output of a routing table from a PC or a router. You must identify the missing or incorrect route. For instance, if the output shows a default gateway of 192.168.1.1, but the actual gateway should be 192.168.1.254, then the route is wrong. Or if the routing table does not have a route to the destination network, you know the packet will be dropped. In AWS exams, you will often see questions that combine route tables with other services. For example, you may have to choose the correct route table configuration for a VPC peering connection. A typical trap is that you need to add a route in both VPC route tables pointing to the peering connection, and if you forget the route in one direction, traffic flows only one way. Exam questions also use routing tables to test your understanding of longest prefix match. A question could show a routing table with several entries for 10.0.0.0/16, 10.0.1.0/24, and 0.0.0.0/0, and then ask which route is used for a packet destined to 10.0.1.10. The correct answer is the /24 route because it is the most specific. A distractor might suggest the /16 route because it looks similar, but that is a common mistake. In Cisco CCNA, questions often require you to interpret the “show ip route” output and identify the routing protocol that installed the route. For example, if a route is marked with an “O”, that means it is from OSPF; “S” means static; “C” means directly connected. You also might be asked to calculate the next hop for a given destination. Azure AZ-104 questions frequently present a scenario where you need to route all internet-bound traffic from a subnet through a firewall. You must create a user-defined route with destination 0.0.0.0/0 and next hop set to the firewall’s IP address. The distractor might suggest using a system route, but system routes cannot be modified in that way. Network+ and Security+ exams sometimes show a routing table from the Windows route print command. You must identify the default gateway, the network mask, and the interface. They may also ask what the effect of deleting the default route would be (answer: no outbound internet connectivity except for directly connected networks). Finally, there are questions about route propagation in AWS or Azure, where you must enable route propagation for VPN connections to automatically add routes to the route table. Understanding these question patterns and the underlying logic will help you approach route table questions with confidence and avoid common traps.

## Example scenario

A small business called GreenLeaf Consulting has moved its operations to the cloud using AWS. They have a VPC with two subnets: a public subnet for their web server (Subnet A) and a private subnet for their database server (Subnet B). The web server needs to be accessible from the internet, and the database server must only be reachable from the web server. The VPC is created with a single route table by default, called the main route table, which is automatically associated with both subnets. At first, the main route table only contains the local route (the route for the VPC’s own CIDR block), so no subnet can reach the internet. The administrator realizes that the web server cannot be accessed from outside, so they create a new custom route table and add a route with destination 0.0.0.0/0 and target the internet gateway that was attached to the VPC. They then associate this custom route table with Subnet A only. Now the web server can send and receive traffic from the internet. However, the database server in Subnet B still only has the default main route table, which has the local route but no default route to the internet. The database server cannot reach the internet, which is exactly what is desired for security. But there is another problem: the web server needs to communicate with the database server. Because both subnets are in the same VPC, the local route already handles that traffic. The local route in both route tables ensures that traffic destined for any IP within the VPC CIDR (e.g., 10.0.0.0/16) is forwarded directly within the VPC. So the web server can connect to the database server on its private IP address. The administrator decides to improve security further. They want the database server to be able to download software updates from the internet, but without exposing it to incoming connections. They create a NAT gateway in the public subnet, assign it an Elastic IP, and then add a route to the private subnet’s route table with destination 0.0.0.0/0 and target the NAT gateway. Now, the database server can initiate outbound connections to the internet for updates, but the internet cannot initiate connections to the database server. If the administrator had accidentally associated the private subnet with the public route table (the one with the internet gateway), then the database server would have been directly exposed to the internet, which is a security risk. This scenario demonstrates the fundamental role of route tables in controlling both connectivity and security. It also shows how careful association and configuration of route tables directly impact the behavior of resources in the cloud.

## Route Table Fundamentals: The Traffic Director in AWS VPCs

A route table is a fundamental networking construct within Amazon Web Services (AWS) that controls where network traffic from a subnet or gateway is directed. Every subnet in a Virtual Private Cloud (VPC) must be associated with exactly one route table at any given time. By default, a VPC creates a main route table that controls the routing for all subnets that do not have an explicit association. Understanding route tables is critical for any cloud practitioner or network engineer because they are the mechanism by which network connectivity is established between different parts of your infrastructure, including connections to the internet, VPNs, and other VPCs.

The core of a route table is its collection of routes, also known as routing entries. Each route consists of a destination (typically an IP address range in Classless Inter-Domain Routing notation) and a target (the resource that should handle traffic destined for that range). When a packet originates from a resource in a subnet, the VPC router evaluates the route table associated with that subnet. It performs a longest prefix match, meaning the most specific route that matches the destination IP address is used. If no match is found, traffic is dropped. This behavior is fundamental to exam questions about why certain connectivity fails.

Routes in a route table can be added automatically by AWS services, manually created by administrators, or propagated via a virtual private gateway. For example, when you create an internet gateway and attach it to your VPC, you must add a route in your route table that points 0.0.0.0/0 (all IPv4 traffic) to that internet gateway to enable internet access for resources in that subnet. Similarly, for IPv6 traffic, a route for ::/0 to an egress-only internet gateway or internet gateway is needed. A crucial exam point is that subnets associated with a route table that has a route to an internet gateway are called public subnets, while those without such a route are private subnets.

Route tables are regional resources, meaning they exist within a specific AWS Region and can only be associated with subnets in that same region but within the same VPC. One VPC can have multiple route tables, allowing different subnets to have different routing behaviors. This is essential for creating a layered security architecture, where public-facing web servers reside in a subnet with internet access, while database servers live in a private subnet with no direct internet route. The main route table cannot be deleted, but you can replace its routes and associations. If you disassociate a subnet from a custom route table, it automatically reverts to the main route table.

For the AWS Cloud Practitioner and Solutions Architect exams, you must understand that route tables are invisible to customers in terms of management-AWS manages the underlying routing hardware. However, you are responsible for configuring the routes themselves. A common scenario tested is ensuring that a private subnet can reach the internet via a NAT gateway: you add a route for 0.0.0.0/0 to the NAT gateway in the private subnet's route table. For peered VPC connections, routes must be added in both VPCs' route tables pointing to the peering connection ID. For VPN connections, propagated routes appear automatically in the route table if you enable route propagation.

The concept of route table propagation is another exam favorite. When you enable route propagation on a route table for a virtual private gateway, AWS automatically adds routes corresponding to your on-premises network. This saves you from manually entering CIDR ranges. However, manually added static routes always take precedence over propagated routes because static routes have a higher administrative distance. Understanding this priority is vital for troubleshooting hybrid network connectivity issues.

route tables are the decision engines for VPC traffic. They define whether a subnet is public, private, or VPN-connected. They are essential for implementing network segmentation, connecting to on-premises data centers, and enabling internet egress. Every AWS networking exam question regarding connectivity between two resources will involve analyzing route table entries. Without a properly configured route table, your VPC resources are isolated, even if security groups and network ACLs allow traffic. Mastery of route tables is a non-negotiable skill for any AWS certification candidate.

## Edge Associations and Gateway Route Tables: Directing Traffic at the Boundary

While most AWS documentation focuses on subnet route tables, a less commonly understood but highly exam-relevant feature is the edge association for route tables. Edge associations allow you to attach a route table directly to an internet gateway or a virtual private gateway, rather than to a subnet. This creates what is known as a gateway route table. This is a powerful capability because it allows you to control inbound traffic before it even reaches a subnet, enabling advanced filtering and redirection patterns that are critical in enterprise architectures.

A gateway route table is a route table that is associated with a gateway (internet gateway or virtual private gateway) rather than with a subnet. When you create an edge association, you specify the gateway ID and the route table ID. The routes in that gateway route table then apply to traffic entering the VPC through that gateway, even before the traffic reaches any subnet. This is different from a standard subnet route table, where routes apply only after traffic has entered the subnet. For example, you can create a route in the gateway route table that directs all traffic destined for a specific IP range to a network virtual appliance (like a firewall or inspection appliance) in the VPC, ensuring that all inbound traffic passes through inspection before reaching its final destination.

The primary use case for gateway route tables is centralized traffic inspection. In a typical three-tier architecture, you might want all internet-bound traffic to be inspected by a firewall. Without a gateway route table, you would need to configure individual subnet route tables to direct traffic to the firewall, which can be cumbersome and error-prone. With a gateway route table associated with the internet gateway, you can add a single route that sends all traffic from the internet (0.0.0.0/0) to a network virtual appliance. The appliance then inspects the traffic and forwards it to the destination subnet. This pattern is often tested in the AWS Solutions Architect and Security exams because it demonstrates an understanding of traffic flow control at the VPC edge.

Another critical detail is that gateway route tables only support routes with a target of a network interface, a peering connection, or a VPN connection-they cannot directly target an internet gateway or virtual private gateway because that would create a routing loop. The most common target is a network interface of an EC2 instance running a firewall appliance. Also, gateway route tables cannot be associated with subnets directly; they only exist to control traffic at the gateway level. When you disassociate a gateway route table from a gateway, the gateway immediately reverts to using its default behavior, which is to forward traffic directly to the subnets based on their own subnet route tables.

From an exam perspective, you should know that gateway route tables are available for both internet gateways and virtual private gateways. For internet gateways, they control inbound traffic from the internet. For virtual private gateways, they control inbound traffic from your on-premises network via VPN or Direct Connect. This is especially important in hybrid architectures where you want to enforce consistent security policies for all traffic entering the VPC, regardless of source. The AWS Cloud Practitioner exam may ask a high-level question about the purpose of gateway route tables, while the Solutions Architect exam will include questions about their configuration and impact on traffic flow.

Edge associations are also relevant when discussing route propagation. If you enable route propagation on a gateway route table that is associated with a virtual private gateway, AWS will automatically add routes for your on-premises networks. However, you must still manually add static routes for other destinations, such as the internet. The order of precedence for routes in a gateway route table is the same as for subnet route tables: most specific prefix wins. Static routes override propagated routes if they have the same prefix length.

In practice, you might use a gateway route table to implement a DMZ pattern where all inbound traffic is directed to a bastion host or a set of security appliances before reaching application servers. This reduces the attack surface and centralizes logging and monitoring. The cost implication is that the traffic passes through an EC2 instance, which incurs compute and data transfer costs, but the security benefit often outweighs the expense. Remember, gateway route tables do not incur additional costs beyond the resources used by the targets.

Finally, a common exam trap is confusing gateway route tables with subnet route tables. The key differentiator is the association: gateway route tables are associated with gateways, while subnet route tables are associated with subnets. Both types of route tables perform the same function-directing traffic based on destination-but they apply at different points in the network path. Understanding when to use each type is a sign of advanced networking knowledge and is frequently tested in scenario-based questions on the AWS Certified Solutions Architect (SAA) exam.

## Route Table Entry Examples: How to Configure and Troubleshoot Common Routes

Configuring route table entries is a hands-on skill that every AWS professional must master. Each entry consists of a destination CIDR (or prefix list), a target (the AWS resource to send traffic to), and an optional status. The target can be an internet gateway ID (igw-xxx), a NAT gateway ID (nat-xxx), a virtual private gateway ID (vgw-xxx), a VPC peering connection ID (pcx-xxx), a network interface ID (eni-xxx), a transit gateway ID (tgw-xxx), a VPC endpoint ID (vpce-xxx), a network firewall endpoint, or a local gateway ID. The status indicates whether the route is active (black) or blocked (blackhole). A blackhole route means the target resource has been deleted or is in a failed state, and traffic to that destination will be dropped.

One of the most common route table entries is the default internet route: destination 0.0.0.0/0 with target igw-xxxxxxxx. This route is required for any subnet that needs to communicate with the internet. For IPv6, the equivalent is ::/0 with target igw-xxxxxxxx. However, a common mistake is adding this default route to a private subnet, which would make it a public subnet and expose resources to the internet. If you need internet access for a private subnet, you must use a NAT gateway or NAT instance. For a NAT gateway, you add a route for 0.0.0.0/0 with target nat-xxxxxxxx to the private subnet's route table. The NAT gateway itself must be in a public subnet with its own route to the internet.

Another key example is the VPC peering route. When you establish a VPC peering connection between two VPCs, you must add routes in both route tables pointing to the peering connection ID. For example, if VPC A has CIDR 10.0.0.0/16 and VPC B has CIDR 172.16.0.0/16, the route table in VPC A must have a route with destination 172.16.0.0/16 and target pcx-xxxxxxx. Similarly, VPC B's route table must have a route with destination 10.0.0.0/16 and target the same peering connection ID. If either route is missing, cross-VPC traffic will fail. A common exam scenario is that the route is added on one side but not the other, or the CIDR ranges overlap, causing routing conflicts. Ping tests between instances in peered VPCs should work if security groups and NACLs allow, but if they don't, check the route tables first.

Transit gateway routes are more complex but appear frequently on advanced exams. A transit gateway acts as a hub for multiple VPCs and on-premises networks. Each VPC that is attached to the transit gateway must have a route in its route table pointing to the transit gateway ID for the destination CIDRs of other attached networks. For example, if a transit gateway has attachments for VPC A (10.0.0.0/16), VPC B (192.168.0.0/16), and a VPN connection (172.16.0.0/12), then VPC A's route table needs a route for 192.168.0.0/16 with target tgw-xxxxxx and another for 172.16.0.0/12 with target tgw-xxxxxx. The transit gateway itself manages routing between attachments using its own route table. This reduces the number of individual VPC peering connections but requires careful configuration of the transit gateway route tables.

Route table entries can also include prefix lists. A prefix list is a set of CIDR blocks that you can reference in a route table entry. Instead of adding multiple individual routes for different IP ranges, you can create a prefix list and add a single route that points to it. This is particularly useful for managing large sets of on-premises IP ranges or for integrating with AWS Managed Prefix Lists (like the S3 prefix list). The route is added with destination set to the prefix list ID (pl-xxxxxxx) and target to the appropriate gateway. This simplifies management and reduces the chance of errors.

When troubleshooting route tables, the first step is to verify the route table association. You can check this using the AWS Management Console, CLI (aws ec2 describe-route-tables), or by looking at the subnet details. The second step is to ensure the target resource exists and is in a valid state. A common pitfall is that a NAT gateway might be in a failed state, causing the route to become blackhole. The third step is to check for conflicting routes: if two routes have the same destination but different targets, the most specific route (longest prefix match) wins. For example, a route for 10.0.0.0/24 to a peering connection will override a route for 10.0.0.0/16 to a transit gateway for traffic destined to 10.0.0.5. Finally, consider the effect of route propagation. If you have a virtual private gateway with route propagation enabled, the propagated routes are automatically added. If you manually add a static route that overlaps with a propagated route, the static route takes precedence only if it has a more specific prefix. If they have the same prefix, the static route wins because of administrative distance.

In the AWS Cloud Practitioner exam, you might be asked to identify which route table entry enables internet access for a subnet. For the SAA exam, you will need to choose the correct combination of routes and targets for a given network architecture. Knowing these examples by heart is essential for success.

## Route Table Cost, Limits, and Performance Considerations

Understanding the costs, limits, and performance implications of route tables is important for architects who need to design scalable, cost-effective networks in AWS. First, the good news: route tables themselves are free. You do not pay for creating route tables, adding routes, or associating them with subnets or gateways. However, the targets of routes incur costs. For example, a route pointing to a NAT gateway incurs hourly charges and data processing fees. A route pointing to a transit gateway incurs attachment fees and data transfer charges. A route pointing to a VPC peering connection incurs data transfer costs between VPCs, but no hourly fee for the peering connection itself. So while the route table is free, what you attach to it defines your networking bill.

AWS imposes hard limits on the number of route tables and routes per VPC. As of this writing, the default limit is 200 route tables per VPC. Each non-propagated route table can have up to 50 entries (routes) by default, but this can be increased to 1000 per route table via a service quota increase request. Propagated routes (from a virtual private gateway or transit gateway) count toward the same route limit. If you exceed the route limit, the route table becomes unable to add new routes, and traffic may be dropped for destinations that are not explicitly matched. This is a common source of failure in large deployments with many on-premises networks. For exam purposes, you should know the default limits and that they can be increased via AWS Support.

An important performance consideration is the longest prefix match algorithm. AWS implements hardware-based routing at the VPC router level, so the number of routes in a route table does not significantly affect packet forwarding latency. However, the number of route tables in a VPC does not directly impact performance either. The real performance bottleneck is the target resource. For example, a NAT gateway has a maximum throughput of 45 Gbps for the largest instance type, but smaller NAT gateways have lower limits. If your route table sends all internet traffic to a single NAT gateway, that NAT gateway becomes a bottleneck. Similarly, a transit gateway has a maximum bandwidth per attachment, and a VPC peering connection can handle up to 25 Gbps per direction. Therefore, while the route table is not the performance limiter, its design determines which resources are used and thus the overall network throughput.

Latency considerations are also tied to the route table design. Traffic that must traverse multiple hops (e.g., from a subnet to a transit gateway to a virtual private gateway to an on-premises network) will have higher latency than traffic that goes directly to a VPC peering connection. Route tables can be used to implement latency-based routing by directing traffic to the most direct path. For example, if you have two direct connect connections, you can add specific routes in your route table to send traffic to the preferred link based on destination. This is a more advanced topic that appears in the AWS Advanced Networking Specialty exam.

Another cost factor is data transfer between Availability Zones (AZs). If a route table directs traffic from an EC2 instance in us-east-1a to a NAT gateway in us-east-1b, the traffic incurs inter-AZ data transfer charges. To minimize costs, it's best to place the NAT gateway in the same AZ as the subnets that use it. Similarly, for VPC peering, data transfer within the same region is cheaper than cross-region peering. Route tables can be designed to enforce local routing where possible, but AWS does not automatically optimize for cost-you must explicitly add routes.

Route tables also have implications for high availability. If a route points to a NAT gateway that goes down, traffic to the internet will fail. To mitigate this, you can use multiple NAT gateways across different AZs and configure route tables for each AZ's public subnets to point to the local NAT gateway. Alternatively, you can use a transit gateway with multiple attachments to provide redundancy. The route table itself is highly available; AWS replicates routing information across multiple redundant routers in the VPC. However, the target resource's availability determines the overall path availability.

From a security perspective, route tables can be used to implement network segmentation at L3. For example, you can create separate route tables for development, staging, and production subnets, each with different routes to the internet or other networks. This isolates traffic and simplifies auditing. However, route tables do not provide any security filtering-that is the job of network ACLs and security groups. A common exam question is: 'You want to block traffic from a specific subnet to the internet. What should you modify?' The answer is the route table: you remove the default route (0.0.0.0/0) or modify it to point to a blackhole or a different target.

route tables are free, but their design has significant cost, performance, and availability implications. Limits are generous but should be monitored in large deployments. The exam will test your understanding of these trade-offs, especially in scenario-based questions where you must choose the most cost-effective or highest-performance routing solution. Always consider the targets and their capacity when designing route tables.

## Common mistakes

- **Mistake:** Associating the same route table with both a public and private subnet without considering the default route.
  - Why it is wrong: If the route table has a default route to an internet gateway, instances in the private subnet become directly reachable from the internet, which breaks security. If it does not have a default route, the public subnet cannot work properly.
  - Fix: Always use separate route tables for public and private subnets, and only add a 0.0.0.0/0 route to an internet gateway on the public subnet route table. For private subnets, use a NAT gateway or leave no default route.
- **Mistake:** Forgetting to add a route to the VPC peering connection in both route tables.
  - Why it is wrong: VPC peering requires a route in each VPC's route table pointing to the peering connection as the target for the other VPC's CIDR block. If you only add the route in one VPC, traffic can flow in only one direction, breaking connectivity.
  - Fix: After creating a VPC peering connection, add routes in both route tables for the remote VPC's CIDR, with the target set to the peering connection ID (pcx-...).
- **Mistake:** Configuring a default route (0.0.0.0/0) with a target that is not reachable, such as an invalid IP or a deleted internet gateway.
  - Why it is wrong: The route table will forward packets to a target that does not exist, causing all outbound traffic to fail silently. The instances will appear to have no connectivity to the internet.
  - Fix: Always verify that the target specified in the route exists and is in the correct state (e.g., internet gateway is attached, NAT gateway is in the same VPC and subnet).
- **Mistake:** Using the same route table for subnets in different VPCs.
  - Why it is wrong: Route tables are scoped to a single VPC. A route table created in VPC A cannot be associated with a subnet in VPC B. Attempting to do so will cause an error or result in no association.
  - Fix: Create separate route tables per VPC, and associate them only with subnets within that same VPC.
- **Mistake:** Overlapping routes with different next hops that violate longest prefix match logic.
  - Why it is wrong: If you have two routes with overlapping CIDR ranges (e.g., 10.0.0.0/16 and 10.0.1.0/24) and they point to different targets, the more specific route (the /24) will be used for matching traffic, which may not be the intended behavior.
  - Fix: Plan your CIDR allocation carefully so that overlapping routes are intentional and consistent. When using overlapping routes, ensure that the more specific route indeed should override the broader one.
- **Mistake:** Not enabling route propagation for VPN connections in AWS.
  - Why it is wrong: When you connect a virtual private gateway to a VPC, routes for your on-premises network are not automatically added to the route table unless route propagation is enabled. Without it, traffic from the VPC to on-premises will not have a route.
  - Fix: In the route table properties, enable route propagation for the virtual private gateway. This will automatically add routes for the on-premises CIDR blocks learned via BGP.

## Exam trap

{"trap":"A question presents a scenario where two VPCs are peered, and traffic is flowing correctly in one direction but not the other. The answer choices include adding a route in only one VPC, or adding a route in both VPCs but with the wrong target. Learners often choose the option that adds a route in only the VPC that is failing to reach the other.","why_learners_choose_it":"Learners think that if traffic is already flowing from VPC A to VPC B, then only VPC B needs a route to send traffic back. They forget that routing must be symmetrical: each VPC must have a route pointing to the peering connection for the other VPC's CIDR. They also may mistakenly believe that the peering connection itself handles routing in both directions automatically.","how_to_avoid_it":"Always remember that VPC peering does not add routes to either VPC's route table. You must manually add routes in both route tables. Even if traffic flows one way initially, the reverse path requires an explicit route in the destination VPC. Always verify that both route tables have entries for the remote VPC CIDR with the peering connection as the target."}

## Commonly confused with

- **Route table vs Routing table (on a router):** A routing table on a router usually contains dynamic routes learned via protocols like OSPF or BGP, while a route table in cloud contexts like AWS is typically a static set of rules. On a router, the routing table includes additional information such as administrative distance, metric, and routing protocol. In contrast, a cloud route table is simpler and managed directly by the user, though both serve the same fundamental purpose of directing traffic. (Example: In Cisco IOS, the routing table is shown with the command “show ip route” and includes protocol codes (C, S, O, etc.), whereas an AWS route table is shown in the console and only lists destination CIDRs and targets.)
- **Route table vs Network ACL (NACL):** A network ACL is a stateless firewall that controls inbound and outbound traffic at the subnet level based on rules. A route table controls the path that traffic takes. A NACL does not route traffic; it only permits or denies packets. A route table does not filter packets; it only decides where to send them. They work together to secure and direct network traffic. (Example: If a packet is allowed by the NACL but the route table has no route to the destination, the packet will be dropped. If a packet is denied by the NACL, it never reaches the route table.)
- **Route table vs Security group:** A security group is a stateful firewall that operates at the instance level, controlling traffic to and from an individual resource like an EC2 instance. A route table is a subnet-level construct that determines where traffic goes. Security groups do not affect routing; they only filter traffic. Route tables do not filter traffic; they guide it. (Example: You can have a security group that allows all HTTP traffic, but if the route table for the subnet does not have a route to the internet, the web server will still be unreachable from the internet.)
- **Route table vs Default gateway:** The default gateway is a specific entry in a route table, usually the 0.0.0.0/0 route. The route table is the entire collection of routes, while the default gateway is just one of them. The default gateway is the next hop used when no other route matches. A route table can have many specific routes in addition to the default gateway. (Example: A PC's route table includes a default gateway entry of 192.168.1.1. It also may have a route for 10.0.0.0/8 pointing to 10.0.0.1. The route table contains both, but the default gateway is only one entry.)
- **Route table vs Transit gateway:** A transit gateway is a central hub that connects multiple VPCs and on-premises networks, acting as a router between them. A route table is a set of rules that can be associated with a transit gateway to control traffic flow. The transit gateway itself can have multiple route tables associated with different attachments. The transit gateway is the hardware or service, while the route table is the configuration that dictates its behavior. (Example: In AWS, a transit gateway may have one route table for all VPCs that need to communicate with each other, and another route table for a VPN attachment to on-premises. The route tables are part of the transit gateway configuration.)

## Step-by-step breakdown

1. **Packet arrives at the network interface** — A network device (router, instance, or host) receives an IP packet at one of its interfaces. The device extracts the destination IP address from the packet header. This is the starting point for the routing decision.
2. **Route table lookup begins** — The device searches its route table for a route that matches the destination IP address. The route table is usually stored in a data structure optimized for fast lookups, such as a prefix tree or a hash table. In cloud environments, this lookup is performed by the virtual router of the VPC.
3. **Longest prefix match is applied** — The device checks all routes that have the same prefix bits as the destination IP. Among those, it selects the route with the longest subnet mask (most specific). For example, for destination 10.0.1.5, the route 10.0.1.0/24 wins over 10.0.0.0/16 because /24 is longer.
4. **No match found? Use the default route** — If no specific route matches the destination IP, the device looks for a default route, usually 0.0.0.0/0 (or ::/0 for IPv6). If a default route exists, the packet is forwarded to the target specified in that route. If no default route exists, the packet is dropped.
5. **Determine the next hop and outgoing interface** — The matching route entry provides two key details: the next-hop IP address (or a cloud service identifier like igw-xxxx) and the outgoing interface. For directly connected networks, the next hop may be the destination itself. For remote networks, the next hop is the IP of the next router.
6. **Forward the packet to the next hop** — The device then sends the packet out through the designated interface toward the next hop. In an AWS VPC, if the target is an internet gateway, the packet is forwarded to the gateway which then routes it to the internet. If the target is a peering connection, the packet is sent to the other VPC.
7. **Subsequent routers repeat the process** — The next hop receives the packet and performs its own route table lookup. This hop-by-hop routing continues until the packet reaches the destination host. Each router along the path uses its own independent route table, which may be different from the source’s route table.
8. **Packet reaches the destination host** — When the final router has a route that matches the destination with an interface that is directly connected to the destination’s network, the packet is delivered directly to the destination host. The destination host then processes the packet and sends a reply if needed.

## Commands

```
aws ec2 describe-route-tables --filters Name=vpc-id,Values=vpc-12345678
```
This CLI command lists all route tables in a specific VPC. It is used for inventory and troubleshooting to see which route tables exist and their associations with subnets and gateways.

*Exam note: Exams often require you to identify the command to list route tables or check a route table's content. Knowing the filter syntax is useful for scenario-based questions.*

```
aws ec2 create-route --route-table-id rtb-12345678 --destination-cidr-block 0.0.0.0/0 --gateway-id igw-98765432
```
Creates a default route (0.0.0.0/0) in a specified route table pointing to an internet gateway. This is used to make a subnet public.

*Exam note: This is a classic exam scenario for enabling internet access. The exam tests whether you choose the correct target type (gateway-id vs nat-gateway-id) based on the subnet type.*

```
aws ec2 create-route --route-table-id rtb-12345678 --destination-cidr-block 10.0.0.0/16 --vpc-peering-connection-id pcx-abcdef12
```
Adds a route to a VPC peering connection. This route is required in both VPCs for traffic to flow between them.

*Exam note: A common mistake is adding the route to only one VPC. The exam tests your understanding that both sides need reciprocal routes.*

```
aws ec2 replace-route --route-table-id rtb-12345678 --destination-cidr-block 0.0.0.0/0 --nat-gateway-id nat-11223344
```
Replaces an existing default route target from an internet gateway to a NAT gateway. This is done when migrating a subnet from public to private but still needing outbound internet access.

*Exam note: The exam may ask how to change a subnet from public to private while maintaining internet egress. The key is to replace the route's target, not recreate the route.*

```
aws ec2 associate-route-table --route-table-id rtb-12345678 --subnet-id subnet-abcdef01
```
Explicitly associates a custom route table with a subnet. If a subnet is not explicitly associated, it uses the main route table.

*Exam note: Exams test that association override the main route table. Disassociating a subnet reverts it to the main route table.*

```
aws ec2 enable-vgw-route-propagation --route-table-id rtb-12345678 --gateway-id vgw-abcdef12
```
Enables automatic route propagation from a virtual private gateway into the specified route table. This adds routes for your on-premises networks.

*Exam note: This is a key concept for hybrid architectures. The exam tests that propagated routes are added automatically but static routes have higher priority for same-prefix routes.*

```
aws ec2 associate-transit-gateway-route-table --transit-gateway-route-table-id tgw-rtb-abcdef12 --transit-gateway-attachment-id tgw-attach-12345678
```
Associates a transit gateway route table with a transit gateway attachment. This determines which route table the attachment uses to forward traffic.

*Exam note: Transit gateway route tables are a separate concept from VPC route tables. The exam tests that attachments must be associated with a route table to function.*

```
aws ec2 delete-route --route-table-id rtb-12345678 --destination-cidr-block 0.0.0.0/0
```
Deletes a route from a route table. If you delete the default route, the subnet loses internet access (unless there's another matching route).

*Exam note: The exam may ask what happens when a route is deleted: traffic to that destination is dropped unless a more specific or default route exists. This is tested in connectivity troubleshooting.*

## Troubleshooting clues

- **Instance in private subnet cannot reach the internet** — symptom: Ping to 8.8.8.8 fails; HTTP requests timeout; no outbound connectivity.. The private subnet's route table likely lacks a default route (0.0.0.0/0) to a NAT gateway or NAT instance. Alternatively, the route exists but the NAT gateway is in a failed state or is not placed in a public subnet with its own internet route. The VPC router drops the packet when no matching route is found. (Exam clue: Exams present a scenario where a private subnet needs internet access. The correct answer is to add a route to a NAT gateway in the private subnet's route table, or ensure the NAT gateway route is present. They test the distinction between public and private subnets.)
- **EC2 instance in public subnet cannot reach the internet** — symptom: Outbound traffic fails; instance has a public IP but no internet access.. The route table for the subnet may not have a default route (0.0.0.0/0) pointing to an internet gateway, or the internet gateway is not attached to the VPC. Also, the instance must have a public IP or an elastic IP assigned. Another cause is a missing route for IPv6 if using IPv6. (Exam clue: A classic exam question: 'You assigned a public IP to an EC2 instance but it still can't reach the internet.' The answer is to check the route table and ensure the internet gateway is attached and the route exists.)
- **Cross-region VPC peering traffic fails** — symptom: ICMP echo requests timeout; TCP connections fail between instances in peered VPCs in different regions.. VPC peering connections do not automatically add routes. The route table in each VPC must have a route for the other VPC's CIDR, with the target being the peering connection ID. Also, cross-region peering requires that the route tables are updated in both VPCs. Security groups and network ACLs must allow traffic. If the route is missing, the VPC router drops the packet. (Exam clue: Exams test the necessity of adding routes in both direction. A scenario where only one VPC has the route is a common trap. The answer is to add the reciprocal route.)
- **Route table shows 'blackhole' for a route** — symptom: The route status is blackhole in the AWS console or CLI; traffic to that destination is dropped.. The target resource (internet gateway, NAT gateway, peering connection, etc.) has been deleted or is in a failed state. The route still exists but is invalid. Traffic matching that route will be silently dropped. This usually happens after deleting a NAT gateway or internet gateway without removing the route. (Exam clue: The exam may present a scenario where a route is blackhole and ask what the likely cause is. The answer is that the associated target resource was removed. They also test that you must either delete the route or replace the target.)
- **Cannot add a route to a route table because of limit exceeded** — symptom: You receive an error like 'LimitExceeded: Cannot add more routes to the route table' when trying to create a new route.. Each route table has a maximum number of entries (default 50, can be increased to 1000). You have reached this limit. This can happen when using route propagation with many on-premises networks that automatically add many routes. (Exam clue: Exams test knowledge of service limits. A scenario where adding a new route fails might require you to either delete unused routes, request a limit increase, or use prefix lists to consolidate routes.)
- **Traffic between two subnets in the same VPC fails** — symptom: Instances in subnet A cannot communicate with instances in subnet B, even though both are in the same VPC.. By default, all subnets in a VPC can communicate with each other automatically because the VPC has an internal local route. This route is always present in every route table (the local route for the VPC CIDR). If traffic fails, the issue is likely a network ACL or security group blocking traffic, not the route table. However, if one subnet uses a custom route table that inadvertently overrides the local route (e.g., by adding a more specific route), that could cause a problem. But the local route cannot be deleted. (Exam clue: The exam tests that the local route for the VPC CIDR is always present and cannot be removed. If intra-VPC communication fails, suspect security groups or NACLs, not routes.)
- **Transit gateway attachment not forwarding traffic** — symptom: Packets sent from a VPC to another network via transit gateway are dropped; the transit gateway route table has the correct routes.. The VPC's route table must have a route pointing to the transit gateway ID for the destination CIDRs of the other network. If the VPC route table does not have that route, traffic from the VPC will not reach the transit gateway. Also, the transit gateway route table must have routes for the destination, and the attachment must be associated with a route table. (Exam clue: Exams test the two-level routing: VPC route table points to transit gateway, and transit gateway route table points to the attachment. A missing route at either level causes failure.)
- **Main route table accidentally modified, affecting all unassociated subnets** — symptom: After modifying the main route table, multiple subnets that were not explicitly associated with custom route tables lose connectivity or gain unexpected behavior.. The main route table is used by any subnet that does not have an explicit association. If you change the main route table (e.g., remove the default internet route), all subnets relying on it will be affected. This is a common mistake when administrators think they are editing a custom route table but actually edit the main one. (Exam clue: The exam tests that the main route table is the default for all unassociated subnets. A scenario where a subnet loses connectivity after a route table change may be due to modifying the main route table instead of the custom one.)

---

Practice questions and the full interactive page: https://courseiva.com/glossary/route-table