Forem: Marvelous Osondu

Building an Event-Driven Architecture on AWS Using EventBridge and SNS for EC2 State Notifications

Marvelous Osondu — Sat, 08 Nov 2025 20:45:16 +0000

Event-driven architectures are the core of modern cloud systems. They allow applications to react automatically to changes, without needing constant manual intervention or polling mechanisms.

In this lab, I implemented an event-driven workflow that monitors EC2 instance state changes and sends email notifications whenever an instance transitions between states, using Amazon EventBridge and Amazon Simple Notification Service (SNS).

Architecture Overview

Goal:

Trigger an email notification whenever an EC2 instance starts, stops, or terminates.

Services Involved:

Amazon EC2 – the compute instance whose state we’re monitoring.
Amazon EventBridge – to capture EC2 state change events.
Amazon SNS – to send notifications to subscribers (email).

Flow:

An EC2 instance changes its state.
EventBridge detects the state change event.
EventBridge triggers an SNS topic.
SNS sends an email notification to the subscribed user.

Steps I Followed

Created an EC2 instance – a simple instance to monitor.
Set up an SNS topic – and subscribed my email address to receive notifications.
Created an EventBridge rule – configured it to listen for EC2 instance state change events.
Added SNS as the target for the EventBridge rule.
Tested it by starting and stopping the EC2 instance — and watched email notifications come in automatically.

Conclusion

This lab showed me how AWS services integrate seamlessly to create automated, reactive systems.
Even with a small setup like this, the principle is clear, that in cloud architecture, events drive efficiency.

I’m excited to explore more event-driven patterns using Lambda, SQS, and Step Functions next.

Building an Event-Driven Architecture with AWS Config and Automated Remediation

Marvelous Osondu — Sat, 08 Nov 2025 20:44:22 +0000

In cloud environments, compliance and configuration management are critical. One small misconfiguration; like an instance type that doesn’t meet your company’s standards, can lead to performance issues or unnecessary costs.

Recently, I set up an event-driven architecture on AWS that automatically evaluates the configuration of EC2 instances and triggers a remediation workflow when something’s off. In my case, the system sends me an email notification whenever an EC2 instance doesn’t meet the ideal configuration setting.

Here’s how I built it:

Step 1: Enabling AWS Config

I started by enabling AWS Config in my account. AWS Config continuously evaluates your resource configurations against defined rules, so it’s perfect for enforcing compliance standards.

Step 2: Setting Up SNS for Notifications

Next, I created an SNS topic to send alerts whenever a non-compliant resource is detected.
Then, I subscribed to the topic using my email address — so any time remediation is triggered, I’d get an instant notification in my inbox.

Step 3: Creating an IAM Role for Remediation

I created a dedicated IAM role that allows AWS Config’s automated remediation feature to publish messages to the SNS topic.
This step ensures that Config has the right permissions to trigger notifications.

Step 4: Defining the Config Rule

After that, I set up an AWS Config rule to check the instance type of my EC2 instances.
I specified that only instances of type t3.micro should be considered compliant.

Step 5: Setting Up Automated Remediation

Here’s where the magic happens — I configured automated remediation in AWS Config so that whenever a non-compliant instance is detected, AWS automatically executes an action (in this case, sending a message to SNS).

Step 6: Testing It Out

To test the setup, I launched an EC2 instance that wasn’t a t3.micro.
Within moments, I received an email notification alerting me that the instance didn’t meet the required configuration.

That confirmed my event-driven architecture was working exactly as intended.

Conclusion:

This project was a simple but powerful demonstration of how AWS services — like Config, SNS, and IAM — can work together to enforce compliance automatically in real-time.

Event-driven architectures like this save teams from hours of manual checks and ensure that your cloud environment stays secure and optimized.

If you’re looking to build a similar workflow, start with a small rule (like instance type) — and then scale up to include security groups, IAM policies, or even S3 bucket configurations.

Below is a simple architecture diagram showing how AWS Config evaluates EC2 instances, triggers remediation, and sends notifications through SNS.

AWS S3 Location Constraint Error? Here’s What You’re Doing Wrong

Marvelous Osondu — Sat, 08 Feb 2025 08:59:29 +0000

If you’re working with AWS S3 and trying to create a new bucket, you might have run into this frustrating error:

An error occurred (IllegalLocationConstraintException) when calling the CreateBucket operation: The unspecified location constraint is incompatible for the region specific endpoint this request was sent to.

I ran into this issue recently, and after a bit of debugging, I figured out exactly what was causing it. If you’re stuck, don’t worry—I’ll walk you through why this happens and how to fix it.

Why This Error Happens

This error occurs because AWS requires you to explicitly specify a region when creating an S3 bucket outside of us-east-1. The problem arises when your AWS request is sent to a region-specific endpoint, but you don’t provide the correct location constraint for that region.

Here’s the thing:

If you create an S3 bucket in us-east-1, you don’t need to specify a region.
If you create an S3 bucket in any other region (e.g., eu-west-1, ap-south-1, etc.), you must specify the LocationConstraint parameter.
If your AWS CLI or SDK request is configured for a different region than the one you're specifying, it will fail.

The Fix: Explicitly Set the Region

To fix this, update your code to ensure the S3 client is using the correct region and explicitly pass the LocationConstraint when needed.

Fix for Python (boto3)

If you’re using Python and boto3, update your code like this:


import boto3

s3_client = boto3.client("s3", region_name="eu-west-1")

s3_client.create_bucket(
    Bucket="my-unique-bucket-name",
    CreateBucketConfiguration={"LocationConstraint": "eu-west-1"}
)

Fix for AWS CLI

If you’re using the AWS CLI, make sure to include the --region flag when creating your bucket:


aws s3api create-bucket --bucket my-bucket-name --region eu-west-1 --create-bucket-configuration LocationConstraint=eu-west-1

Double-Check Your AWS Configuration

If you’re still getting errors, run this command to check your AWS default region:


aws configure get region

If it’s not set correctly, update it with:


aws configure set region eu-west-1

Final thoughts

This issue can be frustrating, but once you understand why it happens, it’s an easy fix. Always make sure your AWS S3 client or CLI request is aligned with the correct region, and explicitly specify the LocationConstraint if you're creating a bucket outside us-east-1.

I hope this helped!

Building a Simple AWS Resource Monitoring Script with Bash

Marvelous Osondu — Mon, 27 Jan 2025 20:38:16 +0000

As a buzzing Cloud/DevOps guy, I recently worked on creating a Bash script to monitor AWS resources. This project allowed me to understand how to interact with AWS services programmatically and automate routine tasks. In this article, I’ll walk you through how I approached this task and built the script.

Why Create an AWS Resource Monitoring Script?
AWS offers a wide range of services, and while their Management Console is powerful, having a lightweight script to quickly monitor resources like EC2 instances, S3 buckets, and CloudWatch metrics can be very handy.

Prerequisite and Setup
Before writing the script, I ensured the following:

AWS CLI: That i had the AWS CLI installed and configured with the necessary permissions. If you don’t have it yet, you can install it from AWS CLI installation guide.
Bash Shell: That the Bash shell was available on my system. It is available on most Linux and macOS systems by default.

Script Structure
The script is divided into three main monitoring functions:

EC2 Instances: Fetches instance details like ID, state, type, and availability zone.
S3 Buckets: Lists all S3 buckets with their creation dates.
CloudWatch Metrics: Lists metrics for a specified namespace (default is AWS/EC2).

Let's dive deep into it!

Step 1: Checking AWS CLI Installation
The first thing the script does is check if the AWS CLI is installed. If not, it prompts the user to install it.

With this, we are sure that the script doesn’t proceed without the necessary tools.

Step 2: Writing the Monitoring Functions
Each function queries AWS resources using the AWS CLI and formats the output into a readable table.

Monitor EC2 Instances: The script uses aws ec2 describe-instances to fetch details about all EC2 instances.

Monitor S3 Buckets: This function lists all S3 buckets using aws s3api list-buckets.

Monitor CloudWatch Metrics: This function fetches CloudWatch metrics for a specific namespace. By default, it’s set to AWS/EC2, but you can modify it.

Step 3: Creating a Menu Interface
To make the script user-friendly, I added a menu interface. The user can choose which resource to monitor by typing a number.

These were the processes i followed to create the script to monitor my resources. I had some real hands-on experience with the AWS CLI and Bash scripting.

Here is the link to the full script: full script

How To Create and Connect To Your First AWS EC2 Instance: A Beginners Guide

Marvelous Osondu — Mon, 06 Jan 2025 17:39:46 +0000

Introduction:

In today’s time and age, cloud technology has become the backbone of numerous industries. From startups to multinational corporations, nearly everyone has embraced the cloud to improve scalability, reduce costs, and enhance flexibility. This rapid adoption has changed how businesses operate, making it essential for professionals across all domains to understand the basic concepts of cloud computing.

Among the many services offered by Amazon Web Services (AWS), EC2 (Elastic Compute Cloud) is unarguably one of the most popular and versatile. EC2 provides scalable compute capacity in the cloud, enabling users to deploy virtual servers in minutes. Whether you're hosting a website, running complex apps, or experimenting with machine learning models, EC2 is a go-to solution for developers and organizations alike.

Learning how to create and manage an EC2 instance is a foundational skill for anyone working in tech today. In this guide, I’ll walk you through the process of launching your very first EC2 instance and connecting to it alike.

Prerequisites:

An account on AWS: You need an active AWS account to access the AWS Management Console. If you don’t already have one, sign up at AWS.
Basic understanding of cloud and EC2: Having a foundational understanding of cloud computing and what EC2 offers (virtual servers for scalable compute capacity) will help you make better decisions about configurations and settings.
Familiarity with the CLI and SSH: You should have some idea about interacting with the shell through the CLI and familiarity with Secure Shell (SSH) is also essential to connect to your instance securely.
Internet access: Ensure your system has internet access.

Getting Started

Let's now dive fully into the creation process.

Step 1: Log in to the AWS Management Console

Go to the AWS Management Console
Sign in with your credentials or create an account if you don't have one.

Step 2: Navigate to the EC2 Dashboard

Search for EC2 in the search bar at the top and select EC2 under "Services."

Step 3: Launch an Instance

Click on the launch instance button

Step 4: Configure the Instance

Name and Tags: Enter a name for your instance (e.g., "My First EC2").
Application and OS Images (AMI): Select an Amazon Machine Image (AMI).

Instance Type: Choose an instance type based on your needs. For beginners select ( t2.micro ) - it's eligible for free tier

Key Pair: Create a new key pair (for secure SSH access) or use an existing one - Download the .pem file when creating a key pair (keep it secure).
Network Settings: Set up your security group - Add rules to allow traffic (e.g., SSH on port 22 for Linux or RDP on port 3389 for Windows).

Storage: Configure the instance's storage. Defaults are usually fine for Free Tier users (8 GiB SSD).

Step 5: Launch your Instance

Review your configuration.
Click Launch Instance.

Step 6: Access Your Instance

Go to the EC2 Dashboard and click Instances in the sidebar.
Find your instance and copy its Public IPv4 Address.
Connect to the instance: Use a terminal to run this command ssh -i "your-key.pem" ec2-user@your-public-ip Replace with your own details.

Once logged in, you can update the OS and Install software or deploy applications.