AWS Networking Full Course in 2 Hours (FREE)

Course Overview

The course presents AWS networking through three recurring questions:

1. Where is a resource, and what is its address?
2. Where should its traffic go next?
3. Is that traffic allowed?

The instructor recommends tracing an individual packet through an architecture and asking these questions at each step. This turns AWS networking services into parts of a connected system rather than a list of names to memorize.

1. Network Foundations and AWS Structure

Networking relies on three basic ideas: addresses, routing, and firewalls. AWS provides virtual versions of these long-established concepts.

The AWS network hierarchy is:

• An AWS account contains resources.
• A region is the geographic area where resources are deployed.
• A region contains multiple Availability Zones (AZs), which are separate infrastructure locations designed to support resilience.
• A VPC is a private network created in one region. It can span the region’s AZs.
• A subnet is a segment of a VPC and belongs to exactly one AZ. Subnets let workloads be distributed across AZs.

AWS creates a default VPC for convenience, but the course recommends creating your own VPC for production environments.

CIDR and Address Planning

• CIDR notation defines the size of a network. For example, 10.0.0.0/16 has 32-bit IPv4 addresses, with 16 bits for the network and 16 bits for host addresses: 65,536 total.
• Smaller ranges can be carved out as subnets. For example, a /24 contains 256 total addresses before AWS reservations.
• The smaller the number after the slash, the larger the network. AWS reserves five addresses in each subnet, so a /24 has 251 usable addresses.
• Common private IPv4 ranges are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Private addresses are not routed directly over the public internet.
• Choose VPC ranges that do not overlap with office networks or other VPCs you may later connect to; overlapping ranges make routing between them problematic.

2. Addresses, Routes, and DNS

Resource Addresses

• An EC2 instance has a private IP address for communication within its network.
• It may also have a public IPv4 address for internet communication. An automatically assigned public IPv4 address can change when an instance is stopped and started.
• An Elastic IP is a static public IPv4 address that can be reassigned between resources. The course notes that AWS charges for public IPv4 addresses, so unused ones should be released.
• IPv6 addresses are generally globally unique, so IPv4-style address translation is not required. IPv6 resources still need appropriate routes and security rules.

Route Tables

• A route table contains destination ranges and targets, and is associated with a subnet.
• VPCs automatically have a local route for the VPC’s CIDR range. This lets resources in different subnets of the same VPC route to one another, subject to security controls.
• A default route such as 0.0.0.0/0 handles IPv4 destinations without a more specific route. Its target might be an internet gateway, NAT gateway, or another connection.
• When multiple routes match, the longest-prefix match wins: the most specific destination range takes precedence.
• A route provides a path; it does not grant permission. A valid route can exist while a firewall blocks the traffic.
• If a route’s target is removed or disabled after the route is created, it may become a “black hole,” and traffic sent there is lost.

DNS

• A VPC includes an AWS DNS resolver. The course identifies the VPC base address plus two (for example, 10.0.0.2) and 169.254.169.253 as resolver addresses.
• Two VPC settings affect DNS:
  • DNS resolution lets resources use the resolver.
  • DNS hostnames enables AWS-generated hostnames for instances.
• Route 53 supports public hosted zones and private hosted zones. Private zones provide names resolvable only within associated VPCs.
• DNS records are cached according to their TTL. The instructor suggests lowering the TTL before a planned record change, then raising it afterward.
• DNS problems are often caused by configuration or zone association rather than routing.

3. Firewalls, Traffic Diagnosis, and Permissions

Security Groups

• A security group is attached to a network interface and protects a resource.
• It has inbound and outbound rules and is stateful: if a connection is allowed in one direction, its reply traffic is automatically allowed.
• Security groups allow traffic; they do not have explicit deny rules.
• Rules can reference other security groups. For example, an application server can allow traffic from a web-server group, and a database can allow traffic only from the application-server group.
• The course recommends using groups to express which application tiers may communicate, rather than maintaining lists of individual IP addresses.

Network ACLs

• A network ACL (NACL) applies at the subnet boundary.
• NACLs are stateless, so inbound and outbound traffic must be permitted separately.
• Rules are evaluated in numerical order; the first matching rule applies. Traffic that matches no rule is denied by the implicit final rule.
• Unlike security groups, NACLs support explicit allow and deny rules.
• Because NACLs do not track connections, replies often require rules for ephemeral ports, commonly in the range 1024–65535.

Tracing an HTTPS Request in Both Directions

For a user connecting to a public web server on port 443:

1. The inbound NACL must allow the request.
2. The server’s inbound security-group rules must allow it.
3. The stateful security group allows the reply traffic automatically.
4. The outbound NACL must allow the reply to the client’s ephemeral port.

A frequent failure is allowing inbound port 443 but forgetting the outbound NACL rule for ephemeral ports. For an application-initiated connection, the corresponding request and response checks apply in the opposite direction.

Troubleshooting with VPC Flow Logs

• VPC Flow Logs record traffic summaries—such as source and destination addresses, ports, protocol, and whether traffic was accepted or rejected. They do not capture packet contents and are not a real-time control mechanism.
• Suggested diagnostic process:
  1. Enable logs for the relevant VPC, subnet, or network interface.
  2. Reproduce the failed connection.
  3. Filter logs by address and destination port.
  4. If there is no record, check the address and route: the packet may never have arrived.
  5. If the record shows rejection, inspect security groups and NACLs.
  6. If it shows acceptance but the application still fails, investigate the service or application on the destination.
• Flow Logs generally do not record traffic to the VPC’s own DNS resolver. The course also notes that logs may be delayed and that storing them can incur costs.

IAM and CloudTrail

• IAM determines who or what may create, inspect, change, or delete network resources. It is separate from the rules that decide whether a packet can pass.
• Apply least privilege: grant each role only the network actions it needs.
• Carefully control who can change security-group rules and routing, since those changes can expose resources or disrupt connectivity.
• CloudTrail records API activity, including who changed a security group, route table, gateway, or other network resource. Flow Logs show what happened to traffic; CloudTrail can help show who changed the configuration.

4. Building a Common VPC Architecture

Public and Private Subnets

• An internet gateway attaches to a VPC, but its presence alone does not make every subnet public.
• A subnet is commonly called public when its route table sends internet-bound traffic to an internet gateway. A subnet without that route is considered private.
• For an IPv4 instance to be directly reachable from the internet, the path generally needs all of the following:
  • An internet gateway attached to the VPC.
  • A subnet route to that gateway.
  • A public IPv4 address or Elastic IP on the instance.
  • Security rules allowing the traffic.
• A private subnet typically houses application servers and databases. To administer private instances, the course describes a bastion host or AWS Systems Manager Session Manager. Session Manager requires a suitable path to AWS services, such as through NAT or VPC endpoints.

NAT Gateways and NAT Instances

• A NAT gateway lets resources in private subnets initiate outbound internet connections while remaining unavailable for unsolicited inbound internet connections.
• Typical route pattern:
  • Public subnet: default route to the internet gateway.
  • Private subnet: default route to a NAT gateway in a public subnet.
• The NAT gateway uses an Elastic IP for outbound IPv4 traffic.
• For availability, the course recommends a NAT gateway per AZ, with private subnets in each AZ routed through their local gateway. A single gateway can otherwise become a failure point for other AZs.
• NAT gateways incur hourly and data-processing charges. VPC endpoints can avoid routing some AWS-service traffic through NAT.
• A NAT instance is an EC2 instance configured to perform NAT. It offers more control and may be cheaper in some small setups, but requires the operator to manage capacity, availability, patching, security, and configuration. The course’s general recommendation is to use the managed NAT gateway unless there is a specific reason not to.

Load Balancers and a Three-Tier Design

• A load balancer provides an entry point for application traffic:
  • An Application Load Balancer (ALB) handles HTTP and can route by host or path.
  • A Network Load Balancer (NLB) handles TCP/UDP traffic and high-throughput use cases.
• A typical flow is: user → internet gateway → public load balancer → private application server → private database.
• Security groups can restrict each tier:
  • Load balancer: accept HTTPS from users.
  • Application servers: accept application traffic only from the load-balancer group.
  • Database: accept database traffic only from the application group.
• The course’s reference design spans two AZs and has six subnets: public, private application, and private database subnets in each AZ.
• It uses separate routing for public subnets, application subnets in each AZ, and database subnets. Database subnets have only the local route when they do not need internet access.
• Deploying each tier across AZs helps the application continue operating if one AZ fails, provided the resources and routes are also available in the surviving AZ.

5. Connecting Beyond One VPC

Start by identifying what needs to connect: two VPCs, an AWS service, an office network, or individual remote users.

VPC Peering and Transit Gateway

• VPC peering is a direct private connection between two VPCs. For it to work:
  • The connection must be accepted.
  • Each side needs a route to the other VPC.
  • Security rules must permit the traffic.
• Peering is not transitive: traffic cannot pass through one peered VPC to reach another. The VPC CIDR ranges must not overlap.
• Peering suits a small number of VPCs with direct, stable relationships.
• Transit Gateway is a regional routing hub for many VPCs and can also connect to VPN or Direct Connect. It supports transitive routing.
• With Transit Gateway, check both routing levels: the VPC route table and the Transit Gateway’s own route table. Multiple Transit Gateway route tables can help segment environments.
• Transit Gateway can simplify a growing network, but adds cost and an extra routing hop. A small number of VPCs may be simpler and cheaper to connect with peering.

VPC Endpoints and PrivateLink

• VPC endpoints provide private access to supported AWS services without sending traffic through the public internet or a NAT gateway.
• A gateway endpoint is a route-table target, available for S3 and DynamoDB. It adds a route for the service’s address ranges and can use an endpoint policy to limit access.
• An interface endpoint creates private network interfaces in selected subnets. DNS can resolve the service name to those private addresses, and endpoint security groups must allow the traffic. Interface endpoints have hourly and data-processing costs.
• AWS PrivateLink can expose a specific service privately to consumers without giving them a route to the provider’s whole network. This differs from peering or Transit Gateway, which connect networks.

Office Networks and Remote Users

• Site-to-site VPN connects an office or data center to AWS using encrypted tunnels over the internet. Routes must work in both directions; the course notes that AWS provides redundant tunnels.
• Direct Connect is a dedicated physical connection to AWS, intended for more predictable performance, capacity, or data-transfer needs. It is not encrypted by default; encryption may need to be added. Organizations may use VPN as a backup.
• Client VPN provides network access for individual remote users, with access controlled through authentication, routes, and security rules.
• Session Manager is another option when an administrator needs a shell on an instance rather than broader network access.

Core Diagnostic Method

When a connection fails, follow the packet rather than changing settings at random:

1. Confirm the source and destination addresses.
2. Check the relevant subnet route tables and the next hop.
3. Verify the connection or gateway exists and is active.
4. Check inbound and outbound security-group and NACL rules, including return traffic and ephemeral ports where applicable.
5. Use Flow Logs to see whether traffic was accepted or rejected.
6. If the network permits the traffic, check the destination service and application.
7. Use CloudTrail to investigate recent configuration changes.

The course’s central lesson is that network location, routing, and permission are separate questions. A packet needs a valid path and permission at every relevant control point.

Speakers and Sources Featured

• Course narrator/instructor — the sole speaking voice in the subtitles, presenting the AWS networking lessons.
• No guest speakers or other distinct sources are identifiable in the supplied subtitles.