DEV Community: Esteban

Building Agentic AI with Amazon Bedrock – Part 1: Your First AI Agent (Beginner Friendly)

Esteban — Fri, 14 Nov 2025 03:02:34 +0000

Imagine an AI that doesn't just answer questions, but actually "does things" for you, for example, checking the weather, booking appointments, or analyzing data. These are called agentic AI systems, and they're transforming how we interact with artificial intelligence.

BTW, this is Part 1 of a four-part project series that I am building.

Overview

This series walks you step-by-step through building real agentic AI systems, from your sime first tool call, to a full production-ready knowledge assistant.

Project 1 — Weather Agent (Beginner) -> Learn the core agent pattern: Define a tool → Call the model → Handle tool_use → Return results to Claude.
Project 2 — Research Assistant (Intermediate) -> Introduce multi-tool orchestration and build an agentic loop that handles multiple tool calls.
Project 3 — Task Planner (Advanced) -> Your agent plans its own execution, retries on failure, and reflects on improvements.
Project 4 — Knowledge Base Agent (Production) -> Use Bedrock’s managed agents + RAG to build enterprise-ready assistants.

My Approach: Applying Infrastructure as Code with Python

Why Python Scripts Instead of Manual Console Work?

Throughout this tutorial, you'll notice that I use Python scripts to create and configure AWS resources rather than clicking through the AWS Console. This is intentional and reflects real-world best practices. Here's why:

Repeatability

Why moving out from the GUI Approach:

• Make a mistake? Start over, clicking through 20+ screens
• Want to create in another region? Repeat all steps manually
• Team member needs to replicate? Send them a 50-step document

Why is better with Python Scripting Approach:

• Make a mistake? Fix the script and re-run
• Different region? Change one variable
• Share with team? Send them the script

Project 1: Build Your First AI Agent With Amazon Bedrock

In this project you'll build your first AI agent from scratch using Amazon Bedrock and AWS Lambda. By the end, you'll have a fully functional weather assistant that:

Understands natural language requests
Calls an external API to get real-time data
Synthesizes information into helpful responses

What you'll learn:

What Amazon Bedrock is and how it works
How to create AI agents that can use tools
How to build Lambda functions as agent tools
How to connect everything using Action Groups
How to test and deploy your agent

Prerequisites:

AWS account
Basic Python knowledge (or use AI to help you, as I did)
Terminal/command line familiarity
20-40 minutes of your time

Key Concepts

Foundation Models: Pre-trained AI models you can use via API. Bedrock offers:

Claude (Anthropic) - Advanced reasoning and tool use
Llama (Meta)
Amazon Titan

Agents: AI systems that can:

Understand natural language
Decide when to use tools
Execute actions
Synthesize responses

Action Groups: Collections of tools (functions) your agent can use. Think of them as the agent's "superpowers."

Tools: Functions your agent can call, like:

Checking weather
Querying databases
Calling APIs
Processing data

How Bedrock Agents Work: The Big Picture

User asks: "What's the weather in NYC?"
          ↓
    [Bedrock Agent]
    - Powered by Claude
    - Has your instructions
    - Knows about action groups
          ↓
    Agent thinks: "I need weather data. 
                   I have a 'get_weather' action. 
                   I'll use that!"
          ↓
    [Action Group]
    - Knows this action calls a Lambda function
          ↓
    [Lambda Function]
    - Calls weather API
    - Gets real data
    - Returns it
          ↓
    [Back to Agent]
    - Receives weather data
    - Crafts natural response
          ↓
    User gets: "It's 52°F and rainy in New York City. 
                Bring an umbrella!"

Enable Bedrock Model Access

Before we start coding, check if you have access to Claude (or your AI model of preference)

aws bedrock list-foundation-models \
--region us-east-1 \
--query 'modelSummaries[?contains(modelId,anthropic.claude`)].modelId'

Note: If you see an error, go to AWS Console → Bedrock → Model Access → Request Access to Claude 3.5 Sonnet models

Building the Lambda Function

What is Lambda? AWS Lambda is a service that runs your code without you managing servers.

Perfect for our use case because:
- Agent calls Lambda only when user asks about weather
- Could be once an hour or 1000 times an hour - Lambda scales automatically
- You pay only for actual requests (free tier: 1M requests/month)

Create lambda_function.py:

import json
import os
import urllib.request
import urllib.parse
from typing import Tuple, Optional, Dict

USER_AGENT = "WeatherAssistant/1.0"

def http_get_json(url: str, headers: Optional[Dict] = None, timeout: int = 8) -> dict:
    req = urllib.request.Request(url, headers=headers or {})
    with urllib.request.urlopen(req, timeout=timeout) as resp:
    return json.loads(resp.read().decode("utf-8"))

def geocode_city(city: str) -> Optional[Tuple[float, float]]:
    if not city:
        return None
    params = urllib.parse.urlencode({"q": city, "format": "json", "limit": 1})
    url = f"https://nominatim.openstreetmap.org/search?{params}"
    headers = {"User-Agent": USER_AGENT}
    try:
        results = http_get_json(url, headers=headers)
        if not results:
            return None
        return float(results[0]["lat"]), float(results[0]["lon"])
    except Exception as e:
        print(f"[ERROR] Geocoding failed: {e}")
        return None

def get_grid_endpoints(lat: float, lon: float) -> Tuple[str, str]:
    url = f"https://api.weather.gov/points/{lat:.4f},{lon:.4f}"
    headers = {"User-Agent": USER_AGENT, "Accept": "application/geo+json"}
    data = http_get_json(url, headers=headers)
    props = data.get("properties", {})
    return props["forecast"], props["forecastHourly"]

def get_forecast(url: str) -> dict:
    headers = {"User-Agent": USER_AGENT, "Accept": "application/geo+json"}
    return http_get_json(url, headers=headers)

def summarize_hourly_24h(hourly_json: dict) -> str:
    periods = hourly_json.get("properties", {}).get("periods", [])
    if not periods:
        return "No hourly forecast available."
    lines = []
    for p in periods[:24]:
        temp = p.get("temperature")
        unit = p.get("temperatureUnit", "F")
        short = p.get("shortForecast", "")
        wind = f"{p.get('windSpeed', '')} {p.get('windDirection', '')}".strip()
        lines.append(f"{temp}°{unit}, {short}, wind {wind}")
    return "Next 24 hours: " + " | ".join(lines[:6])

def lambda_handler(event, context):
    print(f"Received event: {json.dumps(event, default=str)}")
    api_path = event.get('apiPath', '/weather') # Extract parameters from Bedrock agent format
    http_method = event.get('httpMethod', 'GET')
    parameters = event.get('parameters', [])
    # Parse parameters
    city = None
    mode = "hourly"
    for param in parameters:
        if param['name'] == 'city':
            city = param['value']
        elif param['name'] == 'mode':
            mode = param['value']
    print(f"Parsed: city={city}, mode={mode}")
    # Validate input
    if not city:
        return {
            "messageVersion": "1.0",
            "response": {
                "actionGroup": event.get('actionGroup', 'weather-tools'),
                "apiPath": api_path,
                "httpMethod": http_method,
                "httpStatusCode": 400,
                "responseBody": {
                    "application/json": {
                        "body": json.dumps({"error": "Missing required parameter: city"})
                    }
                }
            }
        }
        try:
        # Geocode city
        coords = geocode_city(city)
        if not coords:
            return {
                "messageVersion": "1.0",
                "response": {
                    "actionGroup": event.get('actionGroup', 'weather-tools'),
                    "apiPath": api_path,
                    "httpMethod": http_method,
                    "httpStatusCode": 404,
                    "responseBody": {
                        "application/json": {
                            "body": json.dumps({"error": f"Could not find city: {city}"})
                        }
                    }
                }
            }
        lat, lon = coords
        print(f"Geocoded '{city}' to lat={lat}, lon={lon}")
        # Get weather
        forecast_url, hourly_url = get_grid_endpoints(lat, lon)
        data = get_forecast(hourly_url if mode == "hourly" else forecast_url)
        weather_report = summarize_hourly_24h(data)
        # Return in correct Bedrock format
        return {
            "messageVersion": "1.0",
            "response": {
                "actionGroup": event.get('actionGroup', 'weather-tools'),
                "apiPath": api_path,  # CRITICAL: Must match input
                "httpMethod": http_method,
                "httpStatusCode": 200,
                "responseBody": {
                    "application/json": {
                        "body": json.dumps({"weather_report": weather_report})
                    }
                }
            }
        }
        except Exception as e:
        print(f"[ERROR] {e}")
        return {
            "messageVersion": "1.0",
            "response": {
                "actionGroup": event.get('actionGroup', 'weather-tools'),
                "apiPath": api_path,
                "httpMethod": http_method,
                "httpStatusCode": 500,
                "responseBody": {
                    "application/json": {
                        "body": json.dumps({"error": "Weather service error"})
                    }
                }
            }
        }

Understanding the code:

geocode_city: Converts city names to GPS coordinates
get_grid_endpoints: Gets weather.gov forecast URLs for coordinates
get_forecast: Fetches weather data
summarize_hourly_24h: Formats data for easy reading
lambda_handler: Main entry point that orchestrates everything

Lambda needs permission to write logs, for this we are going to create an IAM Role for the Lambda function

Create trust-policy.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Create the IAM role

aws iam create-role \
    --role-name WeatherLambdaRole \
    --assume-role-policy-document file://trust-policy.json

Attach policy for CloudWatch logging

aws iam attach-role-policy \
    --role-name WeatherLambdaRole \
    --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

Get the role ARN (save this!)

aws iam get-role \
    --role-name WeatherLambdaRole \
    --query 'Role.Arn' \
    --output text

Save the ARN - it looks like: arn:aws:iam::123456789012:role/WeatherLambdaRole

Deploy the Lambda Function

Package the code

zip function.zip lambda_function.py

Deploy to AWS (replace YOUR_ROLE_ARN with the ARN from step 2)

aws lambda create-function \
    --function-name bedrock-weather-function \
    --runtime python3.11 \
    --role **YOUR_ROLE_ARN **\
    --handler lambda_function.lambda_handler \
    --zip-file fileb://function.zip \
    --timeout 30 \
        --memory-size 256

Creating the Bedrock Agent

Step 1: Create IAM Role for the Agent

The agent needs permissions to invoke Lambda and call Bedrock models.

Create agent-trust-policy.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "bedrock.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Create agent-permissions.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "lambda:InvokeFunction"
      ],
      "Resource": "arn:aws:lambda:us-east-1:*:function:bedrock-weather-function"
    },
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel"
      ],
      "Resource": "*"
    }
  ]
}

Create role

aws iam create-role \
    --role-name BedrockAgentRole \
    --assume-role-policy-document file://agent-trust-policy.json

Attach permissions

aws iam put-role-policy \
    --role-name BedrockAgentRole \
    --policy-name AgentPermissions \
    --policy-document file://agent-permissions.json

Get the role ARN (save this!)

aws iam get-role \
    --role-name BedrockAgentRole \
    --query 'Role.Arn' \
    --output text

Wait for role to propagate

sleep 10

Step 2: Create the Agent

Create create_agent.py:

import boto3
import json
import time

client = boto3.client('bedrock-agent', region_name='us-east-1')

# Replace with your role ARN
ROLE_ARN = 'arn:aws:iam::YOUR_ACCOUNT:role/BedrockAgentRole'

print("Creating Bedrock agent...")

try:
    response = client.create_agent(
        agentName='weather-assistant',
        agentResourceRoleArn=ROLE_ARN,
        foundationModel='us.anthropic.claude-3-5-sonnet-20241022-v2:0',
        instruction=(
            "You are a helpful weather assistant. "
            "When users ask about weather in any US city, use the getWeather tool "
            "to fetch current conditions and forecasts. "
            "Provide friendly, conversational responses with relevant weather details. "
            "If asked about multiple cities, check each one. "
            "Always mention temperature, conditions, and any important weather alerts."
        ),
        idleSessionTTLInSeconds=600
    )

    agent_id = response['agent']['agentId']

    print(f"✅ Agent created successfully!")
    print(f"Agent ID: {agent_id}")
    print(f"Agent Name: {response['agent']['agentName']}")
    print(f"\nSave this Agent ID for the next steps!")

    # Save to file
    with open('agent-config.json', 'w') as f:
        json.dump({'agent_id': agent_id}, f)

except Exception as e:
    print(f"❌ Error: {str(e)}")

Run it:

python3 create_agent.py

Step 3: Create the Action Group

Action Groups connect your Lambda function to the agent using an OpenAPI schema.

Create create_action_group.py:

import boto3
import json

client = boto3.client('bedrock-agent', region_name='us-east-1')

    #Replace these with your values

AGENT_ID = 'YOUR_AGENT_ID'  # From previous step
LAMBDA_ARN = 'arn:aws:lambda:us-east-1:YOUR_ACCOUNT:function:bedrock-weather-function'

    #OpenAPI schema defining the tool

openapi_schema = {
    "openapi": "3.0.0",
    "info": {
        "title": "Weather API",
        "version": "1.0.0",
        "description": "API for getting weather forecasts for US cities"
    },
    "paths": {
        "/weather": {
            "get": {
                "summary": "Get weather forecast",
                "description": "Get weather forecast for a US city. Use when user asks about weather, temperature, or conditions.",
                "operationId": "getWeather",
                "parameters": [
                    {
                        "name": "city",
                        "in": "query",
                        "description": "US city name (e.g. 'Seattle', 'New York')",
                        "required": True,
                        "schema": {"type": "string"}
                    },
                    {
                        "name": "mode",
                        "in": "query",
                        "description": "Forecast type: 'hourly' or 'daily'",
                        "required": False,
                        "schema": {
                            "type": "string",
                            "enum": ["hourly", "daily"],
                            "default": "hourly"
                        }
                    }
                ],
                "responses": {
                    "200": {
                        "description": "Weather forecast",
                        "content": {
                            "application/json": {
                                "schema": {
                                    "type": "object",
                                    "properties": {
                                        "weather_report": {"type": "string"}
                                    }
                                }
                            }
                        }
                    }
                }
            }
        }
    }
}

print("Creating action group...")

try:
    response = client.create_agent_action_group(
        agentId=AGENT_ID,
        agentVersion='DRAFT',
        actionGroupName='weather-tools',
        actionGroupExecutor={'lambda': LAMBDA_ARN},
        apiSchema={'payload': json.dumps(openapi_schema)},
        description='Tools for getting weather information',
        actionGroupState='ENABLED'
    )

    print("✅ Action group created!")
    print(f"Action Group ID: {response['agentActionGroup']['actionGroupId']}")

except Exception as e:
    print(f"❌ Error: {str(e)}")

Run it:

python3 create_action_group.py

Step 4: Prepare and Deploy the Agent

Prepare the agent (builds and validates)

aws bedrock-agent prepare-agent --agent-id YOUR_AGENT_ID

Wait for preparation (30-60 seconds)

sleep 30

Create an alias for testing

aws bedrock-agent create-agent-alias \
    --agent-id YOUR_AGENT_ID \
    --agent-alias-name dev

Save the alias ID from the output

Part 5: Testing Your Agent

Create the Test Script called test-agent.py:

import boto3
import json
import sys

client = boto3.client('bedrock-agent-runtime', region_name='us-east-1')

# Replace with your values
AGENT_ID = 'YOUR_AGENT_ID'
AGENT_ALIAS_ID = 'YOUR_ALIAS_ID'

def chat(message):
    """Send a message to the agent and display the response."""

    print(f"\n{'='*70}")
    print(f"You: {message}")
    print(f"{'='*70}\n")

    response = client.invoke_agent(
        agentId=AGENT_ID,
        agentAliasId=AGENT_ALIAS_ID,
        sessionId='test-session',
        inputText=message,
        enableTrace=True
    )

    print("Agent: ", end='', flush=True)

    for event in response['completion']:
        if 'chunk' in event:
            chunk = event['chunk']
            if 'bytes' in chunk:
                print(chunk['bytes'].decode('utf-8'), end='', flush=True)

        elif 'trace' in event:
            trace = event['trace']
            if 'trace' in trace:
                trace_data = trace['trace']
                if 'orchestrationTrace' in trace_data:
                    orch = trace_data['orchestrationTrace']

                    if 'invocationInput' in orch:
                        inv = orch['invocationInput']
                        if 'actionGroupInvocationInput' in inv:
                            action = inv['actionGroupInvocationInput']
                            params = {p['name']: p['value'] for p in action.get('parameters', [])}
                            print(f"\n[Calling tool with params: {params}]")

    print("\n" + "="*70 + "\n")

if __name__ == "__main__":
    # Interactive mode
    print("\n🌤️  Weather Agent - Type 'exit' to quit\n")

    while True:
        try:
            query = input("You: ").strip()
            if query.lower() in ['exit', 'quit']:
                break
            if query:
                chat(query)
        except KeyboardInterrupt:
            break

    print("\n👋 Goodbye!\n")

Test It!

python3 test-agent.py

Try these queries:

"What's the weather in NYC?"
"How's the weather in Miami and New York?"
"Is it going to rain in Boston today?"
"What's the forecast for San Francisco?"

Expected interaction:

You: What's the weather in NYC?

[Calling tool with params: {'city': 'NYC', 'mode': 'hourly'}]

Agent: The weather in NYC is currently 52°F with partly cloudy skies. 
Wind is light at 5 mph from the west. Over the next few hours, temperatures 
will stay in the low 50s with continued partly cloudy conditions. It's a 
pleasant day in NYC!

Part 6: Understanding What You Built

The Complete Flow

Let's trace through what happens when you ask "What's the weather in NYC?":

1. User Input → Bedrock Agent

You type: "What's the weather in NYC?"

2. Agent Reasoning (Claude 3.5 Sonnet)

Claude thinks: "The user wants weather information for NYC. 
I have a getWeather tool available. I should use it with city='NYC'."

3. Agent → Action Group

Request to Action Group:
{
  "apiPath": "/weather",
  "parameters": [
    {"name": "city", "value": "NYC"}
  ]
}

4. Action Group → Lambda Function

Bedrock invokes: bedrock-weather-function
With parameters: city=NYC, mode=hourly

5. Lambda Execution

Step 1: Geocode "NYC" → (40.7306,-73.9352)
Step 2: Call weather.gov/points/40.7306,-73.9352
Step 3: Get hourly forecast URL
Step 4: Fetch forecast data
Step 5: Format response

6. Lambda → Agent

Returns: {
  "weather_report": "Next 24 hours: 52°F, Partly Cloudy, wind 5 mph W | ..."
}

7. Agent Synthesis

Claude reads the data and creates a natural response:
"The weather in NYC is currently 52°F with partly cloudy skies..."

8. Response → User

You see the friendly, natural language response!

Key Concepts Demonstrated

1. Agentic Reasoning

The AI doesn't just follow a script—it decides when and how to use tools based on the user's request.

2. Tool Abstraction

You defined what the tool does (OpenAPI schema), and the AI figures out how to use it.

3. Natural Language Interface

Users don't need to know about APIs, parameters, or JSON—they just ask naturally.

4. Error Handling

The Lambda function handles missing cities, API failures, and edge cases gracefully.

5. Serverless Architecture

Everything scales automatically. No servers to manage, pay only for what you use.

Troubleshooting

Common Issues and Solutions

Issue: "Invocation of model ID with on-demand throughput isn't supported"

Solution: Use inference profile instead of direct model ID:

Update agent with correct model

aws bedrock-agent update-agent \
    --agent-id YOUR_AGENT_ID \
    --agent-name weather-assistant \
    --agent-resource-role-arn YOUR_ROLE_ARN \
    --foundation-model us.anthropic.claude-3-5-sonnet-20241022-v2:0

# Prepare agent
aws bedrock-agent prepare-agent --agent-id YOUR_AGENT_ID

Issue: "APIPath in Lambda response doesn't match input"

Solution: Ensure Lambda returns apiPath exactly as received:

return {
    "response": {
        "apiPath": event.get('apiPath', '/weather'),  # Must match input
        ...
    }
}

Issue: "City not found"

Cause: OpenStreetMap couldn't geocode the city name.

Solution: Try more specific names:

❌ "Portland" → ✅ "Portland, OR"
❌ "Springfield" → ✅ "Springfield, IL"

Issue: Lambda times out

Solution: Increase timeout:

aws lambda update-function-configuration \
    --function-name bedrock-weather-function \
    --timeout 60

Issue: "Weather service temporarily unavailable"

Cause: weather.gov only covers US locations.

Solution: The API works only for US cities. For international weather, you'd need a different API (like OpenWeatherMap).

Viewing Lambda Logs for Debugging

View recent logs

aws logs tail /aws/lambda/bedrock-weather-function --follow

This shows:

Each function execution
Print statements
Errors with stack traces
Execution duration and memory used

Cost Analysis

What Does This Cost to Run?

Let's break down the costs for 1,000 weather queries per month:

1. Amazon Bedrock (Claude 3.5 Sonnet)

Input: ~200 tokens per query = 200K tokens
Output: ~150 tokens per response = 150K tokens
Cost: $3.00 per million input tokens, $15.00 per million output tokens
Monthly cost: $0.60 + $2.25 = $2.85

2. AWS Lambda

1,000 executions × 2 seconds each = 2,000 seconds
256MB memory allocation
First 1M requests free, then $0.20 per million
First 400,000 GB-seconds free
Monthly cost: $0.00 (within free tier)

3. CloudWatch Logs

~5KB per execution = 5MB total
First 5GB free per month
Monthly cost: $0.00 (within free tier)

Total: ~$3.00 per month for 1,000 queries

Conclusion

You've just built a fully functional AI agent that:

Uses Claude 3.5 Sonnet for natural language understanding
Autonomously decides when to use tools
Calls external APIs to get real-time data
Handles errors gracefully
Costs less than $3/month for typical usage
Scales automatically with demand

This is the foundation for building powerful AI applications. The pattern you learned—Agent → Action Group → Lambda → External API—can be applied to countless use cases.

Thank You!

I hope this guide has shown you that building AI agents is not only possible but actually straightforward with the right tools.

Coming in Part 2:

Building multi-tool agents that orchestrate complex workflows
Adding Knowledge Bases for document retrieval (RAG)
Implementing agent memory and conversation context
Advanced error handling and recovery strategies

Stay tuned!

Setting Up Inter-Region VPC Communication Using AWS Transit Gateway

Esteban — Wed, 07 May 2025 13:06:23 +0000

As cloud environments grow across multiple AWS regions and accounts, managing a scalable and secure network architecture becomes essential. AWS Transit Gateway (TGW) offers a hub-and-spoke model that consolidates routing between VPCs and on-prem networks. Unlike traditional VPC peering (point-to-point), TGW enables centralized routing, dynamic scalability, and BGP-based routing for efficient inter-region communication.

In this article, we’ll build a Transit Gateway-based Inter-Region VPC architecture, walk through step-by-step GUI and CLI setup.

Architecture for this Setup

A Transit Gateway in each region (us-east-1, us-west-2)
Two VPCs (VPC-East, VPC-West) with non-overlapping CIDRs
Attach VPCs to their local TGWs
Peer both TGWs across regions
Create TGW Route Tables to enable traffic flow
Simulate a blackhole scenario

Step 1: Create VPCs and Subnets

GUI:

Go to the AWS Console for both regions (us-east-1 and us-west-2)
Navigate to VPC → Create VPC
Select “VPC only”

For Region A: CIDR block: 10.10.0.0/16, name: VPC-East

For Region B: CIDR block: 10.20.0.0/16, name: VPC-West

On the left-hand menu, click “Subnets”.
Click “Create subnet”.
Select the VPC you want to attach the subnet to.
Add the following:

For Region A:

Name tag: Subnet-East
Availability Zone: us-east-1a
IPv4 CIDR block: 10.10.1.0/24

For Region B:

Name tag: Subnet-West
Availability Zone: us-west-2a
IPv4 CIDR block: 10.20.1.0/24

CLI:

# VPC-East
aws ec2 create-vpc --cidr-block 10.10.0.0/16 --region us-east-1 --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=VPC-East}]'

# Subnet-East (in VPC-East)
aws ec2 create-subnet \
--vpc-id <vpc-east-id> \
--cidr-block 10.10.1.0/24 \
--availability-zone us-east-1a \
--region us-east-1 \
--tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=Subnet-East}]'


# VPC-West
aws ec2 create-vpc --cidr-block 10.20.0.0/16 --region us-west-2 --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=VPC-West}]'

# Subnet-West (in VPC-West)
aws ec2 create-subnet \
--vpc-id <vpc-west-id> \
--cidr-block 10.20.1.0/24 \
--availability-zone us-west-2a \
--region us-west-2 \
--tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=Subnet-West}]'

Step 2: Create Transit Gateways

GUI:

Navigate to VPC Console in Region A (us-east-1)
Select “Transit Gateways” from the left menu
Click “Create Transit Gateway”
Configure settings:

Note: Repeat the same process in region B (us-west-2)

CLI:

# Create Transit Gateway in Region A
aws ec2 create-transit-gateway \
 — description “Transit Gateway for Region A” \
 — region us-east-1 \
 — tag-specifications ‘ResourceType=transit-gateway,Tags=[{Key=Name,Value=TGW-Region-A}]’

# Create Transit Gateway in Region B
aws ec2 create-transit-gateway \
 — description “Transit Gateway for Region B” \
 — region us-west-2 \
 — tag-specifications ‘ResourceType=transit-gateway,Tags=[{Key=Name,Value=TGW-Region-B}]’

Step 3: Attach VPCs to Transit Gateways

GUI:

In VPC Console, select “Transit Gateway Attachments”
Click “Create Transit Gateway Attachment”
Configure settings:

CLI:

# Attach VPC to Transit Gateway in Region A

aws ec2 create-transit-gateway-vpc-attachment \
 - transit-gateway-id tgw-xxxxx \
 - vpc-id vpc-xxxxx \
 - subnet-ids subnet-xxxxx subnet-yyyyy \
 - region us-east-1

# Attach VPC to Transit Gateway in Region B

aws ec2 create-transit-gateway-vpc-attachment \
 - transit-gateway-id tgw-yyyyy \
 - vpc-id vpc-yyyyy \
 - subnet-ids subnet-aaaaa subnet-bbbbb \
 - region us-west-2

Step 4: Create Transit Gateway Peering Attachment

GUI:

In Region A’s VPC Console
Select “Transit Gateway Attachments”
Click “Create Transit Gateway Attachment”
Configure settings:

Attachment type: Peering Connection
Transit Gateway (Accepter): Select Region B’s TGW ID
Region: Select Region B

CLI:

# Create peering attachment
aws ec2 create-transit-gateway-peering-attachment \
 - transit-gateway-id tgw-xxxxx \
 - peer-transit-gateway-id tgw-yyyyy \
 - peer-region us-west-2 \
 - region us-east-1

Step 5: Accept Peering Attachment

GUI:

Switch to Region B’s VPC Console
Select “Transit Gateway Attachments”
Select the pending peering attachment
Click “Accept”

CLI:

# Accept peering attachment
aws ec2 accept-transit-gateway-peering-attachment \
 - transit-gateway-attachment-id tgw-attach-xxxxx \
 - region us-west-2

Step 6: Configure Route Tables

GUI:

In each region’s VPC Console:

Go to “Transit Gateway Route Tables”
Add routes pointing to the peered TGW
Update VPC route tables to route inter-region traffic through TGW

CLI:

# Add route to Transit Gateway route table in Region A
aws ec2 create-transit-gateway-route \
 - destination-cidr-block 10.20.0.0/16 \
 - transit-gateway-route-table-id tgw-rtb-xxxxx \
 - transit-gateway-attachment-id tgw-attach-xxxxx \
 - region us-east-1

# Add route to VPC route table in Region A
aws ec2 create-route \
 - route-table-id rtb-xxxxx \
 - destination-cidr-block 10.20.0.0/16 \
 - transit-gateway-id tgw-xxxxx \
 - region us-east-1

Step 7: Implementing Blackhole Routes

What Are Blackhole Routes?

A blackhole route drops traffic that matches a destination CIDR. It’s useful for:

Blocking specific IP ranges
Preventing unauthorized access
Implementing security controls
Avoiding routing loops
Isolating problematic traffic

GUI:

Navigate to VPC Console
Select “Transit Gateway Route Tables”
Select the appropriate route table
Choose “Actions” → “Create static route”
Configure the blackhole route:

CIDR block: (specify the IP range to block)
Choose “Blackhole”

CLI:

# Create a blackhole route in Region A
aws ec2 create-transit-gateway-route \
    --destination-cidr-block 10.0.0.0/16 \
    --blackhole \
    --transit-gateway-route-table-id tgw-rtb-xxxxx \
    --region us-east-1

# Create a blackhole route in Region B
aws ec2 create-transit-gateway-route \
    --destination-cidr-block 172.16.0.0/16 \
    --blackhole \
    --transit-gateway-route-table-id tgw-rtb-yyyyy \
    --region us-west-2

Common Blackhole Route Use Cases:

Blocking Non-Routable Address Spaces:

# Block RFC 1918 private addresses
aws ec2 create-transit-gateway-route \
 - destination-cidr-block 192.168.0.0/16 \
 - blackhole \
 - transit-gateway-route-table-id tgw-rtb-xxxxx

aws ec2 create-transit-gateway-route \
 - destination-cidr-block 172.16.0.0/12 \
 - blackhole \
 - transit-gateway-route-table-id tgw-rtb-xxxxx

aws ec2 create-transit-gateway-route \
 - destination-cidr-block 10.0.0.0/8 \
 - blackhole \
 - transit-gateway-route-table-id tgw-rtb-xxxxx

Implementing Network Segmentation:

# Block access to specific environment
aws ec2 create-transit-gateway-route \
 - destination-cidr-block 10.100.0.0/16 \
 - blackhole \
 - transit-gateway-route-table-id tgw-rtb-xxxxx

Best Practices for Blackhole Routes:

Documentation

Maintain a list of all blackhole routes
Document the purpose of each blackhole route
Include expiration dates if temporary

Implementation Strategy

Start with more specific routes (/32, /24) before broader ones
Test in non-production environment first
Implement gradually to minimize impact

Monitoring

Monitor dropped packet metrics
Set up CloudWatch alarms for blocked traffic
Regular review of blackhole routes

Step 8: Verify Connectivity

Monitor dropped packet metrics

Launch EC2 instances in both VPCs
Test connectivity using ping or other network tools
Check Transit Gateway route tables for proper route propagation

Best Practices

Monitor dropped packet metrics
Use unique ASNs for each Transit Gateway
Implement proper security groups and NACLs
Monitor TGW CloudWatch metrics
Use resource tagging for better management
Document CIDR ranges and routing configurations

Troubleshooting Tips

Verify route table configurations
Check security group rules
Ensure CIDR ranges don’t overlap
Validate TGW attachment states
Review VPC route tables

Cost Considerations

Data transfer charges apply for inter-region traffic
TGW attachment hours are billed
Consider using AWS Cost Explorer for monitoring

Conclusion

With AWS Transit Gateway, you unlock a scalable and resilient inter-region communication framework. Integrating blackhole routes enhances your network control and stability. Whether you’re working in a multi-account, global setup, or building DR strategies, this architecture sets you up for long-term success.

Automating AWS DNS Firewall Domain List Updates Using S3, Lambda, and CLI

Esteban — Mon, 04 Nov 2024 15:42:29 +0000

In a previous article, I outlined a ClickOps process for manually creating a DNS Firewall domain list on AWS [link]. While this manual approach is straightforward, automating updates to your DNS list can streamline management and enhance security by keeping your firewall rules current without requiring constant manual intervention. In this article, I’ll provide a step-by-step guide to automating DNS Firewall domain list updates using AWS S3, Lambda, and CLI methods, offering a more efficient way to maintain DNS protections dynamically and at scale.

Benefits of Automation with AWS DNS Firewall

Efficiency: Automating DNS list updates saves time and reduces human error.
Scalability: Easily manage large lists of blocked domains across multiple VPCs.
Rapid Response: Automatically incorporate threat intelligence and updates in real time, improving security posture.

Automation Methods

Here are two ways to automate your AWS DNS Firewall updates:

Method 1: Automate Updates with AWS S3 and Lambda

This approach enables domain list updates whenever a file is uploaded to an S3 bucket.

Prerequisites

Prepare the text file, compile the file containing all the domains you want to block or allow.
Create a S3 Bucket.

Step 1 — Create the S3 Bucket and Upload the File:

Upload a file (e.g., blocked_dns_list.txt) containing the domains you want to block to the designated S3 bucket.

Step 2— Create the Lambda Function:

Go to the Lambda Console and click “Create Function”
Enter a Name, and choose as the Runtime “Python 3.10”
Click on “Create Function”.

Use the following Lambda function code to automate updates when a file is uploaded to S3:

import boto3
import json

def get_firewall_domain_list_id(r53resolver_client, list_name):
    try:
        paginator = r53resolver_client.get_paginator('list_firewall_domain_lists')
        for page in paginator.paginate():
            for domain_list in page['FirewallDomainLists']:
                if domain_list['Name'] == list_name:
                    return domain_list['Id']
        raise ValueError(f"Firewall domain list '{list_name}' not found")
    except Exception as e:
        raise Exception(f"Error getting firewall domain list ID: {str(e)}")

def lambda_handler(event, context):
    try:
        BUCKET_NAME = "S3-BUCKET-NAME"
        DOMAIN_LIST_NAME = "DOMAIN_LIST_NAME"

        key = event['Records'][0]['s3']['object']['key']
        source_bucket = event['Records'][0]['s3']['bucket']['name']
        if source_bucket != BUCKET_NAME:
            raise ValueError(f"Unexpected bucket: {source_bucket}")

        s3_client = boto3.client('s3')
        r53resolver_client = boto3.client('route53resolver')

        firewall_domain_list_id = get_firewall_domain_list_id(r53resolver_client, DOMAIN_LIST_NAME)

        response = s3_client.get_object(Bucket=BUCKET_NAME, Key=key)
        file_content = response['Body'].read().decode('utf-8')
        domains = [domain.strip() for domain in file_content.splitlines() if domain.strip()]

        response = r53resolver_client.update_firewall_domains(
            FirewallDomainListId=firewall_domain_list_id,
            Operation='REPLACE',
            Domains=domains
        )

        print(f"Successfully updated DNS Firewall Domain List with {len(domains)} domains")
        return {
            'statusCode': 200,
            'body': json.dumps({
                'message': 'Successfully updated DNS Firewall Domain List',
                'domainsUpdated': len(domains)
            })
        }

    except Exception as e:
        error_message = str(e)
        print(f"Error: {error_message}")
        return {
            'statusCode': 500,
            'body': json.dumps({
                'error': 'Error updating DNS Firewall Domain List',
                'message': error_message
            })
        }

Step 3— Configure IAM Permissions for the Lambda Function:

S3 Permissions:

To ensure the Lambda function can access the S3 bucket and update the DNS Firewall domain list, assign it the following IAM permissions:

s3:GetObject — This permission allows the Lambda function to read the content of the uploaded file in the S3 bucket, enabling it to retrieve the list of domains.
s3:ListBucket — While not strictly required for reading the file, this permission can be useful for verifying the existence of objects within the bucket, which aids in error handling and improves function reliability.

Adding these permissions to your Lambda function’s execution role ensures it can effectively retrieve and process domain lists from S3.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::my-threat-intel-bucket",
                "arn:aws:s3:::my-threat-intel-bucket/*"
            ]
        }
    ]
}

Route 53 Resolver Permissions

In addition to the S3 permissions, the Lambda function also interacts with Route 53 Resolver, necessitating the following permissions:

route53resolver:ListFirewallDomainLists — This permission allows the Lambda function to list existing firewall domain lists in Route 53, which is necessary for retrieving the ID of the domain list to update.
route53resolver:UpdateFirewallDomains — This permission is essential for allowing the Lambda function to modify the contents of the specified firewall domain list, enabling the addition or replacement of domains.

 {
      "Effect": "Allow",
      "Action": [
                "route53resolver:ListFirewallDomainLists",
                "route53resolver:UpdateFirewallDomains"
            ],
            "Resource": "*"
 }

Step 4— Set Up S3 Trigger for Lambda:

Configure S3 to invoke this Lambda function whenever a file is uploaded to your specified bucket. This trigger ensures that your DNS firewall domain list is automatically updated with each upload.
Go to your S3 Bucket and click on “Properties”
Create an Event Notification
Enter a name, and at the Event Type choose “All object create event”

At “Destinations” choose Lambda Function, and select the name of function.

Method 2: Automate with AWS CLI

For users who prefer command-line automation, AWS CLI offers an alternative:

aws route53resolver update-firewall-domains \
    --firewall-domain-list-id "rslvr-fdl-<Your_Domain_List_ID>" \
    --operation ADD \
    --domains "example1.com" "example2.com" "example3.com"

Steps:

Replace with your Route 53 Resolver domain list ID.
List your domains to block as arguments under the --domains parameter.
Run the command in your CLI to quickly add or remove domains as needed.

Additional Tips

Automation Frequency: Consider setting a schedule to update your lists based on threat intelligence feeds.
Logging and Monitoring: Enable CloudWatch logging for Lambda functions to track updates or errors.

Conclusion

Automating DNS Firewall domain list updates can significantly improve your AWS environment’s security while reducing operational overhead. By following these methods, you’ll ensure that your firewall rules are up-to-date, scalable, and responsive to the latest threats.

Best Practices for Monitoring Your Amazon VPC

Esteban — Tue, 08 Oct 2024 15:13:30 +0000

Monitoring your Amazon Virtual Private Cloud (VPC) is essential for ensuring optimal performance, security, and cost efficiency.

Here are some best practices and tools to effectively monitor your VPC.

Amazon CloudWatch

Amazon CloudWatch is a monitoring service that provides data and actionable insights. It allows you to track metrics and set alarms for:

Custom Metrics: Create metrics for specific VPC components like Elastic Load Balancers, NAT Gateways, and EC2 instances.
Dashboards: Visualize metrics using customizable dashboards to monitor the overall health of your VPC in real time.

VPC Flow Logs

VPC Flow Logs capture information about the IP traffic going to and from network interfaces in your VPC. This data can help you:

Analyze Traffic Patterns: Understand which resources are communicating and identify unusual traffic spikes.
Troubleshoot Connectivity Issues: Review flow logs to diagnose problems related to network traffic.
Monitor Security Threats: Set up alerts for unusual patterns, such as excessive traffic to or from specific IP addresses.

AWS Config

AWS Config provides visibility into your AWS resources and their configurations. By enabling AWS Config, you can:

Track Configuration Changes: Monitor changes to VPC resources like route tables, security groups, and network ACLs.
Ensure Compliance: Set rules to verify that your VPC adheres to security policies, automating compliance checks.

AWS Trusted Advisor

AWS Trusted Advisor provides real-time guidance to help you provision resources according to AWS best practices. It includes checks for:

Cost Optimization: Identify underutilized resources that may be costing you money.
Security Best Practices: Review your VPC security settings and access controls for potential vulnerabilities.

Regular Audits and Reviews

Conduct regular audits of your VPC configurations and security settings:

Review Security Groups: Ensure that only necessary ports and protocols are open.
Check Route Tables: Verify that routes are correctly configured and that there are no unintended access points.
Access Controls: Regularly review IAM policies and roles associated with your VPC resources.

Alerting and Notification Systems

Set up alerting mechanisms using CloudWatch Alarms or AWS Lambda to notify you of critical issues. Consider integrating with communication tools like:

Amazon SNS (Simple Notification Service): Automatically send notifications via SMS or email when specific alarms are triggered.
Slack or Microsoft Teams: Use webhooks to send real-time updates to your team.

Third-Party Monitoring Tools

Consider using third-party monitoring solutions such as:

Datadog: Offers advanced monitoring and analytics for AWS resources, including VPC performance.
New Relic: Provides application performance monitoring that can include network performance insights.
Nagios: A powerful monitoring tool that can track your VPC resources and alert you to any issues.

Conclusion

Effective monitoring of your Amazon VPC is crucial for maintaining performance, security, and cost efficiency. By leveraging built-in AWS services and third-party tools, you can gain valuable insights, proactively address issues, and optimize your cloud infrastructure.

Reference: https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html

AWS Network Firewall: A Simple Lab Setup Guide - ClickOps

Esteban — Sat, 31 Aug 2024 02:41:48 +0000

AWS Network Firewall is a powerful tool that empowers organizations to secure their applications and infrastructure in the cloud. Understanding how to set up and configure the AWS Network Firewall is crucial for ensuring a robust and resilient network environment. In this hands-on lab, we will go through the process of setting up an AWS environment that optimally utilizes AWS Network Firewall.

Topology

Prerequisites

Before delving into the lab setup, ensure that you have the following prerequisites in place:

An AWS account with the appropriate permissions to create and manage network resources.
A foundational understanding of Amazon VPC concepts, EC2, and AWS services.
Deployment of a VPC, public subnet, and internet gateway should be completed prior to commencing this lab.

Step 1: Setting up the environment.

Create a dedicated subnet for the Network Firewall

In your AWS Console go to VPC >> Subnets >> Create a Subnet

Note: A Network Firewall needs a dedicated subnet with a /28 or larger IP space.

Network Firewall — Rule Groups

Once the subnet is ready, we can move on to creating Network Firewall Rule Groups.

Think of a rule group as a set of rules that dictate how traffic is handled by AWS Network Firewall. These rules help us decide which network traffic is allowed or blocked based on specific criteria. Rule groups are vital for setting up and enforcing security policies for your AWS Network Firewall.

On you VPC Dashboard go to: Network Firewall >> Network Firewall rule groups.

In AWS Network Firewall, there are two main types of rule groups:

Stateful: These are like smart rules that understand the context of network traffic. They can allow or block traffic based on things like source, destination, and more. Think of them as traffic cops that can make decisions based on what they see.
Stateless: These are more like basic traffic filters. They follow simple rules to either allow or block traffic, without understanding the context. It’s like a list of specific traffic rules that are applied without considering the bigger picture.

We will create three type of rule groups:

Stateful group for Domain List
Stateful group standard
Stateless

Stateful group for Domain List

Domain List Rule Group is designed to filter and control network traffic based on domain names, which are like web addresses. You can create a list of domain names that you want to allow or block. This rule group is especially useful for managing access to specific websites or online services.

Note: Capacity is the number of rules you expect to have in this rule group during its lifetime. You can’t change capacity after rule group creation, so leave room to grow.

You can list all the domains that you would like to inspect to either allow or deny.

We will use the following examples:

For now, we will keep the Action to “Allow”.

Stateful groups Standard

This is a more general-purpose rule group that can be customized to match your specific network security needs. It allows us to define rules based on unique requirements, making it versatile for various use cases.

For example, we can specify the values for Layer 3 and Layer 4.

For our lab, we will create an ICMP group rule, and as before, we keep the action as “Pass”.

Stateless group

A stateless rule group in AWS Network Firewall is like a basic set of traffic rules. It decides what traffic can come in and go out of your network, but it doesn’t remember previous actions or understand the bigger picture of the traffic flow. It’s a bit like a gatekeeper checking each person’s ID at the door without knowing anything about them except what’s on the ID. Simple and effective for straightforward security needs.

For our lab, we will create a simple Stateless rule group for all the traffic in and out of our VPC.

After all the Rule groups are created, we should have a list simimar to:

Step 2: Creating a Network Firewall Policy

An AWS Network Firewall policy defines the monitoring and protection behavior for a firewall. The details of the behavior are defined in the rule groups that you add to your policy, and in some policy default settings. To use a firewall policy, you associate it with one or more firewalls.

On your VPC Dashboard go to: Network Firewall >> Firewall Policies and “Click” on create.

Select the Stateless rule group created previously.

Select both stateful rule group created previously.

Click on “Create Firewall Policy”

Step 3: Creating a Network Firewall

An AWS Network Firewall connects a firewall policy, which defines network traffic monitoring and filtering behavior, to the VPC that you want to protect.

The firewall configuration includes specifications for the Availability Zones and subnets where the firewall endpoints are placed. It also defines high-level settings like the firewall logging configuration and tagging on the AWS firewall resource.

On you VPC Dashboard go to: Network Firewall >> Firewalls and click on create.

We choose the VPC where we want our Firewall to inspect the traffic.

We associate the Firewall Policy created on the previous step with our Network Firewall.

Note: Once the firewall creation is completed, go to the details and take note of the Endpoint ID. We will use that value later.

Loggin

Network Firewall generates logs for stateful rule groups. You can configure different destinations for different log types.

Note: You can record alert logs and flow logs from your Network Firewall stateful engine.

Alert logs report traffic that matches your stateful rules that have an action that sends an alert. A stateful rule sends alerts for the rule actions DROP, ALERT, and REJECT.
Flow logs are standard network traffic flow logs. Each flow log record captures the network flow for a specific standard stateless rule group.

Keep any other value as default and go all the way to “Create Firewall”.

Step 4: Routing Configuration

Up to this point, we have created:

Subnet for our Firewall
Rule Groups (Stateful and Stateless)
Firewall Policy
Network Firewall

Before you begin testing out your firewall rules, you need to adjust routing to send traffic through the firewall.

We need to create two new Route Tables:

Internet gateway (IGW) ingress route table.
Firewall subnet route table.

Internet Gateway Route Table

On your VPC Dashboard go to: Route Tables >> Create Route Table

When creating this Route Table, make sure to select the right VPC. On the Edit edge associations section, click on edit and select the Internet gateway.

Now we need to create a route entry that will forward the incoming traffic to the Firewall.

For Destination, enter use the CIDR of your public subnet network. In our lab the address is: 10.0.0.0/24
For Target, select Gateway Load Balancer Endpoint and search for the VPC firewall endpoint that starts with vpce-.

Note: Use the Network Firewall Endpoint ID from step 3.

Firewall route table

We will create a new route table for our firewall and will direct all the outgoing traffic (0.0.0.0/0) to the internet gateway.

We associate this route table with the FirewallSubnet created on step 1.

Finally, we configure our Public Route table (part of the pre-requirement) to forward the outgoing traffic to the Firewall.

Note: Use the Network Firewall Endpoint ID from step 3.

At this point we should have the following three route tables:

Public Route table
Ingress Route table
Firewall Route table

Step 5: Testing

We will verify network connectivity between the EC2 instances and the internet to evaluate the firewall’s ability to block or allow traffic based on your defined rules.

Connecting to our EC2 via CLI we can perform the following:

Using “curl” we will check connectivity with the domains listed on the DomainList Rule Group
Using “ping” we will test the Stateful Standard Rule Group created for ICMP traffic.

At this point both Rule Groups are configured as Allow or Pass, then we should have the following behavior:



curl www.example.com
<!doctype html>
<html>
<head>
    <title>Example Domain</title>

    <meta charset="utf-8" />
    <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <style type="text/css">
    body {
        background-color: #f0f0f2;
        margin: 0;
        padding: 0;
        font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", "Open Sans", "Helvetica Neue", Helvetica, Arial, sans-serif;

    }
    div {
        width: 600px;
        margin: 5em auto;
        padding: 2em;
        background-color: #fdfdff;
        border-radius: 0.5em;
        box-shadow: 2px 3px 7px 2px rgba(0,0,0,0.02);
    }
    a:link, a:visited {
        color: #38488f;
        text-decoration: none;
    }
    @media (max-width: 700px) {
        div {
            margin: 0 auto;
            width: auto;
        }
    }
    </style>
</head>

<body>
<div>
    <h1>Example Domain</h1>
    <p>This domain is for use in illustrative examples in documents. You may use this
    domain in literature without prior coordination or asking for permission.</p>
    <p><a href="https://www.iana.org/domains/example">More information...</a></p>
</div>
</body>
</html>



ping 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=10.0 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=11.2 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=116 time=11.0 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=116 time=10.5 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 10.015/10.726/11.292/0.489 ms

Everything seems to be working as expected. Now, we will modify the action on each of the Rule Groups to Deny or Drop.

curl www.example.com --max-time 5

— max-time 5 tell the curl command to only try for 5 connections.

As we can see, we are not able to connect to www.example.com



PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4088ms

The same result when using ping.

This confirms that the Stateful Rule Groups are working as expected and traffic is denied.

Conclusion

In this simple lab, we have gained valuable insights into setting up an AWS environment that effectively utilizes AWS Network Firewall. This knowledge will enable us to design, implement, and manage secure networking infrastructures in the cloud, safeguarding our applications and data.

AWS VPC Peering vs Transit Gateway: Which One Should You Use?

Esteban — Tue, 27 Aug 2024 13:29:11 +0000

Amazon Web Services (AWS) provides a robust set of networking services to enable seamless communication between resources in a Virtual Private Cloud (VPC).

Two popular options for connecting VPCs are VPC peering and Transit Gateway.

Let’s go over some key differences between the two.

What is VPC peering?

VPC peering allows direct communication between two VPCs. It is a one-to-one connection, meaning you need to create peering connections for each pair of VPCs you want to connect.

VPC peering is relatively straightforward to set up. You establish a peering connection between two VPCs by configuring route tables and accepting connection requests.

On regards to latency, peering connections are generally low-latency since traffic travels directly between the peered VPCs without additional hops.

One thing to keep in mind is that VPC peering is not transitive. If you have multiple VPCs that need to communicate with each other in a hub-and-spoke topology, you must create separate peering connections for each pair.

One of the main issues with this solutions is managing multiple peering connections, which can become complex as your network grows. This can lead to administrative overhead and increased potential for misconfigurations.

As for cost, the data transfer costs are incurred for traffic that flows between peered VPCs. This can be a consideration in your cost management strategy.

When to use VPC peering:

VPC peering is a good option for connecting two VPCs when you need a simple, one-to-one connection with low latency. For example, you might use VPC peering to connect a production VPC to a development VPC.

What is AWS transit gateway?

Transit Gateway is designed to **simplify and centralize network **connectivity. It acts as a hub that connects multiple VPCs, VPNs, and Direct Connect connections, making it a one-to-many or many-to-many solution. This allows TG to simplify network management by providing a single point of connectivity. You configure routing once and can connect numerous VPCs.

While Transit Gateway introduces an additional network hop compared to VPC peering, the impact on latency is typically minimal and well within acceptable limits.

On regards to traffic routing, Transit Gateway supports transitive routing, allowing traffic to flow between any attached VPCs, even if there is no direct peering connection between them. This makes it ideal for hub-and-spoke or full-mesh network architectures. Plus, this service scales easily, supporting hundreds of VPCs, making it suitable for large and complex network infrastructures.

As for cost, data transfer costs for traffic within Transit Gateway are generally lower than using VPC peering for the same level of connectivity due to its hub-and-spoke architecture.

When to use Transit Gateway:

Transit Gateway is a good option for connecting multiple VPCs together in a scalable and transitive way. It is especially well-suited for hub-and-spoke or full-mesh network architectures. If you have a complex network or need to connect a large number of VPCs, Transit Gateway is a good choice.

It is also a good choice for organizations that need to connect their VPCs to on-premises networks or to other AWS services, such as AWS Direct Connect and AWS VPN. Transit Gateway provides a central point of connectivity for all of these resources, making it easier to manage and secure your network.

Choosing the Right Solution

The choice between VPC peering and Transit Gateway depends on your specific requirements and network design. Here are some considerations to help you decide:

Simple vs. Complex Networks:

For smaller, less complex networks with only a few VPCs that need to communicate, VPC peering might suffice. However, if your network is larger, more complex, or needs transitive routing, Transit Gateway is likely the better choice.

Scalability:

Transit Gateway is the clear winner for scalability. If your network is expected to grow, or if you’re unsure about its size in the future, choosing Transit Gateway can save you from the complexities of managing numerous peering connections.

Cost:

Transit Gateway often provides cost savings in terms of data transfer costs, especially in scenarios with multiple VPCs. Consider your budget and how data transfer charges might impact it.

Transitive Routing:

If you require transitive routing (i.e., traffic can flow between VPCs without direct peering connections), Transit Gateway is the way to go.

Conclusion

Both services are valuable tools for connecting VPCs in AWS, but they serve different purposes. While VPC peering is a good option for simple, one-to-one connections, Transit Gateway is a better choice for complex, scalable, and transitive network architectures.

By understanding the differences between these two solutions, you can make informed decisions to meet your specific networking needs on AWS.