AWS Cloud Path Week 13: AWS Networking Workshop Part 3 - Security Controls Deep Dive

Welcome back to our AWS Cloud Path journey! In Week 13, we're diving deep into Part 3 of the AWS Networking Workshop, focusing on advanced security controls that form the foundation of secure cloud networking.

Missed the session? Catch up here:

Prerequisites

Before jumping into this session, ensure you have:

• An AWS account with appropriate permissions
• Basic understanding of VPCs, subnets, and security groups
• Completion of the previous networking workshop sessions (Parts 1 & 2)
• The AWS CloudFormation template deployed from the official workshop

What We're Covering Today

This session focuses on three critical foundational security topics:

1. Network Access Control Lists (NACLs) - Subnet-level security
2. Security Groups - Instance-level security
3. VPC Endpoint Policies - Controlling access to AWS services

Understanding the Architecture

We're working with a multi-VPC setup consisting of:

• VPC A: IP range 10.0.0.0/16
• VPC B: IP range 10.1.0.0/16
• VPC C: IP range 10.2.0.0/16

Each VPC contains:

• Two availability zones
• Public and private subnets in each AZ
• Internet Gateway
• NAT Gateway in public subnets
• EC2 instances for testing

Network Access Control Lists (NACLs) vs Security Groups

One of the most frequently asked questions in AWS networking is: "Why do I need both NACLs and Security Groups?" Let's break down the key differences:

Network Access Control Lists (NACLs)

Key Characteristics:

• Stateless: You must explicitly define both inbound AND outbound rules
• Subnet-level: Applied to entire subnets, affecting all resources within
• Rule numbering: Rules are processed in numerical order (100, 200, etc.)
• Explicit deny capability: Can create explicit deny rules
• Default behavior: Default NACL allows all traffic; custom NACLs deny all by default

Example NACL Configuration:

Rule #100: Allow ICMP from 10.1.0.0/16 (VPC B traffic)
Rule #32767: Deny all (implicit)

Security Groups

Key Characteristics:

• Stateful: If you allow inbound traffic, the response is automatically allowed outbound
• Instance-level: Applied to specific EC2 instances or resources
• Most specific match: Processes the most specific rule that matches
• Allow-only rules: Cannot create explicit deny rules (default deny)
• Default behavior: Deny all inbound, allow all outbound

Working Together: Layered Security

The power comes from using both together:

1. NACL: Controls traffic at the subnet boundary
2. Security Group: Provides granular, resource-specific control

For example:

• NACL allows traffic from VPC B and VPC C to enter the subnet
• Security Group on a specific server only allows ICMP traffic from VPC C
• Result: VPC B traffic reaches the subnet but is blocked at the instance level

Hands-On: Configuring Network Access Control Lists

Step 1: Locate Your NACL

Navigate to VPC → Security → Network ACLs, then find "VPC A workload subnet NACL".

Step 2: Modify Inbound Rules

Update Rule #100 to:

• Type: All ICMP - IPv4
• Protocol: ICMP
• Port Range: All
• Source: 10.1.0.0/16 (VPC B CIDR block)
• Allow/Deny: ALLOW

This configuration allows ICMP (ping) traffic only from VPC B, while blocking traffic from VPC C.

Step 3: Testing Connectivity

From VPC B instance:

ping [VPC-A-instance-IP]
# Expected: Success - packets transmitted and received

From VPC C instance:

ping [VPC-A-instance-IP]  
# Expected: 100% packet loss - traffic blocked

Security Groups: Fine-Grained Control

Security Groups provide the second layer of security with more granular control.

Key Configuration Points

1. No rule numbering: AWS automatically handles rule precedence
2. Most specific match wins: Smaller IP ranges take precedence over larger ones
3. Reference other security groups: Can allow traffic from other security groups by ID

Example Security Group Rule

{
  "Type": "ICMP",
  "Protocol": "ICMP", 
  "Port Range": "All",
  "Source": "10.2.0.0/16",  // Only VPC C traffic
  "Description": "Allow ping from VPC C only"
}

VPC Endpoint Policies

VPC Endpoints enable private connectivity to AWS services without traversing the public internet. Endpoint policies control what actions can be performed through these endpoints.

Creating a VPC Endpoint

1. Navigate to VPC → Endpoints → Create Endpoint
2. Select service (e.g., Amazon S3)
3. Choose VPC and route tables
4. Configure endpoint policy

Example Endpoint Policy (Read-Only S3 Access)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadOnlyAccess",
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "s3:Get*",
        "s3:List*"
      ],
      "Resource": "*"
    }
  ]
}

This policy restricts the endpoint to only allow GET and LIST operations on S3, blocking any write operations.

Important Troubleshooting Notes

During the session, we encountered CloudFormation deployment issues related to Elastic IP allocation limits. Here are some common solutions:

CloudFormation Deployment Issues

1. Elastic IP Limits: Release unused Elastic IPs before deployment
2. Resource Conflicts: Check for existing resources with same names
3. Region-Specific Parameters: Ensure availability zones match your deployment region

Best Practices

1. Always use custom NACLs: Don't rely on default NACLs for production
2. Layer your security: Use both NACLs and Security Groups
3. Be specific in Security Groups: Use the most specific IP ranges possible
4. Test thoroughly: Always verify connectivity after configuration changes
5. Clean up resources: Delete CloudFormation stacks when testing is complete

Key Takeaways

1. NACLs are stateless - you need explicit inbound AND outbound rules
2. Security Groups are stateful - return traffic is automatically allowed
3. Use both for layered security - subnet-level and instance-level protection
4. Order matters in NACLs - rules are processed numerically
5. Most specific wins in Security Groups - smaller IP ranges take precedence
6. VPC Endpoints reduce costs and improve security - private AWS service access

Next Steps

In our upcoming sessions, we'll dive into advanced networking topics including:

• Transit Gateway configurations
• VPN connections and hybrid networking
• Network monitoring with CloudWatch and VPC Flow Logs
• Direct Connect implementations

Workshop Resources

• Official Workshop: AWS Networking Workshop
• CloudFormation Templates: Available in the workshop repository
• Architecture Diagrams: Reference the multi-VPC setup diagrams in the workshop

Remember to clean up your resources after testing to avoid unexpected charges. If you deployed via CloudFormation, simply delete the stack to remove all resources.

Join Us Next Week

We'll continue with advanced networking topics in Week 14. If you're having issues with CloudFormation deployment, join 30 minutes early for troubleshooting assistance.

Note on Visual Content: While the session included live demonstrations of AWS console interactions and architecture diagrams, this text-based format provides step-by-step instructions and code examples to guide you through the same processes. Refer to the embedded video above for visual guidance on console navigation and real-time troubleshooting.

Happy networking, and see you next week for more AWS Cloud Path adventures! 🚀