DEV Community: Ikoh Sylva

Building ChatOps with SNS and AWS Chatbot

Ikoh Sylva — Sat, 08 Aug 2026 13:02:32 +0000

How to wire CloudWatch alarms through SNS and AWS Chatbot so your entire team gets real-time infrastructure alerts directly in Slack or Microsoft Teams with interactive response capabilities built in.

There's a version of cloud operations that many teams are still living in an alarm fires at 2am, the on-call engineer wakes up to 47 emails, opens three separate dashboards, and spends twenty minutes reconstructing what happened before even beginning to respond. The infrastructure was smart enough to detect the problem. The notification system failed everyone.

This project puts AWS alerts where your team already lives in Slack or Microsoft Teams. When a CloudWatch alarm changes state, AWS Chatbot delivers a formatted, interactive notification directly to the channel in seconds. The team sees it together, in context, and can respond without ever leaving the conversation.

This is ChatOps and AWS makes it achievable with two services and about 25 minutes of configuration.

"The fastest incident response starts with the right people seeing the right alert in the right place at the right time."

What Is ChatOps?

ChatOps is a collaboration model where infrastructure operations happen inside a team's chat platform. Instead of engineers pulling data from dashboards and sharing findings in chat, the operations themselves alerts, runbooks, acknowledgements, commands originate from within the chat. The channel becomes the control plane.

Metric	Value
Faster incident response	40–60% improvement with chat-based alerting
Cost of AWS Chatbot	$0 — you only pay for underlying SNS and CloudWatch
Estimated setup time	~25 minutes
Scale	Thousands of notifications per second

Architecture From Alarm to Slack in Four Hops

🔔 CloudWatch Alarm (metric threshold breached) → 📣  SNS Topic (publishes encrypted event) → 🤖  AWS Chatbot (formats message into rich card) → 💬  Slack / Microsoft Teams (team notified instantly)

CloudWatch monitors your infrastructure and detects threshold breaches. When an alarm changes state, it publishes a notification to an SNS topic. AWS Chatbot, subscribed to that topic, picks up the message, formats it into a rich card, and delivers it to your configured Slack channel within seconds.

What Makes AWS Chatbot More Than Just a Relay

Before diving into setup, it's worth understanding why AWS Chatbot exists as a dedicated service rather than using a plain SNS HTTP subscription pointing at a Slack webhook. The capabilities it adds are significant:

Run AWS CLI commands from Slack — type @aws describe-instances directly in a channel and get the response without leaving the conversation
Custom interactive actions — buttons that trigger Lambda functions, acknowledge alerts, or launch CloudFormation stacks from a notification card
Granular IAM guardrails — define exactly which AWS operations team members can invoke from chat
Rich message formatting — alarm notifications rendered as structured cards, not raw JSON dumps
Supports both Slack and Microsoft Teams — one AWS service, two enterprise chat platforms

💡 From notifications to ChatOps: A basic SNS-to-Slack webhook tells you something happened. AWS Chatbot lets you respond to it without context-switching to another tool. That's the difference between being notified and being operational.

Step 1 — Set Up Your Environment

# Set environment variables
export AWS_REGION=$(aws configure get region)
export AWS_ACCOUNT_ID=$(aws sts get-caller-identity \
    --query Account --output text)

# Generate unique resource names
RANDOM_SUFFIX=$(aws secretsmanager get-random-password \
    --exclude-punctuation --exclude-uppercase \
    --password-length 6 --require-each-included-type \
    --output text --query RandomPassword)

export SNS_TOPIC_NAME="team-notifications-${RANDOM_SUFFIX}"
export ALARM_NAME="demo-cpu-alarm-${RANDOM_SUFFIX}"

echo "✅ Environment ready for region: ${AWS_REGION}"

Step 2 — Create the SNS Topic With Encryption

This SNS topic is the central hub CloudWatch publishes to it, and AWS Chatbot subscribes to it. Create it with KMS encryption enabled from the start:

# Create SNS topic with server-side encryption
aws sns create-topic \
    --name ${SNS_TOPIC_NAME} \
    --attributes '{
        "KmsMasterKeyId": "alias/aws/sns",
        "DisplayName": "Team Notifications Topic"
    }'

# Store the Topic ARN
export SNS_TOPIC_ARN=$(aws sns get-topic-attributes \
    --topic-arn arn:aws:sns:${AWS_REGION}:${AWS_ACCOUNT_ID}:${SNS_TOPIC_NAME} \
    --query 'Attributes.TopicArn' --output text)

echo "✅ SNS topic created: ${SNS_TOPIC_ARN}"

🔍 Why encrypt an SNS topic? SNS messages for CloudWatch alarms can contain sensitive operational details instance IDs, IP addresses, metric values, and account identifiers. The key alias/aws/sns uses the AWS-managed key for SNS, which incurs no extra cost beyond standard KMS API calls.

Step 3 — Connect Slack to AWS Chatbot

AWS Chatbot's initial workspace authorisation must happen through the AWS Console there is no CLI path for this OAuth step. Navigate to AWS Chatbot → Configure a chat client → Slack.

Click Configure client and you'll be redirected to Slack
Select your Slack workspace from the dropdown
Review the permissions AWS Chatbot requests and click Allow
You'll be redirected back to the AWS console with the workspace connected

⚠️ This step requires Slack workspace admin permissions. If you're not the Slack workspace admin, you'll need to request that an admin authorise the AWS Chatbot app, or ask them to create the connection. AWS Chatbot will appear as a new app in your Slack workspace's App directory after authorisation.

For Microsoft Teams

Navigate to AWS Chatbot → Configure a chat client → Microsoft Teams and follow the OAuth flow. Teams requires a Global Admin or Teams Administrator role to complete authorisation.

Step 4 — Create the Slack Channel Configuration

With your workspace connected, configure which specific Slack channel receives AWS notifications. In the AWS Chatbot console, click Configure new channel.

Configuration name: team-alerts-{your-suffix}
Slack channel: select your target alert channel (e.g. #aws-alerts or #ops-critical)
IAM role: create a new role (AWS Chatbot will generate one with appropriate permissions)
Channel guardrail policies: add ReadOnlyAccess
SNS topics: add your topic ARN from Step 2

🔍 What guardrail policies actually do: Guardrail policies define the maximum permissions available to anyone running AWS commands from that Slack channel. If you add ReadOnlyAccess, no one can accidentally delete a resource from a Slack command regardless of their personal IAM permissions. Think of it as the outer fence IAM roles define what Chatbot can do in principle; guardrails define what's reachable from chat.

Step 5 — Create a CloudWatch Alarm

For testing, we'll set a very low CPU threshold that's easy to trigger intentionally:

# Create alarm that fires when CPU drops below 1%
aws cloudwatch put-metric-alarm \
    --alarm-name ${ALARM_NAME} \
    --alarm-description "Demo CPU alarm for testing notifications" \
    --metric-name CPUUtilization \
    --namespace AWS/EC2 \
    --statistic Average \
    --period 300 \
    --threshold 1.0 \
    --comparison-operator LessThanThreshold \
    --alarm-actions ${SNS_TOPIC_ARN} \
    --evaluation-periods 1

echo "✅ Alarm created: ${ALARM_NAME}"
echo "🔔 Will trigger when CPU < 1% (for testing)"

💡 Why CPU < 1% as the test threshold? This creates an alarm that transitions to ALARM state almost immediately (no EC2 instances running = CPU averages zero), giving you a real state-change event to flow through SNS and Chatbot without needing actual compute resources. In production, set meaningful thresholds like GreaterThanThreshold at 80% for real CPU alerts.

Step 6 — Test the Full Notification Pipeline

Don't wait for an alarm publish a test message directly to the SNS topic to validate end-to-end delivery:

# Send a test notification
aws sns publish \
    --topic-arn ${SNS_TOPIC_ARN} \
    --subject "Test Alert: Infrastructure Notification" \
    --message '{
        "AlarmName": "Manual Test Alert",
        "AlarmDescription": "Testing chat notification system",
        "NewStateValue": "ALARM",
        "NewStateReason": "Testing notification delivery to Slack",
        "StateChangeTime": "'$(date -u +"%Y-%m-%dT%H:%M:%S.%3NZ")'"
    }'

echo "✅ Test sent — check your Slack channel"

Validate with CLI checks

# 1. Confirm SNS topic exists and is encrypted
aws sns get-topic-attributes \
    --topic-arn ${SNS_TOPIC_ARN} \
    --query 'Attributes.{Name:DisplayName,Key:KmsMasterKeyId}'

# 2. Confirm alarm is pointing to SNS
aws cloudwatch describe-alarms \
    --alarm-names ${ALARM_NAME} \
    --query 'MetricAlarms[0].{Name:AlarmName,State:StateValue,Actions:AlarmActions}'

# 3. Confirm AWS Chatbot is subscribed to your topic
aws sns list-subscriptions-by-topic \
    --topic-arn ${SNS_TOPIC_ARN} \
    --query 'Subscriptions[*].{Protocol:Protocol,Endpoint:Endpoint}'

🎉 Your ChatOps pipeline is live. Every CloudWatch alarm state change will now appear as a formatted card in your Slack channel, visible to the whole team, in real time. No email chains, no dashboard context-switching, no missed alerts buried in an inbox.

What the Notification Looks Like in Slack

AWS Chatbot formats CloudWatch alarm notifications into structured cards showing the alarm name, description, state transition (OK → ALARM), the reason for the state change, timestamp, and a direct link to the alarm in the AWS console. Teams get information, not data.

What makes it even more powerful: team members can run AWS CLI commands directly from the channel. For example:

@aws cloudwatch describe-alarm-history --alarm-name "prod-api-errors"

With the right guardrail permissions, that command runs and the response comes back all without leaving Slack.

Troubleshooting Common Issues

Test message sent but nothing appeared in Slack

AWS Chatbot subscription may not be confirmed. Go to SNS → Subscriptions and look for a subscription with protocol AWSChatbot. If the status is PendingConfirmation, the channel configuration may have failed revisit the channel configuration in the AWS Chatbot console.

AWS Chatbot authorisation failed / workspace not connecting

Almost always a permissions issue at the Slack level. Ensure you're authorising with a Slack workspace admin account, not a regular member.

Alarm is in ALARM state but Slack received nothing

Confirm the alarm's AlarmActions includes the correct SNS topic ARN. Run aws cloudwatch describe-alarms --alarm-names ${ALARM_NAME} and check the AlarmActions field.

Getting "Access Denied" when running AWS commands from Slack

The guardrail policy on the channel configuration is restricting the command. Either the command requires permissions beyond ReadOnlyAccess, or the IAM role attached to the configuration doesn't have the specific permission needed.

The ChatOps Roadmap

The reference architecture outlines five natural extensions:

Multi-environment routing — separate SNS topics for dev, staging, and production, each routing to dedicated Slack channels. A prod alert in #ops-critical is different from a dev alert in #dev-alerts.
Custom alert enrichment via Lambda — subscribe a Lambda function to your SNS topic to transform raw alarm messages before delivery, adding runbook links, affected service names, and on-call rotation info
Escalation workflows with Step Functions — time-based escalation: if an alert in Slack goes unacknowledged for 10 minutes, Step Functions escalates from Slack to email, then SMS, then PagerDuty
Interactive acknowledgement buttons — AWS Chatbot custom actions let engineers acknowledge alerts, trigger automated Lambda remediation, or mute an alarm from a button inside the Slack notification
Cross-account centralisation — aggregate alarms from multiple AWS accounts into a single SNS topic using cross-account role assumptions

Cleanup

# Remove the test CloudWatch alarm
aws cloudwatch delete-alarms \
    --alarm-names ${ALARM_NAME}

# Delete the SNS topic
aws sns delete-topic \
    --topic-arn ${SNS_TOPIC_ARN}

# Manual: delete channel config in AWS Chatbot console
echo "🔧 https://console.aws.amazon.com/chatbot/"

# Clear environment variables
unset SNS_TOPIC_NAME SNS_TOPIC_ARN ALARM_NAME RANDOM_SUFFIX

What I Learned From This Project

SNS topics, CloudWatch alarms, and IAM policies were familiar territory. What was new was understanding how they compose into something with genuine operational impact.

The insight that stuck most was about where information lives. In a traditional ops setup, infrastructure information lives in dashboards and humans have to go get it. In a ChatOps setup, that information comes to where the humans already are. That's not just a convenience; it changes who sees the alert (the whole team, not just whoever happens to be checking email), how fast they see it (immediately, not after polling), and what they can do with it (respond directly, in context, together).

A few technical things that clicked:

AWS Chatbot is an SNS subscriber with superpowers — conceptually, it's just another SNS endpoint. The magic is in what it does with the message before delivery: formatting, rich cards, IAM-backed interactivity
Guardrail policies are not IAM roles — they're a separate layer that caps what's possible from chat, independent of user IAM permissions. A developer with broad permissions can't accidentally use those permissions from Slack if the guardrail prevents it
KMS encryption on SNS is a one-liner — adding "KmsMasterKeyId": "alias/aws/sns" to the topic attributes takes ten seconds and means you're not sending operational data in cleartext. No excuse not to do this in production
Test with direct SNS publish before debugging Chatbot — publishing directly to the SNS topic lets you isolate whether the problem is in the alarm → SNS path or the SNS → Chatbot path

Quick Reference: The Full Setup

# Services and their roles

CloudWatch alarm    → monitors infrastructure metrics; changes state on breach
SNS topic           → receives alarm state-change events; fans out to subscribers
AWS Chatbot         → SNS subscriber; formats + delivers to Slack/Teams channels
IAM role            → grants Chatbot permission to post and run commands
Guardrail policy    → caps what AWS operations are accessible from chat
KMS encryption      → protects message content at rest within SNS

# The alert chain
CPU > 80%
  → CloudWatch alarm transitions to ALARM state
      → Publishes to SNS topic (encrypted)
          → AWS Chatbot receives, formats message
              → Delivers rich card to #aws-alerts in Slack
               → Team sees it, responds, acknowledges — all in one channel

I’m also excited to share that I’ve been able to secure a special discount, in partnership with Sanjeev Kumar’s team, for the DevOps & Cloud Job Placement / Mentorship Program.

For those who may not be familiar, Sanjeev Kumar brings over 20 years of hands-on experience across multiple domains and every phase of product delivery. He is known for his strong architectural mindset, with a deep focus on Automation, DevOps, Cloud, and Security.

Sanjeev has extensive expertise in technology assessment, working closely with senior leadership, architects, and diverse software delivery teams to build scalable and secure systems. Beyond industry practice, he is also an active educator, running a YouTube channel dedicated to helping professionals successfully transition into DevOps and Cloud careers.

This is a great opportunity for anyone looking to level up their DevOps/Cloud skills with real-world mentorship and career guidance.

Do refer below for the link with a dedicated discount automatically applied at checkout;

DevOps & Cloud Job Placement / Mentorship Program.

If you also found this interesting and would love to take the next steps in the application process with AltSchool Africa do use my referral link below;

Apply here or use this Code: W2jBG8 during the registration process and by so doing, you will be supporting me and also getting a discount!

Special Offer: By signing up through the link and using the code shared, you’ll receive a 10% discount!

Don’t miss out on this opportunity to transform your future and also save while doing it! Let’s grow together in the tech space. Also feel free to reach out if you need assistance or clarity regarding the program.

I’m Ikoh Sylva, a passionate cloud computing enthusiast with hands-on experience in AWS. I’m documenting my cloud journey here from a beginner’s perspective, aiming to inspire others along the way.

If you find my contents helpful, please like and follow my posts, and consider sharing this article with anyone starting their own cloud journey.

Let’s connect on social media. I’d love to engage and exchange ideas with you!

LinkedIn Facebook X

Building Real-Time File Upload Notifications with S3 and SNS

Ikoh Sylva — Sat, 25 Jul 2026 08:58:54 +0000

How to wire Amazon S3 to Amazon SNS so that every file backed up to the cloud sends an instant email notification serverless, scalable, and set up in under 20 minutes.

This project building a simple file backup system with S3 event notifications publishing directly to an SNS topic is one of the most practical patterns in AWS. You'll find it in compliance systems, data ingestion pipelines, media processing platforms, and anywhere that teams need instant visibility into what's landing in their cloud storage.

"The best backup system is the one you trust. And trust starts with knowing your backup actually ran."

SNS vs Lambda (Choosing the Right Tool)

Both SNS and Lambda can receive S3 events. Here's how to think about which one belongs in your architecture:

	SNS Direct	Lambda Function
Code required	None	Yes
Fan-out to multiple recipients	Built-in	Manual (SES per recipient)
Best when	The notification is the action	The event triggers business logic
Subscribers	Email, SMS, HTTP, SQS, Lambda	One function (can fan out internally)
Setup time	~15 minutes	~30–60 minutes

For a backup notification system, SNS direct is the clear winner. We don't need to process the event we need everyone who cares to know it happened. That's pub-sub, and SNS is AWS's native pub-sub service.

The Architecture (Four Services, One Flow)

📤 Client (uploads file) → 🪣  S3 Bucket (detects s3:ObjectCreated event) → 📣  SNS Topic (publishes message to all subscribers) → 📬  Subscribers (email / SMS / SQS / HTTP simultaneously)

S3 fires an event the moment an object is created. That event is published to an SNS topic, which then fans out the notification to every subscriber simultaneously. One upload, one SNS message but potentially dozens of recipients each getting it in parallel.

SNS subscriber types you can attach:

Email — team inboxes, ops alerts
SMS — on-call phone alerts
HTTP/S — webhooks, Slack, Microsoft Teams
SQS Queue — async downstream processing
Lambda — custom logic as a downstream step

Step 1 — Create the S3 Bucket

This bucket will act as your backup destination. Navigate to S3 → Create bucket.

Name it something descriptive: yourname-file-backups
Choose a region — record it, all resources must be in the same region
Under Bucket versioning, enable it — this protects against accidental overwrites
Leave Block all public access enabled — backup buckets should never be public

✅ Enable versioning on backup buckets. Versioning means that if a file is overwritten or deleted, the previous version is preserved. For backup use cases, this is critical without it, a bad upload can silently destroy the data you were trying to protect.

Lifecycle rules for cost management (Optional)

While not required for the notification system, lifecycle rules are worth setting up alongside it. Navigate to Management → Lifecycle rules → Create lifecycle rule.

Transition objects to S3 Standard-IA after 30 days (40% cheaper for infrequently accessed data)
Transition to S3 Glacier Flexible Retrieval after 90 days (up to 85% cheaper for archival)
Set expiration on non-current versions after 90 days to avoid paying for old backup versions indefinitely

💡 The backup cost equation: S3 Standard costs $0.023/GB/month. S3 Glacier costs $0.004/GB/month. For long-lived backups, automated lifecycle transitions can reduce storage costs by 80–95% with zero manual intervention and your notification system still fires on every upload.

Step 2 — Create the SNS Topic

Navigate to SNS → Topics → Create topic.

Type: Standard (not FIFO, S3 event notifications do not support FIFO SNS topics)
Name: s3-backup-notifications
Leave all other settings as default
Click Create topic

Copy the Topic ARN from the topic details page: it looks like arn:aws:sns:us-east-1:123456789012:s3-backup-notifications. You'll need it in the next two steps.

⚠️ Standard topic only (FIFO is not supported). S3 event notifications cannot deliver to Amazon SNS FIFO topics. If you accidentally create a FIFO topic (name ending in .fifo), S3 will fail to save the notification configuration. Always use Standard topics for S3-triggered notifications.

Step 3 — Configure the SNS Access Policy

This is the step most tutorials gloss over and where most people hit their first error. S3 cannot publish to your SNS topic until you explicitly grant it permission via a resource-based policy on the topic.

In your SNS topic, go to Edit → Access policy. Replace the default policy with this:

{
  "Version": "2012-10-17",
  "Id": "s3-backup-sns-policy",
  "Statement": [
    {
      "Sid": "AllowS3ToPublish",
      "Effect": "Allow",
      "Principal": {
        "Service": "s3.amazonaws.com"
      },
      "Action": "sns:Publish",
      "Resource": "arn:aws:sns:REGION:ACCOUNT_ID:s3-backup-notifications",
      "Condition": {
        "ArnLike": {
          "aws:SourceArn": "arn:aws:s3:::yourname-file-backups"
        },
        "StringEquals": {
          "aws:SourceAccount": "YOUR_AWS_ACCOUNT_ID"
        }
      }
    }
  ]
}

🔍 Anatomy of this policy: The ArnLike condition restricts publishing to only your specific S3 bucket preventing any other bucket (even in your own account) from sending messages to this topic. The StringEquals on aws:SourceAccount is a defence-in-depth measure against confused deputy attacks (a scenario where a bucket in another account tricks your topic into accepting their events.) Together: "Only my bucket, in my account, can publish here."

Step 4 — Subscribe to the SNS Topic

In your SNS topic, click Create subscription.

Protocol: Email
Endpoint: your email address
Click Create subscription

SNS immediately sends a confirmation email. You must click the confirmation link before the subscription becomes active. Until confirmed, the subscription shows as PendingConfirmation and will not receive any notifications.

✅ Add multiple subscribers for team visibility. You can add as many email subscribers as you need your entire ops team, a shared inbox, a monitoring alias. Each subscriber is independent: adding or removing one doesn't affect the others. Each subscription requires its own confirmation click.

Step 5 — Configure S3 Event Notifications

Navigate to your S3 bucket → Properties → Event notifications → Create event notification.

Event name: BackupFileUploaded
Prefix (optional): e.g. backups/ to only trigger on files in that folder
Suffix (optional): e.g. .zip to only trigger on compressed archives
Event types: check All object create events (covers Put, Post, Copy, CompleteMultipartUpload)
Destination: SNS topic
SNS topic: select or paste the ARN of your topic
Click Save changes

⚠️ If you see "Unable to validate the destination" error: S3 tried to send a test message to your SNS topic and was rejected. Almost always this is the access policy from Step 3 either the bucket ARN in the ArnLike condition doesn't match the actual bucket name, or the account ID is wrong.

💡 Use prefix and suffix filters strategically. If your bucket stores multiple types of content, filters save you from notification noise. A database dump (.sql.gz) warrants a notification. A temporary log file being written mid-process probably doesn't.

Step 6 — Test the Full Pipeline

Upload any file to your bucket via the console, CLI, or any tool that writes to S3:

# Upload a test backup file via CLI
aws s3 cp ./my-database-backup.sql.gz \
    s3://yourname-file-backups/backups/

# Verify it's there
aws s3 ls s3://yourname-file-backups/backups/

Within seconds, your subscribed email should receive a notification. The raw JSON payload S3 sends through SNS looks like this:

{
  "Records": [{
    "eventVersion": "2.1",
    "eventSource": "aws:s3",
    "eventName": "ObjectCreated:Put",
    "eventTime": "2025-01-15T09:23:41.000Z",
    "s3": {
      "bucket": { "name": "yourname-file-backups" },
      "object": {
        "key": "backups/my-database-backup.sql.gz",
        "size": 4096000,
        "eTag": "d41d8cd98f00b204e9800998ecf8427e"
      }
    }
  }]
}

🎉 Your backup notification system is live. Every file that lands in your S3 bucket now triggers an instant notification. No Lambda to maintain, no polling to configure, no server to manage. The system scales to millions of uploads without any changes on your end.

Troubleshooting Common Issues

S3 can't save the event notification "Unable to validate destination"

The SNS topic policy isn't granting S3 permission to publish. Check that the bucket ARN in the ArnLike condition exactly matches your bucket name. Note: S3 ARNs don't include a region or account ID it's just arn:aws:s3:::bucket-name.

Confirmation email never arrived

Check spam. SNS confirmation emails frequently land in junk folders. If it's not there after a few minutes, go to SNS → Subscriptions, find yours in PendingConfirmation state, and click Request confirmation to resend it.

Upload happens but no email received

Confirm the subscription status in SNS → Subscriptions. If it still shows PendingConfirmation, the confirmation link was never clicked. If Confirmed, verify the S3 event notification was saved correctly under S3 → Properties → Event notifications.

Receiving too many notifications / notification noise

Add prefix or suffix filters to your S3 event notification to scope it down. Alternatively, route notifications to an SQS queue first and batch or filter there before forwarding to email.

Real-World Extensions of This Pattern

This S3 → SNS pipeline is a foundation, not a ceiling. Once the plumbing is in place, here's how production teams extend it:

Multi-destination fan-out — Add an SQS queue as a second subscriber: email goes to the ops team, the queue feeds an automated validation workflow checking file integrity
Slack / Teams integration — Subscribe an HTTP/S endpoint to the SNS topic, pointing at a Slack incoming webhook, for real-time channel alerts without email
Cross-account notifications — SNS topics can notify subscribers in other AWS accounts useful for centralising backup alerts in a dedicated monitoring account in an AWS Organisations setup
Compliance audit trails — Store the SNS event messages in an SQS queue, then archive them to S3 Glacier an immutable, timestamped record that every backup ran, when it ran, and how large it was

What I Learned From This Project

It teaches pub-sub thinking at exactly the right level of simplicity.

A few things that genuinely resonated:

SNS access policies are resource-based, not identity-based — just like S3 bucket policies, SNS topic policies are attached to the resource, not the caller. S3 presents as a service principal (s3.amazonaws.com), and the policy must explicitly grant that principal permission.
The confused deputy attack is real, not theoretical — the aws:SourceAccount condition exists because without it, any S3 bucket in the world could potentially publish to your SNS topic if they knew its ARN. Scoping by account prevents that. Scoping by bucket ARN tightens it further. Both conditions together that's defence in depth.
Fan-out changes how you think about notifications — before SNS, "notify someone" meant "send them an email." After SNS, "notify" means "publish once, let the subscribers decide what to do." One upload, many outcomes, none of them coupled to each other.
Versioning and notifications are complementary, not redundant — versioning protects the data; notifications protect the process. Together they answer two different questions: "Is the file safe?" and "Did it arrive?"

Quick Reference: Services and Their Roles

# Services in this project

S3 bucket           → backup storage; fires s3:ObjectCreated events on upload
S3 versioning       → preserves previous file versions (overwrites, deletions)
S3 lifecycle rules  → auto-transitions to cheaper storage classes over time
SNS Standard topic  → receives S3 events; fans out to all active subscribers
SNS access policy   → grants s3.amazonaws.com permission to sns:Publish
SNS subscription    → email (or SMS, SQS, HTTP) endpoint; must be confirmed

# The event chain
File uploaded to S3 → S3 publishes JSON event to SNS topic → SNS fans out to all confirmed subscribers simultaneously → Email arrives within seconds

I’m also excited to share that I’ve been able to secure a special discount, in partnership with Sanjeev Kumar’s team, for the DevOps & Cloud Job Placement / Mentorship Program.

This is a great opportunity for anyone looking to level up their DevOps/Cloud skills with real-world mentorship and career guidance.

Do refer below for the link with a dedicated discount automatically applied at checkout;

DevOps & Cloud Job Placement / Mentorship Program.

If you also found this interesting and would love to take the next steps in the application process with AltSchool Africa do use my referral link below;

Apply here or use this Code: W2jBG8 during the registration process and by so doing, you will be supporting me and also getting a discount!

Special Offer: By signing up through the link and using the code shared, you’ll receive a 10% discount!

If you find my contents helpful, please like and follow my posts, and consider sharing this article with anyone starting their own cloud journey.

Let’s connect on social media. I’d love to engage and exchange ideas with you!

LinkedIn Facebook X

Building Your First Event-Driven Pipeline with S3 and Lambda

Ikoh Sylva — Sat, 13 Jun 2026 07:16:24 +0000

How to wire an S3 bucket to a Lambda function so that every file upload automatically triggers code without polling, without servers, and without a single cron job.

Up until this point in the series, our AWS setup has been passive. S3 holds files, CloudFront delivers them, Route 53 routes traffic. Everything waits to be asked.

This project changes that. We're going to make AWS react. Drop a file in an S3 bucket, and within milliseconds, a Lambda function wakes up, reads the event, and does something useful log the filename, write to CloudWatch, or fire off an email confirmation via SES.

This is event-driven architecture in its simplest and most teachable form. And once you understand it at this scale, you'll recognise the same pattern everywhere in notification systems, data pipelines, media processing workflows, and audit trails.

"A server waits. An event-driven function listens. There's a difference and it matters at scale."

What We're Building

A file lands in S3 → S3 fires an event → Lambda receives it → Lambda acts on it.

📤 You (upload a file)
    → 🪣  S3 Bucket (fires ObjectCreated event)
        → λ  Lambda Function (wakes up, processes event)
            → 📋  CloudWatch Logs (captures output)
            → ✉️  SES (sends email notification)

We'll implement all three response options so you understand each one:

Option	What it does
Log to CloudWatch	Print the filename and event details to CloudWatch Logs
Email via SES	Send a confirmation email when a file arrives
Both	Log and notify — the real-world pattern

Prerequisites

Before starting, make sure you have:

An AWS account with access to S3, Lambda, IAM, CloudWatch, and optionally SES
Basic familiarity with the AWS console this builds directly on the S3 knowledge from our two previously posted articles and here are the links; Link1 and Link2 ICYMI.
If using the SES email option: a verified email address in SES would also be needed (covered in Step 4)

Step 1 — Create the S3 Bucket

If you already have an S3 bucket from our previous article, you can reuse it or create a fresh one for this exercise. Navigate to S3 → Create bucket.

Give it a unique name, e.g. yourname-upload-trigger-demo
Choose a region — note it down, Lambda must be in the same region
Leave all other settings as default for now

⚠️ Keep bucket and Lambda in the same region: S3 event notifications trigger Lambda functions within the same region. If they're in different regions, the trigger won't work. Pick a region at the start and stick to it throughout this project.

Step 2 — Create the Lambda Function

Navigate to Lambda → Create function.

Select Author from scratch
Function name: s3-upload-handler
Runtime: Python 3.12 (or latest available)
Architecture: x86_64
Execution role: select Create a new role with basic Lambda permissions

Click Create function. Lambda provisions your function and drops you into the inline code editor.

💡 What just happened with that IAM role? Lambda created an execution role automatically. This role grants your function permission to write logs to CloudWatch Logs. For the SES option, you'll need to extend this role manually covered in Step 4.

The event structure Lambda receives

Before writing code, it helps to understand what Lambda actually gets. When S3 fires an event, it sends a JSON payload that looks like this:

{
  "Records": [
    {
      "eventName": "ObjectCreated:Put",
      "s3": {
        "bucket": { "name": "yourname-upload-trigger-demo" },
        "object": {
          "key": "reports/q4-summary.pdf",
          "size": 204800
        }
      }
    }
  ]
}

Every upload becomes a record in this array. Your Lambda function digs into this structure to extract the bucket name, file key, and event type.

Option A — Log to CloudWatch

Paste this into the Lambda inline editor and click Deploy:

import json

def lambda_handler(event, context):
    for record in event['Records']:
        bucket = record['s3']['bucket']['name']
        key    = record['s3']['object']['key']
        size   = record['s3']['object']['size']

        print(f"✅ New upload detected")
        print(f"   Bucket : {bucket}")
        print(f"   File   : {key}")
        print(f"   Size   : {size} bytes")

    return {'statusCode': 200, 'body': 'Logged successfully'}

✅ In Lambda, every print() goes to CloudWatch. You don't need to import a logging library. Lambda automatically streams all stdout to CloudWatch Logs. Whatever you print() shows up there within seconds.

Option B — Send an email via SES

For this option, you'll need a verified sender address in SES first (covered in Step 4). Once that's done, use this function:

import json
import boto3

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

SENDER    = "you@yourdomain.com"   # must be SES-verified
RECIPIENT = "you@yourdomain.com"   # can be same address

def lambda_handler(event, context):
    for record in event['Records']:
        bucket = record['s3']['bucket']['name']
        key    = record['s3']['object']['key']
        size   = record['s3']['object']['size']

        ses.send_email(
            Source=SENDER,
            Destination={'ToAddresses': [RECIPIENT]},
            Message={
                'Subject': {'Data': f"New file uploaded to {bucket}"},
                'Body': {'Text': {'Data':
                    f"File uploaded:\n\nBucket: {bucket}\nKey: {key}\nSize: {size} bytes"
                }}
            }
        )
        print(f"Email sent for upload: {key}")

    return {'statusCode': 200, 'body': 'Email sent'}

Step 3 — Add the S3 Trigger

Now we connect S3 to Lambda. In your Lambda function, click Add trigger in the function overview diagram at the top of the page.

Trigger source: S3
Bucket: select your bucket
Event types: PUT — this fires on every new upload
Optionally add a Prefix (e.g. uploads/) or Suffix (e.g. .pdf) to filter which uploads trigger the function
Acknowledge the recursive invocation warning and click Add

⚠️ The recursive invocation warning — take it seriously. If your Lambda function writes files back to the same S3 bucket it's triggered from, you'll create an infinite loop: upload → trigger → Lambda writes file → trigger → Lambda writes file → ... Your bill will spike before you notice. Either write to a different bucket, use a prefix/suffix filter, or simply don't write back to the same bucket from this function.

🔍 What's happening under the hood: When you add the trigger in the Lambda console, AWS does two things automatically: it adds an S3 bucket notification configuration on the bucket, and it adds a resource-based policy to your Lambda function allowing S3 to invoke it. You can inspect both. The bucket notification config lives under S3 → Properties → Event notifications, and the Lambda resource policy lives under Lambda → Configuration → Permissions.

Step 4 — Grant Lambda the Right Permissions

The default Lambda execution role can write to CloudWatch Logs, which is enough for Option A. For SES email sending, you need to extend the role.

Add SES send permission to the Lambda role

Go to IAM → Roles, find the role Lambda created (it will be named something like s3-upload-handler-role-xxxxxxxx), and click Add permissions → Attach policies. Search for and attach AmazonSESFullAccess.

⚠️ AmazonSESFullAccess is broad — fine for learning, not for production. For a real system, create a custom IAM policy that grants only ses:SendEmail on the specific identities you need. The principle of least privilege applies here just as much as it did with the S3 bucket policy in our previous article.

Verify your sender address in SES

Navigate to SES → Verified identities → Create identity.

Select Email address
Enter the address you'll send from
Click Create identity
Check your inbox and click the verification link AWS sends

💡 SES sandbox mode: By default, new AWS accounts are in the SES sandbox. In sandbox mode, you can only send emails to verified addresses both the sender AND recipient must be verified. This is fine for testing. To send to anyone, you need to request production access from the SES console.

Step 5 — Test It End to End

Upload any file to your S3 bucket the console, CLI, or a drag-and-drop will all work.

# Upload via CLI
aws s3 cp ./test-document.pdf s3://yourname-upload-trigger-demo/

Check CloudWatch Logs

Navigate to CloudWatch → Log groups. Look for a log group named /aws/lambda/s3-upload-handler. Click the most recent log stream and you should see your print statements:

✅ New upload detected
   Bucket : yourname-upload-trigger-demo
   File   : test-document.pdf
   Size   : 204800 bytes

Test Lambda directly (before connecting S3)

You don't have to upload a real file to test your function. In the Lambda console, click Test and paste a sample event to simulate what S3 sends:

{
  "Records": [{
    "eventName": "ObjectCreated:Put",
    "s3": {
      "bucket": { "name": "yourname-upload-trigger-demo" },
      "object": { "key": "test-document.pdf", "size": 204800 }
    }
  }]
}

This lets you iterate on your function code quickly without uploading files every time.

Troubleshooting Common Issues

Lambda isn't firing on upload

Check the S3 bucket notification configuration under S3 → Properties → Event notifications. Confirm the event type is set to PUT (or All object create events) and the Lambda ARN is correct. Also confirm both resources are in the same region.

Lambda fires but CloudWatch shows no logs

The Lambda execution role likely doesn't have logs:CreateLogGroup, logs:CreateLogStream, and logs:PutLogEvents permissions. The default role created by Lambda should include these, but if you created a custom role, add the AWSLambdaBasicExecutionRole managed policy.

SES returns an error: Email address not verified

In sandbox mode, both the sender and recipient addresses must be verified in SES. Go to SES → Verified identities and confirm both addresses have a "Verified" status badge.

Function times out

The default Lambda timeout is 3 seconds. If you're making external calls (like SES), it can occasionally be slow. Raise the timeout to 10–15 seconds under Lambda → Configuration → General configuration.

What I Learned From This Project

Of all the projects in the Cloud Engineering Program, this was the one where cloud architecture stopped feeling abstract. Watching a file upload immediately trigger code execution with no server, no polling loop, no scheduler made the event-driven model click in a way that diagrams never had.

A few things that genuinely landed:

Event-driven is fundamentally different from request-driven — your function doesn't wait for someone to call it. The infrastructure calls it for you, the moment something happens. That changes how you design systems entirely.
IAM is everywhere, and it's intentional — Lambda needs permission to be invoked by S3. Lambda needs permission to send email via SES. Lambda needs permission to write logs. Every cross-service interaction requires an explicit grant. Once you internalise this, AWS architecture starts to feel less like bureaucracy and more like a coherent security model.
print() is enough to start — CloudWatch captures everything. You don't need a logging framework, a log server, or a third-party observability tool to get started. The primitives are already there.
The event payload is your contract — understanding the exact structure S3 sends to Lambda, and writing code that correctly parses it, is the real skill here. The rest is just AWS console navigation.

Quick Reference: The Full Setup

# Services and their roles

S3 bucket          → stores files, fires ObjectCreated events on upload
S3 event notif.    → routes PUT events to Lambda (configured on the bucket)
Lambda function    → Python handler, wakes up per event, processes Records[]
Lambda exec. role  → IAM role granting CloudWatch Logs write + SES send
CloudWatch Logs    → captures all print() output from Lambda automatically
SES                → sends transactional email (sandbox: verified addrs only)

# The trigger chain
Upload file to S3  → S3 fires event → Lambda invoked → logs + email sent

What's Next?

Now that you understand event-driven triggers, the natural next step is extending the Lambda function to do something more powerful like resizing images on upload, parsing CSV files and storing records in DynamoDB, or triggering a Step Functions workflow. The same S3 → Lambda pattern underpins all of these. Once you have the trigger working, the sky is the limit on what the function does.

I’m also excited to share that I’ve been able to secure a special discount, in partnership with Sanjeev Kumar’s team, for the DevOps & Cloud Job Placement / Mentorship Program.

This is a great opportunity for anyone looking to level up their DevOps/Cloud skills with real-world mentorship and career guidance.

Do refer below for the link with a dedicated discount automatically applied at checkout;

DevOps & Cloud Job Placement / Mentorship Program.

If you also found this interesting and would love to take the next steps in the application process with AltSchool Africa do use my referral link below;

Apply here or use this Code: W2jBG8 during the registration process and by so doing, you will be supporting me and also getting a discount!

Special Offer: By signing up through the link and using the code shared, you’ll receive a 10% discount!

If you find my contents helpful, please like and follow my posts, and consider sharing this article with anyone starting their own cloud journey.

Let’s connect on social media. I’d love to engage and exchange ideas with you!

LinkedIn Facebook X

Your Website, Your Domain, Your HTTPS — A Complete AWS Custom Domain Setup

Ikoh Sylva — Sat, 06 Jun 2026 17:58:08 +0000

How to register a domain, wire it to Route 53, secure it with a free SSL certificate from ACM, and serve it over HTTPS through CloudFront start to finish.

In our last article, we deployed a static website to S3 and served it through CloudFront. The site was live, fast, and global but it was loading on a URL that looked like d1abc2xyz.cloudfront.net. Not exactly something you'd print on a business card.

This article fixes that. We're going to take that same site and give it a proper home: a custom domain, a free SSL certificate, and a verified HTTPS padlock that browsers love and employers notice.

By the end, your portfolio will load at yourname.com over HTTPS secured, professional, and running entirely on AWS managed infrastructure.

"A CloudFront URL tells the world you know AWS. A custom HTTPS domain tells them you finished the job."

What We're Building

This setup chains five AWS services together. Here's the full picture before we touch anything:

🌍 Browser (yourname.com)
    → 🗂️  Route 53 (DNS lookup)
        → 🔒  ACM Certificate (attached to CloudFront)
            → ☁️  CloudFront (CDN + HTTPS termination)
                → 🪣  S3 (private origin)

Route 53 translates yourname.com into CloudFront's address. CloudFront terminates the HTTPS connection using an ACM certificate, then fetches content from the private S3 bucket as needed.

The four phases:

Phase	What you're doing
Phase 1	Register your domain (or bring an existing one)
Phase 2	Create a hosted zone and update nameservers
Phase 3	Request a free SSL certificate via ACM with DNS validation
Phase 4	Attach the domain and certificate to CloudFront

Phase 1 — Register Your Domain

You have two paths: register directly through Route 53, or bring a domain you already own from another registrar.

Option A: Register through Route 53

Navigate to Route 53 → Registered domains → Register domain. Search for your name, add it to cart, and complete checkout. AWS automatically creates a hosted zone and configures the nameservers Phase 2 is essentially done for you.

⚠️ Pricing heads-up: Route 53 domain registration starts at $13/year for .com and varies by TLD. Unlike S3 and CloudFront, domain registration has no free tier. Hosted zones also cost $0.50/month.

Option B: Bring a domain from another registrar

If you already own a domain from Namecheap, GoDaddy, or elsewhere great. Skip this phase and go straight to Phase 2. You'll update the nameservers at your existing registrar to point at Route 53.

Phase 2 — Connect Your Domain to Route 53

This is the step that hands DNS authority over to AWS. Once done, Route 53 controls where traffic for your domain goes.

Step 1 — Create a hosted zone

Go to Route 53 → Hosted zones → Create hosted zone.

Enter your domain name (e.g. yourname.com)
Leave type as Public hosted zone
Click Create hosted zone

AWS generates four nameserver (NS) records automatically. They look something like this:

ns-412.awsdns-51.com
ns-1624.awsdns-11.co.uk
ns-879.awsdns-45.net
ns-1383.awsdns-44.org

Copy all four. You'll paste them into your registrar in the next step.

Step 2 — Update nameservers at your registrar

Log into wherever you registered your domain and find the nameserver settings. Replace the existing nameservers with the four AWS values from your hosted zone and save.

⚠️ DNS propagation takes time: Nameserver changes can take anywhere from a few minutes to 48 hours to propagate globally. In practice most registrars update within 15–30 minutes. Check propagation status at dnschecker.org by searching your domain for NS records.

🔍 What's actually happening here: When a browser looks up your domain, it asks the internet "who's authoritative for yourname.com?" The answer comes from your registrar's registry and it points to your nameservers. By switching those nameservers to Route 53, you're telling the entire DNS system: "Ask AWS. They know where this site lives."

Phase 3 — Request a Free SSL Certificate with ACM

AWS Certificate Manager issues free, auto-renewing SSL/TLS certificates. Before you click anything, read this:

⚠️ Region matters — use us-east-1 only: CloudFront only accepts ACM certificates created in the us-east-1 (N. Virginia) region. No exceptions. Before you start, confirm the region selector in the top-right corner of the AWS console says US East (N. Virginia).

Step 1 — Request the certificate

Navigate to ACM → Request a certificate → Request a public certificate.

Under Fully qualified domain names, enter your root domain: yourname.com
Click Add another name and add the www version: www.yourname.com
Select DNS validation — faster and fully automated compared to email validation
Click Request

✅ Always cover both root and www: One certificate can cover both yourname.com and www.yourname.com. Do this it means visitors reach your site regardless of whether they type www or not.

Step 2 — Validate ownership via DNS

ACM puts the certificate in Pending validation state. It needs proof you own the domain before issuing the cert.

Open the certificate in ACM and you'll see a validation section with CNAME records that need to be added to your DNS. Since your domain is already in Route 53, AWS makes this a single click:

Click Create records in Route 53. AWS adds the CNAME records automatically. Within minutes, ACM detects them and flips the certificate status to Issued.

🔍 Why DNS validation works this way: ACM can't issue a certificate for a domain you don't control. DNS validation proves ownership by asking you to add a specific CNAME to your DNS something only the domain owner can do. The record stays in your DNS permanently, which is how ACM silently auto-renews the certificate each year without any action from you.

For reference, the CNAME ACM asks you to create looks like this:

Name:   _a79865eb4cd1a6ab990a45779b4e0b96.yourname.com
Type:   CNAME
Value:  _424c7224e9b0a0d17feb4a6acf5c0c1f.acm-validations.aws

Wait until the certificate status shows Issued before continuing. Using Route 53 for DNS, this typically takes 2–5 minutes.

Phase 4 — Attach Everything to CloudFront

A hosted zone, an issued certificate now let's wire it all together.

Step 1 — Update your CloudFront distribution

Go to CloudFront → Your distribution → Edit (General tab).

Under Alternate domain names (CNAMEs), add both:

yourname.com
www.yourname.com

Under Custom SSL certificate, select the certificate you just issued. It should appear in the dropdown automatically this is why the us-east-1 region requirement exists.

Click Save changes. CloudFront will redeploy globally give it a few minutes.

Step 2 — Create DNS records in Route 53

Final step: tell Route 53 to send traffic for your domain to CloudFront. Go to Route 53 → Hosted zones → yourname.com → Create record.

Create an A record for the root domain:

Record name: leave blank (targets root domain)
Record type: A
Alias: toggle on
Route traffic to: Alias to CloudFront distribution
Select your distribution from the dropdown

Repeat the same steps for www: create another A alias record, enter www in the record name, point it at the same CloudFront distribution.

🔍 Why alias records instead of CNAMEs? Route 53 alias records are an AWS-specific DNS extension. They work at the root domain level regular CNAMEs can't. They also update automatically when CloudFront's underlying IPs change and don't incur an extra DNS query charge.

Confirm Your Site Loads Over HTTPS

Open a browser and visit https://yourname.com. You should see:

Your website loading correctly
A padlock icon in the address bar
A valid certificate issued to your domain (click the padlock → Certificate to verify)
http://yourname.com automatically redirecting to HTTPS

🎉 You're fully live — on your own domain, over HTTPS. Your site is now globally distributed through CloudFront, secured with a certificate AWS renews automatically every year, at a URL you actually own.

Troubleshooting Common Issues

Certificate not appearing in the CloudFront dropdown

Almost always a region issue. The certificate was created outside of us-east-1. Re-request it in the correct region it only takes a few minutes.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH or certificate warning

The alternate domain name entered in CloudFront doesn't exactly match what's on the ACM certificate. Double-check for typos they must be identical.

Site loads on the CloudFront URL but not the custom domain

DNS hasn't propagated yet, or the Route 53 alias records are missing or misconfigured. Run nslookup yourname.com in your terminal if it doesn't return a CloudFront address, the A records need attention.

www loads but the root domain doesn't (or vice versa)

One of the two A alias records is missing. Return to Route 53 and confirm you have alias records for both the root and the www subdomain, both pointing at the same CloudFront distribution.

What I Learned From This Project

Before doing this as part of the Cloud Engineering Program, DNS was a black box. You typed a domain, a page appeared, and everything in between was a mystery. Wiring up Route 53, ACM, and CloudFront by hand made it concrete and a few things genuinely clicked:

Nameservers are delegation, not redirection — you're not moving your domain, you're transferring authority over it. The internet now asks AWS, not your registrar, for answers about your domain.
DNS validation is cryptographic proof of ownership — ACM never emails you a link. The CNAME record is the proof. Only the domain owner can add it, so adding it is the trust signal.
Alias records solve a real DNS spec limitation — CNAMEs are forbidden at the root domain level by the DNS protocol itself. Route 53 alias records are AWS's pragmatic workaround, and they're better in every measurable way.
ACM auto-renewal is quietly brilliant — the validation CNAME never gets deleted. It sits in your DNS forever, letting ACM silently re-verify and renew your certificate each year without any action from you.

None of this clicked from reading documentation. It clicked from doing it, watching something break, and figuring out why.

Quick Reference: The Full Chain

# The complete setup, end to end

Domain registrar  →  nameservers updated to Route 53
Route 53          →  hosted zone with A alias records → CloudFront
ACM (us-east-1)   →  SSL cert, DNS-validated via Route 53 CNAME
CloudFront        →  custom domain + ACM cert attached, HTTP→HTTPS redirect
S3 bucket         →  private origin, OAC-restricted to CloudFront only

# End result
https://yourname.com  →  globally distributed · HTTPS · auto-renewing cert

What's Next?

Now that your site lives on a custom domain over HTTPS, the next step is removing the manual deploy process entirely. Hopefully we will cover setting up a GitHub Actions pipeline that auto-deploys on every git push and triggers a CloudFront cache invalidation so your changes go live without you ever opening the AWS console again.

I’m also excited to share that I’ve been able to secure a special discount, in partnership with Sanjeev Kumar’s team, for the DevOps & Cloud Job Placement / Mentorship Program.

This is a great opportunity for anyone looking to level up their DevOps/Cloud skills with real-world mentorship and career guidance.

Do refer below for the link with a dedicated discount automatically applied at checkout;

DevOps & Cloud Job Placement / Mentorship Program.

If you also found this interesting and would love to take the next steps in the application process with AltSchool Africa do use my referral link below;

Apply here or use this Code: W2jBG8 during the registration process and by so doing, you will be supporting me and also getting a discount!

Special Offer: By signing up through the link and using the code shared, you’ll receive a 10% discount!

If you find my contents helpful, please like and follow my posts, and consider sharing this article with anyone starting their own cloud journey.

Let’s connect on social media. I’d love to engage and exchange ideas with you!

LinkedIn Facebook X

Host Your Personal Website on AWS for (Almost) Free — With S3 and CloudFront

Ikoh Sylva — Sat, 30 May 2026 08:00:19 +0000

A practical walkthrough for deploying a static portfolio, resume, or about-me page the cloud-native way with HTTPS, global delivery, and zero server maintenance.

Every cloud engineer needs a live portfolio. It proves you can ship not just talk theory. This project is deceptively simple on the surface, but underneath it teaches you S3 permissions, CDN architecture, bucket policies, and origin access control all concepts that show up on AWS certifications and real-world cloud jobs.

In this guide, I'll walk you through exactly how I deployed my own static website using Amazon S3 for storage and Amazon CloudFront as the content delivery network no EC2, no server patching, no midnight alerts. Just clean, fast, globally distributed HTML.

"The best infrastructure is the kind you don't have to babysit at 2am."

Why S3 + CloudFront?

Before we touch a single AWS console screen, let's understand the architecture we're building and why it makes sense.


💰 Near-zero cost	S3 storage for a personal site costs pennies. CloudFront's free tier covers 1TB/month of data transfer.
⚡ Global speed	CloudFront caches your content at 400+ edge locations worldwide your site loads fast from Lagos to London.
🔒 HTTPS by default	CloudFront provides a free SSL certificate your visitors get a padlock icon without buying anything extra.
🛠️ Zero servers	No EC2, no patching, no SSH keys. AWS manages all the infrastructure underneath.

How the Architecture Works

Here's the request flow from browser to your HTML file:

🧑‍💻 Visitor  ──HTTPS──▶  ☁️ CloudFront (CDN Edge)  ──cache miss only──▶  🪣 S3 Bucket (private origin)

CloudFront sits in front of your S3 bucket as a CDN. When a visitor hits your URL, CloudFront checks if it has a cached copy at the nearest edge location. On a cache hit, it serves instantly. On a miss, it fetches from S3, caches it, and serves the response.

Your S3 bucket can remain private only CloudFront talks to it directly, which is far more secure than opening the bucket to the entire internet.

Let's Build It Step-by-Step

Step 1 — Create Your S3 Bucket

Log into the AWS Management Console and navigate to S3 → Create bucket.

Choose a globally unique bucket name (e.g. yourname-portfolio-2024)
Select your preferred AWS Region
Leave "Block all public access" checked — we'll handle access through CloudFront, not by making the bucket fully public
Leave versioning off for simplicity; enable it later if you want rollback support

⚠️ Common mistake: Beginners often unblock all public access immediately and make the bucket fully public. This works, but it's not best practice. The cleaner and more secure approach is to keep the bucket private and let CloudFront access it via an Origin Access Control (OAC) policy which is exactly what we'll do.

Step 2 — Upload Your HTML Files

Build or gather your static website files. At minimum, you need an index.html. A basic portfolio structure might look like:

my-portfolio/
├── index.html
├── style.css
├── script.js
└── assets/
    ├── profile-photo.jpg
    └── resume.pdf

In the S3 console, open your bucket and click Upload. Drag your files in, keeping the folder structure intact, then click Upload to confirm.

✅ Pro tip: If you have the AWS CLI set up, you can sync your local folder with:
aws s3 sync ./my-portfolio s3://your-bucket-name
Much faster for future updates.

Step 3 — Enable Static Website Hosting

In your S3 bucket, go to Properties → Static website hosting → Edit.

Enable static website hosting
Set Index document to index.html
Optionally set Error document to 404.html

Save changes. AWS will give you an S3 website endpoint URL. Don't share this publicly it's HTTP only and bypasses CloudFront. Think of it as a staging preview.

Step 4 — Create a CloudFront Distribution

Navigate to CloudFront → Create distribution. This is where the magic happens.

Origin settings:

Origin domain: Select your S3 bucket from the dropdown (use the REST endpoint, not the website endpoint)
Origin access: Choose Origin access control settings (recommended)
Click Create new OAC give it a name and leave signing behaviour as "Sign requests"

Default cache behaviour:

Viewer protocol policy: Set to Redirect HTTP to HTTPS
Cache policy: Use CachingOptimized (AWS managed)

Settings:

Default root object: Enter index.html
Price class: Use all edge locations for best global performance, or restrict to a region to reduce cost

Click Create distribution. CloudFront will take a few minutes to deploy globally the status changes from "Deploying" to a green "Enabled".

Step 5 — Add the Bucket Policy for CloudFront OAC

After creating the distribution, the console will show a banner prompting you to update your S3 bucket policy. Click Copy policy, then navigate back to your S3 bucket → Permissions → Bucket policy → Edit and paste it in.

The generated policy looks like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipal",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::ACCOUNT_ID:distribution/DIST_ID"
        }
      }
    }
  ]
}

🔍 What this policy does: It grants the CloudFront service principal read access (s3:GetObject) to every object in your bucket but only from your specific CloudFront distribution. Not from anyone else's CloudFront. Not from the public internet. Just yours.

Step 6 — Test Your Live Site

Go back to CloudFront and copy your Distribution domain name it looks like d1abc2defgh3ij.cloudfront.net. Paste it in your browser.

You should see your index.html rendered, served over HTTPS, with a valid SSL certificate for free.

🎉 You're live! Your personal website is now globally distributed across AWS's edge network. Whether someone visits from Lagos, London, or Los Angeles they're getting a fast, secure experience.

Optional But Recommended: Use Your Own Domain

The CloudFront URL works fine, but yourname.com looks far more professional. Here's the short version:

Register a domain via Route 53 (or bring your own from Namecheap, GoDaddy, etc.)
Request a free SSL certificate via AWS Certificate Manager (ACM) in the us-east-1 region (required for CloudFront)
Add your custom domain as an Alternate domain name (CNAME) in your CloudFront distribution settings and attach the ACM certificate
In Route 53, create an A record (alias) pointing to your CloudFront distribution

What I Learned From This Project

When I first completed this as part of the Cloud Engineering Program, I thought it was going to be a simple file-upload exercise. It turned out to be a surprisingly rich lesson in cloud fundamentals:

IAM and resource-based policies — the bucket policy taught me how AWS evaluates permissions at the resource level, not just the user level
The principle of least privilege — keeping the S3 bucket private and exposing it only through CloudFront OAC is a real-world security pattern, not just textbook advice
CDN architecture — understanding cache hits vs. misses, TTLs, and edge locations made CloudFront feel less magical and more engineerable
DNS and SSL — hooking up Route 53 and ACM demystified how HTTPS actually works end-to-end

These aren't just resume bullet points. They're the building blocks of almost every AWS architecture you'll work on professionally.

Quick Reference: Services Used

Service	Role in This Project
Amazon S3	Object storage for your HTML/CSS/JS/assets
S3 Static Hosting	Turns the bucket into a web server (origin)
Bucket Policy	JSON policy granting CloudFront read access
CloudFront	CDN that caches and delivers content globally
OAC	Origin Access Control secure S3↔CloudFront connection
ACM	Free SSL/TLS certificate (optional, custom domain)
Route 53	DNS routing (optional, custom domain)

What's Next?

Once your static site is live, try extending it:

Add a CI/CD pipeline with GitHub Actions to auto-deploy on every push to your repo
Enable CloudFront invalidations (aws cloudfront create-invalidation) to clear the cache when you update your content
Explore S3 access logging to see who's visiting your site
Deploy a React or Next.js build the same S3 + CloudFront pattern scales directly to frontend frameworks

The static web hosting pattern is one of the most reusable skills in your AWS toolkit. Once you have it down, you'll reach for it constantly.

I’m also excited to share that I’ve been able to secure a special discount, in partnership with Sanjeev Kumar’s team, for the DevOps & Cloud Job Placement / Mentorship Program.

This is a great opportunity for anyone looking to level up their DevOps/Cloud skills with real-world mentorship and career guidance.

Do refer below for the link with a dedicated discount automatically applied at checkout;

DevOps & Cloud Job Placement / Mentorship Program.

If you also found this interesting and would love to take the next steps in the application process with AltSchool Africa do use my referral link below;

Apply here or use this Code: W2jBG8 during the registration process and by so doing, you will be supporting me and also getting a discount!

Special Offer: By signing up through the link and using the code shared, you’ll receive a 10% discount!

If you find my contents helpful, please like and follow my posts, and consider sharing this article with anyone starting their own cloud journey.

Let’s connect on social media. I’d love to engage and exchange ideas with you!

LinkedIn Facebook X

Monitoring Containers on AWS ECS with CloudWatch

Ikoh Sylva — Sat, 23 May 2026 19:46:39 +0000

One of the biggest realizations I had during my cloud engineering journey was this:

Deploying an application is only half the job.

The other half?

Monitoring it.
Understanding how it behaves under load.
Knowing when something is wrong before users complain.

Because in real-world cloud environments, applications are constantly consuming resources, handling requests, and responding to changing traffic patterns. If you’re not monitoring them properly, you’re essentially operating blind.

That’s exactly what this hands-on project aims to help us understand.

In this guide, I’ll walk you through how I monitored containerized workloads running on Amazon ECS, configured task resource settings, and visualized metrics using Amazon CloudWatch dashboards.

What we’ll Be Building

In this project, we will:

Deploy a containerized application on ECS
Configure CPU and memory allocation in the task definition
Monitor resource usage using CloudWatch
Build a dashboard with CPU and memory widgets
Simulate load to observe metric changes in real time

By the end, you’ll understand how to move from simply running containers to actually observing and managing them effectively.

Why Monitoring Matters

Imagine deploying an application that suddenly:

Runs out of memory
Uses excessive CPU
Becomes slow under traffic spikes

Without monitoring:

You won’t know why performance dropped
Troubleshooting becomes difficult
Downtime becomes more likely

With monitoring:

You gain visibility
You can detect issues early
You make informed scaling decisions

This is why observability is such a huge part of modern DevOps and Cloud Engineering.

Architecture Overview

Users
   |
   v
Amazon ECS Cluster
   |
Running ECS Service
   |
Task Definition
(CPU + Memory Allocation)
   |
CloudWatch Metrics & Dashboard

Step 1: ECS Cluster and Running Service

The first step was deploying a containerized application on ECS.

The deployment included:

An ECS Cluster
A Running ECS Service
Active ECS Tasks

This is the foundation where your application runs.

Step 2: Configure Task Definition Resources

One thing beginners often overlook is this:
Containers don’t have unlimited resources.

When creating the ECS task definition, I configured:

CPU allocation
Memory allocation

Example:

CPU: 512
Memory: 1024 MiB

Why This Matters

Resource allocation helps:

Prevent resource exhaustion
Improve application stability
Optimize cloud costs
Define scaling expectations

This is how cloud platforms control workload behavior.

Step 3: Monitoring with CloudWatch

Now comes the exciting part.

Once the ECS service was running, AWS automatically started sending metrics to CloudWatch.

I created a dashboard showing:

CPU utilization
Memory utilization

These widgets provided real-time visibility into how the container was behaving.

Creating the Dashboard

Go to CloudWatch
Navigate to Dashboards
Create Dashboard
Add Widgets:

ECS CPU Utilization
ECS Memory Utilization

What These Metrics Tell You

CPU Utilization

Shows how much processing power the container is using.

High CPU may indicate:

Heavy traffic
Inefficient code
Need for scaling

Memory Utilization

Shows RAM consumption.

High memory usage may indicate:

Memory leaks
Insufficient allocation
Application instability risks

Simulate Load

This was one of the most interesting parts.

To see real metric changes, I simulated load against the application using repeated browser refreshes or lightweight testing tools.

And suddenly:

CPU usage increased
Memory usage shifted

Watching the graphs move in real time made everything feel much more practical.

Why Simulating Load Is Important

This helps you understand:

How applications behave under pressure
When scaling might be needed
How monitoring tools detect changes

Common Mistakes Beginners Make

Ignoring Resource Limits
Containers can crash if memory is exhausted.
Not Monitoring Applications
You can’t fix what you can’t see.
Misinterpreting Metrics
Temporary spikes are normal patterns matter more.

What This Project Really Teaches

At first glance, this might seem like:

“Just another ECS deployment.”

But it’s actually teaching something deeper:

Operational visibility
Resource management
Observability fundamentals
Performance awareness

One of the most important transitions in cloud engineering is moving from:

“My application is running” to “I understand how my application is performing.”

That’s where monitoring changes everything.

This project helped reinforce that cloud engineering isn’t only about infrastructure it’s also about visibility, reliability, and operational intelligence.

And honestly? That’s where things start getting really interesting.

I’m also excited to share that I’ve been able to secure a special discount, in partnership with Sanjeev Kumar’s team, for the DevOps & Cloud Job Placement / Mentorship Program.

This is a great opportunity for anyone looking to level up their DevOps/Cloud skills with real-world mentorship and career guidance.

Do refer below for the link with a dedicated discount automatically applied at checkout;

DevOps & Cloud Job Placement / Mentorship Program.

If you also found this interesting and would love to take the next steps in the application process with AltSchool Africa do use my referral link below;

Apply here or use this Code: W2jBG8 during the registration process and by so doing, you will be supporting me and also getting a discount!

Special Offer: By signing up through the link and using the code shared, you’ll receive a 10% discount!

If you find my contents helpful, please like and follow my posts, and consider sharing this article with anyone starting their own cloud journey.

Let’s connect on social media. I’d love to engage and exchange ideas with you!

LinkedIn Facebook X

Deploying Metabase on AWS ECS (Fargate) with PostgreSQL (RDS)

Ikoh Sylva — Sat, 16 May 2026 07:42:54 +0000

At some point in your cloud journey, you stop just deploying applications and start thinking about data, persistence, and real-world architecture.

Because most production applications don’t just run they store, query, and visualize data.

That’s exactly what this project is about.

In this guide, I’ll walk you through how I deployed Metabase (an open-source business intelligence tool) on AWS using ECS with Fargate, and connected it to a PostgreSQL database hosted on RDS.

This is no longer just a “hello world” setup this is a real application backed by a real database.

What We’ll Be Building

In this project, we will:

Deploy Metabase using containers
Run it on Amazon ECS (Fargate)
Create a PostgreSQL database using Amazon RDS
Connect the application to the database
Configure networking and security for communication

By the end, we’ll have a fully functional data application in the cloud.

Why This Matters

This project introduces critical real-world concepts:

Application + Database architecture
Containerized workloads
Managed databases (RDS)
Secure service-to-service communication
Environment variable configuration

This is the kind of setup you’ll see in production systems.

Architecture Overview

User (Browser)
     |
     v
ECS Service (Fargate)
     |
Metabase Container
     |
     v
Amazon RDS (PostgreSQL)

Both ECS and RDS must be in the same VPC for private communication.

Step 1: Create the RDS PostgreSQL Database

Go to RDS → Create Database
Choose:

Engine: PostgreSQL
Template: Free tier (if available)

Configure:

DB instance identifier: metabase-db
Username: postgres
Password: (your choice)

Networking Settings

Place RDS in your VPC
Choose a private subnet (recommended)
Disable public access (best practice)

Security Group for RDS

Add inbound rule:

Port: 5432 (PostgreSQL)
Source: ECS security group

This allows only your container to access the database.

Step 2: Create ECS Cluster (Fargate)

Go to ECS
Create a cluster
Choose Fargate (Networking only)
Name it: metabase-cluster

Step 3: Create Task Definition

Go to Task Definitions → Create
Choose Fargate

Container Configuration

Container name: metabase
Image: metabase/metabase
Port mapping:
Container port: 3000

Environment Variables

Add the following:

MB_DB_TYPE=postgres
MB_DB_DBNAME=metabase
MB_DB_PORT=5432
MB_DB_USER=postgres
MB_DB_PASS=yourpassword
MB_DB_HOST=<RDS-ENDPOINT>

Replace <RDS-ENDPOINT> with your database endpoint.

This is how Metabase connects to PostgreSQL.

Step 4: Create ECS Service

Launch type: Fargate
Task definition: metabase-task
Number of tasks: 1

Networking Setup

Use the same VPC as RDS
Select subnets (public or private depending on access strategy)
Enable public IP (if accessing via browser)
Security Group for ECS

Add inbound rule:

Port: 3000
Source: your IP (recommended)

Step 5: Deploy and Run

Start the service
Wait for task status → RUNNING

Step 6: Access Metabase

Get the public IP of the ECS task
Open: http://<public-ip>:3000

You should see the Metabase setup screen!

Common Mistakes to Avoid

ECS and RDS in different VPCs
They won’t communicate.
Incorrect RDS endpoint
Connection will fail.
Missing security group rule (5432)
Database access will be blocked.
Wrong environment variables
Metabase won’t initialize properly.

What This Project Teaches You

This project is a major step forward.

You learn:

How applications connect to databases
How to configure secure communication
How to run stateful applications in the cloud
How real-world systems are structured

This is no longer just infrastructure it’s application architecture.

Real-World Use Cases

This setup is similar to:

Internal analytics dashboards
Business intelligence platforms
SaaS reporting tools
Monitoring and metrics visualization

Deploying Metabase with ECS and RDS is where things start to feel real.

You’re no longer just launching resources you’re building connected systems.

And that’s the difference between:

“Learning cloud” and “Thinking like a cloud engineer”

I’m also excited to share that I’ve been able to secure a special discount, in partnership with Sanjeev Kumar’s team, for the DevOps & Cloud Job Placement / Mentorship Program.

This is a great opportunity for anyone looking to level up their DevOps/Cloud skills with real-world mentorship and career guidance.

Do refer below for the link with a dedicated discount automatically applied at checkout;

DevOps & Cloud Job Placement / Mentorship Program.

If you also found this interesting and would love to take the next steps in the application process with AltSchool Africa do use my referral link below;

Apply here or use this Code: W2jBG8 during the registration process and by so doing, you will be supporting me and also getting a discount!

Special Offer: By signing up through the link and using the code shared, you’ll receive a 10% discount!

If you find my contents helpful, please like and follow my posts, and consider sharing this article with anyone starting their own cloud journey.

Let’s connect on social media. I’d love to engage and exchange ideas with you!

LinkedIn Facebook X

Running Grafana on AWS ECS (Fargate)

Ikoh Sylva — Sat, 09 May 2026 19:48:31 +0000

At some point in your cloud journey, you move beyond just deploying servers…

…and start thinking about observability.

Because building systems is one thing.

Understanding how they behave in real time is another.

That’s where tools like Grafana come in.

In this guide, I’ll walk you through how I deployed Grafana on AWS using ECS with Fargate a fully managed container service without managing any servers.

What We’ll Be Building

In this project, we will:

Deploy Grafana using containers
Use Amazon ECS with Fargate (serverless compute for containers)
Expose the application on port 3000
Configure networking and security
Access Grafana via our browser

By the end, we’ll have a live Grafana dashboard running in the cloud.

Why This Matters

This project introduces you to:

Containerized applications
Serverless container orchestration
Networking in ECS
Security group configuration
Observability tools (Grafana)

These are real-world DevOps and Cloud Engineering skills.

Architecture Overview

Internet
   |
Public Subnet
   |
ECS Service (Fargate)
   |
Grafana Container (Port 3000)

No EC2 instances needed Fargate handles everything.

Step 1: Create an ECS Cluster

Go to ECS in the AWS Console
Click Create Cluster
Choose Fargate (Networking only)
Give it a name (e.g., grafana-cluster)

Step 2: Create a Task Definition

Go to Task Definitions → Create
Select Fargate

Configure:

Task name: grafana-task
CPU: 0.5 vCPU
Memory: 1GB

Add Container

Container name: grafana
Image: grafana/grafana
Port mapping:
Container port: 3000

This tells ECS to expose Grafana’s default port.

Step 3: Create a Service

Go to your cluster
Click Create Service

Configure:

Launch type: Fargate
Task definition: grafana-task
Number of tasks: 1

Networking Setup

This step is critical.

Choose a VPC
Select a public subnet
Enable Auto-assign public IP

Step 4: Configure Security Group

Create or modify a security group:

Inbound Rule

Type: Custom TCP
Port: 3000
Source: 0.0.0.0/0 (or restrict to your IP for better security)

This allows access to Grafana via browser.

Step 5: Deploy and Run

Launch the service
Wait for the task to reach RUNNING state

Step 6: Access Grafana

Once running:

Go to ECS → Tasks
Copy the Public IP

Open in browser:

http://<public-ip>:3000

You should see the Grafana login page!

Default Login

Username: admin
Password: admin

(You’ll be prompted to change it immediately.)

Assignment Deliverable (Proof)

To confirm your setup, capture screenshots showing:

ECS cluster
Running task
Task public IP
Grafana UI in browser

This proves:

✔ Successful deployment
✔ Proper networking
✔ Working containerized application

Common Mistakes to Avoid

Forgetting to open port 3000
You won’t be able to access Grafana.
Not assigning a public IP
Your service won’t be reachable.
Using wrong port mapping
Grafana won’t load properly.

What This Project Teaches You

This isn’t just about Grafana.

It teaches you:

How containers are deployed in the cloud
How ECS and Fargate work
How to expose applications securely
How modern infrastructure avoids managing servers

This is exactly how modern DevOps teams deploy applications.

Real-World Use Cases

Grafana is widely used for:

Monitoring cloud infrastructure
Visualizing metrics (CPU, memory, logs)
Integrating with tools like Prometheus and CloudWatch

Deploying Grafana on ECS Fargate is a powerful step forward in your cloud journey.

It moves you from:

“I can launch servers” to “I can now deploy and run real applications in the cloud”

And that’s where things start to get exciting.

I’m also excited to share that I’ve been able to secure a special discount, in partnership with Sanjeev Kumar’s team, for the DevOps & Cloud Job Placement / Mentorship Program.

This is a great opportunity for anyone looking to level up their DevOps/Cloud skills with real-world mentorship and career guidance.

Do refer below for the link with a dedicated discount automatically applied at checkout;

DevOps & Cloud Job Placement / Mentorship Program.

If you also found this interesting and would love to take the next steps in the application process with AltSchool Africa do use my referral link below;

Apply here or use this Code: W2jBG8 during the registration process and by so doing, you will be supporting me and also getting a discount!

Special Offer: By signing up through the link and using the code shared, you’ll receive a 10% discount!

If you find my contents helpful, please like and follow my posts, and consider sharing this article with anyone starting their own cloud journey.

Let’s connect on social media. I’d love to engage and exchange ideas with you!

LinkedIn Facebook X

Building a Multi-VPC Architecture on AWS

Ikoh Sylva — Sat, 02 May 2026 07:37:14 +0000

When people begin learning cloud networking, they often start with a single VPC.
And that’s fine… until you realize that real-world cloud environments rarely stop at just one VPC.

Organizations separate workloads for:

Security
Scalability
Team isolation
Environment segmentation (Dev, Staging, Production)

At that point, a new question arises:

How do these isolated networks communicate with each other securely?

That’s exactly what this hands-on project explores.

What We’ll Be Building

In this guide, we will:

Create two separate VPCs
Design public and private subnets in each VPC
Establish a VPC Peering connection
Configure route tables to enable communication

By the end, we’ll have a basic multi-VPC architecture, similar to what is used in real production environments.

Why This Matters

This project introduces core networking concepts every cloud engineer must understand:

Network isolation
CIDR block design
Routing between networks
Private communication without the internet

These are foundational skills for:

Cloud Engineers
DevOps Engineers
Solutions Architects

Architecture Overview

VPC-A (10.10.0.0/16)          VPC-B (10.20.0.0/16)
----------------------        ----------------------
Public Subnet                Public Subnet
Private Subnet               Private Subnet
        |                          |
        -------- VPC Peering -------

No Internet Gateway or NAT Gateway required this is purely internal communication.

Step 1: Create VPC-A

Name: VPC-A
CIDR block: 10.10.0.0/16

Step 2: Create Subnets in VPC-A

Public Subnet: 10.10.1.0/24
Private Subnet: 10.10.2.0/24

Step 3: Create VPC-B

Name: VPC-B
CIDR block: 10.20.0.0/16

Step 4: Create Subnets in VPC-B

Public Subnet: 10.20.1.0/24
Private Subnet: 10.20.2.0/24

Step 5: Create VPC Peering Connection

Go to VPC Dashboard → Peering Connections
Click Create Peering Connection
Select:
Requester: VPC-A
Accepter: VPC-B
Create and accept the request
Once accepted, the VPCs are logically connected but not yet able to communicate.

Step 6: Update Route Tables (Critical Step)

This is where many beginners get stuck.

For VPC-A Route Table:

Destination: 10.20.0.0/16
Target: VPC Peering Connection

For VPC-B Route Table:

Destination: 10.10.0.0/16
Target: VPC Peering Connection

Without this step, traffic will not flow, even though peering exists.

How It Works

Now:

Traffic from VPC-A → VPC-B is routed through the peering connection
Traffic from VPC-B → VPC-A follows the reverse route

This enables private, secure communication between networks.

Testing the Setup

To validate:

Launch EC2 instances in each VPC
Use private IPs to ping between them

If configured correctly:

✔ Instances should communicate successfully

Important Limitations of VPC Peering

Understanding limitations is key:

No transitive routing (A → B → C won’t work automatically)
CIDR blocks must not overlap
Each route must be manually configured

What This Project Teaches You

It teaches you:

How real-world architectures are segmented
How cloud networking differs from traditional networking
How routing enables communication
How to design secure, isolated systems

Real-World Use Cases

This setup is commonly used for:

Connecting Dev and Production environments
Separating application tiers
Multi-team architectures
Microservices communication across VPCs

I’m also excited to share that I’ve been able to secure a special discount, in partnership with Sanjeev Kumar’s team, for the DevOps & Cloud Job Placement / Mentorship Program.

This is a great opportunity for anyone looking to level up their DevOps/Cloud skills with real-world mentorship and career guidance.

Do refer below for the link with a dedicated discount automatically applied at checkout;

DevOps & Cloud Job Placement / Mentorship Program.

If you also found this interesting and would love to take the next steps in the application process with AltSchool Africa do use my referral link below;

Apply here or use this Code: W2jBG8 during the registration process and by so doing, you will be supporting me and also getting a discount!

Special Offer: By signing up through the link and using the code shared, you’ll receive a 10% discount!

If you find my contents helpful, please like and follow my posts, and consider sharing this article with anyone starting their own cloud journey.

Let’s connect on social media. I’d love to engage and exchange ideas with you!

LinkedIn Facebook X

Launching a Windows Server on AWS EC2

Ikoh Sylva — Sat, 25 Apr 2026 19:11:05 +0000

When people start learning cloud engineering, they often begin with Linux servers and for good reason.

But in real-world environments, Windows servers are just as important.

From enterprise applications to legacy systems and Active Directory environments, Windows workloads are everywhere. So at some point in your cloud journey, you need to answer this question:

Can you confidently deploy and securely access a Windows server in the cloud?

In this guide, I’ll Walk you through exactly how to do that using AWS EC2 based on a hands-on task I completed during my cloud engineering training.

What We’ll Be Building

In this project, we will:

Launch a Windows Server EC2 instance
Deploy it in a public subnet
Configure secure access using RDP (Remote Desktop Protocol)
Restrict access to your own public IP address
Tag your instance for proper identification

By the end, you’ll have a fully running Windows server in the cloud that you can connect to remotely.

Why This Matters

This task teaches you several core cloud concepts:

Compute provisioning (EC2)
Networking (public subnets)
Security (security groups)
Remote access (RDP)
Resource management (tagging)

These are fundamental skills every cloud engineer must master.

Step 1: Launch a New EC2 Instance

Go to the AWS Management Console
Navigate to EC2 Dashboard
Click Launch Instance

Step 2: Choose Your AMI

Select:

Amazon Windows Server 2019 Base (or newer)

This provides a ready-to-use Windows environment.

Step 3: Choose Instance Type

Select t2.micro (Free Tier eligible)

Good for learning and basic testing.

Step 4: Add Name Tag

Give your instance a clear name, e.g.:

Name: Windows-Server-Lab

Tagging helps with:

Organization
Cost tracking
Resource identification

Step 5: Configure Networking

Make sure:

The instance is in a public subnet
Auto-assign Public IP is enabled

This ensures you can connect to it over the internet.

Step 6: Configure Security Group (Very Important)

Create a new security group with:

Inbound Rule

Type: RDP
Port: 3389
Source: My IP

This ensures:

✔ Only your IP can access the server
✔ The server is not exposed to the world

This is a key real-world security practice.

Step 7: Key Pair

Create or select an existing key pair
Download the .pem file

You’ll need this to decrypt the Windows password later.

Step 8: Launch the Instance

Click Launch Instance and wait for:

Instance state → Running
Status checks → 2/2 passed

Step 9: Connect via RDP

Once the instance is ready:

Select your instance
Click Connect
Choose RDP Client
Download the RDP file
Click Get Password
Upload your .pem key
Decrypt the password

Then connect using:

Username: Administrator
Password: (decrypted password)
You’re now inside your Windows server!

Common Mistakes to Avoid

Opening RDP to the world (0.0.0.0/0)
This is a major security risk.
Forgetting to enable public IP
You won’t be able to connect.
Losing your key pair
You won’t be able to retrieve the password.

What This Project Teaches You

This isn’t just about launching a server.
It teaches you:

How to think about security first
How cloud networking actually works
How to connect to real infrastructure
How to manage compute resources properly

This is the foundation of real-world cloud operations.

Launching a Windows EC2 instance might feel like a simple task but it introduces you to critical cloud concepts that scale into enterprise environments.

If you can do this confidently, you’re already building the skills needed to:

Manage enterprise workloads
Support cloud infrastructure
Work in DevOps or Cloud Engineering roles

I’m also excited to share that I’ve been able to secure a special discount, in partnership with Sanjeev Kumar’s team, for the DevOps & Cloud Job Placement / Mentorship Program.

This is a great opportunity for anyone looking to level up their DevOps/Cloud skills with real-world mentorship and career guidance.

Do refer below for the link with a dedicated discount automatically applied at checkout;

DevOps & Cloud Job Placement / Mentorship Program.

If you also found this interesting and would love to take the next steps in the application process with AltSchool Africa do use my referral link below;

Apply here or use this Code: W2jBG8 during the registration process and by so doing, you will be supporting me and also getting a discount!

Special Offer: By signing up through the link and using the code shared, you’ll receive a 10% discount!

If you find my contents helpful, please like and follow my posts, and consider sharing this article with anyone starting their own cloud journey.

Let’s connect on social media. I’d love to engage and exchange ideas with you!

LinkedIn Facebook X

Managing Access the Right Way

Ikoh Sylva — Sat, 18 Apr 2026 17:59:14 +0000

When most people begin their cloud journey, they focus on launching servers, deploying apps, and building projects.

But there’s something just as important if not more:

Who has access to your cloud environment… and what can they do?

This is where AWS Identity Center comes in.

During my cloud engineering training, one of the foundational tasks I completed was setting up Identity Center, creating users, and assigning permissions properly. It may seem like a small step, but in reality, it’s how secure and scalable cloud environments are built.

In this article, I’ll walk you through:

Why it matters
How to configure it
How to create users and assign permissions

Let’s get into it.

Why This Matters

In real-world environments:

Multiple engineers access AWS
Teams have different responsibilities
Security is non-negotiable

Without proper identity management:

❌ Anyone could access sensitive resources
❌ Permissions could be too broad
❌ Auditing becomes difficult

With Identity Center:

✅ Access is controlled
✅ Permissions are clearly defined
✅ Security is enforced

Step 1: Enable AWS Identity Center

Go to the AWS Management Console
Search for “AWS Identity Center”
Click Enable

Once enabled, AWS creates an Identity Center instance for your account.

This is your central identity management system.

Step 2: Create a New User

Next, you’ll create a user that can access AWS resources.

Steps:

Navigate to Users
Click Add user
Enter:
Username
Email address
First and last name
Save the user

This represents a real person (or team member) who needs access.

Step 3: Assign a Permission Set

Permissions define what the user can actually do.

In this task, we use a predefined job function policy:

SecurityAudit

What This Policy Does:

Provides read-only access
Allows users to review configurations
Ideal for auditing and compliance checks

Steps to Assign:

Go to AWS Accounts
Select your account
Click Assign users or groups
Select the user you created
Choose Permission Set → SecurityAudit
Complete the assignment

How It All Comes Together

At this point:

Identity Center is enabled
A user has been created
Permissions have been assigned

This means:

✔ The user can log in
✔ They have controlled access
✔ They cannot make destructive changes

This is real-world security in action.

This also demonstrates:

Proper configuration
Successful user creation
Correct permission assignment

Best Practices (What I Learned Along the Way)

Never Use Root Account for Daily Tasks
Always use Identity Center or IAM users.
Follow Least Privilege Principle
Only grant permissions necessary for the task.
Use Roles Instead of Static Credentials
Temporary access is safer.
Group Users When Scaling
Instead of assigning permissions individually, use groups.

Why This Step Is Bigger Than It Looks

This isn’t just about clicking through AWS.

It teaches you:

How organizations manage access
How security is enforced at scale
How to think like a cloud engineer

Because in the real world:

Security is not optional it’s foundational.
Setting up AWS Identity Center and assigning permissions is one of those foundational skills that separates beginners from professionals.

It’s not flashy but it’s critical and if you understand this, you’re not just learning cloud you’re learning how to build secure systems that people can trust.

I’m also excited to share that I’ve been able to secure a special discount, in partnership with Sanjeev Kumar’s team, for the DevOps & Cloud Job Placement / Mentorship Program.

This is a great opportunity for anyone looking to level up their DevOps/Cloud skills with real-world mentorship and career guidance.

Do refer below for the link with a dedicated discount automatically applied at checkout;

DevOps & Cloud Job Placement / Mentorship Program.

If you also found this interesting and would love to take the next steps in the application process with AltSchool Africa do use my referral link below;

Apply here or use this Code: W2jBG8 during the registration process and by so doing, you will be supporting me and also getting a discount!

Special Offer: By signing up through the link and using the code shared, you’ll receive a 10% discount!

If you find my contents helpful, please like and follow my posts, and consider sharing this article with anyone starting their own cloud journey.

Let’s connect on social media. I’d love to engage and exchange ideas with you!

LinkedIn Facebook X

AWS: Setting Up Your Account the Right Way

Ikoh Sylva — Sat, 11 Apr 2026 13:51:14 +0000

When I began my journey into cloud engineering, one of the very first steps I took was simple but incredibly important;

Setting up my AWS account.

It might sound basic, but this step is the gateway into the world of cloud computing. Whether you're aiming to become a Cloud Engineer, DevOps Engineer, or Solutions Architect, your AWS account is where everything begins.

In this guide, I’ll walk you through:

Why setting up an AWS account matters
How to create one properly
What to expect after setup
How to verify your account (as required in real training programs)

Let’s get into it.

Why You Need an AWS Account

Before you can deploy servers, build applications, or experiment with cloud services, you need access to a cloud platform and AWS is one of the most widely used in the world.

With an AWS account, you can:

Launch virtual servers (EC2)
Store data (S3)
Build scalable applications
Experiment with real-world cloud tools
Practice hands-on (which is critical!)

Cloud is not theory you learn it by doing.

Step 1: Create Your AWS Account

If you don’t already have an account, follow these steps:

1. Go to the AWS Website

Visit: https://aws.amazon.com

Click on “Create an AWS Account”

2. Enter Your Details
You’ll need:

A valid email address (preferably personal)
A strong password
An AWS account name (can be your name or brand)

3. Add Payment Information

AWS requires a debit/credit card for verification.

💡 Don’t worry:

You can stay within the Free Tier
You won’t be charged if you use services responsibly

4. Identity Verification
AWS will send a verification code to your phone.

5. Choose a Support Plan
Select the Basic (Free) Plan

Step 2: Log into the AWS Management Console

Once your account is created:

Go to the AWS Console
Sign in using your credentials

You’ll land on the AWS Management Console Dashboard this is your control center for everything in AWS.

Important Tips for Beginners

1. Stay Within Free Tier

AWS Free Tier includes:

EC2 (750 hours/month)
S3 storage
RDS usage

Always monitor usage to avoid charges.

2. Enable Billing Alerts

Set up alerts to avoid surprises:

Go to Billing Dashboard
Enable notifications

3. Use IAM (Don’t Stay on Root Account)
After setup:

Create an IAM user
Avoid using your root account daily

This is a best practice used in real organizations.

What This Step Really Means

Setting up your AWS account might feel like a small step but it’s actually a major milestone.

It means:

You’ve entered the cloud ecosystem
You’re ready to build real-world projects
You’re no longer just learning you’re doing

Every cloud engineer starts somewhere and this is where it begins.

If you’ve completed this step.

You now have access to one of the most powerful cloud platforms in the world.

The next step?

Start building. Break things. Fix them. Learn. Repeat.

That’s how you grow. If you’ve just set up your AWS account:

Drop a comment or share your experience
Let me know what you plan to build first

I’m also excited to share that I’ve been able to secure a special discount, in partnership with Sanjeev Kumar’s team, for the DevOps & Cloud Job Placement / Mentorship Program.

This is a great opportunity for anyone looking to level up their DevOps/Cloud skills with real-world mentorship and career guidance.

Do refer below for the link with a dedicated discount automatically applied at checkout;

DevOps & Cloud Job Placement / Mentorship Program.

If you also found this interesting and would love to take the next steps in the application process do use my referral link below;

Apply here or use this Code: W2jBG8 during the registration process and by so doing, you will be supporting me and also getting a discount!

Special Offer: By signing up through the link and using the code shared, you’ll receive a 10% discount!

If you find my contents helpful, please like and follow my posts, and consider sharing this article with anyone starting their own cloud journey.

Let’s connect on social media. I’d love to engage and exchange ideas with you!

LinkedIn Facebook X