DEV Community: Chisom Ejiba

Master Amazon SQS in One Page

Chisom Ejiba — Thu, 26 Mar 2026 13:09:26 +0000

At a buka, nobody is taking your order number.

The mama serving jollof doesn't care who came first. She's scooping for whoever is closest, loud, or holding their plate out furthest. You might wait five minutes. Someone who arrived after you gets served first. If you wait patiently, you still get your food. Speed is the whole point.

But at GTBank or Access Bank? Try telling the teller to process your withdrawal before your transfer has cleared. What do you think will happen?

Order matters there. Sequence is everything.

This is exactly the difference between SQS Standard queues and SQS FIFO queues.

Standard queues are the buka model.

Messages go in, messages come out. fast, at scale, in whatever order the system can manage. Sometimes a message is delivered more than once. The order is not guaranteed.

It's actually a feature, a deliberate trade-off for speed and volume.

When order doesn't matter, Standard is what you want.

→ Sending OTP notifications to users? Any order is fine.

→ Resizing profile photos after upload? Do them anyhow.

→ Logging app events for analytics? Sequence doesn't matter.

FIFO queues are the banking hall model.

FIFO means First In, First Out. Whatever enters the queue first is processed first. Every time. No exceptions here. And no duplicate processing, each message is handled exactly once.

The tradeoff is throughput. You can't match the raw volume of a Standard queue.

But for these systems, getting it right matters more than getting it fast.

→ Processing a Paystack or Flutterwave payment? Order matters.

→ Debiting a wallet after a transaction is confirmed? Order matters.

→ Running onboarding steps that depend on each other? Order matters.

The question is not, which one is better?

It's "what happens if two messages arrive in the wrong order or the same message is processed twice?"

If the answer is "nothing, we'll be fine" — Standard queue.

If the answer makes you uncomfortable — FIFO queue.

Most fintech systems running in Nigeria need FIFO. Most notification or media systems don't.

Knowing your system helps you choose accordingly.

What AWS concept should I break down next?

Want to learn more? Let's connect on LinkedIn

Your guide to Amazon SQS

Chisom Ejiba — Wed, 25 Mar 2026 17:07:01 +0000

Your WhatsApp doesn't stop receiving messages just because you're busy.

They sit there. Waiting. In order. Until you're ready.

That's literally how Amazon SQS works.

Imagine a friend is sending you a long voice note.

You're in a meeting. You can't listen right now.

Does the message disappear? No.

Does your friend have to wait and resend it later? No.

It sits in your inbox until you're free.

When your meeting ends, you open it and listen.

Everything in order. Nothing lost.

In cloud systems, services need to talk to each other constantly.

But what if one service is busy? Or slow? Or temporarily down?

Without a queue, the message is lost. The system breaks.

With Amazon SQS in the middle:

→ Service A sends a message and moves on immediately

→ The message waits safely in the queue

→ Service B picks it up when it's ready

No waiting around, lost data, and crashes under pressure.

This is called decoupling, and it's one of the most important ideas in cloud architecture.

Once you get it, you start seeing queues everywhere in how modern apps are built.

Interested in more content
Let's connect on LinkedIn

A Beginner’s Guide to Amazon SES

Chisom Ejiba — Thu, 19 Jun 2025 16:38:05 +0000

Amazon SES is a simple way to send emails that reach people’s inboxes. Whether you run a business, an app, or just need to send updates
Start small, test carefully, and scale as you grow.

How to Set Up Amazon SES

Step-by-Step:
✅Pick a Region
Choose the AWS location closest to your users or app.

✅Verify Your Domain or Email Address

Go to Verified Identities in the SES dashboard.
Add your domain (like yourcompany.com) or email.
Add the DNS records they give you (this proves you own the address).
Wait for confirmation (usually just a few minutes).

✅Request Production Access
By default, SES limits you to 200 emails/day.

Request full access so you can send more.

✅Set Up Email Security (Authentication)

Add SPF and DKIM records to your domain.

These tell email providers that your messages are safe.

Optional: Add a Mail-From domain for more control.

✅Create Your Email Credentials

Generate SMTP username and password for sending email.

Only give this access to your app or team (never share publicly).

✅Send a Test Email

Use Amazon’s simulator, an email client, or a script Make sure it works before you go live.

A Quick way to test if SES works Using SMTP:

✅Open SES in the AWS Console

Search for SES and choose your region.

✅Create SMTP Credentials

Go to SMTP Settings → Create Credentials
Save your username and password (you can’t see them again).

✅Verify Your Sender Email

Add the sender’s email address in SES
Click the confirmation link from your inbox

✅Send a Test Email

Use tools like Thunderbird, Postman, or a simple code script

You’ll need:
SMTP server: email-smtp.us-east-1-amazonaws.com

Port: 587 or 465

Your verified email and the SMTP login details

** How to Send an Email with an AWS Lambda Function **

Sometimes you want an email to go out automatically when something happens (a new user signs up, a payment is received, and so on). You can do that by invoking a Lambda function that calls Amazon SES.

✅Create Your Lambda Function

Go to AWS Console > Lambda > Create function

✅Choose a runtime like Python 3.9

Give it permission to use SES (attach a role with ses:SendEmail)

✅Test the Function

Click Test in the Lambda console
Confirm the email is delivered

✅ Set a Trigger

You can trigger this Lambda function from:

API Gateway (after a user fills a form)

S3 upload (when a file is added)

CloudWatch Events (on a schedule)

If you got here, you’re the real MVP.
Let’s connect on LinkedIn 🤓

A Beginner's Guide to Amazon Auto Scaling

Chisom Ejiba — Fri, 06 Jun 2025 21:36:16 +0000

Amazon Auto Scaling helps your applications handle changing demands by automatically adjusting the number of compute resources, such as EC2 instances, based on traffic or workload.

In simple terms, it means your system adds more servers when traffic increases and removes them when traffic drops.

This improves performance, reduces costs, and ensures availability.

Before you begin, install and configure these tools:

Download the Auto Scaling and CloudWatch command-line tools from AWS to define and manage scaling behavior and monitor metrics, and trigger scaling actions

Export your environment variables (like access keys and secret keys) to authenticate your AWS account, and set your environment variables to authenticate

To fully set up Auto Scaling, you’ll need to configure the following four components:

Launch Configuration
A blueprint that tells Auto Scaling how to launch new instances—what AMI, instance type, security group, and key pair to use.
Auto Scaling Group
The group that manages instance scaling. Define how many instances you want (min, max, desired) and which availability zones to use.
Scaling Policies
Define when and how to scale.
For example:
Scale up when CPU usage is high

Scale down when usage drops

CloudWatch Alarms These alarms monitor instance performance and automatically trigger your scaling policies.

Set Up Auto Scaling

Create a Launch Configuration This is a template for EC2 instances.

It defines:

AMI (Amazon Machine Image)

Instance type

Security groups

Key pair

Create an Auto Scaling Group This group manages multiple EC2 instances.

You define:

Minimum, maximum, and desired number of instances

Availability zones

Load balancer (if needed)

Define Scaling Policies You’ll create two policies:

✔Scale up: Add instances when traffic increases

✔Scale down: Remove instances when traffic drops

Create CloudWatch Alarms CloudWatch helps trigger actions automatically based on metrics.

Create a Scale Up Alarm
Define a condition (e.g., CPU > 70% for 5 minutes)

Link it to your scale-up policy

Create a Scale Down Alarm
Define a condition (e.g., CPU < 30% for 5 minutes)

Link it to your scale-down policy

🎯 Why It Matters
Amazon Auto Scaling helps you:

Stay online during traffic spikes

Avoid paying for idle resources

Improve application performance

Reduce the need for manual monitoring

For more guidance, check AWS's Article on getting started
https://aws.amazon.com/ec2/autoscaling/getting-started/

Hope this article helps you.
😉 Got questions? Let's connect on LinkedIn, you've got this!

🚀 How to keep your app running even when a server fails~A Beginner’s Guide to Elastic Load Balancer (ELB)

Chisom Ejiba — Thu, 22 May 2025 21:46:14 +0000

🔍 What is an Elastic Load Balancer?

An Elastic Load Balancer (ELB) is a service from AWS that spreads incoming traffic across multiple servers.

It helps your app stay online, responsive, and fast, even during server failures or traffic spikes.

🌐 Protocols: How ELB Communicates

ELB supports several common internet protocols like

HTTP (Port 80)

Used for handling regular web traffic.
It’s best when security is not critical. for example, public content that doesn’t need encryption.

HTTPS (Port 443)

Used for secure web traffic.
It encrypts the data sent between users and your servers, protecting sensitive information.
To use HTTPS, you need to attach an SSL/TLS certificate to your load balancer.

Ideal for apps that don’t use HTTP, like chat systems or real-time games.
It gives fast, low-level communication and full control over traffic.

TLS (formerly SSL)

An upgraded version of TCP that adds encryption.
Useful when you need both speed and security (e.g., secure email, FTP, or custom apps).

UDP (Supported in Network Load Balancer)

Best for high-performance, real-time applications like video streaming or VoIP.
It’s faster than TCP because it skips error checking, but less reliable.

✅ Which Protocol Should You Use

For websites → Start with HTTP or HTTPS
For apps with high security needs → Use HTTPS or TLS
For real-time apps → Consider TCP or UDP (with a Network Load Balancer)

✅How the ELB works (the basic architecture):

Users send requests to your app.
The ELB receives those requests and forwards them to healthy servers.
It automatically picks the best performing server at that moment.
You should always place your web servers(eg Apache, Nginx)in at least two different Availability Zones to ensure redundancy.

This setup gives your users a smooth experience,even if one server goes down.

✅ How ELB Checks Server Health

The ELB doesn’t just guess which servers work,it runs health checks to know for sure.

It checks if your servers respond correctly.

You control these key settings:

Healthy threshold – how many times a server must pass the check to be marked “healthy”
Unhealthy threshold – how many failed checks before a server is considered “unhealthy”
Response timeout – how long the ELB waits before deciding a server is slow or down

💡 Tip: Make sure your servers return valid responses (like 200 OK) when ELB pings them.

🌐 Accessing Your Website Through ELB
After setting it up:

AWS gives you a DNS name for the ELB (e.g. my-load-balancer-123456.elb.amazonaws.com)

Open that link in your browser

Add your landing page at the end (e.g. /index.html or /index.php)


http://your-elb-dns-name/index.html

This DNS name routes users through the load balancer to your servers.

💡 What Happens If a Server Fails?

If a server crashes, ELB stops sending traffic to it.

It redirects users to a healthy server, without you lifting a finger.

Users won’t even notice something went wrong.

You get high availability especially during peak times.

📌 Final Thoughts

Elastic Load Balancer helps you build resilient and scalable systems, set up your first ELB today.

Hi, My name is Chisom.
I write beginner articles like these weekly
Connect with me on LinkedIn for more

How to Store Your Data Long-Term Using Amazon Glacier

Chisom Ejiba — Wed, 14 May 2025 22:35:09 +0000

Have you ever wondered where to safely keep data you don’t use often?

Maybe old company records, logs, or backups etc?

That’s where Amazon Glacier comes in.

It’s part of Amazon Web Services (AWS).

It helps you store data for a long time.

And it costs very little compared to regular storage.

Let’s walk through how to use it.

We’ll talk about 3 things:

Creating a Glacier Vault

A vault is where your data will stay in Amazon Glacier.

First, log in to your AWS Management Console.

Go to the Amazon S3 Glacier service.

Click “Create Vault.”

Give your vault a name you can remember.

Choose the AWS Region closest to you or your customers.

Click “Create Vault.”

Uploading Data from Your System to Amazon Glacier

To upload data to Amazon Glacier, you first need to create your own vault.

Once the vault is ready, you can upload files in two main ways:

Option 1: Use the AWS CLI or a tool like S3 Glacier uploader.

Let’s use the AWS CLI as an example.

Make sure you have the AWS CLI installed on your computer.

Run this command in your terminal:

aws glacier upload-archive --account-id - --vault-name your-vault-name --body your-file-path

Replace your-vault-name with the name of your vault.

Replace your-file-path with the full path to your file.

This uploads your file to Glacier.

You will get an archive ID.

Keep this ID safe. you’ll need it to retrieve the file later.

Option 2: Use CloudBerry Explorer (a simple graphical tool)
This is easier if you prefer not to use the command line.

Steps using CloudBerry Explorer:
Install CloudBerry Explorer → Connect your AWS account → Go to Glacier section → Create a vault (if not done already) → Right-click the vault → Choose “Upload” → Select your file from your system → Click OK

Automating Archiving with Lifecycle Rules

Instead of uploading files manually, you can make Amazon do it for you.

This works with Amazon S3 buckets.

You first upload files to an S3 bucket.

Then you set up a Lifecycle Rule to move old files to Glacier.

Go to your S3 bucket in the AWS Console.

Click on “Management” and then “Lifecycle Rules.”

Click “Create Lifecycle Rule.”

Give your rule a name like “Archive to Glacier.”

Choose which files the rule should apply to (you can select all).

Now, choose the option to transition to Glacier after a number of days.

For example, you can set it to move files to Glacier after 180 days.

Click “Create Rule.”

Now your files will move to Glacier automatically after 180 days.

You don’t have to do anything manually.

This saves time and storage cost.

In Summary:

Amazon Glacier is great for storing data you don’t need often.

You can create a vault, upload data manually, or automate it with S3.

It’s safe, reliable, and cheap.

Perfect for backups and old records.

Want more articles like this?
Connect with me on LinkedIn

A Beginner-Friendly Guide to Amazon SNS

Chisom Ejiba — Tue, 29 Apr 2025 08:51:58 +0000

Have you ever thought of Amazon SNS as a messenger? Just like you send a text to multiple friends at once, Amazon SNS (Simple Notification Service) lets you send notifications or messages to multiple systems or users instantly.

Amazon SNS is a fully managed messaging service by AWS. It enables communication between systems through messages that are automatically sent and received.

In this guide, I'll break down the basics of SNS and walk you through a simple lab exercise.

Understanding the Basics: Topic vs Queue

When working with messaging systems like Amazon SNS, it's important to understand the difference between topics and queues.

A Topic works like a loudspeaker. When a message is published to a topic, everyone subscribed to it hears the message at the same time. It's "one-to-many" communication.

A Queue, on the other hand, is like a waiting line. Messages are stored and delivered one at a time to the receivers. Queues are usually handled by services like Amazon SQS (Simple Queue Service).

In simple terms:
A Topic broadcasts to many.
A Queue holds and delivers to one (or a few).

Why Use Amazon SNS?

Amazon SNS helps you send notifications quickly to multiple subscribers. It can trigger automated workflows and decouple application components for better scalability and reliability.

Step-by-Step: Amazon SNS Lab

Navigate to the SNS Service:
Sign in to the AWS Management Console. In the search bar, type SNS and select the service.
Create a New Topic:
Click on Topics in the left-hand menu. Select Create topic. Choose Standard as the type.
Name your topic mytopic for example,then click Create topic.

Create a New Subscriber: On your topic page, click Create subscription. Choose Email as the protocol. Enter the email address where you want to receive notifications, then click Create subscription.

Confirm the Subscription: Check your email inbox. Open the confirmation email from AWS Notifications and click the Confirm subscription link.

Send a Test Message: Return to your mytopic page. Click Publish message. Enter a simple subject and message body. Click Publish message and check your email—you should receive the test message shortly.

Whether you’re triggering workflows, sending alerts, or building scalable apps understanding topics and subscriptions is a great place to start.

Hope this article helps you.
😉 Got questions? Chat me up, you've got this!