DEV Community: Hashir Saud Khan

Understanding AWS Route 53 Routing Policies

Hashir Saud Khan — Fri, 07 Aug 2026 08:10:32 +0000

aws #route53 #dns #networking

AWS Route 53 Routing Policies Explained

INTRO
Route 53 is AWS's DNS service. When someone types www.example.com into their browser, Route 53 is what decides which server or IP address that request actually gets sent to.

A routing policy is simply the rule Route 53 follows to answer one question:

"Which server or location should this user be sent to?"

There are eight routing policies, and each one answers that question a different way. Let's go through them one at a time.

1. SIMPLE ROUTING POLICY
The most basic option. You have one domain, myapp.com, and one server, 10.0.0.1. Route 53 sends every single user to that same server.

User → myapp.com → Server 1

Use this when you only have one server and don't need any special routing logic at all.

Easy way to remember it: "Send everyone to the same place."

2. WEIGHTED ROUTING POLICY
Here, traffic is split across servers based on a percentage/weight you assign.

Server 1 → Weight 80
Server 2 → Weight 20

Out of 100 users, roughly 80 land on Server 1 and 20 land on Server 2.

Real example: You're testing a new version of your app. You send 90% of traffic to the old version and 10% to the new one:

Users
  ↓
Route 53
 ↙    ↘
90%    10%
Old    New

If the new version holds up well, you can gradually shift the split to 50/50, then eventually 100% new version.

Easy way to remember it: "Divide traffic by percentage."

3. LATENCY ROUTING POLICY
Route 53 sends the user to whichever server gives them the lowest latency — the fastest response time.

Pakistan  → Karachi
USA       → Virginia
Europe    → Frankfurt

A user connecting from Pakistan would generally be routed to the Karachi endpoint, if that's the server offering the lowest latency for them:

Pakistan User
    ↓
Route 53
    ↓
Karachi Server

A user in the USA gets routed differently:

USA User
    ↓
Route 53
    ↓
Virginia Server

Easy way to remember it: "Send the user to whichever server is fastest for them."

4. FAILOVER ROUTING POLICY
This one exists for backup servers.

Primary Server   → Working
Secondary Server → Backup

Normally, all traffic goes to the primary:

User → Primary Server

But if a health check detects the primary is down, traffic automatically shifts:

Primary ❌
   ↓
Route 53
   ↓
Secondary ✅

Real example: Your main website server is in Karachi. Your backup server sits in Singapore. If the Karachi server goes down, Route 53 automatically starts sending users to the Singapore server instead.

Easy way to remember it: "Primary down? Send them to the backup."

5. GEOLOCATION ROUTING POLICY
This routes users based on their actual location.

Pakistan user → Pakistan server
USA user      → USA server
UK user       → UK server

Say you run example.com and you want:

Pakistani users to see the Pakistan-specific site
US users to see the US-specific site

Geolocation routing is exactly built for that.

Important distinction:

Latency picks whichever server is fastest, regardless of where the user actually is
Geolocation picks a server based on the user's country, regardless of which one is technically fastest

Easy way to remember it: "Where is the user coming from?"

6. GEOPROXIMITY ROUTING POLICY
This is also location-based, but here you can actually adjust the size of the geographic area each server covers.

Say you have:

AWS Lahore
AWS Singapore

You could decide that most of Pakistan's traffic should go to Lahore, while Singapore and nearby regions go to the Singapore server. You can also apply a bias — for example, if you want the Lahore server to cover a larger geographic area than it normally would, you increase its bias to expand its coverage zone.

Easy way to remember it: "Control the geographic boundary to steer traffic."

7. MULTIVALUE ANSWER ROUTING POLICY
Here, Route 53 can return multiple healthy IP addresses in a single response instead of just one.

Server 1 → 10.0.0.1
Server 2 → 10.0.0.2
Server 3 → 10.0.0.3

Route 53's DNS response might include all three:

DNS Response:
10.0.0.1
10.0.0.2
10.0.0.3

The client then picks one of those addresses to actually connect to. If health checks are enabled, any unhealthy endpoint gets excluded from that list automatically.

Easy way to remember it: "Return several healthy server IPs instead of just one."

8. IP-BASED ROUTING POLICY
This routes traffic based on the user's source IP address.

User IP: 10.x.x.x → Server A
User IP: 20.x.x.x → Server B

You can map specific IP ranges directly to specific endpoints.

Simple example:

Company employees' IP range → Internal Server
Everyone else                → Public Server

That's a good fit for IP-based routing.

Easy way to remember it: "Check the user's IP, then route accordingly."

QUICK REFERENCE TABLE

Policy	Simple meaning	Example
Simple	Everyone gets the same server	Everyone → Server A
Weighted	Split by percentage	80% → A, 20% → B
Latency	Fastest/lowest-latency server	Pakistan → Karachi
Failover	Primary down → backup takes over	A ❌ → B
Geolocation	Based on the user's location	Pakistan → Pakistan server
Geoproximity	Based on geographic area/bias	Lahore gets a larger coverage area
Multivalue	Returns multiple healthy IPs	A + B + C
IP-based	Based on the user's source IP	IP range A → Server A

SHORTCUT FOR REMEMBERING THESE

Simple = Same
Weighted = Percentage
Latency = Fastest
Failover = Backup
Geolocation = Where the user is
Geoproximity = Geographic area control
Multivalue = Multiple IPs
IP-based = User's IP

If you're studying this for an AWS exam, the distinction between Latency vs. Geolocation vs. Geoproximity is the one worth spending the most time on — they all sound similar but solve genuinely different problems.

AWS #Route53 #DNS #Networking #CloudComputing

Scaling and Load Balancing Your Architecture on AWS ⚖️

Hashir Saud Khan — Thu, 06 Aug 2026 07:22:33 +0000

INTRO
This lab takes a single web server and turns it into a properly scalable, load-balanced setup. You start with one EC2 instance running a web app, and by the end, you have a load balancer spreading traffic across multiple instances, an Auto Scaling group automatically adding or removing instances based on CPU load, and CloudWatch alarms watching it all in the background.

Starting Arcitecture

Final Arcitecture

KEY TERMS YOU'LL SEE
Before jumping into steps, here's every term this lab throws at you, defined once so nothing feels unfamiliar later:

AMI (Amazon Machine Image) — a saved snapshot of an instance's boot disk. Once you have one, you can launch as many identical instances from it as you want.
Load Balancer (specifically an Application Load Balancer) — a service that sits in front of your instances and spreads incoming traffic across them, so no single instance gets overwhelmed.
Target Group — the list of instances a load balancer is actually allowed to send traffic to. The load balancer doesn't talk to instances directly; it talks to a target group, and the target group tracks which instances are in it and whether they're healthy.
Listener — a rule on the load balancer that checks for connection requests on a specific port and protocol (like HTTP on port 80) and forwards matching traffic to a target group. It's the piece that actually connects "traffic coming in" to "which target group handles it."
Launch Template — a saved configuration (AMI, instance type, security group, etc.) that tells AWS exactly how to launch a new instance. Auto Scaling doesn't guess what a new instance should look like — it reads this template.
Auto Scaling Group (ASG) — a group of instances that AWS automatically keeps within a size range you define (a minimum, a desired count, and a maximum), launching or terminating instances as needed.
CloudWatch Alarm — a watcher that tracks a metric (like average CPU) and flips into an "In alarm" state when a threshold is crossed, which is what actually triggers Auto Scaling to act.

Keep these seven in mind — every task below is really just building one of them.

TASK 1: CREATE AN AMI FROM THE EXISTING WEB SERVER

Open the EC2 console and go to Instances
Select the Web Server 1 instance (it should be in a Running state)
From the Actions dropdown, choose Image and templates → Create image
Set:
- Image name: Web Server AMI
- Image description: Lab AMI for Web Server
Choose Create image

The confirmation screen gives you the new AMI's ID — you'll need this AMI later when setting up the launch template.

Why we did this: Auto Scaling needs a repeatable template for new instances, and that template starts with an AMI — a frozen copy of a working server, ready to be cloned on demand.

TASK 2: CREATE A LOAD BALANCER

In the EC2 console, go to Load Balancing → Load Balancers
Choose Create load balancer, then under Application Load Balancer, choose Create
Under Basic configuration, set the Load balancer name: LabELB
Under Network mapping:
- VPC: Lab VPC
- Mappings: select both Availability Zones
- First Availability Zone: Public Subnet 1
- Second Availability Zone: Public Subnet 2
Under Security groups: remove the default security group, then attach Web Security Group (already created for you, permits HTTP)
Under Listeners and routing, choose Create target group — this opens a new tab
In that new tab, configure the target group:
- Target type: Instances
- Target group name: lab-target-group
- Choose Next, then on the Register targets page, choose Create target group (don't register any instances yet — the Auto Scaling group will do that automatically later)
Close that tab and return to the load balancer tab
Next to the Forward to dropdown under Default action, choose the refresh icon, then select lab-target-group
Choose Create load balancer
Once created, choose View load balancer, then copy the load balancer's DNS name into a text editor — you'll need it soon to actually open the app in a browser

Why we did this: A load balancer without a target group has nowhere to send traffic — the target group is what actually tracks which instances exist and whether they're healthy enough to receive requests.

TASK 3: CREATE A LAUNCH TEMPLATE

In the EC2 console, go to Instances → Launch Templates
Choose Create launch template
Set:
- Launch template name: lab-app-launch-template
- Template version description: A web server for the load test app
- Check Provide guidance to help me set up a template that I can use with EC2 Auto Scaling
Under Application and OS Images, go to the My AMIs tab — Web Server AMI (the one you created in Task 1) should already be selected
Under Instance type, choose t3.micro
Under Key pair (login), leave it set to Don't include in launch template — you won't need to SSH into these instances directly
Under Network settings, set Security groups to Web Security Group
Choose Create launch template

Why we did this: This is the recipe Auto Scaling reads every time it needs to launch a new instance — AMI, instance type, and security group all bundled together so nothing has to be configured manually per-instance.

TASK 4: CREATE AN AUTO SCALING GROUP

From the launch template you just created, choose Actions → Create Auto Scaling group
Auto Scaling group name: Lab Auto Scaling Group, then choose Next
Under Network:
- VPC: Lab VPC
- Availability Zones and subnets: select Private Subnet 1 (10.0.1.0/24) and Private Subnet 2 (10.0.3.0/24)
Choose Next
On the advanced options page:
- Under Load balancing, choose Attach to an existing load balancer
- Choose Choose from your load balancer target groups, then select lab-target-group | HTTP
- Under Health checks, set Health check type to ELB
Choose Next
On the group size and scaling policies page:
- Desired capacity: 2
- Minimum capacity: 2
- Maximum capacity: 4
- Under Scaling policies, choose Target tracking scaling policy
- Metric type: Average CPU utilization
- Target value: 50
Choose Next through the notifications page (nothing to configure)
On the Add tags page, add a tag:
- Key: Name
- Value: Lab Instance
Choose Next, then Create Auto Scaling group

Note: instances launch into private subnets — they're not directly reachable from the internet, only through the load balancer sitting in the public subnets.

Why we did this: This single group definition replaces manually launching, monitoring, and terminating instances yourself — you just declare the size range and the CPU target, and AWS keeps reality matching that declaration on its own.

TASK 5: VERIFY LOAD BALANCING IS WORKING

Go to EC2 → Instances — you should see two new instances named Lab Instance, launched automatically by the Auto Scaling group
Go to Load Balancing → Target Groups, choose lab-target-group
Under Registered targets, both Lab Instance entries should appear
Wait until both show a Healthy status (refresh as needed) — this confirms each instance is passing the load balancer's health check and is eligible to receive traffic
Open a new browser tab, paste the load balancer's DNS name from Task 2, and press Enter — the Load Test application should load

Why we did this: A healthy status is the load balancer's way of confirming an instance is actually ready for traffic — without this check, the load balancer might send requests to an instance that's still booting or broken, and users would see failures.

TASK 6: TEST AUTO SCALING UNDER LOAD

Go to the CloudWatch console → Alarms → All alarms — you'll see two alarms, created automatically by the Auto Scaling group (a "high CPU" alarm and a "low CPU" alarm), keeping the group's average CPU near the 50% target within its 2–4 instance range
Check the alarm with AlarmHigh in its name — it should currently show state OK (CPU is low, nothing to react to yet)
Go back to the Load Test application tab, and choose Load Test next to the AWS logo — this deliberately spikes CPU usage across the running instances, and the page auto-refreshes to keep the load going
Return to the CloudWatch console — within about 5 minutes, watch for:
- AlarmLow flipping to OK
- AlarmHigh flipping to In alarm, once average CPU crosses 50% for more than 3 minutes
Once AlarmHigh is In alarm, go back to EC2 → Instances — you should now see more than two Lab Instance entries running, launched automatically in response to the alarm

Why we did this: This is the actual proof the whole setup works — not just that instances exist, but that real load causes CloudWatch to detect it and Auto Scaling to react to it, exactly as configured.

TASK 7: TERMINATE THE ORIGINAL WEB SERVER

Go to EC2 → Instances, select only Web Server 1
From Instance state, choose Terminate instance, then confirm with Terminate

Why we did this: Web Server 1 already did its one job — becoming the AMI everything else is built from. Keeping it running afterward serves no purpose and just adds an untracked, unmanaged instance sitting outside your Auto Scaling group.

OPTIONAL CHALLENGE: CREATE AN AMI USING THE AWS CLI
If there's time left, repeat Task 1's goal — but through the CLI instead of the console:

Connect to one of your running EC2 instances using EC2 Instance Connect
Configure your AWS CLI credentials
Use the aws ec2 create-image command, supplying an AMI name and the instance ID you want to image

Why we did this: Every console action in this lab has a CLI equivalent — this challenge is a reminder that nothing here is console-exclusive; it's all scriptable and automatable the same way.

WHY THIS MATTERS OVERALL

A load balancer, target group, launch template, and Auto Scaling group aren't four separate features — they're one pipeline: template defines the instance, the group manages how many exist, and the target group is how the load balancer finds them
Placing Auto Scaling instances in private subnets while the load balancer sits in public subnets is a real security pattern — the only path in is through the load balancer, nothing is directly internet-facing
CloudWatch alarms are the trigger, not the mechanism — Auto Scaling still needs a target tracking policy telling it what to do once an alarm fires
Terminating the original instance after imaging it is easy to forget, but leaving it running defeats the purpose of consolidating everything into a managed, scalable group

AWS #LoadBalancing #AutoScaling #CloudWatch #EC2 #CloudComputing

Building a Serverless Sales Report with AWS Lambda, SNS, and CloudWatch 📊⚡

Hashir Saud Khan — Thu, 06 Aug 2026 07:04:26 +0000

aws #lambda #serverless #tutorial

Working with AWS Lambda

INTRO
This lab builds a small but complete serverless pipeline: a Lambda function that runs on a schedule, pulls sales data out of a MySQL database running on a Café web app, formats it into a report, and emails it to you — all without a single server you manage yourself. Along the way you'll create two Lambda functions, a Lambda layer for a shared library, an SNS topic for email delivery, and a CloudWatch schedule to trigger the whole thing automatically.

Here's the flow, start to finish:

A CloudWatch schedule triggers salesAnalysisReport every evening
That function calls a second function, salesAnalysisReportDataExtractor
The extractor queries the café database directly
The result comes back to salesAnalysisReport
salesAnalysisReport formats it into a message and publishes it to an SNS topic
SNS emails the finished report to you

Everything below builds one piece of that chain at a time.

TASK 1: LOOK AT THE IAM ROLES BEFORE TOUCHING ANYTHING
Before creating either function, you look at the two IAM roles they'll use, so you know exactly what each function is — and isn't — allowed to do.

salesAnalysisReportRole (used by the report function):

AmazonSNSFullAccess — lets it publish the report to SNS
AmazonSSMReadOnlyAccess — lets it read the database credentials from Parameter Store
AWSLambdaBasicRunRole — lets it write logs to CloudWatch
AWSLambdaRole — lets it invoke another Lambda function (the data extractor)

salesAnalysisReportDERole (used by the data extractor function):

AWSLambdaBasicRunRole — same logging permission
AWSLambdaVPCAccessRunRole — lets it create network interfaces so it can actually reach into the VPC where the database lives

Why we did this: Every Lambda function is only as capable as the role attached to it — no role, no permission, no matter how correct the code is. Looking at these upfront means that later, if a function fails with an access error, you already know exactly which permission to check first instead of guessing blind.

TASK 2: CREATE A LAMBDA LAYER, THEN THE DATA EXTRACTOR FUNCTION
This task has five parts — a layer, a function, attaching the layer, importing code, and wiring up networking.

Grab the two files you'll need for this task:

2.1 — Create the Lambda layer:
In Lambda → Layers → Create layer:

Name: pymysqlLibrary
Description: PyMySQL library modules
Upload the pymysql-v3.zip file
Compatible runtime: Python 3.9

2.2 — Create the data extractor function:
In Functions → Create function:

Author from scratch
Name: salesAnalysisReportDataExtractor
Runtime: Python 3.9
Execution role: use the existing salesAnalysisReportDERole

2.3 — Attach the layer to the function:
In the function's Layers section → Add a layer → Custom layers → pymysqlLibrary, version 1.

2.4 — Import the actual code:
In Runtime settings, set the handler to salesAnalysisReportDataExtractor.lambda_handler, then upload salesAnalysisReportDataExtractor-v3.zip as the code source. Take a minute to actually read through the code and its comments — notice it expects dbURL, dbName, dbUser, and dbPassword to be passed in as part of its input event.

2.5 — Configure networking:
Under Configuration → VPC, set:

VPC: Cafe VPC
Subnet: Cafe Public Subnet 1
Security group: CafeSecurityGroup

Why we did this: A Lambda layer exists so you're not bundling the same library into every function that needs it — one shared package, reused anywhere. And the VPC step matters because Lambda functions run outside your VPC by default; without explicitly attaching it to the café's VPC, subnet, and security group, this function would have no network path to reach the database at all.

TASK 3: TEST THE DATA EXTRACTOR — AND FIX WHAT BREAKS
3.1 — Run a first test:
Grab the four database connection values from Parameter Store (/cafe/dbUrl, /cafe/dbName, /cafe/dbUser, /cafe/dbPassword), then create a test event on the function with those values as the JSON input:

{
  "dbUrl": "<value of /cafe/dbUrl>",
  "dbName": "<value of /cafe/dbName>",
  "dbUser": "<value of /cafe/dbUser>",
  "dbPassword": "<value of /cafe/dbPassword>"
}

Run the test — it fails.

3.2 — Read the failure:
The error says the task timed out after 3 seconds. That 3-second default timeout is barely enough time to even attempt a database connection, let alone get a response back — so this points squarely at something blocking the connection itself, not a code bug.

3.3 — Find and fix the real cause:
MySQL listens on port 3306. Check the inbound rules on the security group attached to the database's EC2 instance — if 3306 isn't open to the Lambda function's security group, the connection attempt just hangs until it times out. Add that inbound rule, then run the test again. This time it succeeds, but the response body comes back empty — there's simply no order data in the database yet.

3.4 — Put real data in, then test again:
Open the café website (http://<publicIP>/cafe), place a couple of orders through the menu, then re-run the test. This time the response body actually contains real order data — quantities, product names, everything the report needs.

Why we did this: This is a textbook case of "the code is fine, the network isn't" — a timeout error tells you almost nothing about why by itself, but knowing MySQL's default port narrows the search immediately. And testing with an empty database first, then a populated one, proves two separate things: that the connection works, and that the query logic itself is correct — not just that the function didn't crash.

TASK 4: SET UP THE EMAIL NOTIFICATION
4.1 — Create the SNS topic:
In SNS → Topics → Create topic:

Type: Standard
Name: salesAnalysisReportTopic
Display name: SARTopic

Save the topic's ARN — you'll need it in the next task.

4.2 — Subscribe your email:
Create a subscription on that topic with Protocol: Email, and your own email as the endpoint. Confirm it from the email AWS sends you.

Why we did this: SNS is the delivery mechanism, not the report generator — the Lambda function doesn't know how to send email itself, it just knows how to publish a message to a topic. Confirming the subscription is a required step too: an unconfirmed subscription silently receives nothing, so skipping it means the whole pipeline "works" but nobody ever sees the result.

TASK 5: CREATE THE MAIN REPORT FUNCTION — THIS TIME VIA THE CLI
5.1 — Connect to the CLI host:
Use EC2 Instance Connect to log into the CLI host instance, which already has the AWS CLI and the Python code for this function pre-loaded.

5.2 — Configure the CLI:

aws configure

Supply the access key, secret key, region (us-west-2 for this lab), and json as output format.

5.3 — Create the function via the CLI:
First confirm the code is where you expect it:

cd activity-files
ls

Grab the ARN of salesAnalysisReportRole from IAM, then create the function:

aws lambda create-function \
--function-name salesAnalysisReport \
--runtime python3.9 \
--zip-file fileb://salesAnalysisReport-v2.zip \
--handler salesAnalysisReport.lambda_handler \
--region <region> \
--role <salesAnalysisReportRoleARN>

5.4 — Configure the environment variable:
The code reads the SNS topic ARN from an environment variable called topicARN — it's not hardcoded in the function, so you have to set it. In Configuration → Environment variables, add:

Key: topicARN
Value: the ARN of salesAnalysisReportTopic from Task 4

5.5 — Test it:
Create a test event (no input parameters needed — this function doesn't take any), run it, and check for a statusCode: 200 response. Then check your inbox — you should receive an actual "Daily Sales Analysis Report" email with the items you ordered earlier.

5.6 — Add the daily trigger:
Add an EventBridge (CloudWatch Events) trigger with a schedule expression written as a Cron expression:

cron(Minutes Hours Day-of-month Month Day-of-week Year)

For testing, set it 5 minutes ahead of the current UTC time so you can see it fire quickly. For production, you'd want something like cron(0 20 ? * MON-SAT *) — 8 PM UTC, Monday through Saturday, matching the schedule described at the start of this lab.

Why we did this: Using the CLI here instead of the console is deliberate — it's the same underlying operation, just proving that Lambda functions can be created and deployed as part of a script or pipeline, not only by clicking through a UI. The environment variable step matters for a different reason: hardcoding an ARN into the code would mean editing and redeploying code every time the SNS topic changed, while an environment variable means you can update it in seconds without touching a single line of Python.

WHY THIS MATTERS OVERALL

Two functions calling each other, each with its own scoped IAM role, is a far safer pattern than one function with every permission bundled together
A timeout error almost always means "something on the network side is blocking me," not "my code is broken" — check ports and security groups before you start rewriting logic
Layers, environment variables, and VPC config all exist for the same underlying reason: keeping configuration and shared code outside the function itself, so changes don't require a full redeploy
Testing with empty data and then real data isn't redundant — it's how you separate "the connection works" from "the logic is correct"

AWS #Lambda #Serverless #SNS #CloudWatch #IAM #Cron

Troubleshooting a Broken EC2 Launch Script (LAMP Stack Edition) 🐛🔧

Hashir Saud Khan — Sun, 02 Aug 2026 10:48:56 +0000

Troubleshooting the Creation of an EC2 Instance

INTRO
This one's less about learning a new AWS service and more about a skill every cloud engineer eventually needs: reading someone else's script, figuring out why it's failing, and fixing it without rewriting the whole thing. You're handed a shell script that's supposed to launch a full LAMP stack instance (Linux, Apache, MariaDB, PHP) hosting a Café web app — except the script has two bugs baked into it on purpose. Your job is to find them the way you actually would in real life: by reading error messages, checking open ports, and following a log file.

WHAT THE SCRIPT IS SUPPOSED TO DO
Before touching anything broken, it's worth understanding what a working run of this script does:

Loops through every AWS region looking for a VPC named Cafe VPC
Once found, looks up the subnet, an existing key pair, and the latest Amazon Linux AMI ID
Cleans up any leftover instance or security group from a previous run
Creates a new security group
Launches the EC2 instance, attaching a user data script that installs Apache, MariaDB, and PHP, then deploys the actual website files
Waits for a public IP and prints it out

TASK 1: CONNECT AND SET UP
You connect to a CLI host instance using EC2 Instance Connect, then configure the AWS CLI with your access key, secret key, and region — same as any other CLI-based lab.

Why we did this: Nothing else in this lab works without a properly authenticated CLI session. This is the one step that has to be boring and correct before anything interesting happens.

TASK 2: READ THE SCRIPT BEFORE YOU RUN IT
Before running anything, you make a backup of the script and read through it in a text editor.

Why we did this: This is the habit that actually matters here. If you run a broken script blind and it fails, you're troubleshooting with zero context. If you read it first, you already have a mental model of what should happen, so when it breaks, you know roughly where to look instead of starting from scratch.

TASK 3: RUN IT — AND WATCH IT FAIL
You run the script, and it fails partway through with this error:

An error occurred (InvalidAMIID.NotFound) when calling the RunInstances operation:
The image id '[ami-xxxxxxxxxx]' does not exist

BUG #1: THE HARDCODED REGION
Here's the part of the script that creates the instance:

instanceDetails=$(aws ec2 run-instances \
--image-id $imageId \
--count 1 \
--instance-type $instanceType \
--region us-east-1 \
--subnet-id $subnetId \
--security-group-ids $securityGroup \
...

See it? Earlier in the script, it dynamically finds the correct region by searching every region for the Cafe VPC and stores it in a variable called $region. But then, right here in the run-instances command, it ignores that variable completely and hardcodes --region us-east-1.

AMI IDs are region-specific — the exact same AMI does not exist under the same ID in every region. So the script looked up a perfectly valid AMI ID in, say, us-west-2, and then tried to launch it in us-east-1, where that ID means nothing. That's exactly why AWS says the image doesn't exist — from that region's point of view, it genuinely doesn't.

The fix: swap the hardcoded value for the variable that was already found earlier in the script:

--region $region \

Run the script again, and this time run-instances succeeds — you get back a public IP address.

Why this bug mattered: This is a classic copy-paste trap. Somewhere along the way, someone probably tested the script against us-east-1 directly, hardcoded it to move fast, and forgot to swap it back to the dynamic variable. It's a one-line bug, but it perfectly explains a very confusing-looking error.

TASK 3 CONTINUED: THE WEBSITE STILL DOESN'T LOAD
With the instance launched, you try opening http://<public-ip> in a browser. Nothing loads.

The instance is running, it has a public IP — so what's left? This is where you stop guessing and start checking, one layer at a time.

BUG #2: THE WRONG PORT IN THE SECURITY GROUP
Look at the part of the script that opens ports:

echo "Opening port 22 in the new security group"
aws ec2 authorize-security-group-ingress \
--group-id $securityGroup \
--protocol tcp \
--port 22 \
...

echo "Opening port 80 in the new security group"
aws ec2 authorize-security-group-ingress \
--group-id $securityGroup \
--protocol tcp \
--port 8080 \
...

Read that carefully — the echo line says port 80, but the actual --port flag right below it says 8080. The message lies about what the command actually does. The security group only ever opens SSH (22) and 8080 — never 80, which is the port a web server actually needs for a plain http:// request.

How you'd actually catch this without reading the script: install nmap on the CLI host and scan the instance directly:

sudo yum install -y nmap
nmap -Pn <public-ip>

The scan shows you exactly which ports are open from the outside — and port 80 simply isn't one of them. That's your confirmation the security group, not the web server itself, is the problem.

The fix: change --port 8080 to --port 80 so it matches what the echo statement (and the actual website) needs.

Why this bug mattered: This is why you never fully trust comments or echoed log messages — they describe intent, not necessarily what the code underneath actually does. nmap sidesteps that entirely by checking the real, observable state of the network instead of what the script claims it configured.

CONFIRMING THE FIX WORKED
Reload http://<public-ip> — you should now see "Hello From Your Web Server!". That confirms Apache itself is up and reachable.

To confirm the rest of the user data script ran correctly (MariaDB, PHP, the actual Café app files), tail the cloud-init log on the instance:

sudo tail -f /var/log/cloud-init-output.log

You're looking for clean installation messages and no errors — plus a line confirming the database setup script completed.

Why we did this: A web page loading doesn't automatically mean everything worked — it only confirms the web server layer. The cloud-init log is where you'd catch a silent failure further down the stack, like the database script erroring out even though Apache came up fine.

TASK 4: VERIFY THE ACTUAL WEBSITE WORKS
Last step — visit http://<public-ip>/cafe and confirm the real Café web app loads, not just the placeholder message. From there, add a couple of items to an order, submit it, and check the Order History page shows both orders — proof that the database (MariaDB) is actually storing data, not just installed and idle.

Why we did this: This is the real end-to-end check. Ports open, Apache running, and the app loading are all necessary, but placing an order and seeing it persist is the only thing that proves the full LAMP stack — web server, PHP, and database — is genuinely working together.

WHY THIS MATTERS OVERALL

A confusing AWS error often has a boring, specific cause — InvalidAMIID.NotFound sounds scary, but it almost always just means "you're in the wrong region for that ID"
Never trust a hardcoded value sitting next to a variable that already exists for that exact purpose — that mismatch is one of the most common sources of "it worked yesterday" bugs
echo statements and comments describe what a script author intended — they're not proof of what the code actually does. Always check the real flag, not the message next to it
Tools like nmap let you verify the actual state of a system from the outside, instead of trusting that your configuration commands did what you assumed they did
Success at one layer (the web server responding) doesn't guarantee success at every layer underneath it (the database) — always confirm the deepest thing that actually matters, which here was placing a real order

AWS #EC2 #CLI #Troubleshooting #LAMP #Nmap #CloudComputing

📜 Click to view the full create-lamp-instance-v2.sh script

#!/bin/bash
DATE=`date '+%Y-%m-%d %H:%M:%S'`
echo
echo "Running create-instance.sh on "$DATE
echo
# Hard coded values
instanceType="t3.small"
echo "Instance Type: "$instanceType
profile="default"
echo "Profile: "$profile
echo
echo "Looking up account values..."
# get vpcId
vpc=""
while [[ "$vpc" == "" ]] ; do
  for i in $(aws ec2 describe-regions | grep RegionName | cut -d '"' -f4) ; do
    region=$i;
    vpc=$(aws ec2 describe-vpcs --region $i --filters "Name=tag:Name,Values='Cafe VPC'" --profile $profile | grep VpcId | cut -d '"' -f4 | sed -n 1p );
    if [[ "$vpc" != "" ]]; then
        break;
    fi
  done
done
echo
echo "VPC: "$vpc
echo "Region: "$region
vpc=$(aws ec2 describe-vpcs \
--filters "Name=tag:Name,Values='Cafe VPC'" \
--region $region \
--profile $profile | grep VpcId | cut -d '"' -f4 | sed -n 1p)
echo "VPC: "$vpc
# get subnetId
subnetId=$(aws ec2 describe-subnets \
--filters "Name=tag:Name,Values='Cafe Public Subnet 1'" \
--region $region \
--profile $profile \
--query "Subnets[*]" | grep SubnetId | cut -d '"' -f4 | sed -n 1p)
echo "Subnet Id: "$subnetId
# Get keypair name
key=$(aws ec2 describe-key-pairs \
--profile $profile --region $region | grep KeyName | cut -d '"' -f4 )
echo "Key: "$key
# Get AMI ID
imageId=$(aws ssm get-parameters \
--names '/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2' \
--profile $profile \
--region $region | grep ami- | cut -d '"' -f4 | sed -n 2p)
echo "AMI ID: "$imageId
#check for existing cafe instance
existingEc2Instance=$(aws ec2 describe-instances \
--region $region \
--profile $profile \
--filters "Name=tag:Name,Values=cafeserver" "Name=instance-state-name,Values=running" \
| grep InstanceId | cut -d '"' -f4)
if [[ "$existingEc2Instance" != "" ]]; then
  echo
  echo "WARNING: Found existing running EC2 instance with instance ID "$existingEc2Instance"."
  echo "This script will not succeed if it already exists. "
  echo "Would you like to delete it? [Y/N]"
  echo "&gt;&gt;"
  validResp=0
  while [ $validResp -eq 0 ];
  do
      read answer
      if [[ "$answer" == "Y" || "$answer" == "y" ]]; then
          echo
          echo "Deleting the existing instance..."
          aws ec2 terminate-instances --instance-ids $existingEc2Instance --region $region --profile $profile
          #wait for confirmation it was terminated
          aws ec2 wait instance-terminated --instance-ids $existingEc2Instance --region $region --profile $profile
          validResp="1"
      elif [[ "$answer" == "N" || "$answer" == "n" ]]; then
          echo "Ok, exiting."
          exit 1
      else
          echo "Please reply with Y or N."
      fi
  done
  sleep 10 #give it 10 seconds before trying to delete the SG this instance used.
fi
#check for existing cafeSG security Group
existingMpSg=$(aws ec2 describe-security-groups \
--region $region \
--query "SecurityGroups[?contains(GroupName, 'cafeSG')]" \
--profile $profile | grep GroupId | cut -d '"' -f4)
if [[ "$existingMpSg" != "" ]]; then
  echo
  echo "WARNING: Found existing security group with name "$existingMpSg"."
  echo "This script will not succeed if it already exists. "
  echo "Would you like to delete it? [Y/N]"
  echo "&gt;&gt;"
  validResp=0
  while [ $validResp -eq 0 ];
  do
      read answer
      if [[ "$answer" == "Y" || "$answer" == "y" ]]; then
          echo
          echo "Deleting the existing security group..."
          aws ec2 delete-security-group --group-id $existingMpSg --region $region --profile $profile
          validResp="1"
      elif [[ "$answer" == "N" || "$answer" == "n" ]]; then
          echo "Ok, exiting."
          exit 1
      else
          echo "Please reply with Y or N."
      fi
  done
  sleep 10 #give it 10 seconds before trying to recreate the SG
fi
# CREATE a security group and capture the name of it
echo
echo "Creating a new security group..."
securityGroup=$(aws ec2 create-security-group --group-name "cafeSG" \
--description "cafeSG" \
--region $region \
--group-name "cafeSG" \
--vpc-id $vpc --profile $profile | grep GroupId | cut -d '"' -f4 )
echo "Security Group: "$securityGroup
# Open ports in the security group
echo
echo "Opening port 22 in the new security group"
aws ec2 authorize-security-group-ingress \
--group-id $securityGroup \
--protocol tcp \
--port 22 \
--cidr 0.0.0.0/0 \
--region $region \
--profile $profile
echo "Opening port 80 in the new security group"
aws ec2 authorize-security-group-ingress \
--group-id $securityGroup \
--protocol tcp \
--port 8080 \
--cidr 0.0.0.0/0 \
--region $region \
--profile $profile
echo
echo "Creating an EC2 instance in "$region
instanceDetails=$(aws ec2 run-instances \
--image-id $imageId \
--count 1 \
--instance-type $instanceType \
--region us-east-1 \
--subnet-id $subnetId \
--security-group-ids $securityGroup \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=cafeserver}]' \
--associate-public-ip-address \
--iam-instance-profile Name=LabInstanceProfile \
--profile $profile \
--user-data file://create-lamp-instance-userdata-v2.txt \
--key-name $key )
#if the create instance command failed, exit this script
if [[ "$?" -ne "0" ]]; then
  exit 1
fi
echo
echo "Instance Details...."
echo $instanceDetails | python -m json.tool
# Extract instanceId
instanceId=$(echo $instanceDetails | python -m json.tool | grep InstanceId | sed -n 1p | cut -d '"' -f4)
echo "instanceId="$instanceId
echo
echo "Waiting for a public IP for the new instance..."
pubIp=""
while [[ "$pubIp" == "" ]]; do
  sleep 10;
  pubIp=$(aws ec2 describe-instances --instance-id $instanceId --region $region --profile $profile | grep PublicIp | sed -n 1p | cut -d '"' -f4)
done
echo
echo "The public IP of your LAMP instance is: "$pubIp
echo
echo "Download the Key Pair from the lab console."
echo
echo "Then connect using this command (with .pem or .ppk added to the end of the keypair name):"
echo "ssh -i path-to/"$key" ec2-user@"$pubIp
echo
echo "The website should also become available at"
echo "http://"$pubIp"/cafe/"
echo
DATE=`date '+%Y-%m-%d %H:%M:%S'`
echo
echo "Done running create-instance.sh at "$DATE
echo

Hosting a Static Website on Amazon S3 Using the AWS CLI 🌐🪣

Hashir Saud Khan — Thu, 30 Jul 2026 12:25:57 +0000

Creating a Website on S3

INTRO
This lab is about hosting a real static website — a Café & Bakery site — entirely on Amazon S3, using nothing but the AWS CLI from an EC2 instance. Along the way, you create a new IAM user with S3 access, upload the actual website files, and then build your own script so future updates take one command instead of repeating the whole upload process by hand.

By the end, you'll have a real public URL you can open in a browser and see the site live.

TASK 1: CONNECT TO THE EC2 INSTANCE USING SSM
You start by connecting to the instance through Systems Manager Session Manager — either from the EC2 console (select the instance, choose Connect, then the Session Manager tab) or through a session link if your environment provides one. Either way, this drops you straight into a terminal session on the instance, no SSH key involved.

Once connected, switch to the ec2-user account:

sudo su -l ec2-user
pwd

Why we did this: Every command in this lab needs to run from inside this instance, so this is just making sure you're actually in the right shell, as the right user, before doing anything else.

TASK 2: CONFIGURE THE AWS CLI
Amazon Linux comes with the AWS CLI already installed — unlike Red Hat, you don't need to download or unzip anything here. You just authenticate it:

aws configure

Then supply:

Access Key ID and Secret Access Key for your IAM user
Region: us-west-2
Output format: json

Why we did this: The CLI is just a tool — on its own it doesn't know which AWS account it's allowed to touch. This step is what connects it to your actual lab account so every command after this actually does something.

TASK 3: CREATE AN S3 BUCKET
Bucket names have to be globally unique across all of AWS, so you pick something like your initials plus a few random numbers:

aws s3api create-bucket --bucket <your-bucket-name> --region us-west-2 --create-bucket-configuration LocationConstraint=us-west-2

A successful run returns a JSON response with the bucket's location.

Why we did this: This bucket is going to be the website — every file you upload later needs somewhere to live first. Specifying the region explicitly matters too, because S3 defaults to us-east-1 if you don't say otherwise, and this lab needs everything in us-west-2 to line up.

TASK 4: CREATE A NEW IAM USER WITH S3 ACCESS
Instead of doing everything as the root/admin lab user, you create a dedicated IAM user just for this task:

aws iam create-user --user-name awsS3user
aws iam create-login-profile --user-name awsS3user --password Training123!

Then you sign out of the console, sign back in as awsS3user using the account ID, and try opening S3 — you'll get an access error, because this new user has zero permissions yet.

Back in the terminal, you find the AWS-managed policy that grants full S3 access:

aws iam list-policies --query "Policies[?contains(PolicyName,'S3')]"

And attach it:

aws iam attach-user-policy --policy-arn arn:aws:iam::aws:policy/<policyYouFound> --user-name awsS3user

Why we did this: This is the same principle you'd apply in any real environment — don't do everything as a god-mode account. You create a user scoped to exactly the service it needs (S3, and nothing else), and you can see the access error firsthand before attaching the policy, so you actually witness IAM permissions in action rather than just taking it on faith.

TASK 5: OPEN UP THE BUCKET'S PUBLIC ACCESS
By default, S3 buckets block all public access — good for security, but a website needs to be reachable by anyone. So in the bucket's Permissions tab, you turn off Block all public access, then enable ACLs under Object Ownership.

Why we did this: A private bucket and a public website are contradictory by definition. This step is you deliberately telling AWS "yes, I want this specific bucket to be visible to the internet" — it's not a default AWS assumes for you, because most buckets shouldn't be public.

TASK 6: EXTRACT THE WEBSITE FILES
Back in the terminal:

cd ~/sysops-activity-files
tar xvzf static-website-v2.tar.gz
cd static-website
ls

You should see index.html plus css and images folders — that's the actual site.

Why we did this: The lab ships the website as a compressed archive, so this step just unpacks it into a real folder structure you can upload, the same way you'd receive a client's website files as a zip and need to extract them before deploying anything.

TASK 7: UPLOAD THE FILES AND ENABLE STATIC HOSTING
First, tell S3 which file is the homepage:

aws s3 website s3://<my-bucket>/ --index-document index.html

Then upload everything:

aws s3 cp /home/ec2-user/sysops-activity-files/static-website/ s3://<my-bucket>/ --recursive --acl public-read

--recursive uploads every file in that folder and its subfolders. --acl public-read makes each uploaded file individually viewable by anyone — remember, opening bucket access in Task 5 controls the bucket, but this flag controls the objects inside it.

Confirm the upload:

aws s3 ls <my-bucket>

Then head to the bucket's Properties tab, confirm Static website hosting is Enabled, and open the Bucket website endpoint URL — your Café & Bakery site is now live.

Why we did this: This is the actual deployment — everything before this was just setup. Notice you needed two separate permissions here: the bucket-level public access (Task 5) and the object-level public-read ACL (this task). Miss either one, and visitors get an access-denied error instead of your website.

TASK 8: BUILD A SCRIPT SO YOU DON'T REPEAT YOURSELF
Re-uploading manually every time you change a file gets old fast, so you turn that upload command into a reusable script.

Check your command history to find the exact aws s3 cp line you ran:

history

Create and edit a new file:

cd ~
touch update-website.sh
vi update-website.sh

Inside, add:

#!/bin/bash
aws s3 cp /home/ec2-user/sysops-activity-files/static-website/ s3://<my-bucket>/ --recursive --acl public-read

Save with Esc, then :wq, then make it executable:

chmod +x update-website.sh

Now make an actual change to the site — edit index.html and swap a couple of background colors — then run your new script:

./update-website.sh

Refresh the site in your browser and you'll see your change live.

Why we did this: This is the difference between a one-time task and a repeatable process. The first upload was you doing the work manually; this script means every future update is one command, run the same way, every time — no risk of forgetting a flag or mistyping a bucket name six months from now.

OPTIONAL CHALLENGE: SWITCH FROM cp TO sync
Here's the catch with the script you just built — aws s3 cp --recursive re-uploads every single file, every single time, even the ones that haven't changed at all.

The fix is to swap it for aws s3 sync:

aws s3 sync /home/ec2-user/sysops-activity-files/static-website/ s3://<my-bucket>/ --acl public-read

Make a small change to index.html, run this instead of cp, and refresh the site to confirm it still works.

Why we did this: sync compares what's already in the bucket against what's on your local disk, and only uploads files that are new or changed — not everything, every time. For a small site with three files that barely matters, but imagine a real site with hundreds of images: cp --recursive would re-upload all of them on every single deploy, while sync would only push the one file you actually touched. Same result on screen, far less wasted bandwidth and time behind the scenes.

WHY THIS MATTERS OVERALL

S3 static hosting means you don't need a running server at all — no EC2 instance, no patching, just files sitting in a bucket, served directly to the browser
Bucket-level public access and object-level ACLs are two separate switches — both need to be flipped for a public website to actually work
Creating a scoped IAM user instead of using the account's root permissions is a habit worth carrying into real projects, not just this lab
cp --recursive vs sync is a small command swap with a real efficiency difference once your site is bigger than three files

AWS #S3 #CLI #StaticWebsite #IAM #CloudComputing

Creating Amazon EC2 Instances: Console, CLI, and a Bastion Host or Jump Server 🖥️

Hashir Saud Khan — Thu, 30 Jul 2026 10:16:51 +0000

aws #ec2 #cli #tutorial

Creating Amazon EC2 Instances

INTRO
This lab is about the different ways you can launch an EC2 instance on AWS — through the console, and through the CLI. You'll launch one instance as a bastion host, then use that bastion host to launch a second instance (a web server) using the AWS CLI. By the end, you'll have a small real setup: one instance whose whole job is to give you a safe way in, and another instance doing the actual work.

Quick note before we start — if you've worked in on-prem networks or with other cloud providers, you might know the term jump server instead of bastion host. They're the same thing, just different names depending on where you learned it. A bastion host/jump server is a hardened instance that sits at the edge of your network, and it's the only way in — you connect to it first, then use it to reach other instances that aren't directly exposed. Same concept throughout this lab.

TASK 1: LAUNCH THE BASTION HOST FROM THE CONSOLE
First, you launch an EC2 instance through the AWS Console — this one becomes your bastion host.

Here's what you configure:

Name: Bastion host
AMI: Amazon Linux 2 (from Quick Start)
Instance type: t3.micro
Key pair: Proceed without a key pair — you'll use EC2 Instance Connect instead, so no key pair is needed
Network: Lab VPC, public subnet, public IP enabled
Security group: new one named Bastion security group, described as permitting SSH connections
Storage: default 8 GiB root volume
IAM instance profile: Bastion-Role — this gives the instance permission to make its own calls to EC2 later

Once everything's set, launch it.

Why we did this: You need a single, controlled entry point into your VPC before you do anything else. Instead of exposing every instance directly to the internet, you expose just this one — the bastion host — and everything else stays private, reachable only through it. The IAM role is the other half of this: without it, the bastion host would have no permission to talk to EC2 later in Task 3, no matter how you tried to connect to it.

TASK 2: CONNECT TO THE BASTION HOST
With the instance running, select it in the console, choose Connect, and use the EC2 Instance Connect tab to connect.

That's it — no key file, no terminal setup on your side. You're dropped straight into a shell on the bastion host, right from the browser.

Why we did this: This proves the bastion host is actually reachable and working before you rely on it to do anything else. It's also worth noticing how you connected — no SSH key was ever generated or downloaded for this instance. EC2 Instance Connect handles the authentication behind the scenes through IAM, which is a cleaner story than passing PEM files around, especially for a machine whose whole purpose is being your access point.

TASK 3: LAUNCH A WEB SERVER USING THE AWS CLI
Now for the real task — from inside that bastion host session, you use the AWS CLI to launch a second instance, this time as a web server. Unlike the console, the CLI doesn't guess anything for you — you have to supply every parameter yourself. So the first few steps are just about gathering those parameters.

Step 1 — Get the latest AMI ID:

AZ=`curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone`
export AWS_DEFAULT_REGION=${AZ::-1}
AMI=$(aws ssm get-parameters --names /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2 --query 'Parameters[0].[Value]' --output text)
echo $AMI

Instead of hardcoding an AMI ID (which goes stale the moment AWS patches it), you pull the current one from Parameter Store — the same Parameter Store you'd use to store any other config value.

Step 2 — Get the subnet ID:

SUBNET=$(aws ec2 describe-subnets --filters 'Name=tag:Name,Values=Public Subnet' --query Subnets[].SubnetId --output text)
echo $SUBNET

Step 3 — Get the security group ID:

SG=$(aws ec2 describe-security-groups --filters Name=group-name,Values=WebSecurityGroup --query SecurityGroups[].GroupId --output text)
echo $SG

Step 4 — Download the user data script:

wget https://aws-tc-largeobjects.s3.us-west-2.amazonaws.com/CUR-TF-100-RSJAWS-1-23732/171-lab-JAWS-create-ec2/s3/UserData.txt
cat UserData.txt

This script installs the web server software and the web app itself, and it runs automatically the moment the instance boots — you never have to log into the new instance to set it up manually.

Step 5 — Launch the instance:

INSTANCE=$(aws ec2 run-instances \
  --image-id $AMI \
  --subnet-id $SUBNET \
  --security-group-ids $SG \
  --user-data file:///home/ec2-user/UserData.txt \
  --instance-type t3.micro \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=Web Server}]' \
  --query 'Instances[*].InstanceId' \
  --output text)
echo $INSTANCE

Step 6 — Wait for it to be ready:

aws ec2 describe-instances --instance-ids $INSTANCE --query 'Reservations[].Instances[].State.Name' --output text

Run this again until it says running instead of pending.

Step 7 — Test it:

aws ec2 describe-instances --instance-ids $INSTANCE --query Reservations[].Instances[].PublicDnsName --output text

Paste that DNS name into a browser tab — if the web page loads, the instance launched, booted, and configured itself correctly, entirely through commands you typed.

Why we did this: This is the whole point of the CLI — repeatability. Everything you just did could be saved as a script and run again to spin up an identical web server anytime, with zero clicking. That's the real difference between the console and the CLI: the console is great for a one-off instance, but the CLI is what you reach for when you need the exact same setup twice, or twenty times, without relying on memory or a screenshot of the steps.

PICKING THE RIGHT METHOD
Worth remembering going forward:

Console — quick, one-off, temporary instances
CLI / scripts — repeatable, automatable, consistent deployments
CloudFormation — when you need multiple related resources launched and managed together as one unit

WHY THIS MATTERS OVERALL

Bastion host, jump server — same idea: one hardened, controlled entry point standing between the internet and everything else in your VPC
EC2 Instance Connect swaps out "manage an SSH key" for "let IAM handle it" — one less credential to lose track of
The CLI forces you to know every parameter that goes into launching an instance, which is exactly why it's worth learning even if the console feels faster day-to-day
Pulling the AMI ID from Parameter Store instead of hardcoding it means your launch script never silently uses an outdated, unpatched image

AWS #EC2 #BastionHost #JumpServer #CLI #CloudComputing

Using AWS Systems Manager (Lab): Fleet Manager, Inventory, Run Command, Documents & Parameter Store

Hashir Saud Khan — Wed, 29 Jul 2026 09:41:32 +0000

aws #systemsmanager #ansible #tutorial

Using AWS Systems Manager

INTRO
This lab is about AWS Systems Manager — a service that lets you manage a whole fleet of servers from one central place. Instead of logging into each machine one by one, you use it to check what's installed on your instances, run commands across many of them at once, store configuration values in one spot, and even get a shell on a server — all without ever opening an SSH port.

Now, if you've worked with Ansible before, a lot of this is going to feel familiar, just with different names. So alongside every step, I'll point out the Ansible equivalent — that way, instead of learning something brand new, you're really just learning AWS's word for something you probably already do.

THE BIG PICTURE FIRST — HOW THIS IS DIFFERENT FROM ANSIBLE
Before the steps, one important difference that's worth understanding upfront, because it explains why AWS built things this way:

Ansible is agentless. It reaches out to a server over SSH, runs its tasks, and leaves. No software has to sit running on the target machine.

Systems Manager works the opposite way. It's agent-based — every managed instance runs the SSM Agent in the background. That agent constantly checks in with AWS, waiting for work to do. That's why you never need to open an SSH port or manage keys with Systems Manager — the instance is calling home to AWS instead of AWS calling in to the instance.

Keep that one idea in mind, and everything else in this lab makes a lot more sense.

TASK 1: FLEET MANAGER — LIKE RUNNING ansible -m setup
In Ansible, when you want to know what's actually installed on a box — OS version, packages, running services — you gather facts. That's literally a module call: ansible -m setup.

Fleet Manager's Inventory feature does the same job, just continuously and automatically instead of on-demand.

To set it up:

Search Systems Manager in the console, then go to Fleet Manager on the left
Under Account management, choose Set up inventory
Name it Inventory-Association
Under targets, choose Manually selecting instances and pick your Managed Instance
Leave everything else default and choose Setup Inventory

Once it's running, click the Node ID, then the Inventory tab — you'll see every application installed on that instance. No SSH needed to find out what's running there. That's the whole point.

TASK 2: RUN COMMAND — LIKE RUNNING AN ANSIBLE PLAYBOOK
This is where the comparison gets really direct. In Ansible, you write a playbook — a YAML file describing tasks to run — and point it at a group of hosts.

In Systems Manager, the equivalent of a playbook is called an SSM Document.

It's AWS's pre-packaged (or custom) definition of "here's what to run." Run Command is what actually executes that document against your targets — same relationship as ansible-playbook executing a playbook.

In this task, you'll run a document that installs a small web app (Apache, PHP, the app itself) and starts the web server — basically a mini playbook run.

Go to Node Management → Run Command → Run command
Search documents by Owner → Owned by me, and select the one described as Install Dashboard App
Under target selection, choose Choose instances manually and pick your Managed Instance
Under Output options, turn off Enable an S3 bucket
Expand the AWS CLI command section — this shows you the exact CLI command behind the button, which you could drop into a script instead of clicking through the console every time (same idea as saving a playbook instead of running one-off ansible commands)
Choose Run, wait a minute or two for the status to hit Success

Then grab the instance's public IP from the lab details panel and open it in a browser — you should see the Widget Manufacturing Dashboard you just installed, all without ever logging into the box directly.

One more parallel worth knowing: Ansible lets you target a whole group of hosts using inventory groups. Systems Manager does the same thing using tags — tag a batch of instances, and you can run one document against all of them at once.

TASK 3: PARAMETER STORE — LIKE ANSIBLE VAULT / GROUP VARS
In Ansible, you keep configuration values and secrets outside your playbooks — in group_vars, host_vars, or encrypted with Ansible Vault if it's sensitive. The playbook reads those values instead of having them hardcoded.

Parameter Store is AWS's version of that same idea — a place to store config values and secrets, as plain text or encrypted, referenced by name instead of baked into your application.

In Systems Manager, go to Application Management → Parameter Store → Create parameter
Name: /dashboard/show-beta-features
Description: Display beta features
Leave Tier and Type as default
Value: True
Choose Create parameter

Go back to the dashboard app in your browser and refresh it — a third chart appears. The app was already built to check for that parameter; it just needed the value to exist. This is the same pattern as "dark launching" a feature in Ansible-managed config — the feature is already deployed, just waiting on a variable to flip it on.

(Optional: delete the parameter and refresh again — the chart disappears. That's the value being read live, not cached.)

TASK 4: SESSION MANAGER — THE PART ANSIBLE DOESN'T REALLY HAVE
This is where the comparison breaks a little, and that's worth calling out rather than forcing a fake parallel. Ansible doesn't really have an interactive shell feature — it's built to run tasks and exit, not to give you a live terminal.

Session Manager, on the other hand, gives you a browser-based shell straight into the instance — no SSH key, no open port, no bastion host. It rides on the same SSM Agent connection that Fleet Manager and Run Command already use.

Go to Node Management → Session Manager → Start session
Select your Managed Instance and choose Start session

A shell opens right in your browser. Try:

ls /var/www/html

You'll see the app files Run Command installed earlier.

Then run this to pull instance details through the CLI, right from inside the session:

AZ=`curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone`
export AWS_DEFAULT_REGION=${AZ::-1}
aws ec2 describe-instances

That second block grabs the region the instance is running in, then uses it to list EC2 instance details in JSON — all without you ever needing an SSH key for this box. You could even go check the instance's security group afterward and confirm port 22 isn't open at all. The access is happening entirely through IAM and the SSM Agent instead.

WHY THIS MATTERS

If you already think in Ansible terms, don't relearn from scratch — map the concept: Document = Playbook, Run Command = ansible-playbook, Inventory = fact-gathering, Parameter Store = vars/Vault, tags = inventory groups
The one thing that doesn't map over is the connection model itself — Ansible pushes over SSH, Systems Manager relies on an agent pulling instructions. That single difference is why SSM never needs an open SSH port
Session Manager plus closed SSH ports means every login is going through IAM permissions and gets logged in CloudTrail — that's a real audit trail, not just "someone SSH'd in with a shared key"
None of these four tools work in isolation — Fleet Manager tells you what's there, Run Command changes it, Parameter Store configures it, and Session Manager lets you get hands-on when you need to

AWS #SystemsManager #Ansible #DevOps #CloudComputing #Automation

Monitoring an EC2 Instance with CloudWatch and SNS

Hashir Saud Khan — Fri, 24 Jul 2026 10:43:44 +0000

aws #cloudwatch #monitoring #tutorial

Monitor an EC2 Instance

INTRO
Ever wonder how you'd actually know if something was silently maxing out your server's CPU? That's basically what this lab is about. You set up an alarm that watches an EC2 instance's CPU, wire it to send you an email the moment it spikes, and then you deliberately spike it yourself to prove the whole thing works. It's a simple setup, but it's the same pattern behind real incident alerting — think of the CPU spike as a stand-in for something like malware taking over a box.

WHAT YOU'RE BUILDING
You'll set up three things that talk to each other:

An SNS topic that emails you when triggered
A CloudWatch alarm that watches CPU usage and fires the SNS topic if it crosses 60%
A stress test on the EC2 instance to actually push CPU past that line and prove the alarm works

By the end, you'll also have a CloudWatch dashboard so you can glance at that CPU metric anytime without digging through menus.

STEP 1: SET UP THE SNS TOPIC
First, you need somewhere for the alert to go. Head to SNS and create a topic:

Type: Standard
Name: MyCwAlarm

Once it's created, go to the Subscriptions tab and add a subscription:

Protocol: Email
Endpoint: your actual email address

You'll get a confirmation email almost instantly — open it and confirm the subscription. Come back to the console and check that the status flipped to Confirmed. If it still says "Pending confirmation," the alarm won't be able to reach you later, so don't skip this.

STEP 2: CREATE THE CLOUDWATCH ALARM
Now you tell CloudWatch what to watch and when to yell about it.

Jump into CloudWatch → Metrics → EC2 → Per-Instance Metrics, and find CPUUtilization for your Stress Test instance. Right now it should be sitting near 0% — nothing's happened yet.

Then go to Alarms → Create alarm, and pick that same CPUUtilization metric. Set it up like this:

Statistic: Average
Period: 1 minute
Condition: Greater than 60

For the action, point it at the SNS topic you just made (MyCwAlarm), and give the alarm a name like LabCPUUtilizationAlarm.

That's it — the alarm now sits quietly in the background, watching.

STEP 3: SPIKE THE CPU AND WATCH THE ALARM FIRE
This is the part that actually proves it works. Open a terminal into the Stress Test instance and run:

sudo stress --cpu 10 -v --timeout 400s

This pins the CPU at 100% for about 400 seconds, then lets it drop back down on its own.

Open a second terminal to the same instance and run:

top

so you can watch the CPU load live while it's happening.

Now flip back to the CloudWatch alarm page and refresh every minute or so. Give it a few minutes — you'll see the graph climb past the 60% line, and the alarm state will flip to In alarm. Shortly after, check your inbox — you should have a fresh email from AWS Notifications telling you the alarm went off.

STEP 4: BUILD A DASHBOARD
Once you've seen the alarm work, it's worth having a permanent view of that metric instead of hunting for it every time.

Go to CloudWatch → Dashboards → Create dashboard, name it LabEC2Dashboard, and add a Line widget using the same CPUUtilization metric for your Stress Test instance. Save it, and now you've got a one-click view of that instance's CPU health whenever you need it.

WHAT I TOOK AWAY FROM THIS

An alarm is only as useful as the notification behind it — CloudWatch watches the metric, but SNS is what actually gets a human's attention
A CPU spike by itself doesn't tell you why it happened — it just tells you that it happened. That's the trigger to go investigate, not the answer
Confirming the SNS subscription is an easy step to forget, and if you skip it, the whole alert chain silently breaks
Dashboards aren't just nice-to-have — they turn "let me go find that metric again" into "it's already right there"

AWS #CloudWatch #SNS #EC2 #CloudSecurity #Monitoring

Skipping the Console: Talking to IAM Through the AWS CLI

Hashir Saud Khan — Thu, 23 Jul 2026 11:14:23 +0000

Install and Configure the AWS CLI

INTRO
If you've only ever clicked around the AWS Console, this one's for you. I set up the AWS CLI from scratch on a Red Hat Linux EC2 instance — not Amazon Linux, which comes with it pre-installed, but Red Hat, which doesn't. So I had to install it, connect it to my AWS account, and then use it to actually talk to IAM. Here's exactly how I did it.

WHAT YOU'RE BUILDING
Here's the picture: you SSH into an EC2 instance sitting inside a VPC. That instance gets the AWS CLI installed on it. Once it's configured with an access key, it can reach out and talk to IAM directly from the terminal — no console needed.

WHAT YOU'LL WALK AWAY WITH

The AWS CLI installed and working
The CLI connected to a real AWS account
Comfort using the CLI to query IAM instead of clicking through the console

STEP 1: SSH INTO THE INSTANCE
First thing, you need to get onto the EC2 instance itself.

If you're on macOS or Linux, grab the PEM key, lock down its permissions, and connect:

cd ~/Downloads
chmod 400 labsuser.pem
ssh -i labsuser.pem ec2-user@<ip-address>

Type yes when it asks about the connection — you're using a key pair, so no password needed.

If you're on Windows, you'll use PuTTY with the PPK file instead.

STEP 2: INSTALL THE AWS CLI
Once you're inside the instance, download and install the CLI:

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip -u awscliv2.zip
sudo ./aws/install

Check it worked:

aws --version

You should see something like aws-cli/2.7.24 Python/3.8.8 Linux/... — exact version doesn't matter, just that it responds.

Try aws help too — if it opens up the help pager, you're good. Press q to get out.

STEP 3: LOOK AT THE IAM SETUP IN THE CONSOLE
Before jumping into the CLI, take a quick look at IAM in the console so you know what you're working with.

Go to IAM → Users → your user. Under Permissions, open the attached policy and view it as JSON — that's the actual permission document controlling what you can and can't do.

Then check the Security Credentials tab and find your access key ID. You'll need this (and the matching secret key) in the next step.

STEP 4: CONNECT THE CLI TO YOUR ACCOUNT
Back in the terminal, run:

aws configure

It'll ask you four things:

Access Key ID — paste it in
Secret Access Key — paste it in
Default region — I used us-west-2
Default output format — json

That's it. Your terminal is now authenticated as your AWS user.

STEP 5: TALK TO IAM FROM THE TERMINAL
Now for the fun part — test it out:

aws iam list-users

If everything's wired up right, you'll get back a JSON list of the IAM users in the account. No console, no clicking — just the CLI doing the work.

THE CHALLENGE: PULL THE POLICY DOCUMENT USING ONLY THE CLI
Here's where it gets interesting. The task: grab that same IAM policy document you looked at earlier in the console — but this time, do it entirely through the CLI. No cheating by going back to the console.

Two commands get you there. First, find the policy:

aws iam list-policies --scope Local

--scope Local matters here — it filters down to customer-managed policies instead of dumping every AWS-managed policy at you.

Once you've got the policy's ARN and version ID from that output, pull the actual JSON and save it to a file:

aws iam get-policy-version --policy-arn arn:aws:iam::<account-id>:policy/lab_policy --version-id v1 > lab_policy.json

That > at the end is doing the heavy lifting — it takes whatever the command prints and writes it straight into a file instead of just showing it on screen.

WHAT I TOOK AWAY FROM THIS

The CLI and the console aren't different tools — they're two doors into the same house. Everything you can click, you can also script
Logging into the console needs a username and password. Talking to AWS through the CLI needs an access key and secret key instead — different door, different key
list-policies --scope Local is worth remembering — without it, you're wading through every AWS-managed policy just to find the one you actually own
Piping CLI output into a file with > is a small thing, but it's how you turn a one-off command into something you can actually keep and review later

AWS #CLI #IAM #Linux #CloudComputing #DevOps

The AWS Security Lifecycle and Its Key Services

Hashir Saud Khan — Tue, 21 Jul 2026 08:04:32 +0000

Security Lifecycle: Prevention, Detection, Analysis, Response

INTRO
So I've been digging into how security actually works in practice, and here's the thing — it's not a one-time setup you finish and forget. It's a lifecycle. It loops: Prevention, Detection, Analysis, Response, and back again. Let me walk you through it the way I understood it, along with the exact AWS services tied to each part.

THE SECURITY LIFECYCLE
Picture four stages running in a continuous loop:

Prevention — you stop the incident before it even happens
Detection — if it does happen anyway, you catch it
Analysis — you figure out what went wrong and why
Response — you act on it, then feed what you learned back into Prevention

Notice how it circles back? That's the whole point. Every response makes your next round of prevention stronger.

PREVENTION — WHERE MOST OF YOUR WORK HAPPENS
This is the stage you'll spend the most time on. I broke it into five areas, and each one has a specific AWS service behind it:

1. Network Hardening — Amazon Inspector
You use this for vulnerability assessment. It scans your environment for known issues like CVEs, so you can patch them before anyone else finds them first.

2. System Hardening — AWS Systems Manager
This is where Patch Manager comes in. Instead of logging into every single instance to update it, you patch your whole fleet from one place.

3. Data Security — AWS KMS
You'll use this to encrypt your data at rest with symmetric keys, managed through the AWS Encryption CLI. Even if someone gets to your data, it's useless without the key.

4. Public Key Infrastructure — AWS ACM
This handles your SSL/TLS certificates using asymmetric public/private key pairs. It takes care of issuing and renewing them, so you're not the one finding out a cert expired at 2am.

5. Identity Management — AWS IAM
This is the one everything else depends on. You decide who — or what — gets access to which resource. If your IAM isn't locked down, none of the other four matter as much.

DETECTION, ANALYSIS, RESPONSE
Prevention is just where you start. The other three stages are what close the loop:

Detection — you're watching for suspicious activity or a policy violation as it happens
Analysis — you dig into the logs and findings to trace the root cause and understand the impact
Response — you contain it, fix it, and take what you learned straight back into Prevention

AWS #Security #CloudSecurity #IAM #KMS #Inspector

Deploying MySQL on RDS and Joining Tables Like It's Production

Hashir Saud Khan — Sun, 19 Jul 2026 15:35:50 +0000

Rds challenge lab devto post 🗄️🐬

aws #rds #database #tutorial

Build Your DB Server and Interact With Your DB

INTRO
Did a hands-on AWS challenge lab on Amazon RDS. Task: spin up a managed database, connect from a Linux server, and run real SQL — create tables, insert data, join across tables. No hand-holding here, just requirements to figure out myself. Here's the walkthrough.

SCENARIO
Service: Amazon RDS
Role: Cloud/DB Admin
Goal: Launch RDS under set constraints, connect via EC2, run SQL (create, insert, select, join)

ARCHITECTURE

LinuxServer (EC2) sits in the Lab VPC — this is the client
RDS instance (Aurora or MySQL) in the same VPC
Security group lets LinuxServer talk to RDS
Flow: LinuxServer -> MySQL client (port 3306) -> RDS -> tables

STEP 1: LAUNCH THE RDS INSTANCE
Constraints for this lab:

Engine: Aurora (Provisioned) or MySQL — no serverless
Template: Dev/Test or Free tier
No standby instance (single-AZ only)
Instance size: db.t3.micro to db.t3.medium
Storage: gp2, up to 100 GB — no Provisioned IOPS
Network: Lab VPC
Security group must allow LinuxServer access
MySQL only: turn off Enhanced Monitoring
On-Demand only

These limits keep costs in check — Provisioned IOPS and Multi-AZ are the fastest ways to blow up an RDS bill.

Noted the master username, password, and endpoint — needed next.

STEP 2: CONNECT TO THE LINUX SERVER
Downloaded the PEM key, grabbed the LinuxServer address, connected over SSH:

chmod 400 labsuser.pem
ssh -i labsuser.pem ec2-user@<LinuxServer-address>

This box is just the SQL client — it needs network access to RDS, nothing more.

STEP 3: INSTALL MYSQL CLIENT AND CONNECT
On the LinuxServer:

sudo yum install mysql -y

Connect using the master credentials from Step 1:

mysql -h <rds-endpoint> -u <master-username> -p

If it hangs, it's almost always the security group — check port 3306 inbound.

STEP 4: CREATE THE RESTART TABLE

CREATE DATABASE lab_db;
USE lab_db;

CREATE TABLE RESTART (
    StudentID INT,
    StudentName VARCHAR(100),
    RestartCity VARCHAR(100),
    GraduationDate DATETIME
);

STEP 5: INSERT 10 SAMPLE ROWS

INSERT INTO RESTART (StudentID, StudentName, RestartCity, GraduationDate) VALUES
(1, 'Ahmed Khan', 'Karachi', '2024-01-15 10:00:00'),
(2, 'Sara Ali', 'Lahore', '2024-02-10 11:30:00'),
(3, 'Bilal Hassan', 'Islamabad', '2024-03-05 09:15:00'),
(4, 'Ayesha Malik', 'Karachi', '2024-01-20 14:00:00'),
(5, 'Usman Tariq', 'Faisalabad', '2024-04-12 10:45:00'),
(6, 'Hina Shaikh', 'Karachi', '2024-02-28 13:30:00'),
(7, 'Omar Farooq', 'Multan', '2024-03-18 12:00:00'),
(8, 'Zara Iqbal', 'Lahore', '2024-01-30 15:20:00'),
(9, 'Danish Raza', 'Karachi', '2024-04-02 09:50:00'),
(10, 'Mahnoor Aslam', 'Islamabad', '2024-02-15 11:10:00');

STEP 6: SELECT ALL FROM RESTART

SELECT * FROM RESTART;

STEP 7: CREATE THE CLOUD_PRACTITIONER TABLE

CREATE TABLE CLOUD_PRACTITIONER (
    StudentID INT,
    CertificationDate DATETIME
);

STEP 8: INSERT 5 SAMPLE ROWS

INSERT INTO CLOUD_PRACTITIONER (StudentID, CertificationDate) VALUES
(1, '2024-05-01 10:00:00'),
(3, '2024-05-03 11:00:00'),
(5, '2024-05-05 09:30:00'),
(7, '2024-05-07 14:15:00'),
(9, '2024-05-09 10:20:00');

STEP 9: SELECT ALL FROM CLOUD_PRACTITIONER

SELECT * FROM CLOUD_PRACTITIONER;

STEP 10: INNER JOIN

SELECT R.StudentID, R.StudentName, C.CertificationDate
FROM RESTART R
INNER JOIN CLOUD_PRACTITIONER C
ON R.StudentID = C.StudentID;

Only students in both tables show up — filters out anyone not yet certified.

WHY THIS MATTERS

RDS constraints = real cost guardrails, not busywork
Security groups are the #1 connection blocker
Base table + event table + join = same pattern used in production apps
Always capture before/after proof at each step

TOOLS USED

Amazon RDS (Aurora / MySQL)
Amazon EC2
Amazon VPC + Security Groups
MySQL client / SQL

AWS #RDS #Database #MySQL #CloudComputing #SQL

Blocking Malware with AWS Network Firewall (Bump-in-the-wire Design) 🛑🛡️

Hashir Saud Khan — Fri, 17 Jul 2026 06:59:35 +0000

Blocking Malware Downloads with AWS Network Firewall (Stateful Suricata Rules)

INTRO

Ran a hands-on lab that simulates a real-world security incident: end users at a
company kept accidentally downloading malware after visiting a specific website.
IT had already identified the malicious URLs. My job was to harden the network
perimeter using AWS Network Firewall so those files could never reach an internal
host again. Here's a full walkthrough of what I did and why each step matters.

SCENARIO

Company: AnyCompany (lab scenario)
Role: Security Engineer
Problem: Users downloading malware from a known-bad site
Given: Exact URLs hosting the malicious files
Goal: Block access to those files at the network layer, without touching every single endpoint individually

ARCHITECTURE

A pre-configured EC2 instance (TestInstance) sits in an isolated perimeter subnet — used purely to simulate an end user's browser/download behavior
An AWS Network Firewall (LabFirewall) sits between the VPC and the internet
The firewall is driven by a Firewall Policy (LabFirewallPolicy), which determines stateless vs. stateful packet handling
A Stateful Rule Group written in Suricata syntax is attached to the policy to do the actual content-based blocking

Flow: TestInstance -> Network Firewall (stateless check -> stateful rule
group) -> Internet -> malicious site (now blocked)

STEP 1: CONFIRM THE PROBLEM IS REAL

Before touching any config, I logged into TestInstance via Systems Manager
Session Manager and reproduced the issue:

wget http://malware.wicar.org/data/js_crypto_miner.html
wget http://malware.wicar.org/data/java_jre17_exec.html

Both returned HTTP 200 OK and downloaded successfully. This confirms the
malicious files are currently reachable and the firewall isn't inspecting
or blocking this traffic yet. Never skip this step in real environments —
you need a documented "before" state to prove the fix worked.

STEP 2: SWITCH THE FIREWALL POLICY TO STATEFUL INSPECTION

By default, a lot of basic firewall configs only do stateless filtering
(rules based on IP/port only, no context, no content awareness). To block
based on URI content, traffic needs to go through the stateful rules engine.

In the Firewall Policy (LabFirewallPolicy):

Stateless default actions -> Edit
Fragmented packets: "Use the same actions for all packets"
Action: "Forward to stateful rule groups"
Save

Stateless engine = fast, no context, evaluates each packet in isolation
Stateful engine = slower, but understands traffic flow/direction and lets
you write much more precise rules (and log everything)

STEP 3: WRITE A STATEFUL RULE GROUP (SURICATA SYNTAX)

Created a new Stateful Rule Group:

Rule group type: Stateful
Format: Suricata compatible rule string
Evaluation order: Action order
Name: StatefulRuleGroup
Capacity: 100

Rules used:

drop http $HOME_NET any -> $EXTERNAL_NET 80 (msg:"MALWARE custom solution"; flow: to_server,established; classtype:trojan-activity; sid:2002001; content:"/data/js_crypto_miner.html"; http_uri; rev:1;)

drop http $HOME_NET any -> $EXTERNAL_NET 80 (msg:"MALWARE custom solution"; flow: to_server,established; classtype:trojan-activity; sid:2002002; content:"/data/java_jre17_exec.html"; http_uri; rev:1;)

What this actually does:

drop -> silently block the packet (no reset sent back)
http -> only inspect HTTP traffic
$HOME_NET -> $EXTERNAL_NET -> traffic leaving your VPC toward the internet
flow: to_server, established -> only match on established outbound requests
content: "..."; http_uri -> match specifically on the URI path, not just the domain or IP — this is the key advantage over basic IP/domain blocklists
sid -> unique rule ID (required by Suricata)
classtype: trojan-activity -> categorizes the threat for logging/alerting

STEP 4: ATTACH THE RULE GROUP TO THE FIREWALL

Firewalls -> LabFirewall -> Associated firewall policy -> LabFirewallPolicy
Stateful rule groups -> Add unmanaged stateful rule groups
Select StatefulRuleGroup -> Add stateful rule group

This is the step that actually activates the rules — until this point, the
rule group existed but had zero effect on real traffic.

STEP 5: VALIDATE

Back on TestInstance, re-ran the exact same commands:

wget http://malware.wicar.org/data/js_crypto_miner.html
wget http://malware.wicar.org/data/java_jre17_exec.html

This time: "HTTP request sent, awaiting response..." and then it just hangs
(had to Ctrl+C out of it) — no 200 OK, no file downloaded. The firewall is
silently dropping matching requests before they ever complete.

WHY THIS MATTERS (KEY TAKEAWAYS)

URI-level blocking beats plain IP/domain blocklists. Attackers can move files to a new path on the same domain — a rule matching http_uri content catches the actual malicious payload path, not just the host
Stateless vs. stateful matters. If your firewall policy defaults to stateless-only, none of your Suricata content rules will ever fire
This is a form of IDS/IPS at the network edge without needing a separate third-party appliance — useful as one layer in a defense-in-depth strategy
Always validate with a "before" and "after" test. Screenshots/logs of both states are what actually prove the fix to stakeholders/auditors

TOOLS/SERVICES USED

AWS Network Firewall
AWS VPC
Amazon EC2
Suricata rule syntax (IDS/IPS)

AWS #CyberSecurity #NetworkFirewall #CloudSecurity #InfoSec #Suricata