Amazon VPC Subnets and Routing

What you will be able to do

• Explain the five core cloud decisions involved in amazon vpc subnets and routing.
• Choose a cloud resource or configuration that matches a stated workload requirement.
• Interpret provider state, workload behavior, and operational evidence before changing broader cloud state.
• Apply an inventory, select, configure, verify, recover, and document workflow to a realistic cloud decision.

01

Build the Cloud Decision Map

Trace Amazon VPC traffic through CIDR ranges, subnets, route tables, gateways, and layered traffic controls.

Cloud services combine provider-managed layers with customer-controlled configuration. A useful design keeps workload need, resource scope, identity, network path, data, health, cost, and recovery visible instead of relying on a product name.

Start with an inventory and read-only evidence. Record the account or project, location, resource identifier, owner, configuration source, dependencies, expected behavior, and current observation before changing state.

02

VPC boundary

An Amazon VPC is a logically isolated virtual network with selected address ranges, routes, gateways, and controls. It answers one distinct architecture or operating question within amazon vpc subnets and routing.

Define the VPC purpose and nonoverlapping CIDR plan before attaching workloads. Keep the target, location, identity, configuration, and observed outcome together so another person can reproduce the reasoning.

Respect this boundary: Do not assume a VPC is reachable or isolated without evaluating its paths. The expected evidence is the vpc inventory shows ownership, cidrs, and connections.

03

VPC subnet

A VPC subnet is a CIDR range in one Availability Zone where network interfaces receive addresses. It answers one distinct architecture or operating question within amazon vpc subnets and routing.

Classify each subnet by workload role, exposure, route needs, and zone. Keep the target, location, identity, configuration, and observed outcome together so another person can reproduce the reasoning.

Respect this boundary: Do not call a subnet public merely because a route table has an internet route. The expected evidence is the subnet classification matches routes and resource addresses.

04

Route table

A VPC route table selects a target for traffic matching a destination prefix. It answers one distinct architecture or operating question within amazon vpc subnets and routing.

Trace the most specific route for forward and return traffic. Keep the target, location, identity, configuration, and observed outcome together so another person can reproduce the reasoning.

Respect this boundary: Do not troubleshoot security groups before confirming the selected routes. The expected evidence is both directions select reachable and intended targets.

05

Gateway path

Internet, NAT, VPN, transit, and other gateways provide different VPC connectivity paths. It answers one distinct architecture or operating question within amazon vpc subnets and routing.

Choose the gateway that matches direction, address translation, trust, and availability needs. Keep the target, location, identity, configuration, and observed outcome together so another person can reproduce the reasoning.

Respect this boundary: Do not expect a NAT path to accept unsolicited inbound connections. The expected evidence is the gateway carries only the documented traffic direction.

06

VPC traffic control

Security groups and network ACLs evaluate traffic at different scopes and with different state behavior. It answers one distinct architecture or operating question within amazon vpc subnets and routing.

Test an allowed flow and one intentionally blocked flow from representative endpoints. Keep the target, location, identity, configuration, and observed outcome together so another person can reproduce the reasoning.

Respect this boundary: Stop when a temporary broad rule lacks owner or removal time. The expected evidence is the approved flow passes and the blocked control remains effective.

07

Verify One Cloud Change

Before changing cloud state, name the exact resource, required authorization, user impact, expected signal, cost effect, and recovery path. Preview the scope with an inventory or policy view and protect data or configuration that cannot be recreated safely.

Make one narrow change and stop. If the provider response, location, identity, dependency, or effective configuration differs from the plan, preserve that evidence and reassess instead of adding unrelated changes.

A successful API response or portal notification proves only that an operation was accepted. Repeat the original workload path, inspect health and security signals, verify the resulting resource state independently, and remove temporary access or test resources.

08

Recap Before Practice and Prove

Start with vpc boundary. Define the VPC purpose and nonoverlapping CIDR plan before attaching workloads. Confirm that the vpc inventory shows ownership, cidrs, and connections.

Keep vpc subnet separate. Classify each subnet by workload role, exposure, route needs, and zone. Respect this boundary: do not call a subnet public merely because a route table has an internet route.

Use route table as its own decision. Trace the most specific route for forward and return traffic. Preserve the resulting evidence.

Before a broader change, review gateway path. Choose the gateway that matches direction, address translation, trust, and availability needs. Stop when do not expect a nat path to accept unsolicited inbound connections.

Finish with vpc traffic control. Test an allowed flow and one intentionally blocked flow from representative endpoints. Record the final state, health signal, recovery boundary, owner, and next decision.