# Fixing Private Subnet's Missing NAT Route

### Objective

This SOP explains how to inspect a private subnet’s route table, confirm the NAT gateway is healthy, add the missing default route to the NAT gateway, and verify end-to-end internet connectivity from the subnet. Follow these steps to restore outbound internet access for private subnet workloads.

### [Link to Loom](https://loom.com/share/150b4ee6c4e34066b282a47dbc943518)

### Key Steps

**1\. Retrieve the Private Subnet ID** [0:18](https://loom.com/share/150b4ee6c4e34066b282a47dbc943518?t=18)

![generated-image-at-00:00:18](https://loom.com/i/4fe8dc3ebf314f94a170c461cc7dbcd0?workflows_screenshot=true align="center")

*   Open the AWS CLI terminal.
    
*   Run the AWS `describe` command to retrieve the subnet ID for the private subnet.
    
*   Paste in the API server IP address when prompted.
    
*   Confirm the command returns the subnet ID you will use in the next step.
    

**2\. Inspect the Route Table for the Subnet** [1:46](https://loom.com/share/150b4ee6c4e34066b282a47dbc943518?t=106)

![generated-image-at-00:01:46](https://loom.com/i/1e1798bd070a4b13a6f7295523d19d03?workflows_screenshot=true align="center")

*   Use the subnet ID from the previous step in a new AWS `describe` command.
    
*   Include the full subnet identifier exactly as returned, including the `subnet-` prefix.
    
*   Review the route table output.
    
*   If the output is paginated, continue scrolling/down until the full route table details are visible.
    
*   Check the route table ID, VPC ID, associations, and route state.
    

**3\. Determine Whether a Default Internet Route Exists** [2:33](https://loom.com/share/150b4ee6c4e34066b282a47dbc943518?t=153)

![generated-image-at-00:02:33](https://loom.com/i/351457c28b2a4d058afaa5f59beaff92?workflows_screenshot=true align="center")

*   Review the route table entries for a default route (`0.0.0.0/0`).
    
*   Confirm whether traffic destined for the public internet is routed to a NAT gateway.
    
*   If the route table only contains routes for the VPC/private network, outbound internet access is not configured.
    
*   Note that private subnets do not have direct internet access by default.
    

**4\. Verify the NAT Gateway Is Healthy** [3:42](https://loom.com/share/150b4ee6c4e34066b282a47dbc943518?t=222)

![generated-image-at-00:03:42](https://loom.com/i/fd732481c3e44e758421a751abf16dc3?workflows_screenshot=true align="center")

*   Run an AWS `describe` command for the NAT gateway.
    
*   Confirm the NAT gateway status is available/healthy.
    
*   Verify the status shows success and that the gateway is ready to accept traffic.
    
*   If the NAT gateway is not healthy, resolve that issue before changing the route table.
    

**5\. Create the Missing Route to the NAT Gateway** [5:00](https://loom.com/share/150b4ee6c4e34066b282a47dbc943518?t=300)

![generated-image-at-00:05:00](https://loom.com/i/74d8503dda5943d39a0ca8235f5a443f?workflows_screenshot=true align="center")

*   Return to the AWS CLI terminal.
    
*   Gather the NAT gateway ID.
    
*   Gather the route table ID for the private subnet.
    
*   Create a new route in the route table with:
    
    *   Destination: `0.0.0.0/0`
        
    *   Target: the NAT gateway ID
        
*   Confirm the command returns success (for example, `true`).
    

**6\. Confirm the Route Was Added Correctly** [6:44](https://loom.com/share/150b4ee6c4e34066b282a47dbc943518?t=404)

![generated-image-at-00:06:44](https://loom.com/i/95a9b5c1def14a20b8b24a4d3e74a54e?workflows_screenshot=true align="center")

*   Review the route table output again.
    
*   Verify the new route exists and points all public traffic to the NAT gateway.
    
*   Confirm the destination is `0.0.0.0/0`.
    
*   Confirm the NAT gateway ID is listed as the target.
    
*   Ensure the subnet now has a path for outbound internet traffic.
    

**7\. Validate the Fix End to End** [7:32](https://loom.com/share/150b4ee6c4e34066b282a47dbc943518?t=452)

![generated-image-at-00:07:32](https://loom.com/i/8f82b7926b4347458cbdd4a071a7be8b?workflows_screenshot=true align="center")

*   Run the validation script (`validate.sh`) to check the environment.
    
*   Perform an actual network request using `curl` to test the full connection path.
    
*   Confirm the TCP/TLS handshake succeeds.
    
*   Verify the host resolves and the request reaches the public endpoint successfully.
    
*   Treat a successful request as confirmation that the private subnet internet access issue is resolved.
    

### Cautionary Notes

*   Do not create the route until you have confirmed the NAT gateway is healthy and available.
    
*   Make sure you copy the full subnet ID and route table ID exactly as returned, including prefixes such as `subnet-`.
    
*   If the CLI output is truncated or paginated, scroll through the full output before making changes.
    
*   A private subnet will not have direct internet access unless a default route to a NAT gateway is explicitly configured.
    
*   Validate with an actual network request, not just by checking configuration, to confirm end-to-end connectivity.
    

### Tips for Efficiency

*   Keep the subnet ID, route table ID, and NAT gateway ID in a scratch pad before making changes.
    
*   Reuse the same AWS CLI session to avoid re-authentication or context switching.
    
*   Check the route table before and after the change so you can quickly confirm what was missing.
    
*   Use `curl` or a similar request as the final verification step to catch DNS, routing, and TLS issues in one test.
    
*   If multiple private subnets use the same route table, one route update may restore connectivity for all associated subnets.