DEV Community: Ntseze-Nelvis

Production-Grade 3-Tier Image Processing Platform

Ntseze-Nelvis — Fri, 03 Apr 2026 11:38:52 +0000

==========================================================================

HSBC-gamma:Production-Grade 3-Tier Image Processing Platform

A secure, scalable, and highly available image processing platform built on AWS with Terraform

📋 Overview

This project implements a production-grade 3-tier image processing platform on AWS using Infrastructure as Code (IaC) with Terraform. Users can upload images through a web interface, which are then automatically processed (resized into multiple versions) and stored securely in encrypted S3 buckets.

Key Features

53 Terraform resources deployed in AWS
Multi-AZ high availability across eu-north-1a and eu-north-1b
Auto-scaling (1-3 instances per tier based on CPU utilization)
KMS encryption for all S3 data at rest
Least privilege IAM with instance profiles (no access keys on EC2)
Path-based routing with Application Load Balancer
Complete observability with CloudWatch logs and alarms
Self-healing architecture with health checks

📂 Project Structure

C:.
│   .gitignore
│   .gitlab-ci.yml
│   .terraform.lock.hcl
│   complete-configuration.txt
│   elbv2 describe-target-groups _
│   elbv2 describe-target-groups 
│   main.tf
│   outputs.tf
│   print_project.sh
│   project_tracker.sh
│   providers.tf
│   README.md
│   terraform.tfstate
│   terraform.tfstate.backup
│   terraform.tfvars
│   variables.tf
│
├───.terraform
│   ├───modules
│   │       modules.json
│   │
│   └───providers
│       └───registry.terraform.io
│           └───hashicorp
│               └───aws
│                   └───6.31.0
│                       └───windows_amd64
│                               LICENSE.txt
│                               terraform-provider-aws_v6.31.0_x5.exe
│
└───modules
    ├───alb
    │       main.tf
    │       outputs.tf
    │       variables.tf
    │
    ├───app
    │       asg.tf
    │       launch_template.tf
    │       outputs.tf
    │       user_data.sh
    │       variables.tf
    │
    ├───monitoring
    │       alarms.tf
    │       cloudwatch.tf
    │       logs.tf
    │       user_data.sh
    │       variables.tf
    │
    ├───s3
    │       buckets.tf
    │       kms.tf
    │       lifecycle.tf
    │       outputs.tf
    │       test-upload.html
    │       variables.tf
    │
    ├───security
    │       iam.tf
    │       outputs.tf
    │       sg.tf
    │       variables.tf
    │
    ├───vpc
    │       main.tf
    │       outputs.tf
    │       variables.tf
    │
    └───web
            asg.tf
            launch_template.tf
            output.tf
            user_data.sh
            variables.tf

Module Resource Count

Module	Purpose	Resources
vpc	Network infrastructure	11
security	Security controls	12
s3	Storage layer	9
alb	Load balancing	4
web	Frontend tier	3
app	Backend tier	3
monitoring	Observability	7
Total		53

Architecture Diagram

HSBC-Gamma-Achitectural-Diagram

Quick Start

Prerequisites

# AWS CLI installed and configured
aws configure
# Enter your credentials and region: eu-north-1

# Terraform v1.0+ installed
terraform --version

# Clone the repository
git clone https://github.com/Ntseze-Nelvis/hsbc-gamma-3tier-image-platform.git
cd hsbc-gamma-3tier-image-platform-main

Deploy Infrastructure

# Initialize Terraform
terraform init

# Format and validate configuration
terraform fmt -recursive
terraform validate

# Review what will be created
terraform plan
**Terraform plan**
![Terraform-plan](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/w6g8px681qz6oe41w8gs.jpg)

# Deploy infrastructure
terraform apply -auto-approve

## View outputs
terraform output

Expected Outputs

alb_dns_name = "hsbc-gamma-dev-alb-50807543.eu-north-1.elb.amazonaws.com"
app_asg_name = "app-asg"
kms_key_arn = "arn:aws:kms:eu-north-1:211125430491:key/bb2beb00-4920-44e4-8ea6-6fb2a554b0e8"
processed_bucket_arn = "arn:aws:s3:::hsbc-gamma-dev-processed-images"
raw_bucket_arn = "arn:aws:s3:::hsbc-gamma-dev-raw-images"
web_asg_name = "web-asg"

Terraform apply

Test Your Application

Open your browser and navigate to:

http://hsbc-gamma-dev-alb-50807543.eu-north-1.elb.amazonaws.com

Upload and Process an Image
Click "Choose Image" or drag & drop an image

Wait 5-10 seconds for processing

HSBC-Gamma-Web-App

Verify Processing

## Check raw bucket
aws s3 ls s3://hsbc-gamma-dev-raw-images/

## Check processed bucket
aws s3 ls s3://hsbc-gamma-dev-processed-images/

Expected output shows:
thumbnail-uuid.jpg
small-uuid.jpg
medium-uuid.jpg
large-uuid.jpg

Monitoring & Observability

View CloudWatch Logs

# App tier logs (Flask API)
aws logs tail /hsbc-gamma/app --since 1h --follow

# Web tier logs (Apache)
aws logs tail /hsbc-gamma/web --since 1h --follow

Check Auto Scaling Status

# Web tier instances
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names web-asg

## App tier instances
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names app-asg

Monitor ALB Health

# Check target group health
aws elbv2 describe-target-health \
  --target-group-arn $(aws elbv2 describe-target-groups \
    --names hsbc-gamma-dev-alb-web-tg \
    --query 'TargetGroups[0].TargetGroupArn' \
    --output text)
    ```
{% endraw %}

## Security Validation
## Verify S3 Encryption
{% raw %}

```bash
aws s3api get-bucket-encryption --bucket hsbc-gamma-dev-raw-images
# Expected: KMS encryption enabled

Verify Public Access Block

aws s3api get-public-access-block --bucket hsbc-gamma-dev-raw-images
# Expected: All blocks enabled

Verify Security Groups

aws ec2 describe-security-groups --group-names hsbc-gamma-dev-web-sg \
  --query 'SecurityGroups[0].IpPermissions'
# Expected: Only port 80 from ALB security group

Sample Calculation (2 instances each tier)

EC2: 4 × $8.76 = $35.04
ALB: $0.0225/h × 730h = $16.43
NAT: $0.045/h × 730h = $32.85
S3: Estimated = $8.00
KMS: $1.00 + operations = $1.50
CW: Logs + metrics = $4.00
Data: Estimated = $15.00
─────────────────────────────────
Total: $112.82/month

Troubleshooting

Issue 1: Can't Access Web UI

# Check ALB DNS
terraform output alb_dns_name

## Verify ALB is active
aws elbv2 describe-load-balancers --names hsbc-gamma-dev-alb \
  --query 'LoadBalancers[0].State.Code'

## Test ALB endpoint
curl -I http://$(terraform output -raw alb_dns_name)

Verify ALB is in active state
Ensure security group allows port 80 from 0.0.0.0/0
Check that web tier instances are healthy

Issue 2: Image Upload Fails

Symptoms: Upload returns server error, image not processed

Diagnostic Commands:

# Check app tier logs for errors
aws logs tail /hsbc-gamma/app --since 30m --filter-pattern "ERROR"

# Verify target group health
aws elbv2 describe-target-health \
  --target-group-arn $(aws elbv2 describe-target-groups \
    --names hsbc-gamma-dev-alb-app-tg \
    --query 'TargetGroups[0].TargetGroupArn' \
    --output text)
    #Diagnostic Commands:

Common Solutions:

Restart Flask app on app tier instances
Verify IAM role has S3 permissions
Check S3 bucket policies allow app role access

# Issue 3: Instances Not Launching
#Symptoms: Auto Scaling group shows 0 instances or desired capacity not met
#Diagnostic Commands:

## Check ASG status
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names web-asg

## View scaling activities
aws autoscaling describe-scaling-activities --auto-scaling-group-name web-asg

Clean UpClean Up

# Destroy all infrastructure
terraform destroy -auto-approve

# Verify resources are deleted
aws s3 ls | grep hsbc-gamma-dev
aws ec2 describe-instances --filters "Name=tag:Name,Values=*hsbc*"
aws elbv2 describe-load-balancers --names hsbc-gamma-dev-alb
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names web-asg app-asg

Resources & Documentation

Resource	Link
Terraform AWS Provider	registry.terraform.io/providers/hashicorp/aws
AWS 3-Tier Architecture	aws.amazon.com/architecture/3-tier
IAM Instance Profiles	docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html
Flask Documentation	flask.palletsprojects.com
Pillow Documentation	pillow.readthedocs.io
Auto Scaling Groups	docs.aws.amazon.com/autoscaling/ec2/userguide/
Application Load Balancer	docs.aws.amazon.com/elasticloadbalancing/latest/application/

Terraform Operations

terraform init                                      # Initialize
terraform validate                                  # Validate config
terraform plan                                      # Preview changes
terraform apply -auto-approve                       # Deploy
terraform destroy -auto-approve                     # Destroy all
terraform output                                    # View outputs
terraform output -raw alb_dns_name                  # Get specific output
terraform state list                                # List resources
terraform state show aws_instance.example          # Show resource details
terraform graph | dot -Tpng > graph.png            # Generate graph

# State Management
terraform state mv aws_instance.old aws_instance.new # Move resource
terraform state rm aws_instance.to_remove           # Remove from state
terraform import aws_instance.example i-12345678    # Import resource

AWS CLI Commands

# Account & Identity
aws sts get-caller-identity                        # Verify account

# EC2 & Compute
aws ec2 describe-instances --filters "Name=tag:Name,Values=*hsbc*"

# Auto Scaling
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names web-asg
aws autoscaling describe-scaling-activities --auto-scaling-group-name web-asg

# Load Balancer
aws elbv2 describe-load-balancers --names hsbc-gamma-dev-alb
aws elbv2 describe-target-groups --names hsbc-gamma-dev-alb-web-tg

# S3 Storage
aws s3 ls s3://hsbc-gamma-dev-raw-images/ --recursive --summarize
aws s3api get-bucket-encryption --bucket hsbc-gamma-dev-raw-images

# CloudWatch
aws logs tail /hsbc-gamma/app --since 1h --follow
aws logs filter-log-events --log-group-name /hsbc-gamma/app --filter-pattern "ERROR"

Monitoring & Debugging

# Real-time monitoring
watch -n 5 'aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names web-asg --query "AutoScalingGroups[0].Instances[*].LifecycleState"'

# Check ASG instances health
watch -n 10 'aws elbv2 describe-target-health --target-group-arn $(aws elbv2 describe-target-groups --names hsbc-gamma-dev-alb-web-tg --query "TargetGroups[0].TargetGroupArn" --output text)'

# Network connectivity test
curl -w "Connect: %{time_connect}s TTFB: %{time_starttransfer}s Total: %{time_total}s\n" -o /dev/null -s http://$(terraform output -raw alb_dns_name)

License

This project is licensed under the MIT License - see the LICENSE file for details.

Author

Owner : NTSEZE VOUFFO NELVIS

Role Responsibilities

Role	Responsibilities
Solutions Architect	Architecture design, security compliance, system diagrams, trade-off analysis
Cloud/DevOps Engineer	Infrastructure automation, CI/CD, deployment, monitoring setup

Designing a Production-Grade Multi-AZ Web Architecture on AWS Using ALB, EC2, and Auto Scaling

Ntseze-Nelvis — Thu, 15 Jan 2026 16:06:04 +0000

Executive Summary

In this project, we design and deploy a highly available, fault-tolerant, and scalable web application architecture on AWS using an Application Load Balancer integrated with an existing Auto Scaling Group across multiple Availability Zones.

This architecture reflects real production systems used by:

Banking platforms
E-commerce websites
SaaS products
Enterprise web backends

If you’re preparing for AWS certifications, DevOps interviews, or real production work, this project checks all the boxes.

Project Objective (Interview-Ready Framing)

Design and deploy a production-grade web architecture that automatically handles:

Traffic spikes
Instance failures
Availability Zone outages

— without downtime.

We achieve this by:

Distributing traffic using an Application Load Balancer
Running EC2 instances across multiple AZs
Integrating an existing Auto Scaling Group
Enforcing security best practices
Validating real-world failure scenarios

Prerequisites

Networking

VPC with:
- At least 2 public subnets in different AZs
- Internet Gateway
- Route table: 0.0.0.0/0 → IGW

Compute & Access

Existing Auto Scaling Group: hsbc-asg
EC2 Key Pair (for SSH)
IAM permissions for:
- EC2
- Load Balancers
- Target Groups
- Auto Scaling
- Security Groups

Section 1 — Security Groups (Foundation of Security)

1.1 EC2 Security Group — `sg_web-servers`

Purpose: Control backend server access.

Inbound Rules

Type	Port	Source
HTTP	80	0.0.0.0/0 (temporary)
SSH	22	My IP

Intentional design: Public HTTP is allowed initially for validation, then hardened later — a classic interview scenario.

1.2 Load Balancer Security Group — `sg_alb`

Purpose: Allow public web traffic to ALB only.

Type	Port	Source
HTTP	80	0.0.0.0/0

Sections 2 & 3 — Launch EC2 Web Servers (Multi-AZ)

To demonstrate high availability and fault tolerance, deploy two EC2 instances in different Availability Zones (AZs).

The steps below show how to launch one instance.

Repeat the same steps for the second instance, selecting a different AZ and user data script.

Launch EC2 Instance (Repeat for Second AZ)

Launch a New EC2 Instance

Navigate to AWS Console → EC2 → Instances
Click Launch Instance

Configure Instance Basics

Name: hsbc-server1
AMI: Amazon Linux 2
Instance Type: t2.micro
Key Pair: Select an existing key pair

Network Configuration (Critical)

VPC: Select your existing VPC
Subnet: Public subnet in AZ-A
Auto-assign Public IP: Enabled
Security Group: sg_web-servers

For the second instance, choose a public subnet in a different AZ (AZ-B).

Configure Storage

Leave default settings (8 GB gp3)

Advanced Settings — User Data

Paste the following User Data script:

#!/bin/bash
yum update -y
yum install httpd git -y
git clone https://github.com/Ntseze-Nelvis/CloudReality-ecommerce-web-app.git
cp -r CloudReality-ecommerce-web-app/server1/* /var/www/html/
systemctl start httpd
systemctl enable httpd

Instance B — `hsbc-server2` (AZ-B)

#!/bin/bash
set -e
yum update -y
yum install -y httpd git
cd /home/ec2-user
git clone https://github.com/Ntseze-Nelvis/CloudReality-ecommerce-web-app.git
if [ ! -d "CloudReality-ecommerce-web-app/server2" ]; then
  echo "ERROR: server2 directory not found"
  exit 1
fi
rm -rf /var/www/html/*
cp -r CloudReality-ecommerce-web-app/server2/* /var/www/html/

chown -R apache:apache /var/www/html

systemctl enable --now httpd

Section 4 — Backend Validation (Before ALB)

Why this matters

Always validate components before adding complexity.

Steps

Access each EC2 via public IP (http://)

Confirm content loads correctly

Ensure HTTP service is running

✔ Isolates issues early

✔ Follows production troubleshooting best practices

Section 5 — Target Group (ALB → EC2 / ASG)

Target Group Configuration

Name: tg-hsbc-web
Protocol: HTTP
Port: 80
Health check path: /

Register targets

hsbc-server1
hsbc-server2

Wait until both show Healthy.

Section 6 — Application Load Balancer

ALB Configuration

Name: hsbc-alb-web
Scheme: Internet-facing
Subnets: 2 public AZs
Security Group: sg-alb
Listener: HTTP :80
Action: Forward to tg-hsbc-web

Section 7 — Load Balancing Test

Visit the ALB DNS name:

http://hsbc-alb-web-xxxx.elb.amazonaws.com

Load Balancing Validation

Refresh the ALB endpoint multiple times:

✔ Confirms round-robin traffic distribution

✔ Confirms ALB health checks are functioning correctly

Section 8 — Attach Existing Auto Scaling Group

Attach hsbc-asg to the Application Load Balancer:

Steps

Navigate to Auto Scaling Group → Load Balancing
Attach to an existing target group
Select tg-hsbc-web

✔ New instances automatically register with the ALB

✔ Zero manual intervention required

Section 9 — Real-World Failure Scenarios (Interview Ready)

Test 1 — Instance Failure

Manually terminate an EC2 instance
Auto Scaling Group launches a replacement
ALB reroutes traffic automatically

Test 2 — Load Spike

sudo stress --cpu 4 --timeout 120

✔ ASG scales out automatically

✔ ALB distributes increased traffic

Test 3 — Application Failure

Stop the web service on an instance:

sudo systemctl stop httpd

✔ ALB marks the instance as unhealthy

✔ ASG replaces the instance automatically (if configured)

Section 10 — Security Hardening (Production Must)

Before (Insecure)

EC2 instances allowed HTTP access from 0.0.0.0/0

After (Correct)

Remove public HTTP rule from the EC2 Security Group
Allow HTTP only from sg-alb

✔ EC2 instances are now private

✔ ALB is the single entry point

✔ Highly tested AWS exam & interview concept

Section 11 — Cleanup (Cost Control)

Delete the Application Load Balancer
Delete the Target Group
Restore ASG desired capacity
Terminate test EC2 instances
Remove unused Security Groups and volumes

Certification & Interview Mapping

AWS Exam Topics Covered

High Availability
Elastic Load Balancing
Auto Scaling
Health Checks
Security Groups
Fault Tolerance

Why This Architecture Matters (Interview Gold)

Common Production Problems

Problem	Impact
Single EC2 failure	Application downtime
Traffic spikes	Performance degradation
Manual scaling	Slow & error-prone
Public EC2 exposure	Security risks

Solution Implemented

Multi-AZ EC2 deployment
Application Load Balancer
Auto Scaling Group integration
Health checks & self-healing
ALB → EC2 security isolation

This is the default architecture AWS expects in real environments.

Final Architecture Overview

✔ Highly available

✔ Horizontally scalable

✔ Secure by design

✔ Production-ready

Interview Questions This Project Answers

Q: Why use an ALB instead of exposing EC2 directly?

A: Security, scalability, health checks, and zero-downtime deployments

Q: How does an Auto Scaling Group integrate with an ALB?

A: Through target groups with dynamic instance registration

Q: What happens if an Availability Zone goes down?

A: The ALB routes traffic to healthy AZs automatically

Problem → Solution Summary

Problem	Solution
EC2 failure	Auto Scaling replacement
Traffic spikes	Horizontal scaling
Single-AZ risk	Multi-AZ deployment
Public EC2 exposure	ALB-only access
Manual recovery	Automated health checks

DAY 4 & 5: ADVANCED EC2 DEPLOYMENT PATTERNS & ENTERPRISE STRATEGIES

Ntseze-Nelvis — Fri, 28 Nov 2025 15:24:42 +0000

Objective: Create a fault-tolerant web application across multiple Availability Zones

Step 1: Create Launch Template

1.1 Navigate to EC2 Console

Go to AWS Management Console
Search for EC2 and click on it
In the left sidebar, click Launch Templates

1.2 Create New Launch Template

Click Create launch template

Fill in the following details:

Launch template name and description

Launch template name: production-web
Template version description: Production web servers
Auto Scaling guidance: Check Provide guidance to help me set up a template for use with EC2 Auto Scaling

Application and OS Images (Amazon Machine Image)

AMI: Choose Amazon Linux 2 AMI (ami-0c02fb55956c7d316 or latest)
Click Select

Instance type

Instance type: t3.medium

Key pair (login)

Key pair name: cloudreality-KP

Network settings

Security groups: Select existing or create new:

Security group name: web-sg
Description: Allow SSH and HTTP
Inbound rules:
- SSH (port 22) — Your IP
- HTTP (port 80) — 0.0.0.0/0

1.3 Configure Advanced Details

Scroll to Advanced details → User data and paste:

#!/bin/bash

# Update system and install Apache
yum update -y
yum install -y httpd

# Enable and start Apache
systemctl enable httpd
systemctl start httpd

# Create web page
cat <<EOF > /var/www/html/index.html
<h1>Hello from CloudReality Auto Scaling Group</h1>
<p>Instance ID: $(curl -s http://169.254.169.254/latest/meta-data/instance-id)</p>
<p>Availability Zone: $(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone)</p>
EOF

1.4 Create Launch Template

Click "Create launch template"
You'll see success message: "Launch template production-web was successfully created"

Step 2: Create Auto Scaling Group

2.1 Navigate to Auto Scaling Groups

In EC2 left sidebar, click "Auto Scaling Groups"
Click "Create Auto Scaling group" button

2.2 Choose Launch Template

Auto Scaling group name: production-web-asg
Launch template: Select production-web from dropdown
Click "Next"

2.3 Configure Instance Launch Options

Choose instance launch options:

Purchase options and instance types: Keep default (On-demand)
Network: Select your VPC
Subnets: CRITICAL - Select AT LEAST 2 DIFFERENT SUBNETS in different Availability Zones
- Example: subnet-12345678 (us-east-1a)
- Example: subnet-87654321 (us-east-1b)

Click "Next"

2.4 Configure Advanced Options

Load balancing:

Attach to an existing load balancer: ☐ No load balancer (we'll add later)

![Configure Advanced Options

](...)

Health checks:

☑ EC2 (default)
☑ ELB (check this for application-level health checks)
Health check grace period: 300 seconds

Additional settings:

Monitoring: ☑ Enable CloudWatch detailed monitoring

Click "Next"

2.5 Configure Group Size and Scaling

Group size:

Desired capacity: 3
Minimum capacity: 2
Maximum capacity: 10

Scaling policies:

Select "Target tracking scaling policy"
Metric type: Average CPU utilization
Target value: 50 (percent)

Click "Next"

2.6 Add Tags

Click "Add tag"
Key: Name
Value: production-web
☑ Tag instances (this tags all instances created by ASG)

Click "Next"

2.7 Review and Create

Review all settings
Click "Create Auto Scaling group"

Step 3: Verify Auto Scaling Group

3.1 Check Auto Scaling Group Status

Go to Auto Scaling Groups in EC2 console
Click on your new ASG: production-web-asg
Check "Instance management" tab
You should see 3 instances launching with status "Pending" → "InService"

3.2 Monitor Instance Launch

Go to Instances in EC2 console
You should see 3 new instances with names production-web
Wait for all instances to show "3/3 checks passed"

Step 4: Test the Setup

4.1 Test Web Server

For each instance:

Copy the Public IP address
Open web browser and go to: http://<PUBLIC_IP>
You should see: "Hello from Auto Scaling Group" with instance details

4.2 Test Instance Replacement

In Instances console, select one instance
Click "Instance state" → "Terminate instance"
Confirm termination
Watch Auto Scaling Group:
- ASG will detect missing instance
- New instance will automatically launch
- Wait 2-3 minutes for new instance to be ready

4.3 Test Manual Scaling

Go to Auto Scaling Groups → Select your ASG
Click "Edit" (top right)
Change "Desired capacity" to 5
Click "Update"
Watch 2 new instances launch automatically

Step 5: Configure CloudWatch Alarms

5.1 Create CPU Utilization Alarm

Go to CloudWatch console
Click "Alarms" → "All alarms" → "Create alarm"
Click "Select metric"
Choose "EC2" → "Per-Instance Metrics"
Select "CPUUtilization" for your instances
Click "Select metric"

Configure conditions:

Threshold type: Static
Whenever CPUUtilization is...: Greater > 70
Additional configuration:
- Datapoints to alarm: 2 out of 2
- Missing data treatment: Treat missing data as missing

Configure actions:

Alarm state trigger: In alarm
Select an SNS topic: Create new topic
Name: asg-high-cpu-alert
Email endpoints: Enter your email

Click "Create alarm"

5.2 Create Scale-Out Policy (Optional)

Go back to your Auto Scaling Group
Click "Automatic scaling" tab
Click "Create dynamic scaling policy"
Policy type: Step scaling
Alarm: Select the CPU alarm you created
Take the action: Add 2 capacity units when alarm triggers

Step 6: Monitoring and Validation

6.1 Check Auto Scaling Activities

In your ASG, go to "Activity" tab
You should see history of all scaling activities

6.2 Verify Multi-AZ Distribution

In "Instance management" tab
Check that instances are distributed across different Availability Zones

6.3 Test Application

Access each instance via public IP
Verify all instances serve the web page correctly
Note different instance IDs and AZs shown on each page

Success Checklist

[ ] Launch template created successfully
[ ] Auto Scaling Group created with 3 instances
[ ] Instances distributed across multiple AZs
[ ] Web servers responding on port 80
[ ] Instance auto-replacement working
[ ] Manual scaling working
[ ] CloudWatch alarms configured
[ ] All instances healthy in ASG

Troubleshooting Tips

Instances not launching: Check security group inbound rules
Health checks failing: Increase health check grace period
Web server not responding: Check User Data script for errors
No public IP: Ensure subnets have auto-assign public IP enabled

Your production-grade Auto Scaling Group is now ready! 🚀

Step 1: Delete the Auto Scaling Group (ASG)

Go to the EC2 console → Auto Scaling Groups.
Select your ASG (production-web-asg).
Click Delete.
When prompted, choose “Yes, terminate all instances” so that all EC2 instances managed by this ASG are stopped and deleted.
Wait until the ASG status disappears from the console.

⚠️ Important: Deleting the ASG will not delete your Launch Template or Security Groups. That’s next.

Step 2: Terminate any leftover EC2 instances

Go to EC2 → Instances.
Look for any instances with the name production-web or related.
Select them → Instance state → Terminate instance.
Wait until they show terminated.

Step 3: Delete the Launch Template

Go to EC2 → Launch Templates.
Select the launch template: production-web.
Click Actions → Delete template.
Confirm deletion.

Step 4: Delete Security Groups

Go to EC2 → Security Groups.
Find the security group you created (web-sg) or any related to this app.
Select it → Actions → Delete security group.
Confirm deletion. > ⚠️ You cannot delete a security group if it’s still attached to a running instance or ENI. Make sure all instances are terminated. --- ## Step 5: Delete Load Balancers (if created)
Go to EC2 → Load Balancers (or Elastic Load Balancing).
Find any load balancers you attached to the ASG.
Select it → Actions → Delete.
Confirm deletion.

Step 6: Delete CloudWatch Alarms

Go to CloudWatch → Alarms → All alarms.
Look for alarms you created, e.g., asg-high-cpu-alert.

3. Select → Actions → Delete.

Step 7: Delete SNS Topics (if any)

Go to SNS → Topics.
Find any topic you created (like asg-high-cpu-alert).

3. Select → Delete topic.

Step 8: Clean up Key Pairs (optional)

Go to EC2 → Key Pairs.

2. Select `cloudreality-KP` (or any you used for this app) → Delete key pair.

✅ After completing these steps, your AWS account will be completely clean of this multi-AZ setup.

DAY 4 — ADVANCED EC2 DEPLOYMENT PATTERNS & ENTERPRISE STRATEGIES

Overview

Master production-grade EC2 architectures, automation, and enterprise best practices for real-world deployments.

Hands-On Lab: Production Auto Scaling Group

Objective: Deploy a fault-tolerant web application across multiple Availability Zones.

Create Launch Template

# Create Launch Template
aws ec2 create-launch-template \
  --launch-template-name production-web \
  --version-description "Production web servers" \
  --launch-template-data '{
    "ImageId": "ami-0c02fb55956c7d316",
    "InstanceType": "t3.medium",
    "KeyName": "cloudreality-KP",
    "SecurityGroupIds": ["sg-1234567890abcdef0"],
    "UserData": "IyEvYmluL2Jhc2gKc3VkbyB5dW0gdXBkYXRlIC15CnN1ZG8geXVtIGluc3RhbGwgLXkgaHR0cGQKc3VkbyBzeXN0ZW1jdGwgc3RhcnQgaHR0cGQKZWNobyAiPGgxPkhlbGxvIGZyb20gQXV0byBTY2FsaW5nIEdyb3VwPC9oMT4iIHwgc3VkbyB0ZWUgL3Zhci93d3cvaHRtbC9pbmRleC5odG1s"
  }'

Create Auto Scaling Group

# Create Auto Scaling Group
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name production-web-asg \
  --launch-template LaunchTemplateName=production-web,Version='$Latest' \
  --min-size 2 \
  --max-size 10 \
  --desired-capacity 3 \
  --vpc-zone-identifier "subnet-12345678,subnet-87654321" \
  --health-check-type ELB \
  --health-check-grace-period 300 \
  --tags "Key=Name,Value=production-web,PropagateAtLaunch=true"

Practice Tasks

Test instance replacement by terminating one instance
Scale the ASG manually and observe new instances
Configure CloudWatch alarms for auto-scaling # How to Delete Your Multi-AZ Fault-Tolerant Web Application Setup in AWS

📘 AWS Docs:

Certification Focus

Exam Topic: High Availability, Auto Scaling, Load Balancing
AWS Certs: Solutions Architect Professional, DevOps Engineer Professional

Questions

What's the difference between launch configurations and launch templates?
How do you ensure zero-downtime deployments with Auto Scaling Groups?
What metrics are most important for scaling decisions?

💡 Problem & Solution

Problem	Cause	Fix
ASG instances failing health checks	Application startup too slow	Increase health check grace period
Scaling too aggressively	Wrong CloudWatch alarm thresholds	Adjust scaling policies and cooldown periods
Instances unevenly distributed	Imbalanced subnet configuration	Use multiple AZs and balanced subnets

Certification Questions

Expert Level (Solutions Architect Professional)

Q1: Design a multi-region active-active architecture with 99.99% availability

A: Use Global Accelerator, Route53 latency routing, cross-region read replicas, and automated failover

Q2: How do you implement blue-green deployments for EC2 with zero downtime?

A: Use Elastic Load Balancer with target groups, Auto Scaling groups, and weighted routing

Q3: Design cost-optimized architecture handling 10x traffic spikes

A: Spot Fleets (70%) + On-Demand (20%) + Reserved (10%) with predictive scaling

Enterprise Interview Scenarios

Architecture Design Questions

"Design an EC2 architecture for a financial trading platform requiring <1ms latency"
"How would you secure EC2 instances handling PCI-DSS compliant data?"
"Design a migration strategy for 500 on-premises servers to EC2"

Troubleshooting Scenarios

"Users report intermittent 503 errors - walk through your investigation process"
"Database performance degraded 50% after migration to EC2 - diagnose and fix"
"Auto Scaling group constantly cycling instances - root cause analysis"

Real-World Scenarios

Scenario 1: E-Commerce Platform Migration

Problem: Black Friday traffic spikes causing downtime

Solution: Implemented predictive scaling with CloudWatch metrics and Spot Fleets for cost optimization

Scenario 2: Microservices Container Platform

Problem: Container instances failing health checks

Solution: Implemented custom health checks, instance replacement policies, and proper drain configurations

🗓️ DAY 5 — ENTERPRISE SECURITY & COST OPTIMIZATION

Overview

Implement enterprise-grade security, compliance, and cost optimization strategies for production workloads.

Hands-On Lab: Security Hardening & Cost Management

Objective: Implement security best practices and cost optimization techniques.

Enforce IMDSv2 and disable IMDSv1

# Enforce IMDSv2 and disable IMDSv1
aws ec2 modify-instance-metadata-options \
  --instance-id i-1234567890abcdef0 \
  --http-tokens required \
  --http-endpoint enabled

Create cost allocation tags

bash

# Create cost allocation tags
aws ec2 create-tags \
  --resources i-1234567890abcdef0 \
  --tags Key=CostCenter,Value=Engineering Key=Project,Value=WebApp

Set up budget alerts

# Set up budget alerts
aws budgets create-budget \
  --account-id 123456789012 \
  --budget file://budget.json \
  --notifications-with-subscribers file://notifications.json

you can help share the link https://dev.to/ntsezenelvis/aws-ec2-mastery-bootcamp-45od

Ntseze-Nelvis — Wed, 05 Nov 2025 02:02:26 +0000

AWS EC2 Mastery Bootcamp

Ntseze-Nelvis ・ Nov 5 '25

#devops #tutorial #cli #aws

AWS EC2 Mastery Bootcamp

Ntseze-Nelvis ・ Nov 5 '25

#devops #tutorial #cli #aws

AWS EC2 Mastery Bootcamp

Ntseze-Nelvis — Wed, 05 Nov 2025 02:00:57 +0000

AWS EC2 Series – 3-Days Intensive Hands-On Track

Tags: aws, ec2, devops, cloud, infrastructure

Overview

This 3-day sprint helps you master EC2 fundamentals, networking, and storage with real-world labs, AWS documentation links, and certification-oriented challenges.

Each day blends AWS Console + CLI + troubleshooting to make you exam-ready and project-capable.

🗓️ DAY 1 — EC2 FUNDAMENTALS & INSTANCE OPERATIONS

Overview

Understand EC2 basics AMIs, instance types, pricing models, and lifecycle.

You'll learn to launch, manage, and automate EC2 instances efficiently.

Hands-On Lab: Multi-Instance Launch & Lifecycle

Objective: Launch multiple EC2 instances across AZs.

# Create a key pair
aws ec2 create-key-pair --key-name cloudreality-KP --query 'KeyMaterial' --output text > cloudreality-KP.pem
chmod 400 cloudreality-KP.pem

# Launch instances
aws ec2 run-instances \
  --image-id ami-0c02fb55956c7d316 \   <!-- EDIT THIS: Use AMI for your region -->
  --count 2 \
  --instance-type t3.micro \
  --key-name cloudreality-KP \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=DevOps-Lab}]'

Practice Tasks

Stop/start and observe IP changes
Resize instance type
Terminate one and review volume behavior

📘 AWS Docs:

📚 Certification Focus

Exam Topic: EC2 lifecycle states, AMI and key pair management
AWS Certs: Cloud Practitioner (CLF-C02), Solutions Architect – Associate (SAA-C03)

Questions

What is the difference between stopping and terminating an instance?
Which EC2 purchase option best suits long-term stable workloads?

💡 Problem & Solution

Problem	Cause	Fix
Instance not showing	Wrong region	Switch to correct AWS region
Launch failed	IAM policy missing	Attach AmazonEC2FullAccess
Stopped instance lost IP	Used public IP, not Elastic IP	Allocate and associate an Elastic IP

📚 Certification Focus

Exam Topic: EC2 lifecycle states, AMI and key pair management
AWS Certs: Cloud Practitioner (CLF-C02), Solutions Architect – Associate (SAA-C03)

🎓 Certification Questions

Basic Level (Cloud Practitioner)

Q1: What happens to data on instance store volumes when an EC2 instance is stopped?

A: Data on instance store volumes is lost, while EBS volumes persist.

Q2: Which EC2 pricing model offers the lowest cost for uninterruptible workloads?

A: Reserved Instances (1-3 year commitment)

Intermediate Level (Solutions Architect)

Q3: Your company needs to run a batch processing job for 6 hours. Which purchasing option is most cost-effective?

A: Spot Instances, as they offer up to 90% discount for interruptible workloads.

Q4: How can you ensure an EC2 instance maintains the same public IP after restart?

A: Use an Elastic IP address and associate it with the instance.

Advanced Level (DevOps Engineer)

Q5: Describe how to implement instance refresh with Auto Scaling Groups while maintaining zero downtime.

A: Use rolling deployments with health checks, and configure minimum healthy percentage.

💼 Interview Questions

Basic Questions

"What's the difference between stopping and terminating an EC2 instance?"
"How do you choose between different instance families?"
"What are the key factors in selecting an AMI?"

Intermediate Questions

"How would you design a cost-optimized architecture for a web application with predictable traffic?"
"Explain the process of migrating an on-premises application to EC2."
"What monitoring metrics are crucial for EC2 instances?"

Advanced Questions

"How do you implement disaster recovery for EC2 instances across regions?"
"Describe a scenario where you'd use placement groups and the trade-offs involved."
"How would you troubleshoot an instance that's failing health checks?"

Real-World Scenarios

Scenario 1: Cost Optimization Challenge

Problem: A company's EC2 costs increased 200% due to developers using on-demand instances for development.

Solution: Implemented Auto Scaling with Spot Instances for non-production workloads, saving 65% on compute costs.

Scenario 2: Performance Issue

Problem: Application experiencing high CPU steal on shared tenancy instances.

Solution: Migrated to dedicated instances and implemented proper monitoring with CloudWatch.

🗓️ DAY 2 — NETWORKING, SECURITY GROUPS & ELASTIC IPs

Overview

Secure instance access, configure firewall rules, and deploy a simple web app.

Hands-On Lab: Deploy a Public Web Server

Objective: Assign an Elastic IP, configure SGs, and host a simple webpage.

# Allocate Elastic IP
aws ec2 allocate-address --domain vpc

# Associate to instance
aws ec2 associate-address \
  --instance-id i-0abcd1234efgh5678 \
  --allocation-id eipalloc-0abcdef1234567890

# Create Security Group
aws ec2 create-security-group \
  --group-name web-sg \
  --description "Allow SSH & HTTP access" \
  --vpc-id vpc-0ab12c34d56e78f90

# Add ingress rules
aws ec2 authorize-security-group-ingress --group-name web-sg --protocol tcp --port 22 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-name web-sg --protocol tcp --port 80 --cidr 0.0.0.0/0

Validation

SSH into instance
Install Apache
View site in browser

sudo yum install -y httpd
sudo systemctl start httpd
echo "<h1>Hello from Nelvis EC2 Web Server</h1>" | sudo tee /var/www/html/index.html

📘 AWS Docs:

📚 Certification Focus

Exam Topic: EC2 connectivity, networking, security boundaries
AWS Certs: SysOps Administrator, DevOps Engineer

Questions

Compare Security Groups and NACLs.
Why does Elastic IP retain its address across instance stops?
How can you secure SSH access from a corporate network only?

📘 AWS Docs:

💡 Problem & Solution

Problem	Cause	Fix
SSH Timeout	SG rule missing	Allow TCP 22 inbound
Webpage not loading	HTTP rule missing or Apache off	Add port 80 + start service
Elastic IP not reachable	Wrong instance association	Reassociate using CLI

📚 Certification Focus

Exam Topic: EC2 connectivity, networking, security boundaries
AWS Certs: SysOps Administrator, DevOps Engineer

🎓 Certification Questions

Basic Level

Q1: What's the difference between Security Groups and NACLs?

A: Security Groups are stateful (return traffic allowed automatically) and operate at instance level, while NACLs are stateless and operate at subnet level.

Q2: Why does an Elastic IP retain its address across instance stops?

A: Elastic IPs are allocated to your AWS account, not specific instances.

Intermediate Level

Q3: How can you restrict SSH access to only your corporate network?

A: Modify Security Group to allow port 22 only from your corporate IP range (e.g., 192.168.1.0/24).

Q4: What happens to Elastic IP charges when an instance is stopped?

A: You're charged for unattached Elastic IPs, but not for attached ones to running instances.

Advanced Level

Q5: Design a network architecture that spans multiple AZs with proper failover capabilities.

A: Use multiple subnets across AZs, Elastic IPs with failover scripts, and proper route table configurations.

Interview Questions

Basic Questions

"What's the default behavior of a new Security Group?"
"How do Security Groups differ from traditional firewalls?"
"When would you use an Elastic IP vs. a public IP?"

Intermediate Questions

"How would you design security groups for a 3-tier web application?"
"What are the implications of using 0.0.0.0/0 in security group rules?"
"How do you troubleshoot connectivity issues between instances in different subnets?"

Advanced Questions

"Design a network architecture that complies with PCI-DSS requirements."
"How would you implement zero-trust networking in AWS?"
"What strategies would you use for gradual security group rule migration?"

Real-World Scenarios

Scenario 1: Security Breach

Problem: Company exposed SSH to 0.0.0.0/0, leading to brute force attacks.

Solution: Implemented security group rules restricting SSH to corporate IP, set up AWS WAF, and used Session Manager for SSH.

Scenario 2: High Availability Requirement

Problem: Application needed to survive AZ failure with minimal downtime.

Solution: Deployed across multiple AZs with Elastic IP failover automation and health checks.

🗓️ DAY 3 — EBS VOLUMES, SNAPSHOTS & BACKUPS

Overview

Understand persistent storage, expand volumes, and set up snapshot automation.

Hands-On Lab: EBS Management

Objective: Create, attach, and back up a volume.

# Create EBS Volume
aws ec2 create-volume \
  --availability-zone us-east-1a \
  --size 10 \
  --volume-type gp3

Attach to instance

aws ec2 attach-volume \
  --volume-id vol-0abcdef1234567890 \
  --instance-id i-0abcd1234efgh5678 \
  --device /dev/xvdf

Then SSH into the instance:

sudo mkfs -t xfs /dev/xvdf
sudo mkdir /data
sudo mount /dev/xvdf /data
df -h

📘 AWS Docs:

💡 Problem & Solution

Problem	Cause	Fix
Volume not attaching	Different AZ	Recreate volume in same AZ
Data lost after termination	Root volume deleted	Disable DeleteOnTermination
Snapshots not running	Missing IAM role	Attach AmazonDLMFullAccess

📚 Certification Focus

Exam Topic: Storage, Backup, High Availability
AWS Certs: Solutions Architect, DevOps Engineer

🎓 Certification Questions

Basic Level

Q1: What happens when you detach a root EBS volume?

A: The instance becomes unusable as the operating system is on the root volume.

Q2: How can you restore a snapshot to a new volume?

A: Create a new volume from the snapshot in the EC2 console or using AWS CLI.

Intermediate Level

Q3: What's the difference between gp2, gp3, and io2 volumes?

A: gp2: baseline performance, gp3: provisioned performance, io2: highest performance with durability.

Q4: How do you increase the size of an EBS volume?

A: Modify volume size in console/CLI, then extend filesystem in OS.

Advanced Level

Q5: Design a backup strategy for a mission-critical database on EC2.

A: Use application-consistent snapshots with DLM, multi-region replication, and automated recovery testing.

💼 Interview Questions

Basic Questions

"What are the different EBS volume types and their use cases?"
"How does EBS snapshot pricing work?"
"What's the process for resizing an EBS volume?"

Intermediate Questions

"How would you design a backup strategy for compliance requirements?"
"What are the performance characteristics of different EBS volume types?"
"How do you monitor EBS performance and troubleshoot issues?"

Advanced Questions

"Design a disaster recovery strategy with RTO of 15 minutes and RPO of 5 minutes."
"How would you implement cross-region snapshot replication automatically?"
"What are the considerations for EBS-optimized instances?"

Real-World Scenarios

Scenario 1: Database Performance Issue

Problem: Database performance degraded due to insufficient IOPS on gp2 volumes.

Solution: Migrated to gp3 volumes with provisioned IOPS, implemented monitoring, and set up performance baselines.

Scenario 2: Backup Failure

Problem: Critical snapshots failed due to IAM permissions during automated backup process.

Solution: Implemented proper IAM roles with least privilege, added backup success/failure notifications, and created runbooks.

📘 Extra Learning & Exam Resources

Category	Resource
EC2 Official Docs	https://docs.aws.amazon.com/ec2
AWS Hands-On Tutorials	https://aws.amazon.com/getting-started/hands-on/
AWS Labs GitHub	https://github.com/aws-samples
Exam Prep – AWS Cloud Practitioner	https://aws.amazon.com/certification/certified-cloud-practitioner/
Exam Prep – Solutions Architect	https://aws.amazon.com/certification/certified-solutions-architect-associate/
Exam Prep – DevOps Engineer	https://aws.amazon.com/certification/certified-devops-engineer-professional/
💬 Troubleshooting Reference	https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-troubleshooting.html

DAY 2: EC2 FUNDAMENTALS & INSTANCE MANAGEMENT

Ntseze-Nelvis — Sat, 25 Oct 2025 03:16:51 +0000

Complete Step-by-Step Guide

Welcome to Day 2 of the AWS EC2 Series a hands-on journey to mastering EC2 for DevOps and Cloud Engineers.

🛠 HANDS-ON LAB SCENARIO

Lab: Multi-Instance Deployment & Management

Objective: Launch instances across AZs and practice lifecycle operations.

Step 1: Launch Instances

# Create key pair first
aws ec2 create-key-pair --key-name MyKeyPair --query 'KeyMaterial' --output text > MyKeyPair.pem
chmod 400 MyKeyPair.pem

# Launch instances in different AZs
aws ec2 run-instances \
    --image-id ami-0c02fb55956c7d316 \
    --count 3 \
    --instance-type t3.micro \
    --key-name MyKeyPair \
    --placement AvailabilityZone=us-east-1a

Step 2: Instance Operations

# Get instance IDs
INSTANCE_IDS=$(aws ec2 describe-instances --query 'Reservations[].Instances[].InstanceId' --output text)

# Stop one instance
aws ec2 stop-instances --instance-ids i-1234567890abcdef0

# Change instance type (must be stopped)
aws ec2 modify-instance-attribute --instance-id i-1234567890abcdef0 --instance-type "{\"Value\": \"t3.small\"}"

# Terminate instance
aws ec2 terminate-instances --instance-ids i-1234567890abcdef0

Step 3: Monitoring & Verification

# Check instance states
aws ec2 describe-instances --query 'Reservations[].Instances[].[InstanceId,InstanceType,State.Name]' --output table

# View pricing information
aws ec2 describe-spot-price-history --instance-types t3.micro --product-descriptions "Linux/UNIX" --start-time 2024-01-01T00:00:00Z

REAL-WORLD PROBLEM & SOLUTION

Problem Statement:
Company XYZ spends $5,000/month on EC2 with predictable 24/7 workload.
How to reduce costs by 40%?

Solution Implementation

Step 1: Analyze Current Usage

# Get current instance inventory
aws ec2 describe-instances \
  --query 'Reservations[].Instances[].[InstanceId,InstanceType,State.Name]' \
  --output table

# Check Cost Explorer (via AWS Console)

Step 2: Implement Reserved Instances

# Purchase Reserved Instances (conceptual)
aws ec2 purchase-reserved-instances-offering \
  --reserved-instances-offering-id <offering-id> \
  --instance-count 10 \
  --instance-type m5.large

###Step 3: Cost Monitoring Setup
# Create budget alert
aws budgets create-budget \
  --account-id 123456789012 \
  --budget file://budget.json \
  --notifications-with-subscribers file://notifications.json

budget.json

{
  "BudgetName": "ec2-monthly-budget",
  "BudgetLimit": {
    "Amount": "3000",
    "Unit": "USD"
  },
  "CostFilters": {
    "Service": "Amazon EC2"
  },
  "TimeUnit": "MONTHLY",
  "BudgetType": "COST"
}

🚀 CORE CONCEPTS Q&A

Q1: What's the difference between stopping vs terminating an instance?

Answer:

STOPPING:
- OS gracefully shuts down
- EBS root volume persists
- Instance can be restarted
- Keeps same private IP (usually)
- Charging stops for instance, continues for EBS

TERMINATING:
- Instance is permanently deleted
- EBS root volume deleted by default
- Cannot be recovered
- All data on instance store lost
- All charging stops

Q2: Explain EC2 purchasing options

Answer:

On-Demand:

Pay by second/hour
No long-term commitment
Most flexible, highest cost
Use case: unpredictable workloads

Reserved Instances:

1-3 year commitment
30-60% cost savings
Types: Standard, Convertible, Scheduled
Use case: predictable, steady-state

Spot Instances:

Up to 90% savings
Can be terminated with 2-minute warning
Use case: fault-tolerant, flexible workloads

Savings Plans:

1-3 year commitment
Flexible across instance family/region
Use case: consistent usage patterns

🎯 COMMON INTERVIEW QUESTIONS

Technical Questions

🟡 "What happens to EBS volumes when you terminate an instance?"
By default, root EBS volume is deleted, additional volumes persist.

🟡 "How do you change instance types?"
Stop instance → Change instance type → Start instance.

🟡 "What's the difference between reboot and stop/start?"
Reboot = OS restart (same hardware).
Stop/Start = may move to new hardware, new public IP.

Scenario-Based Question

"A company has applications with different reliability requirements. How would you recommend instance types?"**

Critical production: On-Demand/Reserved
Testing/Dev: Spot Instances
Batch processing: Spot Fleets
Long-running services: Reserved Instances

Certification-Style Questions

Question 1

Your company needs to run a critical database server for 3 years. Which EC2 option provides the lowest total cost?

Options:

A) On-Demand Instances
B) Spot Instances
C) Reserved Instances (All Upfront)
D) Savings Plans

Answer: C - Reserved Instances with All Upfront payment for predictable long-term workloads.

Question 2

What happens to data on an instance store volume when you stop an instance?

Answer: Data is preserved on EBS volumes but lost on instance store volumes when instance is stopped/terminated.

Question 3

Which instance would be most cost-effective for a batch processing job that can handle interruptions?

Answer: Spot Instances — up to 90% savings for interruptible workloads.

Troubleshooting Common Issues

Issue: Instance failed to launch due to insufficient capacity

Solutions:

# Try different instance type
aws ec2 run-instances --instance-type t3.small ...

# Try different AZ
aws ec2 run-instances --placement AvailabilityZone=us-east-1b ...

# Use capacity-optimized allocation strategy for Spot

Issue: Cannot Connect to Instance via SSH

✅ Checklist

✅ Security group allows SSH (port 22)
✅ Correct key pair
✅ Instance is in running state
✅ Public IP address is correct

📊 Day2 Hands-On Checklist

✅ Launch 3 instances in different AZs
✅ Practice stop/start/terminate operations
✅ Change instance type on stopped instance
✅ Create and attach EBS volume
✅ Configure security groups for SSH access
✅ Set up basic CloudWatch monitoring
✅ Calculate potential Reserved Instance savings

AWS EC2 Series

Ntseze-Nelvis — Fri, 10 Oct 2025 16:53:09 +0000

AWS EC2 Series – Part 1: EC2 Dashboard Deep Dive

Tags: aws, ec2, cloud, devops, infrastructure

Overview

Amazon EC2 (Elastic Compute Cloud) is the backbone of AWS compute services.

The EC2 Dashboard is your main console for managing EC2 instances, images, storage, security, and network components.

Mastering the dashboard is essential before diving into instances, AMIs, networking, and auto-scaling.

1. What is the EC2 Dashboard?

The EC2 Dashboard provides a centralized view of all EC2 resources in a specific AWS region. It allows you to:

Launch, stop, or terminate instances.
Monitor the status of instances and associated resources.
Manage storage volumes, snapshots, and security groups.
Track AWS events affecting your EC2 infrastructure.

Think of it as the control tower for your virtual servers and related resources.

2. Key Components of the EC2 Dashboard

Resource Summary

Displays counts of running instances, volumes, security groups, Elastic IPs, and key pairs.

Launch Instance Button

Shortcut to create new EC2 instances using predefined AMIs and instance types.

Events & Notifications

Alerts for scheduled maintenance, system updates, or instance retirement.

Quick Access Panels

Links to AMIs, Volumes, Snapshots, Security Groups, Load Balancers, and Auto Scaling Groups.

Region Selector

Ensures you are viewing resources in the correct AWS Region — crucial when managing multi-region deployments.

3. Common Issues and Solutions

Issue	Cause	Solution
Instances not visible	Wrong region selected	Switch to the correct region in the top-right corner
Unexpected instance stop	Billing issues, scheduled retirement	Check Events and ensure billing is active
Missing access to resources	IAM permissions missing	Request appropriate IAM policy (e.g., `AmazonEC2FullAccess`)

4. Hands-On Guide: Exploring the EC2 Dashboard

Objective: Familiarize yourself with EC2 Dashboard components and navigation.

Step 1:

Step 2:

Observe the Resource Summary. Take note of:

Running instances
EBS volumes
Security groups

Step 3:

Use the Region Selector to switch between regions and see how your resources vary.

Step 4:

Click on Events to review system notifications such as upcoming maintenance or instance retirement.

Step 5: Launch a small test EC2 instance:

Click Launch Instance

Choose Amazon Linux 2 AMI
Select t2.micro (Free Tier eligible)

Configure default VPC and subnet
Attach a key pair for SSH access
Launch and verify the instance appears in the dashboard

Step 6:

Explore other quick-access sections like Volumes, Security Groups, and Load Balancers.

5. Best Practices for Dashboard Usage

Always verify the region before launching resources.
Regularly check Events to avoid unexpected downtime.
Use tags for instances and resources to simplify management.
Combine the dashboard view with CloudWatch for monitoring metrics and alarms.
Leverage IAM roles to restrict dashboard access according to the principle of least privilege.

6. Interview Questions

Basic:

What is the EC2 Dashboard and why is it important?
Why is the region selector critical when managing EC2 resources?

Intermediate:

How do you monitor AWS maintenance events for your EC2 instances?
What is the difference between instance status and system status checks?

Advanced:

How can you replicate the dashboard view using AWS CLI or SDKs?
How do IAM policies affect visibility and access on the EC2 Dashboard?

7. Summary

The EC2 Dashboard is your first stop for managing AWS compute resources.

By understanding its layout, components, and functionality, you can:

Launch and manage EC2 instances efficiently.
Monitor health and system events proactively.
Control access securely through IAM.
Lay the foundation for advanced EC2 topics like auto-scaling, networking, and monitoring.

Next in the Series:

👉 EC2 Global View – Managing Multi-Region EC2 Resources at a Glance

AWS IAM ACCESS ANALYSIS & REPORTS

Ntseze-Nelvis — Thu, 09 Oct 2025 18:23:38 +0000

AWS IAM ACCESS ANALYSIS & REPORTS Deep Dive

aws #iam #security #devops

📌 This article is part of the AWS IAM Deep Dive series.

Part 1: IAM Users Deep Dive
Part 2: IAM Groups Deep Dive
Part 3: IAM Roles Deep Dive
Part 4: IAM Policies Deep Dive
Part 5: IAM Identity Providers Deep Dive
Part 6: AWS IAM ACCOUNT & ROOT MANAGEMENT Deep Dive
Part 7: AWS IAM Access Analysis & Reports Deep Dive (You’re here!)

1. What is Access Analysis & Reports in IAM?

AWS IAM Access Analysis & Reports are built-in tools that help you monitor, audit, and understand permissions across your AWS environment.

They help you detect unused, excessive, or risky permissions — ensuring you always follow the principle of least privilege.

2. Key Components

Access Analyzer

Scans resource-based policies to identify public or cross-account access.
Detects exposure in S3, KMS, IAM roles, and Lambda layers.
Automatically monitors and flags new findings.

Example: Detect if an S3 bucket policy accidentally allows "Principal": "*"

Resource Analysis (New)

Extends Access Analyzer to perform deep inspection at the resource level.
Reveals who can access specific resources and how that access is granted.
Ideal for pinpointing permission paths and exposure.

Example: Check who can modify an EC2 security group or delete a Lambda function.

Unused Access

Identifies permissions that have not been used within a set period (usually 90 days).
Helps you safely remove or restrict policies without affecting workloads.

Example: Remove ec2:DescribeInstances from users who haven’t accessed EC2 in 3 months.

Access Reports

Generate detailed reports for users, groups, and roles.
View permissions and service last accessed data for better auditing.

Example: Review if a role still needs access to RDS or Lambda.

🔑 Credential Reports

Generate an account-wide CSV showing:

Password last used
Access key age
MFA status
Last rotation date

Essential for compliance and governance reviews.

Example: Identify users with no MFA or old access keys.

3. Why It Matters

Access Analysis & Reports help you:

Detect over-permissioned users and roles.
Identify publicly exposed resources.
Enforce compliance (SOC2, ISO, PCI).
Simplify audits and maintain governance visibility.

4. Hands-On Guide

🎯 Goal: Detect and Fix Over-Permissive Access

Step 1: Enable Access Analyzer

Go to IAM → Access Analyzer → Create Analyzer

Choose your region
Select Organization or Account scope
Click Create Analyzer

AWS now continuously scans your environment for risky access.

Step 2: Review Findings

Go to Findings tab
Sort by Public access or Cross-account access
Review each finding → Resolve or Archive

Tip: Use tags or filters to focus on sensitive resources only.

Step 3: Generate a Credential Report

aws iam generate-credential-report  
aws iam get-credential-report --query 'Content' --output text | base64 --decode > credential-report.csv

Review the CSV for:

Users without MFA
Expired access keys
Root account usage

Step 4: Clean Up Unused Access

Go to IAM → Users → Access Advisor
Remove permissions from inactive or unused services.

You’ve just completed a mini IAM audit!

5. Best Practices

Review Access Analyzer findings weekly
Rotate access keys every 90 days or less
Delete inactive users and roles immediately
Grant least privilege only
Automate credential report checks via Lambda or AWS Config

6. Industry Examples

Enterprise: Uses Access Analyzer org-wide to detect cross-account S3 exposure.

Finance: Monthly credential report audits to maintain PCI compliance.

DevOps: Automated alerts when new public access findings appear.

Startup: Regular cleanup of unused IAM roles post-project delivery.

7. Interview Questions

🟢 Basic

What is AWS Access Analyzer?
What’s the difference between Access Analyzer and Access Reports?

🟡 Intermediate

How do you detect unused IAM permissions?
What information does a Credential Report contain?

🔴 Advanced

How can you automate IAM auditing using AWS Config or Lambda?
How would you secure multi-account Access Analyzer configurations?

🙏 Wrapping Up

Access Analysis & Reports act as your AWS security microscope — revealing what’s open, unused, or unsafe in your IAM setup.

Mastering these tools helps you maintain visibility, control, and compliance across all AWS accounts.

🔑 Key Takeaways

Use Access Analyzer to detect risky access.
Generate credential reports regularly.
Remove unused permissions proactively.
Enforce least privilege continuously.

Thanks for reading!

If this helped:

❤️ Leave a like and follow for more AWS/DevOps deep dives

💬 Comment your IAM audit tips or questions

🔗 Share with your team to promote better AWS security hygiene

🚀 Hurray you've completed the IAM Deep Dive Series

ACCOUNT & ROOT MANAGEMENT

Ntseze-Nelvis — Wed, 08 Oct 2025 14:47:42 +0000

AWS IAM ACCOUNT & ROOT MANAGEMENT Deep Dive

📌 This article is part of the AWS IAM Deep Dive series.

- Part 6: AWS IAM ACCOUNT & ROOT MANAGEMENT Deep Dive

1. What Is Account & Root Management in AWS IAM?

AWS Account & Root Management focuses on securing the foundation of your AWS environment. Your root user, account settings, and password policies.

Since the root user has full, unrestricted access, it’s the most powerful (and dangerous) identity in your AWS account.

Proper management ensures you protect this identity while enforcing strong authentication and governance across all users.

2. The Root Account — Handle With Extreme Care

The root user is automatically created when you first set up your AWS account.

It can perform any action, including deleting your entire account — which is why it should rarely (if ever) be used.

⚠️ Dangers of Using the Root Account

Bypasses IAM permissions and SCP restrictions
Can delete CloudTrail logs or disable billing alerts
Often targeted in phishing and credential theft attacks

3. Securing the Root Account

Step 1: Enable MFA (Multi-Factor Authentication)

Go to IAM → Dashboard → Activate MFA on Root Account

Choose Virtual MFA (e.g., Google Authenticator) or Hardware MFA token.

Benefit: Prevents unauthorized sign-in even if your password is leaked.

Step 2: Create an Admin IAM User

Create a new IAM user (e.g., admin-user)
Assign it AdministratorAccess permissions
Use this account for all administrative actions — not the root user

Tip: Store root credentials securely and use them only for critical tasks like billing or MFA recovery.

Step 3: Add Recovery Contacts

Add alternate contacts under Account Settings → Alternate Contacts

Include security, billing, and operations emails.

Ensures AWS sends alerts to the right teams if incidents occur.

🔑 Step 4: Rotate and Secure Credentials

Use a password manager to store root credentials
Rotate them at least once a year
Never embed root credentials in scripts or CI/CD tools

4. Enforcing Account-Wide Security

Password Policies

Set strong password policies for IAM users:

Minimum 12 characters
Require uppercase, lowercase, number, and symbol
Prevent password reuse
Force rotation every 90 days

CLI Example:

aws iam update-account-password-policy \
  --minimum-password-length 12 \
  --require-symbols \
  --require-numbers \
  --require-uppercase-characters \
  --require-lowercase-characters \
  --allow-users-to-change-password \
  --max-password-age 90 \
  --password-reuse-prevention 3

Account Settings Overview

From IAM → Account Settings, you can:

Enable password policies
Configure sign-in URLs
Enforce MFA on all users
Set up an AWS Account Alias (e.g., company-login.awsapps.com)

Tip: Custom aliases make it easier and safer for employees to sign in.

5. Best Practices

Use the root account only for account setup and billing tasks
Enable MFA immediately after creating your AWS account
Delegate admin access to an IAM user or role
Regularly review account security from the IAM Dashboard
Audit root account usage via CloudTrail events

6. Hands-On Guide

🎯 Goal: Lock Down the Root Account

Step 1: Enable MFA on Root

Go to IAM Dashboard → Security Recommendations → MFA on Root Account → Activate

Scan the QR code and store backup codes securely.

Step 2: Create a Secure IAM Admin User

aws iam create-user --user-name admin-user
aws iam attach-user-policy \
  --user-name admin-user \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

Test logging in as admin-user.

Step 3: Disable Root API Keys

Go to My Security Credentials → Access Keys and delete any active keys.

✅ Root should never have long-term access keys.

7. Industry Examples

🏢 Enterprise: Root account locked and controlled by InfoSec team; access only via MFA hardware token in a secure vault.

💻 Startup: Single owner uses root account only for billing, with daily operations done by IAM admins.

💰 Finance: Strict password policy enforced with quarterly credential audits.

🚀 DevOps: Admin roles delegated via AWS SSO, root used only for account recovery.

8. Interview Questions

🟢 Basic

What is the AWS root user?
Why should you avoid using the root account daily?

🟡 Intermediate

How do you enable MFA on the root account?
What does the account password policy control?

🔴 Advanced

How can CloudTrail be used to monitor root account activity?
How do you secure multiple AWS accounts under one organization?

🙏 Wrapping Up

The root account is the heart of your AWS environment — protect it like a crown jewel.

By enforcing MFA, password policies, and restricted usage, you build a strong foundation for all IAM security that follows.

🔑 Key Takeaways

Never use root for daily operations
Enable MFA and disable root access keys
Create an IAM admin for management
Enforce strong password and recovery policies

Thanks for reading!

If this helped:

❤️ Leave a like and follow for more AWS/DevOps deep dives

💬 Comment your IAM security tips

🔗 Share with your team to promote better AWS hygiene

🚀 Stay tuned for the next part of the IAM Deep Dive Series!

IDENTITY PROVIDERS

Ntseze-Nelvis — Fri, 03 Oct 2025 19:17:45 +0000

AWS IAM IDENTITY PROVIDERS Deep Dive

iamidentityproviders #iamroles #iam #aws

📌 This article is part of the AWS IAM Deep Dive series.

Part 1: IAM Users Deep Dive
Part 2: IAM Groups Deep Dive
Part 3: IAM Roles Deep Dive
Part 4: IAM Policies Deep Dive
[Part 5: IAM Identity Providers Deep Dive(https://dev.to/ntsezenelvis/identity-providers-18ka)

PART 5: IAM IDENTITY PROVIDERS

aws #iam #security #devops

1. What is an IAM Identity Provider?

An IAM Identity Provider (IdP) is a trusted external system (e.g., Okta, Azure AD, Google, GitHub, Auth0) that enables federated authentication into AWS without the need for creating long-lived IAM users.

Instead of storing AWS credentials locally, users authenticate with the IdP and assume roles in AWS through STS (Security Token Service).

2. Types of IAM Identity Providers

SAML 2.0 → Enterprise IdPs like Okta, Azure AD, ADFS.
OIDC (OpenID Connect) → Modern apps (Google, GitHub, Auth0).
Cognito → AWS-managed identity provider with social login support.
Web Identity Federation → Direct federation with STS AssumeRoleWithWebIdentity.

3. Trust Policy vs Permission Policy

📌 IAM roles with IdPs use two types of policies:

Trust Policy → Defines who can assume the role (the external IdP).
Permission Policy → Defines what actions the role can perform in AWS.

Example: Trust Policy (SAML Federation with Okta)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:saml-provider/MyOktaIdP"
      },
      "Action": "sts:AssumeRoleWithSAML",
      "Condition": {
        "StringEquals": {
          "SAML:aud": "https://signin.aws.amazon.com/saml"
        }
      }
    }
  ]
}

4. Common Problems with Identity Providers

🔴 Misconfigured SAML metadata (expired certificate or mismatch)

🔴 Overly broad trust policies (Principal: *)

🔴 Missing MFA enforcement in federation

🔴 Roles granting excessive session durations (12h+)

5. Best Practices

✅ Always use short-lived credentials (1–12 hours max)

✅ Enforce MFA via IdP + AWS conditions (aws:MultiFactorAuthPresent)

✅ Map IdP groups to roles in AWS (least privilege principle)

✅ Rotate SAML/OIDC metadata & thumbprints regularly

✅ Monitor STS AssumeRole events in CloudTrail

6. Hands-On Guide

Simple Example: GitHub Actions → AWS

What we're building:

Allow GitHub Actions to upload files to an S3 bucket
No complex SAML setup - using OIDC (modern, simpler approach)

Step-by-Step in 4 Simple Steps

Step 1: Create OIDC Identity Provider in AWS

Go to IAM → Identity Providers
Click "Add Provider"
Choose "OpenID Connect"
Enter:
- Provider URL: https://token.actions.githubusercontent.com
- Audience: sts.amazonaws.com

Click "Add provider"

✅ Done! AWS now trusts GitHub.

Step 2: Create IAM Role - Trust Policy

CHANGE THIS PART:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::[YOUR-AWS-ACCOUNT-ID]:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
          "token.actions.githubusercontent.com:sub": "repo:[YOUR-GITHUB-USERNAME]/[YOUR-REPO-NAME]:ref:refs/heads/main"
        }
      }
    }
  ]
}

Change these 3 things:

[YOUR-AWS-ACCOUNT-ID] → Your 12-digit AWS account number
[YOUR-GITHUB-USERNAME] → Your GitHub username or organization name
[YOUR-REPO-NAME] → Your repository name

Step 3: Add Permissions

Attach policy: AmazonS3FullAccess
Click "Next"

Step 4: Create Workflow File

Create: .github/workflows/deploy.yml

CHANGE THIS PART:

name: Deploy to S3

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write   # ← KEEP THIS LINE
      contents: read

    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v2
      with:
        role-to-assume: arn:aws:iam::[YOUR-AWS-ACCOUNT-ID]:role/github-actions-s3-deploy
        aws-region: us-east-1   # ← Change region if needed

    - name: Upload to S3
      run: |
        aws s3 sync ./ s3://[YOUR-BUCKET-NAME]/

Change these 3 things:

[YOUR-AWS-ACCOUNT-ID] → Same 12-digit AWS account number

us-east-1 → Your AWS region if different

7. Industry Examples

Startup: Developers use Google OIDC federation for AWS CLI access.

Enterprise: Okta SAML federation with AWS Organizations → mapped roles per business unit.

Finance: MFA enforced on SAML federation roles for compliance (PCI, SOX).

DevOps: GitHub Actions OIDC → AssumeRole directly in AWS without storing long-lived secrets.

8. Interview Questions

Basic:

What is an IAM Identity Provider?
Difference between SAML 2.0 and OIDC?

Intermediate:

How does sts:AssumeRoleWithSAML work?
Explain the difference between Trust Policy and Permission Policy.

Advanced:

How do you scale identity federation across multiple AWS accounts?
How do you securely rotate OIDC thumbprints?
How do IAM IdPs integrate with AWS Organizations SCPs?

🙏 Wrapping Up

IAM Identity Providers act as the bridge between external authentication systems and AWS IAM. They remove the need for long-lived IAM credentials and enable federated, secure, and scalable authentication.

🔑 Key takeaways:

Use trust + permission policies correctly
Enforce short-lived sessions & MFA
Monitor & audit federation events

✅ Thanks for reading! If this helped:

Leave a ❤️ reaction and follow for more AWS/DevOps deep dives
Drop your federation experiences/questions in the comments 💬
Share with your team to promote SSO best practices

🚀 Stay tuned for the next deep dive in this IAM series!

IAM POLICIES

Ntseze-Nelvis — Wed, 01 Oct 2025 11:29:37 +0000

AWS IAM Groups Deep Dive

iamgroups #iamusers #iamroles #iampolicies

📌 This article is part of the AWS IAM Deep Dive series.

PART 4: IAM POLICIES

aws #iam #devops #cloud

AWS IAM Policies Complete Guide

1. What is an IAM Policy?

An IAM Policy is a JSON document that defines permissions in AWS. Policies specify:

Who can access (via users, groups, or roles)
What actions can be performed
On which resources (ARNs)
Under what conditions (e.g., IP, MFA, tags)

They are the building blocks of access control in AWS, attached to identities (IAM users, groups, roles) or directly to resources (S3 buckets, KMS keys, etc.).

2. Core Characteristics of IAM Policies

Policy Types

Managed Policies: AWS-managed or customer-managed, reusable across identities
Inline Policies: Embedded directly into a user/group/role (one-to-one relationship)

Policy Document Structure

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow" | "Deny",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": ["arn:aws:s3:::my-bucket/*"],
      "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
    }
  ]
}

Effect: Allow or Deny (explicit deny always wins)
Action: API operations (e.g., ec2:StartInstances)
Resource: Specific resources by ARN
Condition: Contextual restrictions

Policy Evaluation Logic
Start with default deny

Apply explicit denies

Apply explicit allows

Common Problems With IAM Policies

🔴 Overly broad policies: Using Action:"" and Resource:""

🔴 Inline policies sprawl: Hard to manage since they are tied to a single identity

🔴 Policy size/limits: Limited to 6,144 characters; too many statements cause scaling issues

🔴 Lack of conditions: Granting access without MFA/IP conditions increases attack surface

🔴 Dependency confusion: Mixing AWS-managed and customer-managed policies without documentation

Solutions and Best Practices Policy Management Use customer-managed policies instead of inline for reusability

Follow least privilege principle → grant only required actions on specific resources

Use IAM Access Analyzer to validate and detect broad access

Security Hardening
Add MFA requirements in conditions

Use tags & conditions for environment-based restrictions (e.g., Environment=Prod)

Avoid attaching AdministratorAccess except for break-glass scenarios

Lifecycle Management
Version and track policies with IaC (Terraform/CloudFormation)

Regularly run IAM Access Advisor to remove unused permissions

Review SCPs in AWS Organizations for org-wide boundaries

Industry Examples Startup: Developers share a S3ReadWritePolicy (customer-managed) attached to a group; inline avoided

Enterprise: Hundreds of microservices → policies modularized per service; SCPs block public S3 buckets

Finance: MFA required for sensitive actions (ec2:TerminateInstances); quarterly compliance reviews

DevOps: Policies stored in Git, deployed via Terraform; CI/CD pipeline lints policies to prevent : mistakes

Interview Questions on IAM Policies Basic Level What is an IAM Policy?

Difference between AWS-managed and customer-managed policies?

Inline policy vs. managed policy?

Intermediate Level
How does IAM policy evaluation logic work?

How would you enforce least privilege?

Why is Deny more powerful than Allow?

Advanced Level
How do you design scalable IAM policies across multiple AWS accounts?

How do SCPs and IAM policies interact?

How do you restrict actions to specific environments (dev vs. prod)?

Hands-On Guide Pre-checks You must have IAM rights: iam:CreatePolicy, iam:AttachUserPolicy, etc.

Decide: inline or managed? AWS-managed or customer-managed?

Define scope: Actions, Resources, Conditions

Console Steps
Open IAM Console → Policies → Create policy

Choose Visual editor or JSON

Define actions (e.g., s3:GetObject)

Select resources (specific bucket ARN)

Add optional conditions (MFA, IP, tags)

Review and create

CLI Examples

# Create a customer-managed policy
aws iam create-policy \
  --policy-name S3ReadOnlyPolicy \
  --policy-document file://s3readonly.json

# Attach policy to a user
aws iam attach-user-policy \
  --user-name dev-alice \
  --policy-arn arn:aws:iam::123456789012:policy/S3ReadOnlyPolicy

# List policies attached to a group
aws iam list-attached-group-policies --group-name Developers

# Detach policy
aws iam detach-role-policy \
  --role-name EC2AppRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess

# Delete policy (cleanup)
aws iam delete-policy \
  --policy-arn arn:aws:iam::123456789012:policy/S3ReadOnlyPolicy
Automation & Reporting

# Validate policy with Access Analyzer
aws accessanalyzer validate-policy \
  --policy-document file://s3readonly.json \
  --policy-type IDENTITY_POLICY

# List unused policies
aws iam list-policies --scope Local --only-attached=false

🙏 Wrapping Up
IAM Policies are the foundation of AWS security.
By writing clear, reusable, and least-privileged policies, you can build strong guardrails for your environment.

🔑 Remember:

Prefer managed over inline

Always validate with Access Analyzer

Automate with IaC for versioning and consistency

✅ Thanks for reading! If this helped, don’t forget to:

Leave a reaction and follow for more AWS/DevOps guides

Drop your questions or examples of policy misconfigurations

Share this with your team so everyone follows least privilege best practices

🚀 Stay tuned for the next deep dive in this series!

AWS IAM POLICIES Deep Dive

Ntseze-Nelvis — Tue, 30 Sep 2025 12:53:42 +0000

AWS IAM POLICIES Deep Dive

iamgroups #iamusers #iamroles #iampolicies

📌 This article is part of the AWS IAM Deep Dive series.

PART 4: IAM POLICIES

aws #iam #devops #cloud

AWS IAM Policies Complete Guide

1. What is an IAM Policy?

An IAM Policy is a JSON document that defines permissions in AWS. Policies specify:

Who can access (via users, groups, or roles)
What actions can be performed
On which resources (ARNs)
Under what conditions (e.g., IP, MFA, tags)

They are the building blocks of access control in AWS, attached to identities (IAM users, groups, roles) or directly to resources (S3 buckets, KMS keys, etc.).

2. Core Characteristics of IAM Policies

Policy Types

Managed Policies: AWS-managed or customer-managed, reusable across identities
Inline Policies: Embedded directly into a user/group/role (one-to-one relationship)

Policy Document Structure

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow" | "Deny",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": ["arn:aws:s3:::my-bucket/*"],
      "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
    }
  ]
}

Effect: Allow or Deny (explicit deny always wins)
Action: API operations (e.g., ec2:StartInstances)
Resource: Specific resources by ARN
Condition: Contextual restrictions

Policy Evaluation Logic
Start with default deny

Apply explicit denies

Apply explicit allows

Common Problems With IAM Policies

🔴 Overly broad policies: Using Action:"" and Resource:""

🔴 Inline policies sprawl: Hard to manage since they are tied to a single identity

🔴 Policy size/limits: Limited to 6,144 characters; too many statements cause scaling issues

🔴 Lack of conditions: Granting access without MFA/IP conditions increases attack surface

🔴 Dependency confusion: Mixing AWS-managed and customer-managed policies without documentation

Solutions and Best Practices Policy Management Use customer-managed policies instead of inline for reusability

Follow least privilege principle → grant only required actions on specific resources

Use IAM Access Analyzer to validate and detect broad access

Security Hardening
Add MFA requirements in conditions

Use tags & conditions for environment-based restrictions (e.g., Environment=Prod)

Avoid attaching AdministratorAccess except for break-glass scenarios

Lifecycle Management
Version and track policies with IaC (Terraform/CloudFormation)

Regularly run IAM Access Advisor to remove unused permissions

Review SCPs in AWS Organizations for org-wide boundaries

Industry Examples Startup: Developers share a S3ReadWritePolicy (customer-managed) attached to a group; inline avoided

Enterprise: Hundreds of microservices → policies modularized per service; SCPs block public S3 buckets

Finance: MFA required for sensitive actions (ec2:TerminateInstances); quarterly compliance reviews

DevOps: Policies stored in Git, deployed via Terraform; CI/CD pipeline lints policies to prevent : mistakes

Interview Questions on IAM Policies Basic Level What is an IAM Policy?

Difference between AWS-managed and customer-managed policies?

Inline policy vs. managed policy?

Intermediate Level
How does IAM policy evaluation logic work?

How would you enforce least privilege?

Why is Deny more powerful than Allow?

Advanced Level
How do you design scalable IAM policies across multiple AWS accounts?

How do SCPs and IAM policies interact?

How do you restrict actions to specific environments (dev vs. prod)?

Hands-On Guide Pre-checks You must have IAM rights: iam:CreatePolicy, iam:AttachUserPolicy, etc.

Decide: inline or managed? AWS-managed or customer-managed?

Define scope: Actions, Resources, Conditions

Console Steps
Open IAM Console → Policies → Create policy

Choose Visual editor or JSON

Define actions (e.g., s3:GetObject)
Select resources (specific bucket ARN)
Add optional conditions (MFA, IP, tags)

Review and create

CLI Examples

# Create a customer-managed policy
aws iam create-policy \
  --policy-name S3ReadOnlyPolicy \
  --policy-document file://s3readonly.json

# Attach policy to a user
aws iam attach-user-policy \
  --user-name dev-alice \
  --policy-arn arn:aws:iam::123456789012:policy/S3ReadOnlyPolicy

# List policies attached to a group
aws iam list-attached-group-policies --group-name Developers

# Detach policy
aws iam detach-role-policy \
  --role-name EC2AppRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess

# Delete policy (cleanup)
aws iam delete-policy \
  --policy-arn arn:aws:iam::123456789012:policy/S3ReadOnlyPolicy
Automation & Reporting

# Validate policy with Access Analyzer
aws accessanalyzer validate-policy \
  --policy-document file://s3readonly.json \
  --policy-type IDENTITY_POLICY

# List unused policies
aws iam list-policies --scope Local --only-attached=false

🙏 Wrapping Up
IAM Policies are the foundation of AWS security.
By writing clear, reusable, and least-privileged policies, you can build strong guardrails for your environment.

🔑 Remember:

Prefer managed over inline

Always validate with Access Analyzer

Automate with IaC for versioning and consistency

✅ Thanks for reading! If this helped, don’t forget to:

Leave a reaction and follow for more AWS/DevOps guides

Drop your questions or examples of policy misconfigurations

Share this with your team so everyone follows least privilege best practices

🚀 Stay tuned for the next deep dive in this series!

DEV Community: Ntseze-Nelvis

Production-Grade 3-Tier Image Processing Platform

HSBC-gamma:Production-Grade 3-Tier Image Processing Platform

📋 Overview

Key Features

📂 Project Structure

Module Resource Count

Architecture Diagram

Quick Start

Prerequisites

Deploy Infrastructure

Expected Outputs

Test Your Application

Open your browser and navigate to:

Verify Processing

Monitoring & Observability

View CloudWatch Logs

Check Auto Scaling Status

Monitor ALB Health

Verify Public Access Block

Verify Security Groups

Sample Calculation (2 instances each tier)

Troubleshooting

Issue 1: Can't Access Web UI

Issue 2: Image Upload Fails

Symptoms: Upload returns server error, image not processed

Diagnostic Commands:

Clean UpClean Up

Resources & Documentation

Terraform Operations

AWS CLI Commands

Monitoring & Debugging

License

Author

Role Responsibilities

Designing a Production-Grade Multi-AZ Web Architecture on AWS Using ALB, EC2, and Auto Scaling

Executive Summary

Project Objective (Interview-Ready Framing)

Prerequisites

Networking

Compute & Access

Section 1 — Security Groups (Foundation of Security)

1.1 EC2 Security Group — sg_web-servers

Inbound Rules

Intentional design: Public HTTP is allowed initially for validation, then hardened later — a classic interview scenario.

1.2 Load Balancer Security Group — sg_alb

Sections 2 & 3 — Launch EC2 Web Servers (Multi-AZ)

Launch EC2 Instance (Repeat for Second AZ)

Launch a New EC2 Instance

Configure Instance Basics

Network Configuration (Critical)

Configure Storage

Advanced Settings — User Data

Instance B — hsbc-server2 (AZ-B)

Section 4 — Backend Validation (Before ALB)

Why this matters

Steps

Section 5 — Target Group (ALB → EC2 / ASG)

Target Group Configuration

Register targets

Section 6 — Application Load Balancer

ALB Configuration

Section 7 — Load Balancing Test

Load Balancing Validation

Section 8 — Attach Existing Auto Scaling Group

Steps

Section 9 — Real-World Failure Scenarios (Interview Ready)

Test 1 — Instance Failure

Test 2 — Load Spike

Test 3 — Application Failure

Section 10 — Security Hardening (Production Must)

Before (Insecure)

After (Correct)

Section 11 — Cleanup (Cost Control)

Certification & Interview Mapping

AWS Exam Topics Covered

Why This Architecture Matters (Interview Gold)

Common Production Problems

Solution Implemented

Final Architecture Overview

1.1 EC2 Security Group — `sg_web-servers`

1.2 Load Balancer Security Group — `sg_alb`

Instance B — `hsbc-server2` (AZ-B)

2. Select `cloudreality-KP` (or any you used for this app) → Delete key pair.