DEV Community

Cover image for What Really Happens When You Access AWS: Complete Data Flow Example
AWS Community Builders profile image Stella Achar Oiro
Stella Achar Oiro for AWS Community Builders

Posted on

What Really Happens When You Access AWS: Complete Data Flow Example

#networking #aws #python #cloudcomputing

You learned the OSI model in Part 1.

You learned how switches and routers work in Part 2.

You learned IP addressing and protocols in Part 3.

Now I show you how it all works together.

This is the complete journey, Your laptop → AWS EC2 instance → Your laptop.

Every protocol. Every header. Every table lookup. Every hop.

By the end, you will understand exactly what happens when you run any AWS command.

Let me trace the entire data flow.

The Scenario

You run a simple Python script:

import boto3

ec2 = boto3.client('ec2', region_name='us-east-1')
response = ec2.describe_instances()

print(f"Found {len(response['Reservations'])} instances")
Enter fullscreen mode Exit fullscreen mode

That one line triggers a cascade of networking events across:

  • 7 OSI layers
  • Multiple switches
  • Multiple routers
  • Dozens of protocols
  • Hundreds of hops

Let me show you every single step.

Your Network Setup

Your Computer:

  • IP: 192.168.1.100
  • MAC: AA:AA:AA:AA:AA:AA
  • Subnet: 192.168.1.0/24
  • Gateway: 192.168.1.1
  • DNS: 8.8.8.8

Your Home Router:

  • Internal IP: 192.168.1.1
  • Internal MAC: R1:R1:R1:R1:R1:R1
  • External IP: 203.0.113.50 (ISP assigned)

AWS EC2 API Endpoint:

  • Domain: ec2.us-east-1.amazonaws.com
  • IP: 52.94.133.131 (one of many)
  • Located in us-east-1 region

Phase 1: DNS Resolution

Your computer knows the domain name but needs the IP address.

Step 1: Check Local DNS Cache

Your computer checks:

$ dscacheutil -q host -a name ec2.us-east-1.amazonaws.com
Enter fullscreen mode Exit fullscreen mode

Cache empty. Need to query DNS server.

Step 2: Construct DNS Query

Your computer creates DNS request:

Layer 7 (Application):
  DNS Query: "What is IP for ec2.us-east-1.amazonaws.com?"

Layer 4 (Transport):
  Protocol: UDP
  Source Port: 54321 (random)
  Destination Port: 53 (DNS)

Layer 3 (Network):
  Source IP: 192.168.1.100 (you)
  Destination IP: 8.8.8.8 (Google DNS)

Layer 2 (Data Link):
  Source MAC: AA:AA:AA:AA:AA:AA (you)
  Destination MAC: ??? (need gateway MAC)
Enter fullscreen mode Exit fullscreen mode

Step 3: ARP for Gateway

Your computer needs gateway's MAC address.

Check ARP cache:

$ arp -a | grep 192.168.1.1
Enter fullscreen mode Exit fullscreen mode

If cached:

192.168.1.1 → R1:R1:R1:R1:R1:R1
Enter fullscreen mode Exit fullscreen mode

Use cached MAC. Skip ARP.

If not cached:

ARP Request (broadcast):
  Who has 192.168.1.1?
  Tell 192.168.1.100 at MAC AA:AA

Router responds:
  192.168.1.1 is at MAC R1:R1

Cache updated:
  192.168.1.1 → R1:R1
Enter fullscreen mode Exit fullscreen mode

Step 4: Send DNS Query

Complete packet to gateway:

[L2: AA:AA → R1:R1]              (to router)
[L3: 192.168.1.100 → 8.8.8.8]    (to Google DNS)
[L4: UDP 54321 → 53]              (DNS query)
[L7: DNS Query for ec2.us-east-1.amazonaws.com]
Enter fullscreen mode Exit fullscreen mode

Step 5: Router Processes DNS Query

Your home router receives packet:

  1. Remove Layer 2 header (reached router)
  2. Check routing table:
    • Destination: 8.8.8.8
    • Not local (192.168.1.x)
    • Match default route: 0.0.0.0/0 → ISP
  3. Perform NAT (Network Address Translation):
    • Change source IP: 192.168.1.100 → 203.0.113.50 (router's public IP)
    • Track connection in NAT table
  4. Create new Layer 2 header for ISP router
  5. Forward packet

Step 6: Internet Journey to Google DNS

Packet traverses multiple routers:

Your Router → ISP Router 1 → ISP Router 2 → 
Internet Backbone Router 1 → Internet Backbone Router 2 → 
Google Edge Router → Google DNS Server (8.8.8.8)
Enter fullscreen mode Exit fullscreen mode

At each router:

  • Layer 2 header changes (hop-to-hop)
  • Layer 3 header stays same (end-to-end)
  • Routing table determines next hop
  • ARP resolves next hop MAC

Step 7: Google DNS Responds

Google DNS server sends response:

DNS Response:
  ec2.us-east-1.amazonaws.com → 52.94.133.131

Layer 3:
  Source: 8.8.8.8 (Google DNS)
  Destination: 203.0.113.50 (your router's public IP)
Enter fullscreen mode Exit fullscreen mode

Step 8: Response Returns Through Internet

Packet traverses back through routers to your home router.

Step 9: Your Router Receives Response

Router checks NAT table:

NAT Table:
  External: 203.0.113.50:54321 ←→ Internal: 192.168.1.100:54321
Enter fullscreen mode Exit fullscreen mode

Router translates:

  • Destination IP: 203.0.113.50 → 192.168.1.100
  • Forwards to your computer

Step 10: Your Computer Receives DNS Response

Your computer:

  1. Removes headers layer by layer
  2. Extracts DNS response: 52.94.133.131
  3. Caches result:
    • ec2.us-east-1.amazonaws.com → 52.94.133.131
    • TTL: 60 seconds

DNS resolution complete.

Phase 2: TCP Connection Establishment

Your computer now knows AWS API endpoint IP. Time to establish connection.

Step 1: TCP SYN (Synchronize)

Your computer initiates TCP 3-way handshake:

Layer 4:
  TCP Flags: SYN
  Source Port: 55555 (random)
  Destination Port: 443 (HTTPS)
  Sequence Number: 1000

Layer 3:
  Source: 192.168.1.100
  Destination: 52.94.133.131

Layer 2:
  Source: AA:AA
  Destination: R1:R1 (gateway)
Enter fullscreen mode Exit fullscreen mode

Packet travels through internet to AWS.

Step 2: TCP SYN-ACK (Synchronize-Acknowledge)

AWS server responds:

TCP Flags: SYN-ACK
Source Port: 443
Destination Port: 55555
Sequence Number: 2000
Acknowledgment Number: 1001
Enter fullscreen mode Exit fullscreen mode

Travels back through internet to your computer.

Step 3: TCP ACK (Acknowledge)

Your computer completes handshake:

TCP Flags: ACK
Acknowledgment Number: 2001
Enter fullscreen mode Exit fullscreen mode

TCP connection established.

Connection Identity:

192.168.1.100:55555 ←→ 52.94.133.131:443
Enter fullscreen mode Exit fullscreen mode

This unique 4-tuple identifies this specific connection.

Phase 3: TLS Handshake

Connection established but not encrypted. Need TLS.

Step 1: Client Hello

Your computer sends:

TLS ClientHello:
  - TLS version: 1.3
  - Cipher suites supported
  - Random bytes for key generation
Enter fullscreen mode Exit fullscreen mode

Step 2: Server Hello

AWS responds:

TLS ServerHello:
  - Chosen cipher suite
  - Server certificate
  - Random bytes
Enter fullscreen mode Exit fullscreen mode

Step 3: Certificate Verification

Your computer verifies AWS certificate:

  • Issued by: Amazon Trust Services
  • Valid for: *.amazonaws.com
  • Not expired
  • Signature valid

Certificate trusted. Continue.

Step 4: Key Exchange

Both sides:

  • Generate session keys using random bytes
  • Establish encryption parameters

Step 5: Finished Messages

Both sides exchange encrypted "Finished" messages.

TLS tunnel established. All future data encrypted.

Phase 4: HTTP Request

Now your computer sends the actual API request.

Step 1: boto3 Constructs HTTP Request

# Your code
ec2 = boto3.client('ec2', region_name='us-east-1')
response = ec2.describe_instances()
Enter fullscreen mode Exit fullscreen mode

boto3 creates:

POST / HTTP/1.1
Host: ec2.us-east-1.amazonaws.com
Content-Type: application/x-amz-json-1.1
X-Amz-Target: AmazonEC2.DescribeInstances
Authorization: AWS4-HMAC-SHA256 Credential=...
Content-Length: 2

{}
Enter fullscreen mode Exit fullscreen mode

Step 2: Complete Packet Structure

Layer 7 (Application):
  [HTTP POST request above]

Layer 6 (Presentation):
  [TLS encryption of HTTP data]

Layer 5 (Session):
  [TLS session management]

Layer 4 (Transport):
  Protocol: TCP
  Source Port: 55555
  Destination Port: 443
  Flags: PSH, ACK (push data, acknowledge)

Layer 3 (Network):
  Source IP: 192.168.1.100
  Destination IP: 52.94.133.131
  Protocol: TCP
  TTL: 64

Layer 2 (Data Link):
  Source MAC: AA:AA
  Destination MAC: R1:R1 (to gateway)
  Type: IPv4

Layer 1 (Physical):
  [Bits transmitted over Wi-Fi]
Enter fullscreen mode Exit fullscreen mode

Step 3: Journey Through Your Network

Packet travels:

  1. Your computer → Home switch (if present)
  2. Home switch → Home router

Switch operations:

  • Learn: Port X → MAC AA:AA
  • Check table for R1:R1
  • Forward: To router port

Step 4: Home Router Processing

Router receives packet:

  1. Remove Layer 2 header
  2. Check routing table:
    • Destination: 52.94.133.131
    • Match: 0.0.0.0/0 → ISP (default route)
  3. NAT translation:
    • Source IP: 192.168.1.100 → 203.0.113.50
    • Track: 203.0.113.50:55555 ←→ 192.168.1.100:55555
  4. Create new Layer 2 header:
    • Destination: ISP router MAC
  5. Forward packet

Step 5: ISP Router Processing

First ISP router receives packet:

  1. Remove Layer 2 header
  2. Check routing table:
    • Destination: 52.94.133.131
    • Match: 52.0.0.0/8 → Internet backbone
  3. Create new Layer 2 header
  4. Forward packet

This repeats at every router.

Step 6: Internet Backbone Routers

Packet traverses multiple Tier 1 ISP routers:

ISP Router 1 → ISP Router 2 → 
Regional Router 1 → Regional Router 2 →
Internet Exchange Point →
AWS Edge Router → AWS Region Router
Enter fullscreen mode Exit fullscreen mode

Each router:

  • Checks routing table
  • Determines next hop based on destination network
  • ARPs for next hop MAC (if needed)
  • Forwards packet

Layer 3 header constant throughout.
Layer 2 header changes at every hop.

Step 7: AWS Edge Router

AWS edge router receives packet:

Check routing table:

  • Destination: 52.94.133.131
  • Match: 52.94.133.0/24 → us-east-1 API servers
  • Next hop: Load balancer in us-east-1

Step 8: AWS Application Load Balancer

ALB receives packet:

  1. Terminate TLS connection
  2. Decrypt HTTPS request
  3. Examine HTTP headers:
    • Host: ec2.us-east-1.amazonaws.com
    • X-Amz-Target: AmazonEC2.DescribeInstances
  4. Route to EC2 API backend server
  5. Re-encrypt with internal TLS
  6. Forward to backend

Step 9: EC2 API Server

Backend server receives request:

  1. Decrypt TLS
  2. Parse HTTP request
  3. Validate authorization signature
  4. Execute: DescribeInstances
  5. Query EC2 service database
  6. Retrieve instance metadata
  7. Format JSON response

Step 10: Processing Complete

API server has response ready.

Phase 5: HTTP Response

Now the response travels back.

Step 1: EC2 API Server Sends Response

HTTP/1.1 200 OK
Content-Type: application/x-amz-json-1.1
Content-Length: 1543

{
  "Reservations": [
    {
      "Instances": [
        {
          "InstanceId": "i-1234567890abcdef0",
          "InstanceType": "t3.micro",
          "State": {"Name": "running"},
          "PrivateIpAddress": "10.0.1.50",
          ...
        }
      ]
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

Step 2: Response Returns Through AWS Infrastructure

EC2 API Server → ALB → AWS Region Router → 
AWS Edge Router → Internet
Enter fullscreen mode Exit fullscreen mode

ALB:

  • Encrypts response with TLS
  • Sends to your connection (tracked by source/dest IPs and ports)

Step 3: Internet Journey Back

Packet traverses back through internet routers:

AWS Edge → Internet Exchange → 
Tier 1 ISP Routers → Your ISP Routers → Your Router
Enter fullscreen mode Exit fullscreen mode

Each router:

  • Checks destination IP (203.0.113.50)
  • Routes accordingly

Step 4: Your Router Receives Response

Router checks NAT table:

NAT Table:
  External: 203.0.113.50:55555 ←→ Internal: 192.168.1.100:55555
Enter fullscreen mode Exit fullscreen mode

Router translates:

  • Destination IP: 203.0.113.50 → 192.168.1.100
  • Destination port: 55555 (preserved)

Creates new Layer 2 header:

  • Destination MAC: AA:AA (your computer)

Forwards to your computer.

Step 5: Your Computer Processes Response

Your computer receives packet:

De-encapsulation:

Layer 1: Bits received from Wi-Fi
         ↓
Layer 2: Check MAC = AA:AA? YES
         Remove Ethernet header
         ↓
Layer 3: Check IP = 192.168.1.100? YES
         Remove IP header
         ↓
Layer 4: Check Port = 55555? YES
         TCP reassembly
         Remove TCP header
         ↓
Layer 5: TLS session identified
         ↓
Layer 6: Decrypt TLS
         ↓
Layer 7: Parse HTTP response
         Extract JSON data
         ↓
Application: boto3 processes response
Enter fullscreen mode Exit fullscreen mode

Your Python script receives:

response = {
    'Reservations': [...]
}

print(f"Found {len(response['Reservations'])} instances")
# Output: Found 1 instances
Enter fullscreen mode Exit fullscreen mode

Complete.

Summary: What Just Happened

Your simple boto3 call triggered:

DNS Resolution:

  • 1 DNS query (UDP)
  • 1 DNS response
  • ARP for gateway
  • Multiple router hops

TCP Connection:

  • 3-way handshake (SYN, SYN-ACK, ACK)
  • Multiple router hops each way

TLS Handshake:

  • ClientHello
  • ServerHello
  • Certificate verification
  • Key exchange
  • Multiple encrypted messages

HTTP Request:

  • 1 HTTP POST request
  • Through 20+ routers (typical)
  • NAT translation at your router
  • Load balancer routing

HTTP Response:

  • 1 HTTP 200 response
  • Back through 20+ routers
  • NAT reverse translation
  • De-encryption and processing

Total packets exchanged: ~50-100

Total time: ~100-200 milliseconds

All of this happens invisibly. Every single time.

The Three Tables in Action

Let me show you how all three tables were used.

MAC Address Table (Switches):

Your home switch (if present):

Before:
Port  |  MAC
------|------
(empty)

After first packet:
Port  |  MAC
------|------
5     |  AA:AA (your computer)
8     |  R1:R1 (router)
Enter fullscreen mode Exit fullscreen mode

Used for forwarding within your home network.

ARP Table (Your Computer and Routers):

Your computer:

Initial:
IP          |  MAC
------------|------
(empty)

After DNS query:
IP              |  MAC
----------------|------
192.168.1.1     |  R1:R1 (gateway)

After response:
(same, reused throughout connection)
Enter fullscreen mode Exit fullscreen mode

Routing Table (All Routers):

Your home router:

Network             |  Next Hop
--------------------|------------------
192.168.1.0/24      |  Local (LAN)
0.0.0.0/0           |  ISP (default)
Enter fullscreen mode Exit fullscreen mode

ISP router:

Network             |  Next Hop
--------------------|------------------
203.0.113.0/24      |  Local
52.0.0.0/8          |  AWS peering point
0.0.0.0/0           |  Backbone
Enter fullscreen mode Exit fullscreen mode

AWS edge router:

Network             |  Next Hop
--------------------|------------------
52.94.133.0/24      |  us-east-1 API servers
10.0.0.0/8          |  VPC networks
Enter fullscreen mode Exit fullscreen mode

All three tables work together at every hop.

Real-World Healthcare Example

Let me show you a practical healthcare scenario.

Architecture:

Patient Mobile App (Internet)
        ↓
API Gateway (HTTPS endpoint)
        ↓
Lambda Function (VPC)
        ↓
RDS PostgreSQL (Private subnet)
Enter fullscreen mode Exit fullscreen mode

Scenario: Patient Requests Medical Records

Patient app sends:

GET /api/records/patient/12345 HTTP/1.1
Host: api.myhealthapp.com
Authorization: Bearer eyJ...
Enter fullscreen mode Exit fullscreen mode

Step 1: DNS Resolution

Query: api.myhealthapp.com
Response: 54.123.45.67 (API Gateway endpoint)
Enter fullscreen mode Exit fullscreen mode

Step 2: HTTPS to API Gateway

Packet traverses internet to AWS.

API Gateway:

  • Terminates TLS
  • Validates JWT token
  • Checks authorization
  • Invokes Lambda function

Step 3: Lambda Function Execution

Lambda in VPC:

import boto3
import psycopg2

def lambda_handler(event, context):
    patient_id = event['pathParameters']['patient_id']

    # Lambda has ENI in VPC subnet
    # Private IP: 10.0.2.50

    # Connect to RDS in private subnet
    conn = psycopg2.connect(
        host="mydb.abc123.us-east-1.rds.amazonaws.com",
        database="healthrecords",
        user="app_user",
        password="..."
    )

    cursor = conn.cursor()
    cursor.execute(
        "SELECT * FROM records WHERE patient_id = %s",
        (patient_id,)
    )
    records = cursor.fetchall()

    return {
        'statusCode': 200,
        'body': json.dumps(records)
    }
Enter fullscreen mode Exit fullscreen mode

Step 4: Lambda → RDS Connection

Lambda needs to connect to RDS.

DNS resolution (internal):

Query: mydb.abc123.us-east-1.rds.amazonaws.com
Response: 10.0.3.100 (RDS private IP)
Enter fullscreen mode Exit fullscreen mode

Lambda checks:

My IP: 10.0.2.50 (subnet 10.0.2.0/24)
Destination: 10.0.3.100 (subnet 10.0.3.0/24)
Different subnets → Check route table
Enter fullscreen mode Exit fullscreen mode

VPC Route Table:

Network         |  Target
----------------|----------
10.0.0.0/16     |  local
Enter fullscreen mode Exit fullscreen mode

Both subnets in 10.0.0.0/16 VPC. Route is "local."

Lambda sends packet:

[L3: 10.0.2.50 → 10.0.3.100]
[L4: TCP random port → 5432 (PostgreSQL)]
Enter fullscreen mode Exit fullscreen mode

Step 5: Security Group Check

Lambda ENI Security Group (outbound):

Allow all outbound traffic ✓
Enter fullscreen mode Exit fullscreen mode

RDS Security Group (inbound):

Allow TCP 5432 from 10.0.2.0/24 (Lambda subnet) ✓
Enter fullscreen mode Exit fullscreen mode

Packet allowed through.

Step 6: RDS Processes Query

RDS receives connection:

  1. Authenticates user
  2. Executes query
  3. Returns encrypted patient records
  4. Logs access (HIPAA compliance)

Step 7: Response Path

RDS (10.0.3.100) → Lambda (10.0.2.50) → 
API Gateway → Internet → Patient App
Enter fullscreen mode Exit fullscreen mode

All within VPC uses internal routing.

All encrypted in transit (TLS).

All access logged (CloudTrail).

HIPAA Considerations:

  1. Encryption in transit: TLS everywhere
  2. Encryption at rest: RDS encryption enabled
  3. Network isolation: RDS in private subnet (no internet)
  4. Access control: Security Groups restrict access
  5. Audit logging: CloudTrail + VPC Flow Logs
  6. Data protection: PHI never leaves VPC unencrypted

This architecture meets HIPAA technical safeguards.

Troubleshooting Framework

When connectivity fails, debug layer by layer.

Problem: "Cannot connect to EC2 instance"

Layer 1: Physical connectivity

$ ping 8.8.8.8
Enter fullscreen mode Exit fullscreen mode

If fails: Check network cable, Wi-Fi connection.
If succeeds: Layer 1 works. Move to Layer 2.

Layer 2: Local network

$ arp -a | grep 192.168.1.1
Enter fullscreen mode Exit fullscreen mode

Can you see gateway MAC?
If no: ARP issue or gateway down.
If yes: Layer 2 works. Move to Layer 3.

Layer 3: IP routing

$ ping 192.168.1.1
Enter fullscreen mode Exit fullscreen mode

Can you ping gateway?
If no: Gateway unreachable.
If yes: Gateway works.

$ ping 52.94.133.131
Enter fullscreen mode Exit fullscreen mode

Can you ping AWS?
If no: Internet routing issue.
If yes: Layer 3 works. Move to Layer 4.

Layer 4: Ports and protocols

$ telnet 52.94.133.131 443
Enter fullscreen mode Exit fullscreen mode

or

$ nc -zv 52.94.133.131 443
Enter fullscreen mode Exit fullscreen mode

Can you connect to port 443?
If no: Port blocked (firewall, security group).
If yes: Layer 4 works. Move to Layer 7.

Layer 7: Application

$ curl -v https://ec2.us-east-1.amazonaws.com
Enter fullscreen mode Exit fullscreen mode

Does HTTPS work?
If no: Certificate issue, application down.
If yes: Layer 7 works.

AWS-Specific Checks:

Check 1: Security Groups

$ aws ec2 describe-security-groups --group-ids sg-xxxxx
Enter fullscreen mode Exit fullscreen mode

Verify:

  • Inbound rules allow your IP
  • Outbound rules allow destination

Check 2: Network ACLs

$ aws ec2 describe-network-acls --network-acl-ids acl-xxxxx
Enter fullscreen mode Exit fullscreen mode

Verify:

  • Inbound rules allow traffic
  • Outbound rules allow responses
  • Stateless (must allow both directions)

Check 3: Route Tables

$ aws ec2 describe-route-tables --filters "Name=vpc-id,Values=vpc-xxxxx"
Enter fullscreen mode Exit fullscreen mode

Verify:

  • Local route exists (10.0.0.0/16 → local)
  • Internet route exists (0.0.0.0/0 → igw-xxxxx)
  • Subnet associations correct

Check 4: Internet Gateway

$ aws ec2 describe-internet-gateways --filters "Name=attachment.vpc-id,Values=vpc-xxxxx"
Enter fullscreen mode Exit fullscreen mode

Verify:

  • IGW exists
  • IGW attached to VPC
  • State: available

Check 5: Instance Status

$ aws ec2 describe-instance-status --instance-ids i-xxxxx
Enter fullscreen mode Exit fullscreen mode

Verify:

  • Instance running
  • Status checks passing
  • System reachability OK

Check 6: VPC Flow Logs

$ aws ec2 describe-flow-logs --filter "Name=resource-id,Values=eni-xxxxx"
Enter fullscreen mode Exit fullscreen mode

Review logs for:

  • ACCEPT vs REJECT
  • Which security group/NACL blocked
  • Source and destination IPs

Python Debugging Script:

import boto3
import socket

def debug_connectivity(instance_id, region='us-east-1'):
    """Debug EC2 instance connectivity"""

    ec2 = boto3.client('ec2', region_name=region)

    # Get instance details
    response = ec2.describe_instances(InstanceIds=[instance_id])
    instance = response['Reservations'][0]['Instances'][0]

    private_ip = instance.get('PrivateIpAddress')
    public_ip = instance.get('PublicIpAddress')
    state = instance['State']['Name']
    subnet_id = instance['SubnetId']
    vpc_id = instance['VpcId']
    security_groups = instance['SecurityGroups']

    print(f"Instance: {instance_id}")
    print(f"State: {state}")
    print(f"Private IP: {private_ip}")
    print(f"Public IP: {public_ip}")
    print(f"VPC: {vpc_id}")
    print(f"Subnet: {subnet_id}")
    print(f"\nSecurity Groups:")

    for sg in security_groups:
        sg_id = sg['GroupId']
        print(f"  {sg_id}")

        # Get security group rules
        sg_details = ec2.describe_security_groups(GroupIds=[sg_id])

        print("  Inbound Rules:")
        for rule in sg_details['SecurityGroups'][0]['IpPermissions']:
            protocol = rule.get('IpProtocol', 'all')
            from_port = rule.get('FromPort', 'all')
            to_port = rule.get('ToPort', 'all')

            print(f"    {protocol} {from_port}-{to_port}")

            for ip_range in rule.get('IpRanges', []):
                print(f"      from {ip_range['CidrIp']}")

    # Check route table
    print(f"\nRoute Table for subnet {subnet_id}:")

    route_tables = ec2.describe_route_tables(
        Filters=[
            {'Name': 'association.subnet-id', 'Values': [subnet_id]}
        ]
    )

    if route_tables['RouteTables']:
        for route in route_tables['RouteTables'][0]['Routes']:
            dest = route.get('DestinationCidrBlock', 'N/A')
            target = route.get('GatewayId', 
                              route.get('NatGatewayId', 
                              route.get('NetworkInterfaceId', 'local')))
            print(f"  {dest} → {target}")

    # Test connectivity if public IP exists
    if public_ip:
        print(f"\nTesting connectivity to {public_ip}...")

        # Try ping (ICMP)
        import subprocess
        result = subprocess.run(
            ['ping', '-c', '1', '-W', '1', public_ip],
            capture_output=True
        )

        if result.returncode == 0:
            print("  ✓ ICMP (ping) successful")
        else:
            print("  ✗ ICMP (ping) failed")

        # Try TCP port 22 (SSH)
        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        sock.settimeout(2)
        result = sock.connect_ex((public_ip, 22))

        if result == 0:
            print("  ✓ TCP port 22 (SSH) open")
        else:
            print("  ✗ TCP port 22 (SSH) closed/filtered")

        sock.close()

# Usage
debug_connectivity('i-1234567890abcdef0')
Enter fullscreen mode Exit fullscreen mode

This script checks every common issue.

Key Takeaways

Complete data flow requires:

  1. DNS resolution (name to IP)
  2. ARP resolution (IP to MAC for each hop)
  3. Routing decisions (at every router)
  4. Security checks (security groups, NACLs)
  5. Protocol handshakes (TCP, TLS)
  6. Application processing (HTTP request/response)

Every AWS API call involves:

  • 50-100 packets
  • 20+ router hops
  • All 7 OSI layers
  • Multiple protocols (DNS, TCP, TLS, HTTP)
  • NAT translation
  • Load balancer routing

The three tables work together:

  • MAC Address Table: Switches forward within networks
  • ARP Table: Resolve next hop IPs to MACs
  • Routing Table: Determine packet paths

For HIPAA compliance:

  • Encrypt data in transit (TLS)
  • Encrypt data at rest (KMS)
  • Isolate databases (private subnets)
  • Control access (security groups)
  • Log everything (CloudTrail, VPC Flow Logs)

What You Have Learned

Congratulations. You completed the series.

Part 1: OSI Model

  • 7 layers, 7 solutions
  • Why each layer matters for AWS

Part 2: Switches and Routers

  • How devices forward data
  • MAC tables, ARP tables, routing tables
  • AWS VPC Route Tables

Part 3: IP Addresses and Protocols

  • IP addressing and subnetting
  • Essential protocols (ARP, DNS, DHCP, HTTP)
  • The four settings every host needs

Part 4: Complete Data Flow

  • End-to-end packet journey
  • Every protocol in action
  • Real troubleshooting framework
  • Healthcare example with HIPAA

You now understand networking at a fundamental level.

You can:

  • Design VPC architectures properly
  • Troubleshoot connectivity issues systematically
  • Explain what happens when code runs
  • Make informed decisions about security and routing

This knowledge transfers to any cloud provider and any networking scenario.

What Comes Next

You have the fundamentals. Now go deeper:

Advanced Topics:

  • VPN and Direct Connect
  • Transit Gateway architectures
  • VPC peering and PrivateLink
  • Network performance optimization
  • Advanced security (WAF, Shield)

AWS Certifications:

  • Solutions Architect Associate
  • Advanced Networking Specialty
  • Security Specialty

Practical Projects:

  • Build multi-tier application in VPC
  • Implement hybrid cloud connectivity
  • Design disaster recovery architecture
  • Deploy microservices with service mesh

Keep learning. Keep building. Keep asking questions.

Your Turn

You made it through all four parts.

What is your biggest takeaway?

What networking concept finally clicked?

What will you build with this knowledge?

Drop a comment. I want to hear your story.

This series:

Thank you for following along on this journey.

Follow me for more AWS content, healthcare technology insights, and learning in public.

Resources

AWS Documentation:

Networking Tools:

  • Wireshark - Packet capture and analysis
  • tcpdump - Command-line packet analyzer
  • MTR - Network diagnostic tool

HIPAA Resources:

Practice:

Stella Achar Oiro is a software developer with clinical healthcare experience, currently studying for AWS certifications while building HIPAA-compliant cloud infrastructure. She shares her learning journey to help other developers transition to cloud engineering.

This is Part 4 (finale) of a 4-part series on Networking Fundamentals for Cloud Engineers.

Thank you for reading the complete series. Your engagement and questions made this journey worthwhile.

Top comments (0)