DEV Community: Adedoyin

Mastering Full-Stack Deployment: EC2 Guide to Deploying a Web Application on AWS (Hands-On)

Adedoyin — Fri, 30 Jan 2026 11:34:23 +0000

Moving from local development to a live cloud environment can be one of the most challenging steps for developers. In this walkthrough, I break down the configuration, security groups, and server setup needed to get an application running smoothly on AWS EC2 ☁️

A hands-on guide covering everything you need to know to take an application live. From instance setup to full-stack configuration, this post will surely help you navigate the complexities of AWS with confidence.

View Hands-on

Below is the architectural diagram of the infrastructure I built in the project.

Remember, it is good practice to design for High availability, Resilience, Scalability and Tolerance.

There are certain techniques to achieve this such as Having a standby or redundant server/instance in another Availability zone or region (in case of failure or crash). Adding Load Balancers to distribute traffic, Auto-scaling, Web application firewalls WAF (To protect your server against common attacks and DDOS), AWS Shield and more.

View Walkthrough

My Opinion: Compute is the New Oil. The Cloud is no longer the Exterior; It is the Foundation.

Adedoyin — Tue, 20 Jan 2026 18:48:31 +0000

As we approach the anticipated late-January release of Amazon’s Q4 2025 earnings, the stakes for the 'Cloud War' have never been higher. Coming off a blockbuster Q3 where net sales hit $180.2 billion (a 13% YoY increase), Amazon has signaled that the migration to the cloud isn't just continuing—it’s reaccelerating. Driven by an insatiable demand for AI, AWS growth surged by 20% last quarter, pushing Amazon to project Q4 sales between $206 and $213 billion. Despite potential economic headwinds, the message is clear: the world is no longer just using the cloud; it is moving in.

The Signal in the Noise: A Universal Warning

For a startup in 2026, launching without a cloud-native, AI-ready infrastructure is akin to opening a bank without an internet connection. You might function, but you cannot compete on speed, cost, or scale.

The numbers above are not just a scorecard for one tech giant; they are a barometer for the global economy. While Amazon Web Services (AWS) posted 20% growth, their primary competitors—Microsoft Azure and Google Cloud—reported even steeper accelerations in late 2025 (ranging from 30% to 40% year-over-year).

This collective surge signals something profound: the market has moved from "experimenting" with AI to deploying it at an industrial scale across all major platforms.

For businesses and startups watching from the sidelines, this is a warning. The era of "digital transformation" as a buzzword is over. We are now in the era of Digital Survival. The infrastructure gap is widening, and companies that fail to embrace modern cloud architecture—whether on AWS, Azure, or Google Cloud—are risking obsolescence.

The "Left Behind" Reality

The surge in cloud revenues reported in late 2025 is driven by companies rebuilding their foundations to support heavy AI workloads. This creates a bifurcation in the business world:

The Cloud-Natives: These companies leverage "hyperscaler" elasticity to run predictive analytics, automate complex workflows with AI agents, and personalize customer experiences in real-time. They use the best tools from every provider—perhaps Google’s advanced data analytics combined with Microsoft’s enterprise AI integration.
The Legacy Holders: Stuck managing on-premise servers or outdated, static single-cloud instances, these businesses pay more for less computing power. Their data remains siloed, making it impossible to integrate modern tools like Copilot, Gemini, or Claude.

The Infrastructure of Intelligence

Amazon’s guidance for Q4 2025—expecting sales up to $213 billion—validates a crucial trend, but it is backed by a wider industry movement. In 2025 alone, the "Big Three" cloud providers combined invested over $300 billion in capital expenditures (Capex), primarily in GPUs and data centers.

Compute is the new oil, and Cloud is the pipeline.

Speed to Market: Cloud-native startups can deploy new features in minutes using serverless architectures (like Azure Functions, Google Cloud Run, or AWS Lambda). Legacy competitors take months.
Cost Efficiency: AI demand sensing allows cloud-enabled businesses to optimize inventory and reduce waste.
Scalability: When an AI application goes viral or a seasonal spike hits, modern cloud infrastructure expands automatically. On-premise servers crash.

The Risk of Inaction

The headwinds mentioned in Amazon’s guidance—economic factors and potential volatility—hurt legacy businesses the most. Cloud-adopting companies use AI to navigate these headwinds, optimizing supply chains and pricing dynamically to maintain margins.

If your business is not capturing data in the cloud today, you cannot train the AI models you will need tomorrow. The "Left Behind" aren't just losing a tech upgrade; they are losing the ability to see the future of their own market.

Conclusion

The earnings reports from Amazon, Microsoft, and Alphabet are massive leading indicators. The trillions of dollars flowing into cloud and AI create a slipstream. Businesses that draft behind this momentum—by adopting robust, often multi-cloud strategies—will be pulled forward into the next economy. Those that anchor themselves to the past will watch the gap widen until it is too large to cross.

The mandate for 2026 is clear: Modernize your infrastructure, or prepare to be outpaced.

In My next post I will talk about 5 key questions a business should ask to decide which cloud provider (AWS, Azure, or Google Cloud) best fits their specific AI and data needs

I’ve SSH’d Into EC2 Dozens of Times. This One Still Took 4 Hours!

Adedoyin — Tue, 13 Jan 2026 20:13:55 +0000

Yesterday, I spent FOUR hours trying to SSH into an EC2 instance. 4 HOURS. I’ve done this dozens of times before, This wasn’t my first time. Tried from both my macOS and windows terminal maybe it was a local system issue. Nothing worked

What am I writing about this?
I knew the drill.
I checked the “obvious” things first
I didn’t skip the basics:

Security group? ✅ Port 22 open
Source IP? ✅ Correct
Instance running? ✅
Public IP? ✅
My .pem key and permissions? All In check.

On paper everything was right. And yet… no access. Typical case of When experience doesn’t save you from overwhelm. This is the part people don’t talk about enough. Even when you know what you’re doing:

different environments behave differently
muscle memory fails when the context changes
small details you normally gloss over suddenly matter.

I wasn’t confused because I didn’t understand EC2. I was overwhelmed because too many variables were in play at once.
At some point, I wasn’t debugging anymore — I was context-switching:

shell differences
key permissions
command syntax
AWS quirks

Individually trivial. Collectively exhausting. The mistake wasn’t ignorance — it was friction Nothing was fundamentally broken. There was no dramatic misconfiguration. when I say “friction” in this context, I’m talking about anything that slows down your thinking, disrupts your flow or makes an otherwise straightforward task mentally heavier.

That’s how you lose hours on something you “already know.” When it finally worked When I eventually got in, the solution felt almost embarrassing in its simplicity. Not because I missed something obvious — but because clarity only comes after calm. The system failed in a predictable but poorly observable way.

Once the noise dropped, everything lined up.

Next time, this same setup will take minutes.

The real lesson
This experience reinforced something important:

Familiar ≠ frictionless
Experience ≠ immunity to overwhelm
Struggle ≠ incompetence

Sometimes the challenge isn’t technical. It’s maintaining mental clarity while systems quietly resist you.

For anyone reading this
If something you’ve done many times suddenly feels hard:

slow down
reduce variables
don’t let frustration rewrite your self-assessment

Being experienced doesn’t mean things never break. It means you eventually get through them.
And sometimes, that’s enough.

How I Passed the AWS Certified Cloud Practitioner in 24 Days (For Free)

Adedoyin — Mon, 05 Jan 2026 23:39:34 +0000

If you are looking to validate your cloud skills, the AWS Certified Cloud Practitioner (CLF-C02) is the starting line. It’s the foundational badge that says, "I understand the AWS Cloud ecosystem." Passing the Cloud Practitioner exam proves you understand the vocabulary of the cloud. It does not mean you are ready to architect a complex, fault-tolerant system for a Fortune 500 company tomorrow.

I recently passed this exam, and I did it in just 24 days.

But before I share my study plan, I need to be transparent about two things:

I didn't start from zero. I have been working with AWS services prior to this exam.
I spent $0 on study materials. I used entirely free resources.

However, having hands-on experience doesn’t automatically mean you’ll pass. The exam is its own beast, designed to test not just what you can do, but how well you know the specific AWS terminology and "the AWS way" of solving problems. So even a complete beginner with the right study materials can ace this exam.

Here is how I navigated the tricky questions and passed in under a month—and how you can too.

The "Experience Paradox"

You might think, "If I already use EC2 and S3, do I really need to study?" The answer is a resounding yes.

There is a difference between knowing how to spin up a server and answering a multiple-choice question that asks you to choose between two services that sound almost identical. The exam loves tricky scenarios. You need to sit down and train your brain to recognize keywords that differentiate a "good" answer from the "right" answer.

The Lesson: Don’t rely solely on your work experience. You need to study the exam logic.

My 24-Day Strategy (Using Free Resources)

Everyone learns differently. I focused on finding high-quality free content that matched my learning style. Whether you are a visual learner or a note-taker, there is a free path for you.

Step 1: The Knowledge Injection (Days 1–14)

I spent the first two weeks consuming the core material. Since I was not interested in spending any money for a foundational certificate, I stuck to free content, but if you are more comfortable with paid courses (like Udemy or A Cloud Guru), that works perfectly fine too.

For Visual Learners:

AWS Skill Builder: This is Amazon’s official free learning center. Look for the "AWS Cloud Practitioner Essentials" digital course. It’s interactive and comes straight from the source.
YouTube (FreeCodeCamp): Search for the "AWS Certified Cloud Practitioner" full course on FreeCodeCamp. These are often 13+ hour videos that cover everything in depth.

For Readers/Note Takers:

AWS Whitepapers: This is non-negotiable. Read the Overview of Amazon Web Services and the AWS Well-Architected Framework. The exam pulls questions directly from these concepts.

Step 2: Cracking the "Tricky" Code (Days 15–23)

This was the most critical phase. I shifted from passive learning to active testing.

I hunted down free practice questions and sample exams. My goal wasn't just to get the answer right, but to understand why the other three answers were wrong.

Identify the Distractors: AWS will often list a service that could work, but isn't the most cost-effective or cloud-native solution.
Keyword Association: I trained myself to link problems to services. (e.g., "Decoupling" SQS; "Global content delivery" CloudFront).

Step 3: Exam Day (Day 24)

By the time I sat for the exam, I wasn't just relying on my prior work experience; I was relying on my ability to dissect the questions.

Exam Day Advice

Identify what AWS is really asking. Eliminate obviously wrong answers first. This skill alone can easily be the difference between failing and passing. Don’t rush Read each question slowly.
AWS loves to add extra information you don’t need, Use keywords like “most cost-effective”, “least operational effort”, or “high availability”
Trust your preparation: If you’re unsure, think: What would AWS recommend as best practice? If you’ve studied properly, many questions will feel familiar.

Final Thoughts: Certified ≠ Qualified

I am proud of this certification, but I want to leave you with an important piece of advice: This certificate is just a foundational step.

Certified means you passed a test.
Qualified means you can build solutions.

Do not stop here. Use this win to build momentum. Real growth comes from:

Hands-on projects

Real-world problem solving

Breaking and fixing systems

Going for higher-level certifications (Solutions Architect, Developer, DevOps, etc.)

Get certified, but don’t stop there.

If you’re serious about cloud computing, this is just the beginning. 🚀

AWS Organizations: The Easy Way

Adedoyin — Mon, 29 Dec 2025 20:47:01 +0000

As you grow in AWS, you quickly learn that putting everything in one account is a recipe for disaster. You want a "Sandbox" for testing, a "Prod" for the real deal, and maybe a "Security" account.
But there’s a catch: AWS requires a unique email address for every single account. Who wants to manage five different email inboxes just to run a few Organization units(OUs)?

The Solution: Gmail Aliases + AWS Organizations
You can actually manage an entire AWS Organization using one Gmail inbox. Here is the step-by-step guide to adding a new account to an Organizational Unit (OU) using the email alias trick.

Step 1: Setting up the "Plus Alias" Trick

Main Email: yourname@gmail.com (Use this for your Management Account)
New Dev Account: yourname+dev@gmail.com e.g adehello+dev@gmail.com
New Prod Account: yourname+prod@gmail.com e.g adehello+prod@gmail.com

How it works

To AWS: This is a brand-new, unique email address.
To Gmail: It ignores everything from the + to the @ symbol. [i.e All emails sent to adehello+dev@gmail.com and adehello+prod@gmail.com will arrive in the inbox of adehello@gmail.com. All emails sent to these aliases will land in your primary inbox.

Step 2: Create the Account Directly in an OU

Instead of creating an account and moving it later, do it all in one go:

Log into your AWS Management Account.
Navigate to AWS Organizations.
On the AWS accounts page, select the OU where you want the new account to live.
Click Add an AWS account > Create an AWS account.
Email Address: Use your alias (e.g., yourname+dev@gmail.com).
IAM Role Name: Keep the default OrganizationAccountAccessRole.
This allows you to jump from your main account into this new one without a password!

Step 3: The "First Login" Gotcha

When AWS creates an account via Organizations, it doesn't ask you for a password. It generates a random one you'll never see. To log in as the Root User for the first time:
Go to the AWS Sign-In Console.
Select Root User and enter your alias email.
Click Forgot password?.
Check your primary Gmail inbox, reset the password, and you're in.

Step 4: Security Must-Dos 🛡️

Since your primary Gmail now controls multiple AWS accounts, security is non-negotiable:

MFA everything: Enable Hardware or App-based MFA on your Gmail account AND every AWS Root user you create.
Use IAM Identity Center: Once your accounts are in their OUs, set up IAM Identity Center (SSO). It’s the "modern way" to access your accounts so you never have to use the Root password again.

#aws #cloud #devops #tutorial #cloudcomputing