DEV Community: Elizabeth Adeotun Adegbaju

Don't let anyone discourage you from getting certified in a particular field.
Listen to someone who has taken - and passed - that exam at least twice.

Why does that matter?
Because they’ve taken it at different points in their journey - maybe early on, maybe after years of hands-on experience - and can give you a more accurate take on whether that certification truly tests real-world expertise or not.

My Take

I remember the first time I passed the AWS Solutions Architect - Professional exam.
It felt like I had just walked through fire.

It was the toughest exam I had taken at the time, and I didn’t have much production-grade AWS experience (I even had to do a lot of practice labs for some services). I was practically shouting to anyone who would listen:

“I can’t believe I passed that. It was so hard.”

Fast forward to the renewal:

“Yeah, I could write that again tomorrow.”

Because now? I know a lot more than I did three years ago.
Studying felt smooth. Effortless, even.

Do you catch my drift?

If your certification renewal feels just as hard as the first time, the only acceptable reason should be that you’ve barely worked in that domain since. That’s fair. Otherwise, it shouldn’t feel like you're starting from scratch.

Some people downplay certifications. They say it’s just paper.

But I see it differently, especially now.
This renewal wasn’t about proving anything to others.
It was for me.
To validate that I’m still sharp, still growing, and still deeply connected to the work I do.

Have you renewed any cloud certifications recently?
How different did it feel from the first time?
I’d love to hear your experience in the comments.

AWS Cloud Path Week 18: Building a Serverless Coffee Shop Backend

Elizabeth Adeotun Adegbaju — Sun, 03 Aug 2025 20:11:10 +0000

In this session of AWS Cloud Path, we try our hands at building a serverless backend for a coffee shop ordering system using AWS Step Functions, Lambda, DynamoDB, and EventBridge. The system handles order processing, barista notifications, and order status updates in a completely serverless architecture. Check out the workshop here: Serverlesspresso Workshop

Missed the session? Catch up here:

Prerequisites

AWS Account with appropriate permissions
Basic understanding of serverless architecture
Familiarity with AWS services

The Coffee Shop System Overview

The application consists of three front-end components:

Overhead monitor display
Barista application
Customer ordering application

The backend system needs to handle requests from all these front-ends while managing different data payloads for each interface.

Key Features

QR code-based ordering system with limits (10 drinks/5 minutes)
Barista queue management (maximum 20 drinks at a time)
Real-time order status updates
Shop status management (open/closed)

Building the Workflow with AWS Step Functions

1. Initial Setup

The workflow begins by checking two crucial conditions:

If the shop is open
If the barista queue has capacity

We implement this using AWS Step Functions state machine with the following components:

{
  "Comment": "Coffee Shop Order Processing Workflow",
  "StartAt": "CheckShopStatus",
  "States": {
    "CheckShopStatus": {
      "Type": "Task",
      "Resource": "arn:aws:states:::dynamodb:getItem",
      "Parameters": {
        "TableName": "serverless-coffee-config",
        "Key": {
          "pk": {"S": "config"},
          "sk": {"S": "shop"}
        }
      },
      "Next": "IsShopOpen"
    }
    // Additional states follow
  }
}

2. Shop Status Verification

The workflow first queries DynamoDB to check if the shop is open. This is implemented as a choice state that branches based on the shop's status:

If shop is closed: Emit event via EventBridge
If shop is open: Proceed to capacity check

3. Capacity Management

The system checks if the barista queue has capacity by listing current Step Functions executions:

Maximum limit: 20 drinks in queue
Uses Step Functions List Executions API
Implements capacity verification before accepting new orders

4. Order Number Generation

When an order is accepted, we generate a unique order number using DynamoDB:

{
  "TableName": "counting-table",
  "Key": {
    "id": {"S": "orderId"}
  },
  "UpdateExpression": "SET id_value = id_value + :inc",
  "ExpressionAttributeValues": {
    ":inc": {"N": "1"}
  },
  "ReturnValues": "ALL_NEW"
}

5. Event-Driven Communication

The workflow uses EventBridge for event-driven communication:

Order started events
Shop status updates
Order completion notifications
Error handling events

6. Timeout Management

The system implements two crucial timeout scenarios:

Customer timeout: 900 seconds (15 minutes) for order placement
Barista timeout: 900 seconds for order preparation

Each timeout is handled with appropriate error states and event emissions.

Error Handling

The workflow implements comprehensive error handling:

Customer timeouts
Barista timeouts
Shop closure scenarios
Queue capacity issues

Each error case emits specific events that can be handled by other components of the system.

Testing the Workflow

To test callbacks in the workflow:

# For successful completion
aws stepfunctions send-task-success --task-token <TASK_TOKEN> --task-output "{}"

# For failure scenarios
aws stepfunctions send-task-failure --task-token <TASK_TOKEN> --error "Error.Type" --cause "Error description"

Next Steps

In the next session, we'll focus on:

Connecting front-end applications
Testing the complete system

The completed backend will provide a robust foundation for the coffee shop ordering system, handling everything from order placement to completion in a serverless architecture.

Remember to check your AWS free tier status before deploying, as the total cost for these services should be under $1 with free tier benefits.

Happy coding! ☕️

AWS Cloud Path Week 17: How to Configure AWS Client VPN

Elizabeth Adeotun Adegbaju — Sun, 03 Aug 2025 19:15:00 +0000

Welcome to another technical tutorial in the AWS Cloud Path series! In this guide, we'll walk through the process of setting up AWS Client VPN, a fully managed remote access VPN solution that enables secure access to your AWS resources from anywhere.

Missed the session? Catch up here:

Prerequisites

An AWS account with necessary permissions
Basic understanding of VPC and networking concepts

Understanding AWS Client VPN

Before diving into the setup, let's understand what AWS Client VPN is and how it differs from Site-to-Site VPN:

AWS Client VPN is designed for individual remote access from anywhere
Unlike Site-to-Site VPN, it doesn't require a customer gateway or fixed location
It's ideal for remote workers who need secure access to AWS resources
Supports both mutual authentication and user-based authentication methods
Fully elastic and automatically scales based on demand

Architecture Overview

The setup we'll be creating includes:

A VPC with CIDR block 10.0.0.0/16
4 private subnets:
- 2 subnets for RDS databases
- 2 subnets for Client VPN endpoints
Client VPN endpoint with associated Elastic Network Interfaces
Certificate management through AWS Certificate Manager (ACM)

Step-by-Step Configuration

1. Generate and Import Certificates

First, we need to create and import the necessary certificates:

a. Clone the OpenVPN easy-rsa repository:

git clone https://github.com/OpenVPN/easy-rsa.git
cd easy-rsa/easyrsa3
./easyrsa init-pki

b. Generate the server certificate:

./easyrsa build-ca nopass
./easyrsa build-server-full server nopass

c. Import certificates to AWS Certificate Manager (ACM):

Navigate to ACM in the AWS Console
Click "Import Certificate"
Import the certificate body, private key, and certificate chain

2. Create the VPC Infrastructure

Set up your VPC with the following configuration:

CIDR block: 10.0.0.0/16
4 private subnets across 2 availability zones:

  - RDS subnet 1: 10.0.2.0/24
  - RDS subnet 2: 10.0.4.0/24
  - Client VPN subnet 1: 10.0.6.0/24
  - Client VPN subnet 2: 10.0.8.0/24

3. Create Client VPN Endpoint

a. Navigate to VPC → Client VPN Endpoints
b. Click "Create Client VPN Endpoint"
c. Configure the following settings:

- Name tag: AWS-Client-VPN
- Client IPv4 CIDR: Choose an unused CIDR block
- Server certificate: Select the certificate imported to ACM
- Authentication: Choose Mutual Authentication
- Client certificate: Select the client certificate
- Enable split-tunnel routing
- Select your VPC and subnets

4. Configure Security and Routing

a. Associate target networks:

Select the Client VPN subnets
Wait for association to complete

b. Add authorization rules:

Configure network access
Set up routing tables for VPC access

5. Download and Configure Client

a. Download the Client VPN configuration file from the AWS Console
b. Install AWS Client VPN desktop application
c. Import the configuration file
d. Connect using the client certificate

Best Practices and Considerations

Security

Always use strong authentication methods
Regularly rotate certificates
Implement least privilege access

Cost Management

Enable split-tunnel to reduce data transfer costs
Monitor connection usage
Consider connection timeout settings

Performance

Associate endpoints with multiple subnets for high availability
Configure DNS servers appropriately
Monitor connection quality

Troubleshooting Tips

Connection Issues:

Verify certificate validity
Check subnet associations
Confirm security group rules

Access Problems:

Verify authorization rules
Check routing tables
Validate client configuration

Conclusion

AWS Client VPN provides a secure and scalable solution for remote access to your AWS resources. By following this guide, you've learned how to:

Set up certificates for authentication
Create and configure a Client VPN endpoint
Associate networks and configure routing
Set up client access

The setup we've covered provides a foundation for secure remote access to your AWS resources. You can further customize the configuration based on your specific security and access requirements.

Next Steps

Implement user-based authentication with AWS IAM
Set up connection logging and monitoring
Configure additional security features like multi-factor authentication
Integrate with your existing identity provider

Remember to review the AWS Client VPN documentation for detailed information about advanced features and configurations.

AWS Cloud Path Week 16: AWS Networking Workshop Part 6 (Final) -Understanding AWS Gateway Load Balancer

Elizabeth Adeotun Adegbaju — Sun, 03 Aug 2025 18:44:00 +0000

In this hands-on session on AWS networking, we'll explore AWS Gateway Load Balancer (GWLB) and understand its role in managing network traffic and security appliances.

Missed the session? Catch up here:

Prerequisites

An AWS account with administrative access
Basic understanding of AWS VPC and networking concepts
Familiarity with AWS Console navigation

Understanding AWS Gateway Load Balancer

AWS Gateway Load Balancer (GWLB) is a unique type of load balancer specifically designed to help you deploy, scale, and manage your third-party virtual appliances. It's particularly useful when working with security appliances and other network virtual appliances.

Key Characteristics

Network Layer Operation:
- GWLB operates at Layer 3/4 (Layer 3 Gateway + Layer 4 Load Balancing) of the OSI model
- This differs from Application Load Balancer (Layer 7) and Network Load Balancer (Layer 4)
5-Tuple Hash:
GWLB uses a 5-tuple hash to select targets and ensure flow stickiness. The components include:
- Source IP address
- Source port
- Destination IP address
- Destination port
- IP protocol
GENEVE Protocol:
- GWLB uses GENEVE protocol for encapsulating traffic
- This enables the preservation of flow information and additional metadata

VPC Endpoints Integration

A crucial aspect of GWLB is its integration with VPC endpoints:

GWLB creates VPC endpoints (GWLBe) for connectivity
These endpoints allow internal connections without traversing the public internet
You need to configure proper routing to utilize these endpoints effectively

Setting up Gateway Load Balancer

1. Creating the Load Balancer

To create a Gateway Load Balancer:

Navigate to EC2 > Load Balancers
Choose "Create Load Balancer"
Select "Gateway Load Balancer"
Configure basic settings:

   Name: gwlb-firewall (or your preferred name)
   Scheme: IPv4

2. Target Group Configuration

Create a target group for your GWLB:

Type: Instances
Protocol: GENEVE
Port: 6081 (default)

3. VPC Endpoint Service

Create a VPC endpoint service for your GWLB:

Navigate to VPC > Endpoint Services
Create endpoint service
Select your GWLB
Configure acceptance settings based on your requirements

4. VPC Endpoints

Create VPC endpoints to connect your GWLB:

Navigate to VPC > Endpoints
Create endpoint
Select "GatewayLoadBalancer" as the service type
Choose appropriate VPC and subnets

5. Route Table Configuration

Configure your route tables to direct traffic through the GWLB endpoints:

Navigate to VPC > Route Tables
Edit routes to point specific traffic to your GWLB endpoints
Ensure proper routing between your VPCs and the security VPC

Best Practices

High Availability:
- Deploy across multiple Availability Zones
- Use multiple endpoints for redundancy
Security:
- Implement proper security group rules
- Consider using endpoint acceptance requirements in production
Documentation:
- Maintain detailed documentation of your network architecture
- Document all IP ranges and routing configurations
- Keep track of endpoint IDs and associations

Monitoring and Troubleshooting

When working with GWLB, keep an eye on:

Endpoint health status
Target group health
Traffic flow patterns
Route table configurations

Common Issues and Solutions

Endpoint Connection Issues:
- Verify route table configurations
- Check security group rules
- Ensure proper subnet associations
Traffic Flow Problems:
- Verify 5-tuple hash configurations
- Check endpoint service settings
- Review target group health

Next Steps

To deepen your understanding of AWS networking:

Explore the AWS Networking Workshop: https://networking.workshop.aws/
Practice implementing different security appliances with GWLB
Learn about integration with third-party security solutions

Conclusion

AWS Gateway Load Balancer provides a powerful way to manage and scale your network security appliances. While it requires careful planning and configuration, it offers robust capabilities for handling network traffic and security requirements in your AWS infrastructure.

Remember that networking configurations, especially in production environments, should be thoroughly tested and documented. Take time to understand the traffic flow and security implications of your GWLB implementation.

AWS Cloud Path Week 15: AWS Networking Workshop Part 5 - Hybrid DNS with Route 53 Resolver, Network Monitoring and VPC Flow Logs

Elizabeth Adeotun Adegbaju — Sun, 03 Aug 2025 10:42:02 +0000

Missed the session? Catch up here:

Welcome to Week 15 of the AWS Cloud Path series! In this comprehensive workshop, we dive deep into AWS network monitoring capabilities, focusing on Route 53 Resolver for hybrid DNS, CloudWatch monitoring, and VPC Flow Logs. This session builds upon the foundational AWS networking workshop available at https://networking.workshop.aws/.

Prerequisites

Before starting this workshop, ensure you have:

AWS account with appropriate permissions
Basic understanding of VPC and networking concepts
Familiarity with CloudFormation templates
Access to AWS CLI or AWS Console

Hybrid DNS with Route 53 Resolver

DNS resolution is fundamental to any internet-connected infrastructure. When working with hybrid cloud environments, you need seamless DNS resolution between your on-premises infrastructure and AWS environments without routing traffic through the public internet.

Understanding Route 53 Resolver

Route 53 Resolver makes hybrid cloud easier for enterprise customers by enabling DNS resolution across connected environments. The key components include:

Outbound Endpoints: These are Elastic Network Interfaces (ENIs) that forward DNS queries from your AWS environment to on-premises DNS servers.

Elastic Network Interfaces: Remember that ENIs always have IP addresses, so when planning your VPC subnets, account for the IP addresses that AWS resources using network interfaces will consume.

Setting Up Outbound Endpoints

To create an outbound endpoint:

Navigate to Route 53 in the AWS Console
Under Resolver, select "Outbound endpoints"
Click "Create outbound endpoint"
Configure the following:
- Endpoint name: Choose a descriptive name
- VPC: Select the VPC connected to your on-premises environment
- Security group: Note that you cannot change this after creation
- IP address type: Choose IPv4, IPv6, or dual stack (IPv4 recommended)
- Availability zones: Minimum of two for high availability
- IP addresses: Specify automatic assignment or manual IP addresses

The endpoint creates network interfaces in at least two availability zones for redundancy. This ensures your DNS resolution remains available even if one AZ experiences issues.

Creating Resolver Rules

After setting up the outbound endpoint, create resolver rules to define which domain names should be forwarded:

Go to Route 53 Resolver Rules
Click "Create rule"
Configure:
- Rule name: Descriptive identifier
- Rule type: Forward (most common)
- Domain name: The domain to resolve (e.g., example.corp)
- Outbound endpoint: Select your created endpoint
- Target IP addresses: IP address of your on-premises DNS server
- VPC associations: Select VPCs that should use this rule

This configuration ensures that whenever resources in associated VPCs need to resolve the specified domain, they'll forward the request through your outbound endpoint to the on-premises DNS server.

CloudWatch Monitoring for Networks

CloudWatch is the central monitoring service in AWS, supporting metrics from virtually every AWS service including networking components.

Automatic Dashboards

CloudWatch provides automatic dashboards for various services, including VPC networking. These pre-configured dashboards show key metrics without manual setup:

Active connection counts
Packet drop counts
Network interface utilization
Transit Gateway metrics

To access automatic dashboards:

Navigate to CloudWatch Console
Select "Dashboards" from the left menu
Choose "Automatic dashboards"
Select "VPC and Transit Gateway" or relevant service

Creating Custom Dashboards

While automatic dashboards are convenient, custom dashboards allow you to focus on specific metrics relevant to your environment.

Creating a Custom Network Dashboard:

Go to CloudWatch → Dashboards
Click "Create dashboard"
Add widgets by selecting metrics:
- Navigate to EC2 → Per-Instance Metrics
- Filter by "Network" to find network-related metrics
- Select NetworkIn and NetworkOut for specific instances
Configure visualization (line chart, number, gauge)
Name your dashboard appropriately

Pro tip: Custom dashboards become essential when presenting metrics to management or when you need to monitor specific combinations of metrics not available in automatic dashboards.

Setting Up CloudWatch Alarms

Alarms help you proactively monitor your infrastructure and respond to issues before they impact users.

Creating a Network Alarm:

Navigate to CloudWatch → Alarms → All alarms
Click "Create alarm"
Select metric (e.g., EC2 → Per-Instance Metrics → NetworkIn)
Configure conditions:
- Statistic: Maximum, Average, or Sum (pay attention to which is appropriate)
- Period: 1 minute for immediate response, longer for trend analysis
- Threshold type: Static (you define value) vs Anomaly detection (AWS learns normal patterns)
- Condition: Greater than, less than specific value

SNS Integration:
Configure Simple Notification Service (SNS) for alarm notifications:

Create new SNS topic or use existing
Add email endpoints for notifications
Configure alarm states (In alarm, OK, Insufficient data)
Set up actions like auto-scaling or Lambda functions for automated responses

Important: Always confirm your email subscription to receive alarm notifications.

VPC Flow Logs

VPC Flow Logs capture information about IP traffic flowing through your VPC network interfaces, providing visibility into network communication patterns.

Understanding Flow Logs

Flow Logs monitor traffic to and from network interfaces within your VPC. Since every AWS resource with network connectivity uses an Elastic Network Interface, Flow Logs provide comprehensive network visibility.

Key capabilities:

Monitor traffic patterns within your VPC
Debug network connectivity issues
Analyze security group and NACL effectiveness
Track data transfer for cost optimization

Setting Up VPC Flow Logs

Step 1: Create CloudWatch Log Group

Navigate to CloudWatch → Log groups
Click "Create log group"
Configure:
- Name: networking-workshop-flow-logs
- Retention setting: Set realistic retention (1 week, 1 month) - avoid "Never expire" to control costs
- Log class: Standard for frequently accessed logs, Infrequent Access for cost savings

Step 2: Create Flow Log

Go to VPC Console
Select your VPC
Navigate to "Flow logs" tab
Click "Create flow log"
Configure:
- Name: Descriptive identifier
- Filter: All traffic (recommended for comprehensive monitoring)
- Maximum aggregation interval: 1 minute for detailed monitoring, 10 minutes for cost optimization
- Destination: CloudWatch Logs
- Log group: Select created log group
- IAM role: Use existing or create new service role

Analyzing Flow Logs with CloudWatch Insights

CloudWatch Logs Insights provides a query language for analyzing log data:

Navigate to CloudWatch → Logs Insights
Select your flow logs log group
Use sample queries or create custom queries:

fields @timestamp, srcaddr, dstaddr, srcport, dstport, bytes
| filter srcaddr like /10.0/
| stats sum(bytes) by srcaddr, dstaddr
| sort bytes desc
| limit 10

This query shows the top 10 source/destination pairs by bytes transferred.

Sample Use Cases:

Identify top talkers in your network
Analyze traffic patterns by time
Debug connectivity issues
Monitor for unusual network activity

Cost Optimization Tips

Flow Logs can generate significant costs:

Set appropriate retention periods
Use selective filtering (accepted/rejected traffic only)
Consider log aggregation intervals
Monitor log group size regularly
Delete unnecessary log groups

Generating Test Traffic

To validate your monitoring setup, generate network traffic between instances:

Using Session Manager:

Connect to EC2 instance via Systems Manager Session Manager
Use networking tools like ping or iperf3
Generate traffic between VPCs through Transit Gateway
Monitor resulting metrics and logs

Security Group Configuration:
Ensure security groups allow the traffic you're trying to generate:

ICMP for ping traffic
Specific ports for application traffic
Proper source/destination configurations

Key Takeaways

Hybrid DNS: Route 53 Resolver enables seamless DNS resolution between AWS and on-premises environments
Monitoring Strategy: Combine automatic dashboards with custom dashboards tailored to your specific needs
Proactive Alerting: Set up CloudWatch alarms with appropriate thresholds and SNS notifications
Network Visibility: VPC Flow Logs provide comprehensive insight into network traffic patterns
Cost Management: Always set realistic retention periods and monitor log storage costs
Testing: Generate test traffic to validate your monitoring and alerting setup

Cleanup Instructions

Don't forget to clean up resources to avoid unexpected charges:

Delete EC2 instances
Remove VPC Flow Logs
Delete CloudWatch log groups with short retention needs
Clean up SNS topics and subscriptions
Remove unnecessary CloudWatch dashboards and alarms

What's Next

This completes the foundational AWS Networking Workshop series, we will have one more part for the AWS Network Workshop Parts (6 in total).

For AWS credits to support your learning and experimentation, check the community resources or reach out through the appropriate channels.

Remember: The foundation you've built here with VPC networking, monitoring, and DNS resolution forms the basis for more advanced AWS networking topics. Practice these concepts and experiment with different configurations to deepen your understanding.

This article is based on the AWS Networking Workshop available at https://networking.workshop.aws/. The visual demonstrations and hands-on examples from the video provide additional context beyond what can be represented in text format.

AWS Cloud Path Week 14: AWS Networking Workshop Part 4 - Advanced Networking with Transit Gateway and VPN

Elizabeth Adeotun Adegbaju — Sun, 03 Aug 2025 01:15:08 +0000

Welcome to the continuation of our comprehensive AWS Networking journey! This session marks Week 14 of the AWS Cloud Path, diving deep into advanced networking concepts and practical implementations.

Missed the session? Catch up here:

Prerequisites and Workshop Setup

Before diving into the advanced networking concepts, this session dedicates significant time to environment preparation. The workshop begins with:

CloudFormation Template Deployment: The first 30 minutes focus on deploying the prerequisite environment using CloudFormation templates. This foundational setup is crucial for the hands-on activities that follow.

Common Setup Issues: The session addresses typical deployment challenges and provides troubleshooting guidance for common CloudFormation stack creation problems.

Workshop Overview

This session continues the comprehensive AWS Networking workshop series, building upon previous foundations to explore:

Advanced Networking Components

Transit Gateway: Learn how to implement and manage AWS Transit Gateway for scalable network connectivity
VPN Configurations: Explore various VPN implementation patterns and best practices
Security Integration: Understanding how networking security integrates with advanced AWS services
Monitoring and Observability: Implementing comprehensive network monitoring solutions

Key Learning Objectives

Network Architecture Design: Understanding how to design scalable and secure network architectures using AWS services.

Practical Implementation: Moving beyond theory to hands-on implementation of complex networking scenarios.

Security Best Practices: Implementing security controls and monitoring across your network infrastructure.

Troubleshooting Skills: Developing skills to diagnose and resolve common networking issues in AWS environments.

Workshop Structure and Approach

The session follows the official AWS networking workshop available at networking.workshop.aws, which provides a structured learning path covering:

Foundation to Advanced Concepts

Starting with VPC and subnet fundamentals and progressively building to advanced configurations with Transit Gateway and VPN implementations.

Real-World Scenarios

The workshop incorporates practical examples that mirror real-world networking challenges you might encounter in production environments.

Hands-On Learning

Every concept is reinforced through practical exercises, ensuring you gain both theoretical understanding and practical experience.

Implementation Focus Areas

Transit Gateway Deep Dive

Understanding the architecture, routing capabilities, and integration patterns that make Transit Gateway a powerful networking solution for complex environments.

VPN Integration Patterns

Exploring different VPN configuration options, from site-to-site connections to client VPN implementations, with security considerations throughout.

Network Security Integration

Learning how to implement security controls, monitoring, and compliance measures across your network infrastructure.

Monitoring and Troubleshooting

Developing skills to monitor network performance, diagnose issues, and implement proactive monitoring solutions.

Practical Applications

The workshop emphasizes real-world application of concepts, helping you understand not just how to implement these services, but when and why to use them in different scenarios.

Enterprise Networking

Understanding how these concepts apply to enterprise-scale networking requirements and hybrid cloud implementations.

Multi-Account Strategies

Exploring how advanced networking services support multi-account AWS environments and organizational structures.

Performance Optimization

Learning techniques to optimize network performance and cost-effectiveness in complex AWS environments.

Key Takeaways and Next Steps

This session provides essential knowledge for anyone working with complex AWS networking environments. The combination of theoretical knowledge and practical implementation creates a solid foundation for advanced AWS networking scenarios.

Continue Your Learning: The workshop series provides a comprehensive pathway through AWS networking services, building expertise incrementally.

Practice Implementation: The hands-on nature of this workshop provides valuable experience that directly translates to real-world scenarios.

Community Engagement: Participating in these sessions connects you with other learners and provides opportunities for knowledge sharing and collaboration.

The structured approach and comprehensive coverage make this an invaluable resource for anyone looking to master AWS networking services and advance their cloud infrastructure skills.

Note: While this article provides an overview based on the video content, the actual workshop includes detailed technical demonstrations and hands-on exercises that are best experienced through direct participation or video viewing.

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

Elizabeth Adeotun Adegbaju — Sat, 02 Aug 2025 23:45:35 +0000

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:

Network Access Control Lists (NACLs) - Subnet-level security
Security Groups - Instance-level security
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:

NACL: Controls traffic at the subnet boundary
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

No rule numbering: AWS automatically handles rule precedence
Most specific match wins: Smaller IP ranges take precedence over larger ones
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

Navigate to VPC → Endpoints → Create Endpoint
Select service (e.g., Amazon S3)
Choose VPC and route tables
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

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

Best Practices

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

Key Takeaways

NACLs are stateless - you need explicit inbound AND outbound rules
Security Groups are stateful - return traffic is automatically allowed
Use both for layered security - subnet-level and instance-level protection
Order matters in NACLs - rules are processed numerically
Most specific wins in Security Groups - smaller IP ranges take precedence
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! 🚀

AWS Cloud Path Week 12: AWS Networking Workshop Part 2

Elizabeth Adeotun Adegbaju — Sat, 02 Aug 2025 23:10:30 +0000

Welcome to Week 12 of the AWS Cloud Path series! In this continuation of our AWS networking journey, we dive deep into VPC endpoints, EC2 instance deployment, and connectivity testing. This hands-on workshop builds upon the foundational networking concepts we established in Part 1.

Missed the session? Catch up here:

Prerequisites

Before diving in, ensure you have:

An active AWS account
Basic understanding of VPC concepts (covered in Part 1)
Familiarity with EC2 instances
AWS CLI configured (optional but helpful)
Budget awareness: This workshop costs approximately $7 in US-East-1

⚠️ Cost Alert: Different AWS regions have varying pricing. The $7 estimate applies to US-East-1 (Ohio). Always check your region's pricing before proceeding.

Workshop Architecture Overview

We're building upon our existing VPC infrastructure that includes:

VPC with public and private subnets across two availability zones
Internet Gateway and NAT Gateway
Route tables and Network ACLs
Security groups

Today we're adding:

VPC Endpoints: Gateway endpoint for S3 and interface endpoint for AWS KMS
EC2 Instances: One in public subnet, one in private subnet
Connectivity Testing: Verifying our network configuration

Understanding VPC Endpoints

VPC endpoints provide private connectivity from your AWS environment to AWS services without traversing the public internet. This is crucial for:

Security: Traffic stays within AWS infrastructure
Cost Optimization: Avoiding data transfer charges for external traffic
Performance: Reduced latency for AWS service calls

Types of VPC Endpoints

There are two types of VPC endpoints:

Gateway Endpoints: Only available for S3 and DynamoDB
Interface Endpoints: Available for all other AWS services

This distinction is important for AWS certification exams and architectural decisions.

Creating VPC Endpoints

Interface Endpoint for AWS KMS

AWS Key Management Service (KMS) manages encryption keys in your AWS environment. To create a private connection to KMS:

Navigate to VPC Console → Endpoints
Click "Create endpoint"
Configure the endpoint:

   Name: VPC-A-KMS-endpoint
   Service category: AWS services
   Service: com.amazonaws.<region>.kms
   VPC: Select your VPC-A
   Route tables: Select all route tables
   Subnets: Choose your private subnets
   Security groups: Use default for full access
   Policy: Full access

Key Configuration Notes:

Interface endpoints create elastic network interfaces (ENIs) with IP addresses
You can specify custom IP addresses or let AWS auto-assign
Full access policy allows all resources in your VPC to use the endpoint
The endpoint will be in "pending" state initially

Gateway Endpoint for Amazon S3

S3 gateway endpoints are simpler to configure:

Create endpoint with these settings:

   Name: VPC-A-S3-endpoint
   Service: com.amazonaws.<region>.s3
   Type: Gateway
   VPC: Select your VPC-A
   Route tables: Select all route tables
   Policy: Full access

Gateway vs Interface Differences:

Gateway endpoints don't require subnet or security group configuration
They work by adding routes to your route tables
No ENI creation or IP address assignment needed

Deploying EC2 Instances

Public Subnet Instance

Deploy an EC2 instance for external connectivity testing:

Instance Configuration:
  Name: VPC-A-public-ec2-server
  AMI: Amazon Linux 2023
  Instance Type: t2.micro
  Key Pair: Create new or use existing
  Network Settings:
    VPC: VPC-A
    Subnet: public-subnet-AZ2
    Auto-assign Public IP: Enable
    Primary IP: 10.0.2.10
  Security Group:
    Name: VPC-A-security-group
    Rules:
      - SSH (port 22): 0.0.0.0/0
      - All ICMP: 0.0.0.0/0
  IAM Instance Profile: networking-workshop-instance-profile

Private Subnet Instance

Deploy an instance for internal connectivity testing:

Instance Configuration:
  Name: VPC-A-private-AZ1-server
  AMI: Amazon Linux 2023
  Instance Type: t2.micro
  Key Pair: Same as public instance
  Network Settings:
    VPC: VPC-A
    Subnet: private-subnet-AZ1
    Auto-assign Public IP: Disable
    Primary IP: 10.0.1.10
  Security Group: Same as public instance
  IAM Instance Profile: networking-workshop-instance-profile

Important Security Notes:

Private instance has NO public IP address
Access is only possible through AWS Systems Manager Session Manager
The IAM instance profile includes SSM permissions for management

Connectivity Testing

Testing Public Instance Connectivity

From your local terminal, test ICMP connectivity:

# Test ping to public instance
ping <public-ip-address>

# Expected: Successful ping responses
# This works because we opened ICMP ports in security groups

Testing Private Instance Internal Connectivity

Access the private instance via Session Manager:

EC2 Console → Select private instance → Connect → Session Manager
Once connected, test internal connectivity:

# Test connectivity to public instance (internal communication)
ping 10.0.2.10

# Test external connectivity through NAT Gateway
ping example.com

Why This Works:

Internal ping succeeds because VPC allows local traffic
External ping succeeds through NAT Gateway in public subnet
Private instance is protected from direct internet access

Understanding VPC Endpoint Routing

Interface Endpoint Resolution

Test DNS resolution for KMS endpoint:

# From private instance, check KMS endpoint resolution
dig kms.eu-central-1.amazonaws.com

# Expected output shows local IP addresses within your VPC CIDR
# Example: 10.0.1.x, 10.0.2.x

This demonstrates that:

DNS queries for KMS resolve to local IP addresses
Traffic stays within your VPC infrastructure
No public internet traversal occurs

Gateway Endpoint Routing

Check route table entries:

Navigate to VPC → Route Tables → Private Route Table
Look for entries with:
- Destination: Prefix list (e.g., pl-xxxxxx)
- Target: Your VPC S3 endpoint

The prefix list contains IP address ranges for S3 in your region. When traffic matches these destinations, it routes through your gateway endpoint instead of the internet gateway.

Key Learnings and Best Practices

Cost Optimization

VPC endpoints reduce data transfer costs by keeping traffic within AWS
Gateway endpoints are free; interface endpoints have hourly charges
Consider endpoint usage patterns when designing architecture

Security Benefits

Private connectivity eliminates internet-based attack vectors
Fine-grained access control through endpoint policies
Traffic inspection and monitoring capabilities

Architectural Considerations

One endpoint per service (can't reuse endpoints across services)
Interface endpoints create ENIs that consume IP addresses
Gateway endpoints use route table entries (no IP consumption)

Troubleshooting Tips

Endpoint status must be "Available" before use
Check security group rules for interface endpoints
Verify route table associations for gateway endpoints
DNS resolution should return VPC-local IP addresses

Cleanup Instructions

Important: Don't leave resources running to avoid unnecessary charges!

Follow this cleanup order:

Terminate EC2 instances
Delete VPC endpoints (interface and gateway)
Delete the VPC (removes subnets, route tables, gateways automatically)
Delete the CloudFormation stack for IAM roles and prerequisites

What's Next?

In our next session, we'll explore:

Advanced VPC connectivity with Transit Gateway
VPN configurations for hybrid connectivity
Network monitoring and troubleshooting tools
Security group and NACL deep dive

This workshop demonstrates how VPC endpoints provide secure, cost-effective connectivity to AWS services while maintaining network isolation. The combination of proper subnet design, security groups, and endpoint configuration creates a robust networking foundation for your AWS workloads.

Note: The visual demonstrations in the workshop video show real-time AWS Console interactions and terminal commands. While this text representation covers the core concepts and configurations, watching the video provides additional context for navigating the AWS Console and understanding the step-by-step process.

AWS Cloud Path Week 11: AWS Networking Workshop Part 1 - Building Secure VPC Infrastructure

Elizabeth Adeotun Adegbaju — Sat, 02 Aug 2025 22:48:13 +0000

Welcome to Week 11 of the AWS Cloud Path series! In this hands-on workshop, we dive deep into AWS networking fundamentals by working through a comprehensive AWS Networking Workshop. This tutorial covers the full spectrum of AWS networking, from basic VPC and subnet configurations to advanced setups with security groups, route tables, and NAT gateways.

Missed the session? Catch up here:

Prerequisites

Before diving into this workshop, you should have:

An active AWS account with appropriate permissions
Basic understanding of networking concepts (IP addresses, CIDR blocks, subnets)
Familiarity with AWS Console navigation
Understanding that resources created in this workshop will incur costs (~$7 USD in us-east-1)

⚠️ Cost Warning: The resources created in this workshop will cost approximately $7 in the US East 1 region. Pricing may vary in different regions.

Workshop Overview

This workshop is part of the AWS Networking Immersion Day and covers foundational to advanced networking topics:

Foundation Topics Covered:

Virtual Private Cloud (VPC) creation and configuration
Public and private subnet architecture
Internet Gateway setup
NAT Gateway configuration
Route tables and routing
Network Access Control Lists (NACLs)
Security group configuration

Advanced Topics (Future Sessions):

VPC Endpoints
Transit Gateway
VPN connections
Gateway Load Balancers
Multi-cast networking

Step-by-Step Implementation

1. Environment Setup with CloudFormation

Before creating our networking infrastructure, we need to deploy a CloudFormation template that provisions prerequisite resources.

Deploying the Initial Stack

Download the provided CloudFormation template
Navigate to the CloudFormation console
Create a new stack and upload the template
Name your stack (e.g., "networking-workshop-prerequisites")
Deploy the stack

Resources Created:

Flow logs role
VPC endpoint policies
Elastic IP addresses

# The CloudFormation template creates essential resources like:
# - IAM roles for flow logs
# - Endpoint policies
# - Pre-allocated Elastic IPs

2. Creating Your VPC Foundation

VPC Creation

Navigate to the VPC console and create a new VPC:

Name: VPCA
IPv4 CIDR block: 10.0.0.0/16
IPv6 CIDR block: No IPv6 CIDR block
Tenancy: Default

CIDR Block Explanation:
10.0.0.0/16 provides approximately 65,536 IP addresses
This gives us plenty of room for multiple subnets across availability zones

Enable DNS Hostnames

After VPC creation:

Select your VPC
Go to Actions → Edit VPC settings
Enable DNS hostnames
Save changes

This allows instances in your VPC to receive public DNS hostnames when they have public IP addresses.

3. Subnet Architecture Design

We'll create four subnets across two Availability Zones following AWS best practices:

Subnet Type	AZ	CIDR Block	Purpose
Public Subnet AZ1	eu-central-1a	10.0.0.0/24	Resources needing direct internet access
Private Subnet AZ1	eu-central-1a	10.0.1.0/24	Backend resources, databases
Public Subnet AZ2	eu-central-1b	10.0.2.0/24	High availability public resources
Private Subnet AZ2	eu-central-1b	10.0.3.0/24	High availability private resources

Creating Subnets

For each subnet:

Navigate to VPC → Subnets → Create subnet
Select your VPC (VPCA)
Configure subnet settings following the table above
Create the subnet

Naming Convention Best Practices:

Use consistent naming patterns (e.g., VPCA-public-subnet-az1)
Include VPC identifier, subnet type, and availability zone
This makes resource management much easier in production environments

4. Network Access Control Lists (NACLs)

Creating Custom NACLs

Default NACLs allow all traffic, which isn't ideal for security. Let's create a custom NACL:

Navigate to VPC → Network ACLs → Create network ACL
Name: VPCA-workload-subnet-nacl
VPC: VPCA

Configuring NACL Rules

Inbound Rules:

Rule # | Type | Protocol | Port Range | Source | Allow/Deny
100    | HTTP | TCP      | 80         | 0.0.0.0/0 | ALLOW

Outbound Rules:

Rule # | Type | Protocol | Port Range | Destination | Allow/Deny
100    | All Traffic | All | All | 0.0.0.0/0 | ALLOW

⚠️ Security Note: This configuration allows all traffic for demonstration purposes. In production, implement least-privilege access with specific rules for your application requirements.

Associate Subnets with NACL

Select your custom NACL
Go to Subnet associations tab
Edit subnet associations
Associate all four subnets with the custom NACL

5. Route Tables Configuration

Route tables determine where network traffic from subnets is directed. We'll create separate route tables for public and private subnets.

Public Route Table

Navigate to VPC → Route Tables → Create route table
Name: VPCA-public-route-table
VPC: VPCA
Associate with public subnets

Private Route Table

Create another route table
Name: VPCA-private-route-table
VPC: VPCA
Associate with private subnets

Default Routes:
Both route tables automatically include a local route for the VPC CIDR (10.0.0.0/16) with target "local", enabling communication within the VPC.

6. Internet Connectivity Setup

Internet Gateway Configuration

Public subnets need internet access through an Internet Gateway:

Navigate to VPC → Internet Gateways → Create Internet Gateway
Name: VPCA-IGW
Attach to VPCA

Configure Public Route Table

Add internet route to public route table:

Select VPCA-public-route-table
Edit routes → Add route
Destination: 0.0.0.0/0
Target: Internet Gateway (VPCA-IGW)

This route directs all non-local traffic to the internet gateway.

NAT Gateway for Private Subnets

Private subnets need outbound internet access through a NAT Gateway:

Navigate to VPC → NAT Gateways → Create NAT Gateway
Name: VPCA-NAT-Gateway
Subnet: Select a public subnet (VPCA-public-subnet-az1)
Connectivity type: Public
Elastic IP: Allocate Elastic IP
Create NAT Gateway

Configure Private Route Table

Add NAT Gateway route to private route table:

Select VPCA-private-route-table
Edit routes → Add route
Destination: 0.0.0.0/0
Target: NAT Gateway (VPCA-NAT-Gateway)

Key Learning Points

1. CIDR Block Planning

Plan your IP address space carefully
Leave room for future expansion
Avoid overlapping CIDR blocks
Consider connectivity requirements with other networks

2. High Availability Design

Deploy resources across multiple Availability Zones
Use consistent naming conventions
Implement redundancy for critical components

3. Security Best Practices

Use custom NACLs instead of defaults
Follow least-privilege access principles
Separate public and private subnets
Control outbound traffic from private subnets

4. Route Table Strategy

Create dedicated route tables for different subnet types
Understand local routes vs. internet routes
Plan for hybrid connectivity (VPN/Direct Connect)

Common Troubleshooting Tips

Internet Connectivity Issues

Check Internet Gateway: Ensure it's attached to the VPC
Verify Route Tables: Confirm 0.0.0.0/0 routes point to correct targets
Security Groups: Check that security groups allow required traffic
NACLs: Ensure NACLs aren't blocking traffic

NAT Gateway Problems

Subnet Selection: NAT Gateway must be in a public subnet
Elastic IP: Ensure Elastic IP is allocated and attached
Route Configuration: Private subnets should route 0.0.0.0/0 to NAT Gateway

Production Considerations

Cost Optimization

NAT Gateway: Consider NAT instances for development environments
Elastic IPs: Release unused Elastic IP addresses
Data Transfer: Monitor data transfer costs

Security Enhancements

Implement AWS Config rules for compliance monitoring
Use VPC Flow Logs for traffic analysis
Consider AWS Network Firewall for advanced filtering

Monitoring and Logging

Enable VPC Flow Logs
Set up CloudWatch monitoring for NAT Gateways
Monitor Elastic IP usage and costs

Next Steps

In the upcoming sessions, we'll explore:

VPC Endpoints (Next Session)

S3 Gateway Endpoints
Interface Endpoints for AWS services
Private connectivity without internet gateway dependency
Cost optimization through private connectivity

Advanced Networking Topics

Transit Gateway for multi-VPC connectivity
VPN connections for hybrid cloud
Direct Connect for dedicated connectivity
Network segmentation strategies

Conclusion

This foundational networking workshop provides the essential building blocks for secure, scalable AWS network architectures. By understanding VPCs, subnets, route tables, and security controls, you're building expertise in the core networking components that underpin most AWS solutions.

The hands-on approach of working through actual AWS console configurations helps solidify theoretical knowledge with practical skills. Remember to clean up resources after the workshop to avoid unnecessary costs!

Additional Resources

Join us next week as we continue with VPC Endpoints and explore how to create private connectivity to AWS services without routing traffic through the public internet!