DEV Community: Naomi Ansah

Don’t Lock Yourself Out of AWS: MFA Backup and IAM Best Practices.

Naomi Ansah — Sun, 15 Mar 2026 11:48:23 +0000

A few days ago, I noticed something strange with my phone. The screen had started behaving unpredictably. Sometimes it responded perfectly, and sometimes it ignored my touch completely.At first it just felt like a minor inconvenience. But then a thought crossed my mind that made me pause.My authenticator app was on that phone and that authenticator app was the only way I could generate the login codes for my Amazon Web Services account.

Suddenly the situation felt much more serious. If the phone stopped working completely, I could lose access to my AWS account. That realization pushed me to take a closer look at how my account was secured. What started as a small precaution turned into a surprisingly valuable learning experience about MFA backups, IAM users, and AWS security best practices.

When I first created my AWS account, I had already enabled Multi-Factor Authentication on the root user. At the time, I thought that was enough. AWS strongly recommends MFA, and I had followed that advice. But the phone issue made me realize something I hadn’t considered before. Security isn’t just about enabling MFA!

It’s also about making sure you can still access your account if something happens to the device generating the authentication codes.

Phones get lost. Screens break. Devices fail. If my phone stopped working entirely, the authentication codes stored in that authenticator app would disappear with it. Recovering access to an AWS account in that situation can be difficult and stressful. That was the moment I decided I needed a backup MFA device. Fortunately, AWS allows multiple MFA devices to be registered for an account. I installed an authenticator extension on my laptop and connected it as a second MFA device. Now my authentication setup includes two devices generating login codes: my phone and my laptop.

While going through this process, I also revisited another important AWS best practice: avoiding daily use of the root account. When you create an AWS account, the first identity you receive is the root user. The root account has unrestricted access to every service and resource in the account. Because of that level of power, AWS recommends using the root account only for critical account management tasks. Daily work should be done using users created through AWS Identity and Access Management. Following that recommendation, I created an IAM administrator user with full administrative permissions and enabled MFA for that user as well.

Of course, the process wasn’t completely smooth. At one point, AWS told me that my MFA token was out of sync. After a bit of investigation, I discovered the problem was simply that my laptop clock was slightly out of alignment with internet time servers. Once the system clock synchronized correctly, the authentication codes started working again.

Another moment of confusion happened when I accidentally used the wrong MFA code during login. Because I now had two AWS tokens in my authenticator, it was easy to mix them up. One token was for the root account and the other for the IAM administrator user. Using the wrong one resulted in login failures that initially made me think something was broken. After completing everything, my account now follows a much safer structure.

Looking back, the entire process started with something as simple as a phone screen glitch. But that small problem forced me to rethink my AWS security setup and implement practices that I probably should have put in place much earlier.

For anyone learning AWS, security fundamentals can sometimes feel less exciting than launching EC2 instances or deploying applications. But they are just as important. Enabling MFA, creating backup authentication devices, and using IAM users instead of the root account are small steps that can prevent major headaches later. In my case, a malfunctioning phone screen turned into a reminder that good cloud security starts with the basics.

aws#cloudsecurity#devops#cloudcomputing#beginners

How I Secured My Static Website at the Edge Using Amazon CloudFront

Naomi Ansah — Sat, 03 Jan 2026 18:18:40 +0000

When I first deployed my portfolio as a static website, my focus was simple: getting it online. Like many beginners, I assumed security was something to think about later, perhaps at the server level or once traffic started to grow. As I learned more about how web traffic actually flows, I realized something important: the safest, cheapest, and smartest place to stop bad traffic is at the edge, before it ever reaches the origin.
In this project, I secured my static portfolio entirely at the edge using Amazon CloudFront, long before any request touched my Amazon S3 bucket.
At the time, I already had a working static website hosted in an S3 bucket. The site consisted only of static assets: HTML, CSS, JavaScript, and images. To improve performance and global availability, I placed the site behind a CloudFront distribution and configured the S3 bucket as the origin. While this setup distributed my content globally, it did not yet provide any protection at the edge. My objective was to ensure that traffic was encrypted, unnecessary or malicious requests were blocked early, security headers were applied automatically, and the S3 origin remained protected from direct or excessive access.

In CloudFront, edge security happens before caching and before requests are forwarded to the origin. This is achieved using CloudFront Functions, which run lightweight JavaScript code at CloudFront edge locations. I chose to run my function at the Viewer Request event, which is the earliest point in the request lifecycle. At this stage, CloudFront can inspect incoming requests immediately and decide whether they should be allowed or blocked.
Blocking requests at this point is especially important because it prevents unnecessary traffic from reaching the S3 bucket, improves overall performance, lowers cost by reducing origin requests, and reduces the attack surface. For beginners, CloudFront Functions are easy to explore because the AWS Console includes a built-in editor with sample code, and AWS documentation clearly explains how to create and test functions safely.
The first protection I added was enforcing HTTPS. Within the CloudFront distribution settings, I edited the default cache behavior and set the viewer protocol policy to redirect HTTP requests to HTTPS. With this configuration in place, any user attempting to access the site over an unencrypted connection is automatically redirected to HTTPS. This enforcement happens entirely at the edge and requires no changes to the website code itself.

After that, I created a CloudFront Function to block suspicious requests. Using the AWS Console, I navigated to CloudFront Functions and created a new function. The purpose of the function was straightforward: block requests targeting common WordPress administrative paths such as /wp-login.php and /wp-admin. Since my site is not a WordPress site, any request for these paths is unnecessary and potentially malicious.

The function inspects the request URI and immediately returns a 403 Forbidden response when a match is found. If the request does not match a blocked path, it is allowed to continue normally. Once the function code was saved, I published it, which is required for the function to run at CloudFront edge locations. I then associated the function with the Viewer Request event by editing the default behavior of the CloudFront distribution. After saving the changes, I waited a few minutes for the distribution to deploy globally.

To confirm that the protection worked as expected, I tested both normal and suspicious requests. The website loaded normally during regular access. However, when I manually navigated to a blocked path such as /wp-login.php, CloudFront immediately returned a 403 response, confirming that the request was stopped at the edge.

To further strengthen the security of the site, I attached a Response Headers Policy to the CloudFront behavior. This allowed CloudFront to automatically add important security headers to every response sent to the browser. These headers enforce HTTPS usage, help prevent clickjacking, and stop browsers from interpreting content as a different MIME type than intended. Because the headers are injected at the edge, no changes to the site files were required.

With this setup in place, security decisions are made as early as possible in the request lifecycle. By enforcing HTTPS, blocking suspicious paths, and adding security headers at the edge, the S3 origin remains protected while the website benefits from improved performance and reduced risk. Most importantly, this approach does not rely on servers, backend code, or complex infrastructure. Everything is handled by CloudFront at the edge.
If you already have a static website hosted on S3 and distributed through CloudFront, adding edge protection is a practical and achievable next step. CloudFront Functions provide a lightweight and effective way to inspect and block traffic early, without introducing operational complexity. By securing your website at the edge, you protect your origin, improve performance, and build a more resilient web presence.

aws #cloud #cloudfront #security#womenintech

Lost Your EC2 SSH Key? Here’s Every Way I Recovered Access

Naomi Ansah — Sat, 27 Dec 2025 11:50:46 +0000

The first time you lose an SSH key for an EC2 instance, it feels final. The server is running, your application is still alive, but the door is locked and the key is gone. I learned very quickly that AWS does not keep private keys for you, and once a .pem file is lost, it is lost forever.
Instead of panicking, I decided to turn this moment into learning. I deliberately walked through every realistic recovery method available in Amazon Web Services, starting from zero, creating instances from scratch, breaking access on purpose, and then recovering it again. What I discovered is that “losing an EC2 key” is not a dead end. It’s a branching path with multiple recovery strategies, each suited for a different situation.

Understanding the Core Truth About EC2 Keys
Before touching any recovery method, there is one truth that must be clear. AWS never stores your private SSH key. The .pem file lives only on your local machine. The EC2 instance never sees it. What the instance stores instead is the public version of that key inside a file called authorized_keys.
This means recovery is never about getting your old .pem file back. Recovery is always about getting temporary access and then adding a new public key.
Once that clicked, everything else made sense.

Temporary Access with EC2 Instance Connect
The first recovery path I explored was EC2 Instance Connect. This method works only when the instance is running, the AMI supports it, the instance has network access, and port 22 is open. When all those conditions are met, AWS can temporarily inject a one-time public key into the instance and open a browser-based SSH session.
What surprised me most is that this access is not time-limited in the way people assume. The injected key itself lives for about a minute, but once the SSH session starts, it behaves like any normal SSH connection. I stayed logged in for as long as I wanted. When I disconnected, the temporary key disappeared.
This method doesn’t recover your old key, but it gives you a crucial foothold. From inside the instance, you can add a brand-new public key and restore permanent access. It’s fast, clean, and perfect for emergencies but it depends heavily on networking and AMI support.

The “Surgery” Method: Detaching the Root Volume
Next, I practiced the most powerful and most intimidating method: detaching the root EBS volume. This approach works even when SSH is completely broken. The instance can be stopped, misconfigured, or unreachable, and recovery is still possible.
The process feels like surgery. You stop the broken instance, detach its root volume, and attach that volume to a second helper instance in the same availability zone. From there, you mount the disk, navigate into the filesystem, and manually edit the authorized_keys file.
While doing this on Amazon Linux 2023, I ran into a real-world issue that many tutorials skip. The filesystem is XFS, and because both disks were created from the same AMI, they shared the same UUID. XFS refuses to mount duplicate UUIDs unless you explicitly tell it to. Using the -o nouuid option was the key that made the mount succeed.
After adding a new public key, fixing permissions, and reattaching the volume to the original instance, I started it again and logged in successfully. This method taught me more about Linux, filesystems, and AWS storage than any lab ever could. It’s not fast, but it works even when everything else fails.

Recovering Access Without SSH Using Systems Manager
The cleanest recovery experience came from AWS Systems Manager Session Manager. Instead of relying on SSH at all, this method uses IAM and an encrypted control channel managed by AWS. There is no port 22, no .pem file, and no public SSH exposure.
I launched an instance using Amazon Linux 2023 and attached an IAM role with the AmazonSSMManagedInstanceCore policy. After a short delay, the instance appeared as “managed” in Systems Manager Fleet Manager. From there, I opened a browser-based shell using Session Manager and gained access immediately.
Inside the session, I verified that I was logged in as ssm-user, then elevated privileges and manually added an SSH public key. This meant I could later SSH normally if I wanted, but I no longer had to depend on SSH for access at all.
This method feels like how EC2 is meant to be managed in production environments. It’s secure, auditable, and resilient to lost keys. If I had to choose one approach to standardize on, this would be it.

Starting Fresh with an AMI
Finally, I explored the cleanest reset option: creating an AMI and launching a new instance. This method assumes you don’t care about preserving the original instance identity. You simply create an image of the server, launch a new instance from that image, and select a new key pair during launch.
What I appreciated here is the simplicity. There is no filesystem mounting, no Linux surgery, and no emergency access needed. The tradeoff is that the instance ID and public IP change, but the operating system, software, and data remain intact.
I also learned an important cleanup lesson. Deleting an AMI is not complete until the associated snapshot is deleted as well. Forgetting that step leaves behind storage charges that quietly accumulate.

What This Taught Me About Cloud Engineering
Losing an EC2 SSH key stopped feeling scary once I understood that access and identity are separate concepts in AWS. The private key is just one authentication mechanism, not the server itself. Every recovery method I practiced reinforced that cloud infrastructure is designed to be recoverable, provided you understand the tools.
More importantly, this journey shifted how I think about “best practice.” In learning environments, EC2 Instance Connect and AMI recovery are convenient. In real systems, Systems Manager Session Manager is the safest long-term strategy. And when everything is broken, volume attachment remains the ultimate escape hatch.
If you’re learning AWS and haven’t practiced these scenarios yet, I strongly recommend doing so before you need them in real life. The first time you recover a server you thought was lost, something clicks and cloud engineering starts to feel real.

aws#ec2#cloudcomputing#learninginpublic#careergrowth#Womenintech

Going Beyond Static Hosting: Deploying a Node.js Contact Form API on AWS EC2

Naomi Ansah — Sat, 20 Dec 2025 12:48:20 +0000

When people talk about hosting portfolios, the usual recommendation is static hosting using platforms like Amazon S3, Vercel, Netlify, or CloudFront. And honestly, that’s often the right architectural choice.
But as part of my cloud learning journey, I wanted to understand what those managed services actually abstract away. Instead of stopping at static hosting, I decided to build and deploy a backend service on AWS EC2 to power the contact form on my portfolio.
This article walks through what I built, why I chose EC2, and what I learned along the way.
Why EC2 for a Contact Form?
To be clear, EC2 is not the “best” tool for hosting a static portfolio. Managed services exist for a reason, and they usually provide better scalability, security, and simplicity for this kind of use case.
However, EC2 is one of the best tools for learning. I wanted to understand how applications run on real servers, how backend services are deployed, how traffic flows through a system, and how uptime and reliability are handled in practice.
Specifically, I wanted hands-on experience working with Linux servers, managing long-running processes, configuring reverse proxies, and handling real HTTP requests. That learning goal is what made EC2 the right choice for this project.
What I Built
For this project, I built a small Node.js and Express API with two simple endpoints. One endpoint handles health checks using a GET /api/health route, while the second endpoint, POST /api/contact, receives contact form submissions from my portfolio.
Instead of relying on third-party form services, my frontend sends form data directly to this backend API, giving me full control over the request flow and server behavior.
High-Level Architecture
At a high level, the architecture looks like this: a user interacts with my portfolio in the browser, the request travels over the internet to an AWS EC2 instance, Nginx receives the incoming traffic, and then forwards API requests to the Node.js application running on port 3000 and managed by PM2.
This setup mirrors how many real-world production systems are structured, even at much larger scales.
Step-by-Step Overview
I started by configuring the EC2 security group. SSH access on port 22 was restricted to my IP address, while HTTP traffic on port 80 was allowed from anywhere so the API could be publicly accessible.
Next, I launched the EC2 instance using an Ubuntu AMI and a free-tier eligible instance type. Once the instance was running, I connected to it via SSH using a key pair. This was my first reminder that servers are not “deploy-and-forget” resources, access control and security matter from the very beginning.
After connecting, I installed Node.js (LTS) and npm on the server. This allowed the backend to run in the cloud exactly as it did on my local machine.
I then copied my backend project to the EC2 instance, installed the dependencies using npm install, and verified that the API worked by running node server.js directly on the server.
Of course, running a Node application this way only works while the SSH session is active. To solve this, I introduced PM2, a process manager for Node.js applications. PM2 runs the application in the background, restarts it automatically if it crashes, keeps it running after SSH disconnects, and ensures it restarts on server reboot. This transformed my backend from a fragile process into a persistent service.
Since my Node.js app listens on port 3000, I didn’t want to expose it directly to the public internet. I installed Nginx and configured it as a reverse proxy so that all public traffic comes in on port 80, while requests to /api/* are forwarded internally to the Node application. This step introduced me to real-world request routing and proxy behavior, including fixing a classic trailing-slash issue in the proxy pass configuration.
Testing End-to-End
Once everything was wired together, I tested the setup end-to-end. I used curl directly from the server, inspected requests in the browser’s
Network tab, and submitted the contact form from the live portfolio itself.
Seeing consistent 200 OK responses from a cloud-hosted backend felt very different from testing locally and made the entire system feel real.
What I Learned
This project helped me understand how backend services actually run on cloud servers, why process managers like PM2 are essential, and how Nginx fits into real production deployments. It also clarified the difference between simply running code and operating a service that needs to stay online.
More importantly, it gave me confidence working with Linux, AWS EC2, Node.js backends, Nginx, and production-style workflows. It also reinforced why managed services exist and how much complexity they quietly remove.
And that was exactly the goal.
If you’re early in your cloud journey and curious about what happens under the hood, I highly recommend trying something similar.

AWS#Cloud#Node#Backend#Learninginpublic#WomeninTech

CloudFront +s3 Tutorial: How I Hosted my Portfolio Securely on AWS

Naomi Ansah — Sat, 06 Dec 2025 16:30:21 +0000

I recently deployed my developer portfolio on AWS using Amazon S3 and CloudFront without making the bucket public!

Most tutorials make you disable public access on the S3 bucket, but I wanted a secure, production-ready setup. So instead, I kept S3 private and used CloudFront as the only public entry point.

Here’s the exact process I followed, step by step.

*Prerequisites *
AWS account (Free Tier works)
Static website build (React/Vite or plain HTML/CSS/JS)
Basic familiarity with AWS Console

Step 1: Build & Upload Portfolio Files to S3
Before uploading, I created an optimized production build:
For React/Vite:
npm run build
This created a dist/build folder containing:

index.html
vite
assets(Folder)

This is what should be deployed and NOT your source code.
Then:

Create a bucket
Keep "Block Public Access" ON
Open S3 Console
Upload the dist/build files into the bucket root

Step 2 : Enable Static Website Hosting (Optional)
This helps with file access.
Go to the bucket Properties
Scroll to Static Website Hosting
Enable it
Set:
index.html

Step 3 : Create CloudFront Distribution

Open CloudFront Console
Click Create Distribution
Select your S3 bucket as the origin
For Origin Access, choose:
Origin Access Control (OAC)
CloudFront generates permissions
Apply them to your bucket

This keeps your S3 bucket private and protected, while CloudFront handles public routing.

Step 4 : Restrict Direct S3 Access
CloudFront gives you a policy to paste into your bucket permissions.
This ensures:

S3 is not publicly readable
Only CloudFront can serve content
This is the secure approach, unlike making S3 public.

Step 5 :Set Default Root Object
In CloudFront distribution settings:
Default Root Object: index.html

This makes the portfolio load without typing index.html.

Step 6 : Wait for Deployment & Test
It takes a few minutes for CloudFront to deploy.
Then you get a domain like:
d37dnhohvgt3x2.cloudfront.net
I opened mine and…
Portfolio LIVE & SECURE!

I love this setup because it keeps your s3 bucket private, follows production best practices, is still free tier friendly and CloudFront boosts performance globally.
If you're deploying a portfolio or static site, S3 + CloudFront is a powerful and scalable solution.
Feel free to drop questions 😀 I’m actively learning Cloud Engineering and happy to help!

aws #cloud #cloudfront #s3 #webdev #portfolio #tutorial

If you found this helpful, please leave a ❤ ️ or bookmark it!