Networking in AWS: Complete Guide to VPC, Subnets, Security Groups, and More

When I started working with AWS five years ago, networking was the most confusing part for me. Terms like VPC, subnets, and security groups seemed overwhelming. After managing dozens of AWS environments, I want to share what I learned in simple terms.

This guide covers everything you need to know about AWS networking, with practical examples from my experience as a cloud DevOps engineer.

What is AWS VPC and Why Do You Need It?

Think of AWS VPC (Virtual Private Cloud) as your own private network in the cloud. Just like you have a private network at home or office, VPC gives you complete control over your cloud networking environment.

Why Use VPC?

When I first deployed applications directly in AWS default network, I quickly learned why VPC is essential:

• Security: Complete control over who can access your resources
• Isolation: Your network is separate from other AWS customers
• Customization: Design network topology based on your needs
• Compliance: Meet regulatory requirements for network isolation

Real-World VPC Example

Let me show you a VPC setup I created for a client's e-commerce platform:

VPC CIDR: 10.0.0.0/16
- Can hold 65,536 IP addresses
- Spans multiple Availability Zones
- Hosts web servers, databases, and internal services

When to Create New VPC vs Using Default

Create New VPC When:

• Production workloads
• Need custom IP ranges
• Require strict security controls
• Multiple environments (dev, staging, prod)

Use Default VPC When:

• Learning AWS
• Simple testing
• Quick prototypes
• Single-instance applications

Understanding IP Addresses in AWS

IP addresses in AWS work differently than traditional networks. Here's what I learned managing hundreds of instances.

Private vs Public IP Addresses

Private IP Addresses:

• Used for internal communication within VPC
• Never change during instance lifetime
• Free to use
• Examples: 10.0.1.5, 192.168.1.10, 172.16.1.20

Public IP Addresses:

• Used for internet communication
• Can change when instance stops/starts
• Costs money for unused addresses
• Example: 54.123.45.67

Elastic IP Addresses - When and Why

I use Elastic IPs when I need:

• Fixed public IP for DNS records
• Quick failover between instances
• Load balancer configurations

Important: AWS charges for unused Elastic IPs. I learned this the hard way when my AWS bill jumped $50 one month from forgotten addresses.

Understanding CIDR Notation

Before planning IP addresses, you need to understand CIDR (Classless Inter-Domain Routing). This confused me for months when I started with AWS.

What is CIDR? CIDR tells you how many IP addresses are available in a network block. The number after the slash (/) indicates how many bits are used for the network portion.

CIDR Calculation Made Simple:

IP Address: 10.0.0.0/16
- /16 means first 16 bits are for network
- Remaining 32-16 = 16 bits for hosts
- 2^16 = 65,536 total addresses
- Usable: 65,536 - 5 = 65,531 (AWS reserves 5)

Common CIDR Blocks in AWS:

/16 = 65,536 addresses (VPC maximum size)
/17 = 32,768 addresses
/18 = 16,384 addresses
/19 = 8,192 addresses
/20 = 4,096 addresses
/21 = 2,048 addresses
/22 = 1,024 addresses
/23 = 512 addresses
/24 = 256 addresses (most common for subnets)
/25 = 128 addresses
/26 = 64 addresses
/27 = 32 addresses (minimum subnet size)
/28 = 16 addresses (not recommended)

Quick CIDR Calculation Formula:

• Available IPs = 2^(32 - CIDR number)
• For /24: 2^(32-24) = 2^8 = 256 addresses
• For /16: 2^(32-16) = 2^16 = 65,536 addresses

Real-World CIDR Planning Example:

I was tasked with designing a network for a company with 3 environments:

Company Network: 10.0.0.0/16 (65,536 total IPs)

Production Environment: 10.0.0.0/18 (16,384 IPs)
├── Public Subnets:
│   ├── AZ-1a: 10.0.0.0/24 (256 IPs)
│   └── AZ-1b: 10.0.1.0/24 (256 IPs)
├── Private Subnets:
│   ├── AZ-1a: 10.0.10.0/24 (256 IPs)
│   └── AZ-1b: 10.0.11.0/24 (256 IPs)
└── Database Subnets:
    ├── AZ-1a: 10.0.20.0/24 (256 IPs)
    └── AZ-1b: 10.0.21.0/24 (256 IPs)

Staging Environment: 10.0.64.0/18 (16,384 IPs)
├── Subnets: 10.0.64.0/24, 10.0.65.0/24, etc.

Development Environment: 10.0.128.0/18 (16,384 IPs)
├── Subnets: 10.0.128.0/24, 10.0.129.0/24, etc.

Reserved for Future: 10.0.192.0/18 (16,384 IPs)

CIDR Overlap Prevention:

The biggest mistake I see is creating overlapping CIDR blocks:

❌ Wrong:
VPC-1: 10.0.0.0/16
VPC-2: 10.0.100.0/16  (Overlaps!)

✅ Correct:
VPC-1: 10.0.0.0/16    (10.0.0.0 - 10.0.255.255)
VPC-2: 10.1.0.0/16    (10.1.0.0 - 10.1.255.255)

Subnet Sizing Guidelines:

Based on my experience with different workloads:

Small Web App: /27 (32 IPs) - 1-2 instances
Medium App: /24 (256 IPs) - 10-50 instances
Large App: /22 (1024 IPs) - 100+ instances
Database Subnet: /24 (256 IPs) - Usually sufficient
Load Balancer Subnet: /24 (256 IPs) - Standard size

Practical CIDR Subnetting Challenge:

Let me share a real scenario from my work. I needed to create subnets for a microservices architecture:

Given VPC: 10.0.0.0/16 (65,536 IPs available)
Requirements:
- 4 Availability Zones
- 3 Tiers per AZ (Public, Private, Database)
- Room for future growth

Solution:
AZ-1a Subnets:
├── Public:    10.0.0.0/24  (256 IPs)
├── Private:   10.0.1.0/24  (256 IPs)
└── Database:  10.0.2.0/24  (256 IPs)

AZ-1b Subnets:
├── Public:    10.0.10.0/24  (256 IPs)
├── Private:   10.0.11.0/24  (256 IPs)
└── Database:  10.0.12.0/24  (256 IPs)

AZ-1c Subnets:
├── Public:    10.0.20.0/24  (256 IPs)
├── Private:   10.0.21.0/24  (256 IPs)
└── Database:  10.0.22.0/24  (256 IPs)

AZ-1d Subnets:
├── Public:    10.0.30.0/24  (256 IPs)
├── Private:   10.0.31.0/24  (256 IPs)
└── Database:  10.0.32.0/24  (256 IPs)

Reserved: 10.0.40.0/21 (2,048 IPs for future use)

CIDR Mistakes I Made (Learn from them):

1. Too Small Subnets: Started with /28 (16 IPs), ran out quickly
2. No Future Planning: Used consecutive /24s, couldn't expand later
3. Overlapping Ranges: Created 10.0.0.0/16 and 10.0.50.0/16 (overlap!)
4. Wrong VPC Peering: Different VPCs with same CIDR blocks

CIDR Best Practices from 3+ Years:

1. Always start with /16 VPC (max flexibility)
2. Use /24 subnets as standard (256 IPs each)
3. Leave gaps between subnets for expansion
4. Document your IP plan before creating anything
5. Use IP calculators for complex scenarios

IP Address Planning Strategy

Here's how I plan IP addresses for projects:

Production VPC: 10.0.0.0/16
├── Public Subnet: 10.0.1.0/24 (256 addresses)
├── Private Subnet: 10.0.2.0/24 (256 addresses)
├── Database Subnet: 10.0.3.0/24 (256 addresses)
└── Reserved: 10.0.4.0/22 (1024 addresses for future)

AWS Subnets Explained Simply

Subnets are like rooms in your VPC house. Each room serves a specific purpose and has its own security rules.

Public vs Private Subnets

Public Subnets:

• Have internet gateway route (0.0.0.0/0)
• Resources get public IP addresses
• Used for load balancers, web servers
• Direct internet access

Private Subnets:

• No direct internet route
• Resources only get private IP addresses
• Used for application servers, databases
• Access internet through NAT Gateway

Subnet Planning Best Practices

From my experience, here's how I design subnets:

Multi-Tier Architecture Example

Web Tier (Public Subnets):
- us-east-1a: 10.0.1.0/24
- us-east-1b: 10.0.2.0/24

Application Tier (Private Subnets):
- us-east-1a: 10.0.11.0/24
- us-east-1b: 10.0.12.0/24

Database Tier (Private Subnets):
- us-east-1a: 10.0.21.0/24
- us-east-1b: 10.0.22.0/24

Subnet Size Calculation

I use this formula to determine subnet sizes:

• /24 subnet = 256 addresses (251 usable)
• /25 subnet = 128 addresses (123 usable)
• /26 subnet = 64 addresses (59 usable)
• /27 subnet = 32 addresses (27 usable)

Why fewer usable addresses? AWS reserves 5 IP addresses in each subnet:

• First address: Network address
• Second address: VPC router
• Third address: DNS server
• Fourth address: Future use
• Last address: Broadcast address

NAT Gateway: Internet Access for Private Resources

NAT Gateway allows resources in private subnets to access the internet while remaining private. I use this for software updates, API calls, and downloading packages.

How NAT Gateway Works

Think of NAT Gateway as a one-way door:

• Private resources can reach internet
• Internet cannot directly reach private resources
• All outbound traffic appears to come from NAT Gateway IP

NAT Gateway vs NAT Instance

I've used both options. Here's my comparison:

NAT Gateway (Recommended):

• Managed by AWS
• High availability within AZ
• No maintenance required
• Scales automatically
• Higher cost but worth it

NAT Instance:

• EC2 instance you manage
• Single point of failure
• Requires maintenance and updates
• Lower cost but more work

Real-World NAT Gateway Setup

Here's how I typically configure NAT Gateway:

# Create NAT Gateway in public subnet
aws ec2 create-nat-gateway \
  --subnet-id subnet-12345678 \
  --allocation-id eipalloc-12345678

# Update private subnet route table
aws ec2 create-route \
  --route-table-id rtb-12345678 \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id nat-12345678

NAT Gateway Cost Optimization

NAT Gateway can be expensive. Here's how I reduce costs:

• Use single NAT Gateway for development environments
• Consider NAT Instance for cost-sensitive workloads
• Monitor data transfer charges
• Use VPC endpoints for AWS services when possible

Network Access Control Lists (NACLs)

NACLs are subnet-level firewalls. They're like security guards at building entrances - they check every person (packet) coming in and going out.

How NACLs Work

NACLs operate at the subnet level and are:

• Stateless: Must configure inbound AND outbound rules
• Rule-based: Rules processed in numerical order
• Default deny: Explicit allow rules required

NACL vs Security Groups

I often get asked about the difference:

Network ACLs:

• Subnet level
• Stateless (inbound + outbound rules needed)
• Rule numbers determine order
• First match wins
• Default deny

Security Groups:

• Instance level
• Stateful (outbound automatic for inbound)
• All rules evaluated
• Default deny inbound, allow outbound

NACL Rules Example

Here's a typical NACL configuration I use:

Inbound Rules:
Rule 100: HTTP (80) from 0.0.0.0/0 - ALLOW
Rule 110: HTTPS (443) from 0.0.0.0/0 - ALLOW
Rule 120: SSH (22) from 10.0.0.0/16 - ALLOW
Rule 130: Ephemeral Ports (1024-65535) from 0.0.0.0/0 - ALLOW
Rule 32767: ALL Traffic - DENY

Outbound Rules:
Rule 100: HTTP (80) to 0.0.0.0/0 - ALLOW
Rule 110: HTTPS (443) to 0.0.0.0/0 - ALLOW
Rule 120: Ephemeral Ports (1024-65535) to 0.0.0.0/0 - ALLOW
Rule 32767: ALL Traffic - DENY

When to Use Custom NACLs

I create custom NACLs when:

• Need subnet-level security controls
• Compliance requires network segmentation
• Want additional security layer
• Blocking specific IP ranges or ports

Most of the time, default NACL with security groups is sufficient.

Security Groups: Your Virtual Firewall

Security groups are instance-level firewalls. I think of them as personal bodyguards for each EC2 instance.

Security Group Fundamentals

Key characteristics:

• Stateful: Outbound traffic automatically allowed for inbound connections
• Instance level: Applied to network interfaces
• Default deny: Only explicitly allowed traffic permitted
• Multiple groups: Can assign multiple security groups to one instance

Security Group Design Patterns

Over the years, I've developed these patterns:

Web Tier Security Group

Inbound:
- Port 80 (HTTP) from 0.0.0.0/0
- Port 443 (HTTPS) from 0.0.0.0/0
- Port 22 (SSH) from bastion security group

Outbound:
- All traffic (default)

Application Tier Security Group

Inbound:
- Port 8080 from web tier security group
- Port 22 (SSH) from bastion security group

Outbound:
- Port 3306 (MySQL) to database security group
- Port 443 (HTTPS) to 0.0.0.0/0 (for APIs)

Database Tier Security Group

Inbound:
- Port 3306 (MySQL) from application security group
- Port 22 (SSH) from bastion security group

Outbound:
- Port 443 (HTTPS) to 0.0.0.0/0 (for updates)

Security Group Best Practices

From managing production environments:

1. Use descriptive names: web-tier-sg, app-tier-sg, db-tier-sg
2. Reference other security groups: Instead of IP addresses
3. Principle of least privilege: Only allow necessary ports
4. Regular audits: Review and remove unused rules
5. Document rules: Add descriptions for complex rules

Common Security Group Mistakes

I've seen (and made) these mistakes:

• Opening port 22 to 0.0.0.0/0: Use bastion hosts instead
• Using 0.0.0.0/0 for database access: Reference application security groups
• Not updating rules: Remove access when no longer needed
• Complex rule sets: Keep it simple and documented

VPC Components Working Together

Let me show you how all these components work together with a real example from a project I managed.

E-commerce Platform Architecture

Internet Gateway
       |
   Load Balancer (Public Subnet)
       |
   Web Servers (Private Subnet)
       |
   Application Servers (Private Subnet)
       |
   Database (Private Subnet)
       |
   NAT Gateway (for updates)

Traffic Flow Example

User accessing website:

1. User request arrives at Internet Gateway
2. Load Balancer in public subnet receives traffic
3. Security Group checks if port 443 allowed
4. NACL verifies subnet-level access
5. Load Balancer forwards to web server in private subnet
6. Web server processes request, may call application server
7. Application server queries database if needed
8. Response flows back through same path

Configuration Files

Here's how I configure this setup using CloudFormation:

# VPC Configuration
VPC:
  Type: AWS::EC2::VPC
  Properties:
    CidrBlock: 10.0.0.0/16
    EnableDnsHostnames: true
    EnableDnsSupport: true

# Public Subnet
PublicSubnet:
  Type: AWS::EC2::Subnet
  Properties:
    VpcId: !Ref VPC
    CidrBlock: 10.0.1.0/24
    MapPublicIpOnLaunch: true

# Private Subnet
PrivateSubnet:
  Type: AWS::EC2::Subnet
  Properties:
    VpcId: !Ref VPC
    CidrBlock: 10.0.2.0/24
    MapPublicIpOnLaunch: false

# Internet Gateway
InternetGateway:
  Type: AWS::EC2::InternetGateway

# NAT Gateway
NATGateway:
  Type: AWS::EC2::NatGateway
  Properties:
    AllocationId: !GetAtt EIPForNAT.AllocationId
    SubnetId: !Ref PublicSubnet

Troubleshooting Network Issues

I've spent countless hours troubleshooting network problems. Here are the most common issues and solutions.

Cannot Connect to Instance

Check List:

1. Security group allows the port
2. NACL allows the traffic
3. Route table has correct routes
4. Instance has public IP (for internet access)
5. Internet gateway attached to VPC

Debug Commands:

# Check security groups
aws ec2 describe-security-groups --group-ids sg-12345678

# Check route tables
aws ec2 describe-route-tables --route-table-ids rtb-12345678

# Test connectivity
telnet instance-ip port-number

Private Instance Cannot Reach Internet

Common Causes:

• No NAT Gateway in route table
• NAT Gateway in wrong subnet
• Security group blocking outbound traffic
• No Elastic IP on NAT Gateway

Solution Steps:

1. Verify NAT Gateway exists and has Elastic IP
2. Check private subnet route table has NAT Gateway route
3. Verify security groups allow outbound traffic
4. Test with simple curl command

High NAT Gateway Costs

Cost Reduction Strategies:

• Use VPC endpoints for AWS services
• Consolidate NAT Gateways across environments
• Monitor data transfer patterns
• Consider NAT instance for non-critical workloads

Advanced Networking Concepts

After mastering the basics, here are advanced concepts I use in complex environments.

VPC Peering

Connects two VPCs to communicate as if they're in the same network.

When I Use VPC Peering:

• Connecting production and shared services VPC
• Cross-account resource access
• Multi-region applications

Limitations to Remember:

• No transitive routing
• CIDR blocks cannot overlap
• Cross-region peering available but limited

VPC Endpoints

Direct connection to AWS services without internet gateway.

Types I Use:

Gateway Endpoints (S3, DynamoDB):

# Create S3 VPC endpoint
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-12345678 \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-12345678

Interface Endpoints (EC2, Lambda, etc):

# Create EC2 VPC endpoint
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-12345678 \
  --service-name com.amazonaws.us-east-1.ec2 \
  --subnet-ids subnet-12345678

Transit Gateway

Connects multiple VPCs and on-premises networks through a central hub.

When I Recommend Transit Gateway:

• More than 3-4 VPCs to connect
• Complex routing requirements
• Hybrid cloud connectivity
• Centralized network management

Monitoring and Logging

Network monitoring is crucial for troubleshooting and security.

VPC Flow Logs

Captures IP traffic information for network interfaces.

# Enable VPC Flow Logs
aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-12345678 \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name VPCFlowLogs

CloudWatch Metrics

Key metrics I monitor:

• NAT Gateway: BytesInFromSource, BytesOutToDestination
• VPC: PacketsDropped, NetworkPacketsIn/Out
• Security Groups: Connection tracking

Network Monitoring Tools

AWS Native Tools:

• VPC Flow Logs
• CloudWatch
• AWS Config
• GuardDuty

Third-Party Tools:

• Datadog Network Monitoring
• New Relic Infrastructure
• Splunk Network Monitoring

Cost Optimization Strategies

Networking can be expensive. Here's how I optimize costs:

Data Transfer Costs

Expensive:

• Cross-AZ data transfer
• NAT Gateway data processing
• Inter-region transfer

Cost Reduction:

• Keep related resources in same AZ when possible
• Use VPC endpoints for AWS services
• Compress data transfers
• Monitor transfer patterns

NAT Gateway Optimization

Strategies:

• Single NAT Gateway for development
• Schedule NAT Gateway for non-production
• Use NAT instance for cost-sensitive workloads
• VPC endpoints instead of internet routing

IP Address Management

Best Practices:

• Release unused Elastic IPs immediately
• Use auto-assigned public IPs when possible
• Plan subnet sizes carefully
• Regular IP address audits

Security Best Practices

Network security is critical. Here's my security checklist:

Defense in Depth

Multiple Security Layers:

1. Network ACLs (subnet level)
2. Security Groups (instance level)
3. Host-based firewalls
4. Application-level security

Principle of Least Privilege

Access Rules:

• Only allow necessary ports
• Use specific IP ranges when possible
• Reference security groups instead of IP addresses
• Regular access reviews

Monitoring and Alerting

Security Monitoring:

• VPC Flow Logs analysis
• GuardDuty for threat detection
• CloudTrail for API calls
• Config for compliance

Network Segmentation

Isolation Strategies:

• Separate subnets for different tiers
• Dedicated VPCs for environments
• Limited cross-subnet communication
• Bastion hosts for administrative access

Real-World Implementation Guide

Let me walk you through implementing a complete network setup.

Step 1: Plan Your Network

Requirements Gathering:

• How many environments? (dev, staging, prod)
• Expected traffic patterns?
• Compliance requirements?
• High availability needs?
• Cost constraints?

Step 2: Design Network Architecture

Example Three-Tier Design:

Production VPC: 10.0.0.0/16

Public Subnets (Load Balancers):
- AZ-1a: 10.0.1.0/24
- AZ-1b: 10.0.2.0/24

Private Subnets (Application):
- AZ-1a: 10.0.11.0/24
- AZ-1b: 10.0.12.0/24

Database Subnets:
- AZ-1a: 10.0.21.0/24
- AZ-1b: 10.0.22.0/24

Step 3: Implement Infrastructure

Using Terraform:

# VPC
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name = "production-vpc"
  }
}

# Public Subnet
resource "aws_subnet" "public" {
  count             = 2
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.${count.index + 1}.0/24"
  availability_zone = data.aws_availability_zones.available.names[count.index]

  map_public_ip_on_launch = true

  tags = {
    Name = "public-subnet-${count.index + 1}"
  }
}

Step 4: Configure Security

Security Group Creation:

resource "aws_security_group" "web" {
  name        = "web-tier-sg"
  description = "Security group for web tier"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Step 5: Test and Validate

Testing Checklist:

• Instances can communicate within VPC
• Public instances have internet access
• Private instances reach internet via NAT
• Security groups block unauthorized access
• DNS resolution works correctly
• Cross-AZ communication functions

Common Mistakes and How to Avoid Them

After five years of AWS networking, here are mistakes I see repeatedly:

Subnet Sizing Errors

Mistake: Creating subnets too small or too large Solution: Plan for 50% growth, use /24 for most subnets

Security Group Complexity

Mistake: Overly complex security group rules Solution: Keep rules simple, use descriptive names, reference other security groups

No Network Documentation

Mistake: Not documenting network design Solution: Maintain network diagrams, document IP ranges, create runbooks

Cost Surprises

Mistake: Unexpected NAT Gateway or data transfer costs Solution: Monitor costs regularly, use VPC endpoints, optimize data flows

Single Points of Failure

Mistake: Single NAT Gateway for critical workloads
Solution: Deploy NAT Gateways in multiple AZs for high availability

Tools and Resources I Recommend

AWS Tools

• VPC Console: Visual network design
• CloudFormation: Infrastructure as code
• AWS CLI: Command-line management
• AWS Config: Compliance monitoring

Third-Party Tools

• Terraform: Infrastructure automation
• Ansible: Configuration management
• Datadog: Network monitoring
• Lucidchart: Network diagrams

Learning Resources

• AWS Documentation: Always start here
• AWS Well-Architected: Network design best practices
• YouTube: AWS re:Invent sessions
• Hands-on Labs: Nothing beats practical experience

Conclusion

AWS networking might seem complex at first, but understanding these core components makes everything clearer:

• VPC: Your private cloud network
• Subnets: Network segments with specific purposes
• Security Groups: Instance-level firewalls
• NACLs: Subnet-level firewalls
• NAT Gateway: Internet access for private resources
• Route Tables: Traffic direction rules

Start with simple designs and gradually add complexity as needed. Focus on security, monitor costs, and document everything.

The key is hands-on practice. Create test environments, break things, fix them, and learn from mistakes. That's how I became comfortable with AWS networking.

Remember: Good network design is invisible to users but critical for security, performance, and cost optimization.

References and Further Reading

1. AWS VPC User Guide - Official AWS VPC documentation
2. AWS Well-Architected Network Pillar - Best practices for network design
3. VPC Flow Logs User Guide - Network monitoring and troubleshooting
4. AWS Security Groups Documentation - Security group configuration
5. NAT Gateway Documentation - NAT Gateway setup and management
6. AWS Networking Best Practices - Architecture guidance
7. VPC Peering Guide - Connecting VPCs
8. AWS Transit Gateway - Advanced network connectivity
9. VPC Endpoints User Guide - Private connections to AWS services
10. AWS CloudFormation VPC Templates - Infrastructure as code examples

Let's connect on LinkedIn to discuss AWS networking challenges and share experiences.