DEV Community: Sahinur

Building `aws-ec2-check`: A Small Open-Source AWS Utility with Node.js

Sahinur — Sat, 31 Oct 2026 18:00:00 +0000

As I started working more deeply with AWS, I noticed a small but recurring workflow:

When debugging an EC2-based application, I often need to quickly answer a few basic questions:

Is the instance running?
What type of instance is it?
Which region and Availability Zone is it in?
What are its public and private IPs?
Are the EC2 status checks healthy?

The AWS Console provides all of this information, but sometimes I just want a quick answer from my terminal.

So I built aws-ec2-check, a small open-source CLI for inspecting AWS EC2 instances directly from the command line.

The project is now publicly available on GitHub:

GitHub: https://github.com/devSahinur/aws-ec2-check

The repository is written in TypeScript and is published under the MIT License.

The problem

When working with EC2-based applications, a lot of troubleshooting starts with basic infrastructure information.

For example:

Is the instance running?

Is the instance healthy?

Which Availability Zone is it using?

What's the public IP?

What's the instance type?

Are the EC2 status checks passing?

I could open the AWS Console and look these up.

But when I'm already working in the terminal, switching between tools feels unnecessary for such a small task.

That was the motivation behind the project.

What `aws-ec2-check` does

The idea is simple:

Terminal
   ↓
aws-ec2-check
   ↓
AWS SDK for JavaScript
   ↓
Amazon EC2

For a specific instance, the CLI is designed to provide useful EC2 information such as instance state, metadata, and health/status information.

A typical command looks like:

aws-ec2-check i-0123456789abcdef0

The project also supports a CLI-first workflow rather than requiring users to interact with the AWS Console.

Why build another AWS tool?

There is already an official AWS CLI.

So I'm not trying to replace it.

The goal of this project is much smaller:

Make one common EC2 inspection workflow convenient from the terminal.

That distinction is important.

I don't think every open-source project needs to become a massive platform.

Sometimes a small developer utility is enough to solve a real annoyance.

How it's built

I chose TypeScript because it fits naturally with my Node.js backend background while giving the project strong typing and a better development experience.

The repository is currently categorized around:

AWS
CLI
DevOps
EC2
Node.js
TypeScript

and is publicly available as devSahinur/aws-ec2-check.

At a high level, the architecture is:

Developer
    ↓
CLI
    ↓
TypeScript
    ↓
AWS SDK for JavaScript
    ↓
EC2 API

The CLI acts as a small abstraction over the EC2 APIs needed for inspection.

AWS SDK instead of the Console

One thing I wanted to learn from this project was what happens underneath the AWS Console.

When I use the Console, a lot of AWS operations feel like buttons and tables.

When building a CLI with the AWS SDK, those same workflows become explicit API calls.

That makes the architecture easier to reason about:

CLI command
    ↓
Application logic
    ↓
AWS SDK
    ↓
EC2 API
    ↓
Response
    ↓
Formatted terminal output

For me, this was a useful way to connect AWS infrastructure knowledge with backend development.

Security matters

Because this tool interacts with AWS, credential handling was one of the parts I paid close attention to.

I don't want AWS credentials embedded in the source code.

The tool should work with AWS's standard credential resolution mechanisms rather than inventing its own authentication approach.

That means developers can use their existing AWS configuration or appropriate AWS roles.

Just as importantly, the tool is intended for inspection, not unnecessary infrastructure modification.

That led to another important design principle:

A small tool should ask for small permissions.

There's no reason for an EC2 inspection tool to require administrator access.

IAM and least privilege

AWS permissions can become dangerous when developers solve every AccessDenied problem by attaching broad policies.

For this project, I wanted the permissions model to follow the same principle I discussed in my earlier IAM article:

Required action
      ↓
Required resource
      ↓
Minimum permission

Rather than:

Required action
      ↓
AdministratorAccess

This is a small CLI, but the security principle is the same as it is for a large production system.

Keeping the CLI simple

I wanted the command structure to stay easy to understand.

The core idea is:

aws-ec2-check <instance-id>

And as the project evolves, additional commands and options can support common workflows without making the CLI feel complicated.

For example:

aws-ec2-check --help

and:

aws-ec2-check --version

make the tool easier to discover and use.

Why TypeScript?

For a small project like this, TypeScript isn't required.

But I still prefer it because it gives me:

Better type safety
Better editor support
Easier refactoring
Clearer function contracts
Better maintainability as the project grows

It also keeps the project close to the technologies I already use in backend development.

Testing the project

Another thing I wanted to avoid was creating a CLI that only works on my machine.

A useful open-source project needs to be reproducible.

So the project is structured around the usual development workflow:

npm install
npm run build
npm test
npm run lint
npm run typecheck

The goal is to keep the project easy to validate locally and suitable for automated checks through GitHub.

What I learned building it

The interesting part of building this project wasn't only calling the EC2 API.

It made me think more carefully about the difference between:

"I can write the code."

and:

"I can publish something other developers can actually use."

That difference includes a lot of small details.

CLI design

A CLI needs clear commands and understandable output.

The user shouldn't have to understand the internal implementation just to get an EC2 status.

AWS authentication

AWS credential handling shouldn't be reinvented.

Using established AWS mechanisms is safer and easier to maintain.

Error handling

AWS errors can contain useful technical information, but exposing raw errors to users isn't always the best experience.

A good CLI should turn those failures into useful messages.

Documentation

Open source isn't just about code.

A developer should be able to discover:

What does this tool do?
How do I install it?
How do I authenticate?
What permissions are required?
What commands are available?
What should I do when something fails?

If the README can't answer those questions, the project isn't finished.

What I'd like to add next

The first version is intentionally focused.

But there are several areas that can make the tool more useful over time:

Instance filtering
Tag-based filtering
Multi-region support
JSON output improvements
More detailed health information
Additional EC2 inspection commands
Better automation support

The important part is adding features based on real developer needs rather than adding functionality just to make the project bigger.

Why open source?

One of my goals with this project was to move beyond simply learning AWS privately.

I wanted to follow a cycle like:

Learn
  ↓
Build
  ↓
Document
  ↓
Publish
  ↓
Get feedback
  ↓
Improve

That's one of the reasons I'm interested in building in public.

A project becomes more valuable when other developers can inspect it, use it, report issues, and contribute ideas.

Try it

The repository is available here:

https://github.com/devSahinur/aws-ec2-check

It's a public GitHub repository built with TypeScript and focused on AWS EC2 inspection.

You can explore the implementation, open an issue, suggest an improvement, or contribute to the project.

Final takeaway

I didn't want to build a huge AWS platform.

I wanted to solve one small problem:

Make EC2 inspection easier from the terminal.

That small problem turned into a useful learning project covering:

TypeScript + Node.js + AWS SDK + EC2 + IAM + CLI development + Open Source

For me, that's the real value of building small developer tools.

You don't always need a huge project to learn something meaningful.

Sometimes you just need to take one annoying workflow and make it a little better.

Build something small. Make it useful. Publish it. Then keep improving it.

Load Testing My Node.js API on AWS: What I Learned

Sahinur — Thu, 29 Oct 2026 18:00:00 +0000

An API can work perfectly when I'm testing it alone.

Send one request.

It responds quickly.

Everything looks fine.

But what happens when 10 users make requests at the same time?

What about 100?

What about 1,000?

That's where load testing becomes important.

As a backend developer working with Node.js and Express, I want to know how an API behaves before real traffic exposes its limitations.

In this post, I'll walk through how I think about load testing a Node.js API running on AWS EC2.

Why load test?

Functional testing answers:

Does the API work?

Load testing asks a different question:

How does the API behave under pressure?

An API might return the correct response for a single request but struggle when concurrency increases.

For example:

1 request
   ↓
Everything looks good

100 concurrent requests
   ↓
Latency increases

500 concurrent requests
   ↓
Database becomes a bottleneck

1000 concurrent requests
   ↓
Errors / timeouts

Without load testing, I may discover these limitations only after production traffic arrives.

The setup

For a typical Node.js backend, my architecture looks like:

Client
   ↓
Nginx
   ↓
AWS EC2
   ↓
Node.js + Express
   ↓
MongoDB

The API may contain endpoints such as:

GET    /api/users
GET    /api/products
POST   /api/orders
GET    /api/orders/:id

For load testing, I don't want to test every endpoint equally.

I focus on the endpoints that are:

Frequently used
Business-critical
Database-heavy
Computationally expensive
Likely to experience high concurrency

Tooling

There are several tools I can use for API load testing.

Some popular options include:

k6
Artillery
Locust
Apache JMeter

For a Node.js/backend workflow, k6 is particularly convenient because the test scenarios are easy to define and version-control.

The important thing isn't which tool I choose.

It's being able to reproduce the same test consistently.

A simple k6 test

A basic test could look like:

import http from "k6/http";
import { check } from "k6";

export const options = {
  stages: [
    { duration: "30s", target: 10 },
    { duration: "1m", target: 50 },
    { duration: "1m", target: 100 },
    { duration: "30s", target: 0 }
  ]
};

export default function () {
  const response = http.get(
    "https://api.example.com/api/products"
  );

  check(response, {
    "status is 200": (r) => r.status === 200
  });
}

The idea is to gradually increase traffic rather than immediately sending a huge number of requests.

This gives me a better understanding of how the system behaves as load increases.

The test stages

A useful load test isn't just:

Send lots of requests

I prefer thinking in stages.

          Users
            │
        100 │              ╭──────
            │             ╱
         50 │        ╭───╯
            │       ╱
         10 │──────╯
            │
            └──────────────────── Time

For example:

Stage 1 — Baseline

Start with a small number of users.

The purpose is to understand normal performance.

Stage 2 — Ramp up

Gradually increase concurrent users.

Now I'm looking for:

Increasing latency
CPU changes
Memory growth
Database pressure
Error rates

Stage 3 — Peak load

Push the API toward the expected production workload.

This is where bottlenecks often become visible.

Stage 4 — Recovery

Reduce traffic again.

I want to see whether the system returns to its normal state.

This last step is easy to overlook.

A system that survives peak traffic but never properly recovers can still have a serious problem.

What I measure

There are several metrics I care about.

P50 latency

P50 represents the median request latency.

It tells me what a typical request looks like.

P95 latency

P95 is more interesting for production behavior.

It tells me that approximately 95% of requests are faster than that value.

If P50 looks good but P95 becomes very high, some users are experiencing significantly worse performance.

P99 latency

P99 helps expose the tail of the latency distribution.

This is especially useful when investigating occasional slow requests.

Error rate

Latency isn't the only concern.

I also want to know:

How many requests failed?

A fast API returning lots of 500 errors isn't a healthy API.

Throughput

I also want to understand how many requests the system can handle.

Conceptually:

Requests/sec
     │
     │              ───────
     │           ───
     │        ───
     │     ───
     │────
     └──────────────────── Load

At some point, adding more traffic may no longer increase useful throughput.

That's an important signal.

Results

For a real test, I'd record the results in a table like this:

Metric	Result
P50 latency	Measure
P95 latency	Measure
P99 latency	Measure
Error rate	Measure
Max sustained RPS	Measure
Peak concurrent users	Measure

I prefer recording these numbers rather than simply saying:

"The API was fast."

Numbers make performance discussions much more useful.

Watching the EC2 instance

While the load test is running, I also want to know what is happening on the server.

For example:

top

or:

free -h

For a Node.js application running with PM2:

pm2 monit

This helps correlate API performance with system resources.

For example:

Traffic increases
      ↓
CPU increases
      ↓
Latency increases

or:

Traffic increases
      ↓
CPU remains reasonable
      ↓
Database connections increase
      ↓
Latency increases

Those two scenarios require completely different solutions.

The surprise: the API isn't always the bottleneck

One of the biggest things load testing can reveal is that the application server isn't necessarily the problem.

Consider this architecture:

Load
 ↓
EC2
 ↓
Node.js
 ↓
MongoDB

You might expect the EC2 server to reach its limit first.

But the actual bottleneck could be:

MongoDB queries
Database connections
Slow indexes
Network latency
External APIs
Large responses
Memory usage

This is why I don't look at only one metric.

I want to correlate:

API latency
+
Error rate
+
CPU
+
Memory
+
Database behavior
+
Network

A common database problem

Suppose an endpoint performs:

const users = await User.find({
  status: "active"
});

With a small dataset, this might appear completely fine.

But under load, if the query returns a large number of documents, the application may spend significantly more time processing the result.

That can increase:

Response latency
Memory usage
CPU usage
Database workload

Pagination can help:

const users = await User.find({
  status: "active"
})
  .limit(50)
  .lean();

Indexes can also be important.

For example, if the application frequently searches by:

status
email
userId
createdAt

I want to make sure the database query patterns are properly supported.

What happens when the test gets too aggressive?

A load test can eventually push the system beyond its intended capacity.

That's useful information—but it should be done carefully.

If the system reaches:

High CPU
High memory
Database saturation
High error rate

I don't immediately conclude that the server needs to be bigger.

First I ask:

What became the bottleneck?

Only then do I decide whether the solution is:

Better application code
Database optimization
Caching
Connection-pool tuning
Horizontal scaling
Vertical scaling
Architecture changes

Changes I would make after testing

Depending on the results, the next step could be one or more of these.

1. Optimize database queries

Reduce unnecessary data and make frequently used queries efficient.

2. Add pagination

Avoid returning huge datasets in a single request.

3. Improve connection handling

Make sure database connections are managed efficiently under concurrency.

4. Add caching

For frequently requested data that doesn't change often, caching can reduce unnecessary database work.

5. Scale the application

If the application is genuinely CPU or memory constrained, scaling the EC2 infrastructure may be appropriate.

6. Improve observability

Load testing should ideally be combined with monitoring so that performance problems can be investigated instead of guessed.

Load testing isn't about finding one magic number

One mistake I try to avoid is thinking:

"Our API supports 500 requests per second."

That's rarely the whole story.

The real question is:

500 requests/sec
under what conditions?

For example:

Which endpoint?
What payload size?
How many concurrent users?
What database size?
What response size?
What error rate?
What latency target?

A meaningful performance number always needs context.

A simple performance checklist

Before considering an API ready for significant traffic, I'd check:

[ ] Baseline performance measured
[ ] Peak expected traffic tested
[ ] P50 latency recorded
[ ] P95 latency recorded
[ ] P99 latency recorded
[ ] Error rate recorded
[ ] Maximum sustainable throughput measured
[ ] CPU monitored
[ ] Memory monitored
[ ] Database performance monitored
[ ] Slow queries investigated
[ ] Recovery after peak load tested

What I learned

Load testing changed the way I think about backend performance.

Before testing, I might ask:

"Is the API fast?"

After testing, I ask:

"How does the API behave as concurrency increases?"

That's a much better question.

A backend isn't truly production-ready just because it works with a few requests.

I want to understand how it behaves when:

Traffic increases
      ↓
Resources increase
      ↓
Latency changes
      ↓
Bottlenecks appear
      ↓
System reaches its limits
      ↓
System recovers

Final takeaway

Load testing isn't something I want to do only after an application starts having production problems.

It should be part of understanding the system.

For a Node.js + Express backend running on AWS EC2, I want to know:

How much traffic can it handle?

Where does it start slowing down?

What becomes the bottleneck?

Does it recover correctly?

Those answers are much more valuable than simply knowing that the API works.

Don't wait for production traffic to discover your application's limits. Test those limits before your users do.

Migrating a Node.js Endpoint to AWS Lambda: What I Would Watch For

Sahinur — Wed, 21 Oct 2026 18:00:00 +0000

Moving an endpoint from a traditional Node.js backend to AWS Lambda sounds straightforward.

Take the business logic, put it inside a Lambda function, connect API Gateway, and you're done.

In practice, the architecture changes more than the deployment model.

A traditional Express application is designed around a continuously running server.

Lambda is designed around short-lived function executions.

That difference affects application structure, database connections, configuration, authentication, logging, and performance.

Coming from a Node.js + Express background, these are the things I would pay attention to when migrating an endpoint to Lambda.

Why migrate only one endpoint?

I wouldn't start by moving an entire monolith to serverless.

That's a much bigger risk.

A better approach is to select one endpoint and use it as a migration experiment.

A good candidate could have:

Relatively independent business logic
Predictable input/output
Limited dependencies on the rest of the monolith
No requirement for a long-running process
A workload that can benefit from independent scaling

The architecture could change from:

Before

Client
   ↓
Nginx
   ↓
EC2
   ↓
Node.js + Express
   ↓
MongoDB

to:

After

Client
   ↓
API Gateway
   ↓
Lambda
   ↓
MongoDB

The rest of the application can continue running on EC2 while the selected endpoint is handled by Lambda.

The migration plan

I would break the migration into small steps.

Step 1: Identify the endpoint

First, understand exactly what the endpoint does.

For example:

POST /api/orders

The endpoint might:

Validate the request
Authenticate the user
Read data
Perform business logic
Write to MongoDB
Return a response

Before moving it, I would identify every dependency.

Endpoint
   │
   ├── Authentication
   ├── Validation
   ├── Database
   ├── Services
   ├── Environment variables
   └── External APIs

This makes hidden dependencies visible.

Step 2: Separate business logic from Express

One of the biggest advantages of separating application logic from the HTTP framework is that the business logic becomes easier to reuse.

Instead of putting everything inside:

app.post("/orders", async (req, res) => {
  // everything here
});

I would separate the business logic:

const createOrder = async (userId, data) => {
  // business logic
};

Then Express can call it:

app.post("/orders", async (req, res) => {
  const order = await createOrder(
    req.user.id,
    req.body
  );

  res.json(order);
});

And a Lambda handler can call the same logic:

export const handler = async (event) => {
  const body = JSON.parse(event.body);

  const order = await createOrder(
    event.requestContext.authorizer.userId,
    body
  );

  return {
    statusCode: 200,
    body: JSON.stringify(order)
  };
};

The important idea is:

The business logic shouldn't depend heavily on Express.

Step 3: Add API Gateway

The next layer is API Gateway.

The request flow becomes:

Client
   ↓
API Gateway
   ↓
Lambda
   ↓
Business Logic
   ↓
MongoDB

API Gateway becomes responsible for receiving the HTTP request and invoking the Lambda function.

Depending on the architecture, authentication and authorization can also be handled through appropriate API Gateway/Lambda mechanisms.

What can break?

This is where serverless migrations become interesting.

Problem 1: Database connections

This is one of the first things I'd investigate.

With an Express application on EC2, the Node.js process stays alive.

A MongoDB connection can remain available between requests.

Lambda works differently.

A Lambda execution environment can be created, reused, or terminated.

If every invocation creates a new database connection, a high number of requests can create unnecessary connection pressure.

A naive pattern might look like:

export const handler = async (event) => {
  const db = await mongoose.connect(process.env.MONGODB_URI);

  // process request
};

Doing this without considering connection reuse can become problematic.

A better pattern is to cache the connection/promise at the module level so that warm Lambda environments can reuse it.

The important lesson is:

Don't treat Lambda like a traditional always-running Express server.

Problem 2: Cold starts

Another difference is cold-start latency.

When AWS needs a new execution environment, Lambda has to initialize the runtime and application code.

That can add latency to some requests.

The simplified flow is:

Request
   ↓
New Lambda environment
   ↓
Initialize runtime
   ↓
Load application
   ↓
Connect / initialize dependencies
   ↓
Execute handler

A warm invocation can be much simpler:

Request
   ↓
Existing environment
   ↓
Execute handler

This means application startup time matters.

Large dependency trees and heavy initialization can make cold starts worse.

Problem 3: Environment variables

A traditional application may have environment configuration such as:

MONGODB_URI
JWT_SECRET
API_KEY
NODE_ENV

When moving the endpoint to Lambda, those configuration values need to be available to the function.

I would avoid putting sensitive values directly into source code.

The deployment architecture should separate:

Code
+
Configuration
+
Secrets

This becomes especially important when the same function has different configurations for development, staging, and production.

Problem 4: Express assumptions

A monolithic Express application has access to things such as:

req
res
middleware
next()

Lambda doesn't naturally work with that same request lifecycle.

Instead, the handler receives an event:

export const handler = async (event) => {
  // event
};

That means Express middleware cannot always be moved directly without modification.

Authentication, validation, error handling, and request parsing may need to be adapted.

This is one reason I would avoid simply copying an Express controller into Lambda and expecting everything to work.

Problem 5: Logging changes

With an EC2-based application, I might inspect application logs using tools such as PM2:

pm2 logs

With Lambda, logging is centered around CloudWatch Logs.

For example:

console.log("Processing order", orderId);

can be captured by CloudWatch.

This changes the operational workflow.

Instead of thinking:

SSH → server → PM2 logs

the workflow becomes more like:

Lambda
   ↓
CloudWatch Logs
   ↓
Metrics / Logs / Alarms

For a production migration, I'd make sure observability is ready before moving traffic.

How I would reduce migration risk

I wouldn't immediately switch 100% of production traffic.

A safer approach is:

Existing Endpoint
       │
       ├────────→ EC2 / Express
       │
       └────────→ Lambda

Depending on the routing strategy, traffic can be moved gradually.

The migration should have a clear rollback path.

If Lambda introduces unexpected latency or errors, the original endpoint should remain available until confidence is established.

Testing before production

Before migrating traffic, I'd test more than just whether the Lambda returns HTTP 200.

I'd test:

[ ] Authentication
[ ] Validation
[ ] Database operations
[ ] Error handling
[ ] External API calls
[ ] Environment variables
[ ] Cold-start behavior
[ ] Concurrent requests
[ ] Database connection behavior
[ ] Response latency

I'd also test the endpoint using realistic payload sizes and data volumes.

A function that works perfectly with one request isn't necessarily ready for production.

Is Lambda always better?

No.

This is probably the most important lesson.

Lambda can be a great fit for certain workloads, but migrating an endpoint simply because:

"Serverless is modern"

isn't a good architectural reason.

A continuously running Express service may still be a better choice when:

The workload is consistently high
The application has long-running processes
The architecture is tightly coupled
Existing infrastructure is already efficient
The team benefits from the traditional server model

Lambda becomes more attractive when the workload is well suited to event-driven execution and we want AWS to handle more of the underlying infrastructure.

What I would measure

Before and after migration, I'd compare:

Metric	Before	After
Average latency	Measure	Measure
p95 latency	Measure	Measure
Error rate	Measure	Measure
Cold-start latency	N/A	Measure
Requests/sec	Measure	Measure
Database connections	Measure	Measure
Infrastructure overhead	Measure	Measure

The point isn't to prove Lambda is better.

The point is to determine whether this particular endpoint benefits from the migration.

Was it worth it?

For me, the answer would depend entirely on the measurements.

If the migration provides:

Better scalability
Lower operational overhead
Appropriate latency
Reliable database behavior
Reasonable cost

then it can be a good architectural decision.

But if the endpoint becomes significantly more complicated without providing meaningful benefits, keeping it on the existing infrastructure may be the better decision.

Final takeaway

The biggest lesson I take from a Lambda migration is:

Moving code to Lambda isn't the same as designing for serverless.

A successful migration requires thinking about:

Runtime
Database connections
Cold starts
Configuration
Authentication
Observability
Scaling
Failure handling

The best approach isn't to rewrite everything at once.

Start with one suitable endpoint.

Measure its behavior.

Learn from the migration.

Then decide whether the pattern makes sense for the rest of the system.

Good architecture isn't about moving everything to the newest technology.

It's about choosing the right architecture for the workload.

IAM Permissions I Got Wrong (And What I Learned)

Sahinur — Wed, 07 Oct 2026 18:00:00 +0000

IAM is one of those AWS services that looks simple at first.

Create a user or role, attach a policy, give it access, and move on.

Then one day you deploy an application and see:

AccessDenied

And suddenly you're asking:

Which permission is missing?

Working with AWS has taught me that IAM isn't just about making something work.

It's about giving the application exactly the permissions it needs—and nothing more.

Here are some of the lessons I've learned.

Mistake 1: Using `*` just to get it working

One of the easiest ways to solve an AWS permission problem is to make the policy extremely broad.

For example:

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

Technically, this can make many permission errors disappear.

But it creates a much bigger security problem.

The application now has permission to perform actions it may never need.

For example, if a backend only needs to upload objects to one S3 bucket, it shouldn't automatically have permission to:

Delete buckets
Create IAM users
Modify EC2 instances
Read unrelated databases
Access every S3 bucket

The better approach is to scope permissions to the actual requirement.

For example:

{
  "Effect": "Allow",
  "Action": [
    "s3:PutObject"
  ],
  "Resource": "arn:aws:s3:::my-app-uploads/*"
}

Now the role has a much smaller permission boundary.

The lesson is simple:

Don't use broad permissions as the permanent solution to a permission error.

Mistake 2: Confusing users and roles

Another important concept is understanding when to use an IAM user and when to use an IAM role.

For applications running on AWS, I prefer the application to assume a role rather than embedding long-term AWS credentials inside the application.

For example:

EC2
  ↓
IAM Role
  ↓
AWS Services

Instead of:

EC2
  ↓
AWS Access Key
  ↓
AWS Services

The role-based approach allows AWS services to obtain temporary credentials without storing permanent access keys in the application.

This is especially important for workloads running on services such as EC2, Lambda, and ECS.

Mistake 3: Giving the wrong resource access

Another common IAM problem is getting the action right but the resource wrong.

For example, you may allow:

"Action": "s3:GetObject"

but the resource doesn't match the actual object ARN.

A policy can look correct at first glance while still producing:

AccessDenied

That's why debugging IAM requires checking both:

Action
+
Resource

For S3, for example, bucket-level and object-level ARNs can be different depending on the operation.

Mistake 4: Forgetting that permissions can come from multiple places

IAM authorization isn't always as simple as looking at one policy.

When debugging access, I consider:

Identity-based policies
        +
Resource-based policies
        +
Permissions boundaries
        +
Session policies
        +
Service control policies
        +
Resource configuration

This is one reason IAM errors can sometimes be confusing.

You might add an Allow policy and still receive AccessDenied.

An explicit Deny somewhere else can override an Allow.

So my debugging process starts with understanding where the permission decision is actually coming from.

How I approach an AccessDenied error

When an AWS operation fails, I don't immediately start adding more permissions.

I first identify:

1. Who is making the request?

Is it:

IAM User?
IAM Role?
EC2 Instance Role?
Lambda Execution Role?
ECS Task Role?

2. What action is being attempted?

For example:

s3:GetObject
s3:PutObject
dynamodb:GetItem
secretsmanager:GetSecretValue

3. Which resource is being accessed?

For example:

S3 bucket/object
DynamoDB table
Secrets Manager secret

4. Which policy should allow the operation?

Then I check the relevant policy instead of randomly adding permissions.

This makes debugging much more systematic.

Least privilege

The principle I try to follow is:

Give the application the minimum permissions required to perform its job.

Imagine an API that only needs to upload user profile images.

Instead of:

S3: *

I'd want something closer to:

s3:PutObject
       ↓
specific bucket
       ↓
specific path

The same principle applies to other AWS services.

Instead of:

DynamoDB: *

use the specific actions required by the application.

Instead of:

Secrets Manager: *

allow access only to the secrets the application actually needs.

This reduces the potential impact if credentials or an application component are compromised.

Tools that help

AWS provides several tools that make IAM troubleshooting easier.

IAM Policy Simulator

The IAM Policy Simulator can help test whether a policy allows or denies specific actions.

Instead of repeatedly deploying an application just to test permissions, you can reason about the policy directly.

IAM Access Analyzer

Access Analyzer can help identify overly broad access and unintended external access.

It's particularly useful when reviewing policies and trying to move toward least-privilege permissions.

CloudTrail

When debugging AWS activity, CloudTrail can provide valuable information about API calls.

It helps answer questions such as:

Who made the request?

What AWS API was called?

When did it happen?

What resource was involved?

That context can make an IAM problem much easier to understand.

A better IAM workflow

My preferred workflow looks like this:

Application needs AWS access
          ↓
Identify exact AWS action
          ↓
Identify exact resource
          ↓
Create minimum required policy
          ↓
Test
          ↓
Review permissions
          ↓
Monitor

Not:

AccessDenied
    ↓
Add AdministratorAccess
    ↓
Problem solved

The second approach may be faster for five minutes, but it's much harder to defend from a security perspective.

IAM checklist

Before considering an application role ready for production, I'd ask:

[ ] Does the application use an IAM role where appropriate?
[ ] Are long-term credentials avoided?
[ ] Are permissions limited to required actions?
[ ] Are resources scoped as narrowly as practical?
[ ] Have wildcard permissions been reviewed?
[ ] Have explicit denies been considered?
[ ] Have IAM Access Analyzer findings been reviewed?
[ ] Have policies been tested?
[ ] Are production and development permissions separated?
[ ] Are unused permissions removed?

What I learned

The biggest lesson is that IAM isn't something you should solve by trial and error forever.

When I see:

AccessDenied

I now try to understand the authorization path instead of immediately adding another policy.

The question isn't:

"How can I give this application more access?"

It's:

"What is the smallest amount of access this application actually needs?"

That mindset changes the way you design AWS infrastructure.

Final takeaway

IAM can feel frustrating when you're starting with AWS.

But once you stop treating permissions as random configuration and start thinking in terms of:

Principal
   ↓
Action
   ↓
Resource
   ↓
Policy
   ↓
Authorization

the system becomes much easier to reason about.

And one of the most important AWS security habits I've learned is:

Make it work with the minimum permissions—not maximum permissions.

Setting Up CI/CD for a Node.js Backend with GitHub Actions and AWS

Sahinur — Wed, 30 Sep 2026 18:00:00 +0000

Deploying a backend manually works when a project is small.

SSH into the server, pull the latest code, install dependencies, restart the application, and check whether everything is working.

But as the application and team grow, this process becomes repetitive—and manual steps are easy to get wrong.

That's where CI/CD becomes useful.

In this post, I'll walk through a practical CI/CD approach for a Node.js + Express backend deployed on AWS EC2 using GitHub Actions.

Before: How we deployed

A simple manual deployment can look like this:

Developer
   ↓
Git Push
   ↓
GitHub
   ↓
SSH into EC2
   ↓
git pull
   ↓
npm install
   ↓
PM2 restart

It works.

But every deployment depends on someone remembering the correct sequence of commands.

A small mistake can cause problems:

Forgetting to pull the latest code
Installing dependencies incorrectly
Restarting the wrong process
Deploying from the wrong branch
Forgetting an environment variable
Restarting the application before checking the build

The goal of CI/CD is to make this process more predictable.

The pipeline I want

For a Node.js backend, a simple pipeline can look like:

Developer
    ↓
GitHub
    ↓
GitHub Actions
    ↓
Install Dependencies
    ↓
Run Tests
    ↓
Build / Validate
    ↓
Deploy to AWS EC2
    ↓
Restart Application
    ↓
Health Check

The important idea is that a deployment should not simply mean:

"Push code → restart server."

It should mean:

"Push code → verify code → deploy → verify deployment."

Step 1: Create the workflow

GitHub Actions workflows live inside:

.github/
└── workflows/
    └── deploy.yml

A basic workflow can start like this:

name: Deploy Node.js API

on:
  push:
    branches:
      - main

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

Now every push to the main branch can automatically trigger the workflow.

Step 2: Validate before deploying

One of the most important principles I follow with CI/CD is:

Don't deploy code that hasn't passed basic checks.

For example:

- name: Run tests
  run: npm test

You can also include linting:

- name: Run lint
  run: npm run lint

And if the project has a build step:

- name: Build application
  run: npm run build

The exact commands depend on the project.

The important thing is that the deployment job should depend on these checks succeeding.

Step 3: Deploy to EC2

There are several ways to deploy an application to EC2.

A straightforward approach is to connect to the server and execute deployment commands.

Conceptually:

GitHub Actions
      ↓
SSH
      ↓
EC2
      ↓
Pull latest code
      ↓
Install dependencies
      ↓
Restart PM2

A deployment command might look like:

cd /var/www/my-api

git pull origin main

npm ci

pm2 restart my-api

The exact directory, process name, and deployment strategy depend on the application.

Step 4: Keep secrets out of Git

This is one of the most important parts of CI/CD.

I don't want credentials such as:

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
DATABASE_URL
JWT_SECRET

inside the repository.

Instead, sensitive values should be managed through appropriate secret-management mechanisms.

For GitHub Actions, repository or environment secrets can be used for CI/CD credentials.

For the application itself, production configuration should ideally be managed separately from source code.

The basic rule is:

Source code can be committed. Secrets should not be.

What broke the first time

CI/CD looks simple when drawn as a diagram.

Real deployments are rarely that simple.

Some common problems I watch for are:

1. Environment differences

The application works locally:

Local → Works

But production has:

Production → Missing environment variable

The code may be correct while the deployment configuration is not.

2. Node.js version mismatch

For example:

Local:
Node.js 20

CI:
Node.js 18

Production:
Node.js 20

This can create confusing build or dependency issues.

That's why I prefer explicitly defining the Node.js version in CI.

3. Dependency installation

Using:

npm install

can produce different dependency resolution behavior depending on the project state.

For CI environments, I generally prefer:

npm ci

when a valid package-lock.json is available.

4. Restarting the wrong process

With PM2, the deployment isn't finished just because the new code reached the server.

The correct application process needs to be restarted or reloaded.

After deployment, I want to verify:

pm2 status

and inspect logs when necessary:

pm2 logs

Health checks matter

A successful deployment command doesn't necessarily mean a successful deployment.

For example:

git pull       ✓
npm ci         ✓
pm2 restart    ✓

The application could still be returning:

HTTP 500

That's why a health check is useful.

For example:

curl -f https://api.example.com/health

If the health endpoint fails, the deployment should be treated as unsuccessful.

This gives the pipeline a much better definition of "success."

Rollback strategy

One of the biggest things I want from a deployment system is a safe way to recover.

A simple rollback strategy can be based on Git commits.

For example:

Version A
   ↓
Deploy
   ↓
Version B
   ↓
Problem detected
   ↓
Rollback
   ↓
Version A

Before making the deployment more advanced, I want to make sure the team knows:

What version is currently running?
What changed?
How do we return to the previous version?
How do we verify the rollback?

For larger systems, more advanced strategies such as blue/green or canary deployments can provide safer releases.

What a mature pipeline looks like

Eventually, the workflow can become:

              ┌──────────────┐
              │   Developer  │
              └──────┬───────┘
                     │
                     ▼
                ┌─────────┐
                │ GitHub  │
                └────┬────┘
                     │
                     ▼
             ┌───────────────┐
             │ GitHub Actions│
             └───────┬───────┘
                     │
          ┌──────────┴──────────┐
          ▼                     ▼
     Install/Test            Lint/Build
          │                     │
          └──────────┬──────────┘
                     ▼
                  Deploy
                     │
                     ▼
                  AWS EC2
                     │
                     ▼
               Health Check
                     │
              ┌──────┴──────┐
              ▼             ▼
           Success        Failure
              │             │
              ▼             ▼
          Complete       Rollback

The goal isn't to create the most complicated pipeline possible.

It's to remove unnecessary manual work while making deployments safer.

What I learned

The biggest lesson for me is that CI/CD isn't just automation.

It's about creating a repeatable engineering process.

A good pipeline should answer:

Has the code been tested?
Can it be deployed safely?
What version was deployed?
Did the deployment actually work?
Can we recover if something goes wrong?

Even a relatively simple Node.js backend can benefit from this mindset.

Final takeaway

Manual deployment isn't necessarily bad.

It's just difficult to scale.

As projects grow, automation becomes valuable because it reduces repetitive work and makes the deployment process predictable.

For a Node.js + Express backend on AWS EC2, a simple GitHub Actions pipeline can provide a solid starting point:

Code
 ↓
Test
 ↓
Build
 ↓
Deploy
 ↓
Health Check

From there, the pipeline can evolve with the application.

The goal of CI/CD isn't to deploy faster at any cost.

It's to deploy more consistently, more safely, and with greater confidence.

How I Approach AWS Cost Optimization as a Backend Developer

Sahinur — Tue, 29 Sep 2026 18:00:00 +0000

AWS makes it very easy to deploy an application.

You can launch an EC2 instance, connect your backend, configure a database, add storage, and have a production system running relatively quickly.

But there's another side of cloud infrastructure that becomes important as an application grows:

How much is it actually costing?

As a backend developer, I've learned that AWS cost optimization isn't about simply choosing the cheapest service.

It's about understanding what you're running, why you're running it, and whether you're actually using the resources you're paying for.

Here are some of the things I look at when thinking about AWS costs.

Starting point

For a typical Node.js backend running on AWS, the infrastructure might look something like:

Client
   ↓
Nginx
   ↓
EC2
   ↓
Node.js + Express
   ↓
MongoDB

Additional services:
- S3
- CloudWatch
- Load Balancer
- Data Transfer

Each service can contribute to the overall infrastructure cost.

The important thing is that the bill isn't always dominated by the service you expect.

Sometimes a small collection of unused resources can quietly generate costs over time.

That's why I prefer to start with visibility before optimization.

Change 1: Right-size compute resources

One of the first things I look at is whether the EC2 instance is appropriately sized for the workload.

It's tempting to choose a larger instance because:

"More CPU and RAM means better performance."

But if the application consistently uses only a fraction of those resources, we're paying for capacity we're not using.

I look at metrics such as:

CPU utilization
Memory usage
Network traffic
Request patterns
Application workload

The goal isn't:

Use the smallest server possible.

The goal is:

Use the right server for the workload.

For example, if an application consistently operates far below the capacity of its instance, moving to an appropriately sized instance can reduce unnecessary infrastructure cost.

But this needs to be done carefully.

Reducing resources too aggressively can create performance and reliability problems.

Change 2: Review storage usage

Storage is another area I pay attention to.

For applications using Amazon S3, not every object necessarily needs to remain in the same storage class forever.

For example:

New data
   ↓
Frequently accessed
   ↓
Less frequently accessed
   ↓
Archive

This is where lifecycle policies can become useful.

Instead of manually moving old data, lifecycle rules can automatically transition objects according to the application's requirements.

The important question is:

Does this data still need the same level of accessibility as when it was created?

If not, there may be an opportunity to optimize storage costs.

Change 3: Remove unused resources

This is one of the simplest optimization opportunities.

Cloud infrastructure can accumulate resources that were created for testing, debugging, or previous versions of an application.

For example:

Unused EC2 instances
Old EBS volumes
Old snapshots
Unused load balancers
Unused Elastic IPs
Old test resources

A resource that isn't being used can still cost money.

This is why I think regular infrastructure cleanup is important.

Before deleting anything, I verify that the resource isn't required by another application or recovery process.

Change 4: Understand traffic and data transfer

Another area that can be overlooked is data transfer.

An application might have perfectly reasonable compute costs but generate unexpected costs through network traffic.

For example:

Client
  ↓
Application
  ↓
Database
  ↓
Storage

When data moves between different services, regions, or external systems, the traffic pattern can affect the overall cost.

So when investigating AWS costs, I don't look only at CPU and memory.

I also consider:

Request volume
Network traffic
Data transfer
Storage growth
External API usage

The tools I use to think about cost

AWS provides several tools that can help with cost visibility and optimization.

AWS Cost Explorer

Cost Explorer helps break down AWS spending and identify where costs are coming from.

Instead of looking only at the total bill, I want to answer questions such as:

Which service costs the most?

Which resource changed recently?

Is the cost increasing?

What caused the increase?

That makes the bill much more useful as an engineering signal.

AWS Budgets

Budgets can help establish spending thresholds and alerts.

For example:

Monthly budget
      ↓
Usage tracking
      ↓
Threshold reached
      ↓
Alert

This is especially useful for projects where unexpected resource usage could result in an unexpected bill.

AWS Compute Optimizer

For compute resources, AWS Compute Optimizer can provide recommendations based on observed workload patterns.

This is useful because infrastructure decisions shouldn't be based entirely on assumptions.

Actual usage data is much more valuable.

What I learned

One of the biggest lessons for me is that cost optimization is an engineering responsibility, not only a finance responsibility.

Every architecture decision can have a cost implication.

For example:

More instances
      ↓
Higher compute cost

More storage
      ↓
Higher storage cost

More traffic
      ↓
Potentially higher transfer cost

More logging
      ↓
Potentially higher observability cost

This doesn't mean we should avoid using AWS services.

It means we should understand the trade-offs.

Cost optimization vs performance

There is also an important balance.

You shouldn't optimize cost by making the application unreliable.

For example, reducing an EC2 instance from a large size to a tiny instance might save money, but if the application starts running out of memory under production traffic, the optimization wasn't successful.

The same applies to databases, storage, networking, and monitoring.

A better principle is:

Optimize unnecessary cost, not necessary capacity.

A simple checklist I follow

Before considering an AWS environment optimized, I'd ask:

[ ] Are compute resources appropriately sized?
[ ] Are unused resources removed?
[ ] Are storage lifecycle policies being used where appropriate?
[ ] Are unexpected traffic costs understood?
[ ] Are AWS costs being monitored regularly?
[ ] Are spending alerts configured?
[ ] Are production resources separated from temporary resources?
[ ] Are optimization decisions based on actual usage?

This doesn't need to be a complicated process.

Even a regular review can reveal resources that are no longer necessary.

Final takeaway

AWS cost optimization isn't about making everything as cheap as possible.

It's about making sure the infrastructure you're paying for is actually providing value.

As a backend developer, I now try to think about three things together:

Performance + Reliability + Cost

A good cloud architecture should balance all three.

The cheapest architecture isn't necessarily the best architecture.

The best architecture is the one that provides the required performance and reliability without paying for unnecessary capacity.

RDS vs DynamoDB: How I Think About Choosing an AWS Database

Sahinur — Thu, 17 Sep 2026 18:00:00 +0000

Choosing a database is one of those decisions that can look simple at the beginning of a project.

You need to store some data, so you pick a database and start building.

But once you start thinking about scale, queries, cost, performance, and maintenance, the decision becomes much more interesting.

As a Node.js backend developer, I've mostly worked with MongoDB, but while learning and working with AWS, I've spent more time understanding how AWS database services such as Amazon RDS and Amazon DynamoDB fit into backend architectures.

They solve very different problems.

Here's how I approach the decision.

The data shape comes first

Before choosing a database, I think about the data and, more importantly, how the application will access that data.

For example, imagine an e-commerce application.

We might have:

Users
Products
Orders
Payments
Reviews

An order might contain relationships between multiple entities:

User
  ↓
Orders
  ↓
Products
  ↓
Payments

If the application requires complex relationships, joins, transactions, and flexible SQL queries, a relational database becomes very attractive.

That's where RDS can make sense.

But not every application needs that model.

Imagine an application where the primary access pattern is:

Get user by ID
Get user's notifications
Get latest notifications
Mark notification as read

If these access patterns are predictable and the application needs massive scalability, DynamoDB becomes an interesting option.

The key lesson is:

Don't start with the database. Start with the data and access patterns.

What pulls me toward RDS

Amazon RDS provides managed relational databases such as:

PostgreSQL
MySQL
MariaDB
Oracle
SQL Server

One of the biggest advantages is the relational model.

For applications with relationships between entities, SQL can make the data model and queries much easier to reason about.

For example:

SELECT
    users.name,
    orders.id,
    orders.total
FROM users
JOIN orders
    ON users.id = orders.user_id
WHERE users.id = 1001;

This type of relationship-oriented query is natural in a relational database.

RDS is particularly attractive when I need:

Complex queries
Relationships
Joins
Transactions
SQL
Reporting
Existing relational database expertise

Another advantage is that many backend developers already understand SQL and relational database design.

That can significantly reduce the learning curve.

What pulls me toward DynamoDB

DynamoDB is fundamentally different.

Instead of starting with relationships and joins, I think about access patterns.

For example:

GetUserById
GetOrdersByUser
GetLatestOrders
GetOrderById

The table and indexes are designed around how the application will query the data.

This approach can be extremely powerful for applications that need:

High scalability
Low-latency access
Predictable access patterns
Serverless architectures
High request volumes
Automatic scaling

DynamoDB also removes much of the traditional database server management.

That makes it particularly interesting when building serverless applications with services such as Lambda and API Gateway.

The architectural difference

A traditional RDS-based backend might look like:

Client
   ↓
API
   ↓
Node.js / Express
   ↓
Amazon RDS

The application connects to a relational database and performs SQL queries.

A serverless architecture could look like:

Client
   ↓
API Gateway
   ↓
Lambda
   ↓
DynamoDB

Here, the database fits naturally into an event-driven or serverless architecture.

Neither architecture is automatically better.

The workload determines which one makes more sense.

What about MongoDB?

This is especially relevant to me because my backend experience includes MongoDB.

MongoDB uses a document-oriented model:

{
  name: "Sahinur",
  email: "user@example.com",
  skills: [
    "Node.js",
    "Express",
    "MongoDB"
  ]
}

This can be very convenient for applications where the data naturally fits into documents.

It also feels familiar when working with JavaScript and Node.js.

That experience made me realize something important:

Database choice isn't only about technical specifications.

Developer experience, existing knowledge, application requirements, and team expertise all matter.

How I would make the decision

If I were starting a new AWS backend, I'd ask these questions first.

1. Do I need complex relationships?

If the application heavily depends on relationships and joins, I'd lean toward a relational database such as RDS.

2. Are my access patterns predictable?

If I know exactly how the application will read and write data and need highly scalable low-latency access, DynamoDB becomes more attractive.

3. Do I need SQL?

If the team relies heavily on SQL queries, reporting, and relational data analysis, RDS is likely the easier choice.

4. Is the application serverless?

If I'm building around Lambda and API Gateway, DynamoDB can fit naturally into that architecture.

5. What does the team already know?

A technically powerful database isn't useful if the team doesn't understand how to model and operate it effectively.

A simple comparison

Factor	RDS	DynamoDB
Database model	Relational	NoSQL
Query model	SQL	Key/index based
Joins	Yes	No traditional joins
Transactions	Strong relational transactions	Supported, but different model
Scaling	Managed, but capacity planning still matters	Designed for large-scale automatic scaling
Schema	Structured	Flexible
Best fit	Relational applications	High-scale access-pattern-driven workloads
Serverless fit	Possible	Excellent

The biggest lesson

The biggest lesson I've learned while studying different database architectures is:

Don't choose a database because it's popular. Choose it because its data model matches your application.

A database can be extremely fast and scalable but still be the wrong choice if your application's access patterns don't fit it.

Similarly, choosing a relational database when your application has simple key-value access patterns can introduce unnecessary complexity.

What I'd do before committing

Before choosing a database, I'd write down the application's most important operations:

1. Create user
2. Get user by ID
3. Get user's orders
4. Create order
5. Update order
6. Get latest orders
7. Generate reports

Then I'd evaluate how naturally each database handles those operations.

This exercise can reveal more than a generic database comparison ever will.

Final takeaway

For me, the RDS vs DynamoDB discussion isn't really about which service is better.

It's about matching the database model to the application.

If I need relational data, SQL, joins, and complex queries, RDS is a strong candidate.

If I have predictable access patterns and need highly scalable, low-latency NoSQL access, DynamoDB is worth serious consideration.

And my experience with MongoDB has reinforced the same principle:

The right database is the one that makes your application's most important operations simple, reliable, and scalable.

That's the way I now approach database decisions when designing backend systems on AWS.

How I Would Structure a Node.js Backend on AWS: EC2 vs Lambda

Sahinur — Thu, 10 Sep 2026 18:00:00 +0000

When building a backend on AWS, one of the first decisions is not which framework to use.

It's where and how the backend should run.

As a Node.js developer, I've worked with Express-based APIs and AWS EC2, and one question that keeps coming up is:

Should I run my backend on a traditional server, or move toward a serverless architecture such as API Gateway + Lambda?

There isn't one answer for every application.

The right choice depends on traffic, workload, architecture, team experience, and operational requirements.

Here's how I think about the decision.

The requirement

For a typical Node.js backend, I usually need:

REST APIs
Authentication and authorization
MongoDB or another database
File uploads
Background processing
Logging and monitoring
Reliable deployment
The ability to handle changing traffic

A simple backend might look like:

Client
   ↓
Node.js + Express API
   ↓
MongoDB

When deploying this to AWS, there are several ways to run it.

Options I considered

Option A: EC2 + Node.js + Express

This is the traditional approach.

Client
   ↓
Nginx
   ↓
AWS EC2
   ↓
Node.js + Express
   ↓
MongoDB

The biggest advantage is control.

I can manage:

The operating system
Node.js process
PM2
Nginx
Networking
Installed dependencies
Background processes

It's also a straightforward model for developers who already understand traditional server deployment.

But that control also creates more responsibility.

I need to think about:

Server maintenance
Scaling
Memory usage
Process management
Security updates
Monitoring
High availability

I've seen this firsthand with production Node.js applications: the application itself may be working correctly, but server resources such as memory can become a problem under real traffic.

Option B: API Gateway + Lambda

The serverless approach changes the architecture:

Client
   ↓
API Gateway
   ↓
Lambda
   ↓
Database

Instead of keeping a Node.js server running continuously, individual Lambda functions execute in response to requests.

This can reduce the amount of server infrastructure I need to manage.

It can also make automatic scaling much easier for workloads that aren't constantly running at high utilization.

But serverless introduces its own considerations.

For example:

Cold starts
Execution limits
Function design
Database connection management
Logging
Local development
Vendor-specific architecture

So serverless isn't automatically "better."

Option C: ECS / Fargate

Another option is containerizing the Node.js application:

Client
   ↓
Load Balancer
   ↓
ECS / Fargate
   ↓
Node.js + Express
   ↓
MongoDB

This gives me many of the benefits of containers without requiring me to manage the underlying EC2 instances directly.

For larger applications or teams already using Docker, this can be a very attractive middle ground.

The architecture I'd choose

For a small-to-medium Node.js API with predictable traffic, EC2 can still be a practical choice.

A basic architecture could be:

                 ┌──────────────┐
                 │    Client    │
                 └──────┬───────┘
                        │
                        ▼
                 ┌──────────────┐
                 │    Nginx     │
                 └──────┬───────┘
                        │
                        ▼
              ┌──────────────────┐
              │     AWS EC2      │
              │                  │
              │ Node.js +        │
              │ Express + PM2    │
              └────────┬─────────┘
                       │
                       ▼
                 ┌──────────────┐
                 │   MongoDB    │
                 └──────────────┘

This architecture is simple, familiar, and gives me direct control over the application environment.

But I wouldn't automatically use it for every new project.

If the application has highly variable traffic, independent functions, or a strong serverless requirement, I'd seriously consider API Gateway + Lambda.

The trade-offs

The interesting part isn't choosing the "most modern" AWS service.

It's understanding what you're giving up and what you're gaining.

Factor	EC2	Lambda
Server management	Higher	Lower
Scaling	Requires configuration	Automatic
Long-running processes	Good	Limited
Cold starts	No	Possible
Infrastructure control	High	Lower
Deployment model	Server/application	Function-based
Operational complexity	Higher	Different, not zero
Best fit	Persistent services	Event/API-driven workloads

This is why I don't think "serverless means no problems."

It means you're moving some operational responsibilities away from servers and taking on a different set of architectural considerations.

A lesson from production

One thing that changed how I think about architecture is realizing that application behavior matters just as much as infrastructure choice.

For example, a Node.js API can run perfectly on a powerful EC2 instance and still have problems if an endpoint loads thousands of MongoDB documents into memory.

Likewise, moving that endpoint to Lambda wouldn't automatically fix inefficient data processing.

The architecture can help, but good application design still matters.

What I'd change next time

If I were starting a new AWS backend today, I'd make the architecture decision based on the workload instead of choosing a service simply because it's popular.

I'd ask:

How predictable is the traffic?
Does the application need long-running processes?
How much infrastructure do we want to manage?
What are the database access patterns?
How important is automatic scaling?
What are the latency requirements?
Does the team already have experience with containers or serverless?

Only after answering those questions would I choose between EC2, ECS/Fargate, and Lambda.

Final takeaway

There is no single AWS architecture that is perfect for every Node.js application.

EC2, ECS/Fargate, and Lambda solve different problems.

For me, the important lesson is to start with the application's requirements and workload, then choose the AWS service that fits.

The goal isn't to use the most services.

The goal is to build a system that is reliable, maintainable, scalable, and appropriate for the actual workload.

And that's one of the things I'm continuing to learn as I work deeper with AWS and backend engineering.

A Node.js Backend Memory Issue That Only Showed Up in Production

Sahinur — Wed, 02 Sep 2026 04:27:15 +0000

One of the most frustrating backend problems is an issue that works perfectly in development and staging, but starts failing when real production traffic arrives.

I recently worked with a Node.js + Express + MongoDB backend running on an AWS EC2 instance, where we started seeing unexpected memory usage in production.

The application was working normally at first. Then, as traffic increased, the server's memory usage kept climbing until the Node.js process eventually crashed.

Here's how I approached the problem.

The setup

The backend was built with:

Node.js
Express.js
MongoDB
AWS EC2
PM2 for process management

The basic architecture looked like this:

Client
   ↓
Nginx
   ↓
Node.js + Express
   ↓
MongoDB

The application handled API requests normally during development and staging.

The EC2 instance also had enough resources for the expected workload, so initially there was no obvious reason for the server to run out of memory.

What went wrong

After the application had been running under production traffic for some time, memory usage started increasing.

We noticed the EC2 instance's memory utilization gradually climbing instead of returning to its normal level after requests were completed.

Eventually, the Node.js process became unstable and crashed.

A representative error looked like this:

<--- Last few GCs --->

FATAL ERROR: Reached heap limit
Allocation failed - JavaScript heap out of memory

Node.js v20.x

At first, increasing the server resources seemed like the easiest solution.

But that would only hide the actual problem.

The important question was:

Why was the application continuously consuming more memory?

Why staging didn't catch it

This was one of the interesting parts of the problem.

The application worked correctly in staging because the environment was significantly different from production.

The main differences were:

Lower traffic
Fewer concurrent requests
Smaller datasets
Shorter test duration
Less realistic production usage patterns

A memory problem doesn't necessarily appear immediately.

An application can use a little more memory after every request without causing any visible problem during a short test.

For example:

Request 1  →  500 MB
Request 100 → 550 MB
Request 1,000 → 700 MB
Request 10,000 → 1.2 GB

Eventually, the server reaches its available memory limit.

This made the problem difficult to reproduce in staging.

How I investigated the problem

The first thing I did was check the EC2 instance's resource usage.

I used system-level monitoring to check memory consumption:

free -h

I also checked running processes:

top

and inspected the Node.js process managed by PM2:

pm2 status
pm2 monit

The important observation was that CPU usage wasn't consistently high.

Memory usage, however, continued increasing.

That changed the direction of the investigation.

Instead of asking:

"Why is the API slow?"

I started asking:

"What is keeping objects in memory longer than expected?"

Looking at the application

I started reviewing endpoints that processed large amounts of data.

One suspicious pattern was fetching a large dataset from MongoDB and keeping the entire result in memory before processing it.

For example:

const users = await User.find({
  status: "active"
});

const result = users.map(user => {
  // process user
});

return res.json(result);

This can become expensive when the collection grows.

If MongoDB returns thousands or tens of thousands of documents, Node.js has to hold those JavaScript objects in memory.

The problem becomes worse if multiple requests are doing the same thing concurrently.

The fix

The first improvement was to avoid loading unnecessary records into memory.

Instead of retrieving everything, we introduced pagination:

const page = Number(req.query.page) || 1;
const limit = 50;

const users = await User.find({
  status: "active"
})
  .skip((page - 1) * limit)
  .limit(limit)
  .lean();

Now the application only processes a limited number of documents per request.

We also reviewed queries to make sure we weren't returning fields that the API didn't actually need.

For example:

const users = await User.find({
  status: "active"
})
  .select("name email status")
  .limit(50)
  .lean();

This reduced unnecessary data being loaded into the Node.js process.

Monitoring after the fix

After making the changes, I continued monitoring the application rather than assuming the problem was solved.

The important thing was to observe memory usage over a longer period under realistic traffic.

The expected pattern was:

Memory
  │
  │       ╭──╮      ╭──╮
  │    ╭──╯  ╰──╮ ╭─╯  ╰──
  │────╯────────╰─╯──────────
  │
  └────────────────────────── Time

Instead of continuously climbing, memory usage should stabilize within a reasonable range.

I also kept PM2 monitoring in place so that unexpected process behavior could be detected quickly.

What I learned

This incident taught me an important lesson:

A backend can work perfectly in development and still have serious resource problems in production.

For Node.js applications, I now pay much more attention to:

Large MongoDB queries
Pagination
Selecting only required fields
Processing large datasets
Concurrent requests
Memory usage over time
Production-like load testing

I also learned that simply increasing the EC2 instance size isn't always the correct solution.

More RAM can postpone the crash, but it doesn't necessarily fix the underlying problem.

What I'd do differently

If I were setting up the same system again, I'd introduce memory monitoring and load testing much earlier.

I'd also test endpoints with production-sized datasets instead of relying only on small staging datasets.

The biggest takeaway for me was simple:

Don't just test whether your API works. Test how it behaves after running for a long time under realistic load.

That's where some of the most interesting backend problems reveal themselves.

Book Review: "Software Development From A to Z" — The Book I Wish I'd Read Before My First Dev Job

Sahinur — Thu, 20 Aug 2026 09:27:19 +0000

Most programming books teach you one thing deeply: a language, a framework, a database. Very few explain how all of those things fit together inside an actual team, or why the product manager keeps asking you for estimates, or what the designer is doing for three weeks before you get a single mockup.

Software Development From A to Z by Olga Filipova and Rui Vilão (Apress, 2018) tries to fill exactly that gap. I finished it recently, and here's my take.

What the book is about

The premise is simple: follow one small team building one product, an online learning platform, from "hey, I have an idea" all the way to maintaining it in production. Each chapter is narrated from the seat of a different role:

Having an idea (and turning it into an MVP)
Roles, responsibilities, Scrum and Kanban
The product manager: requirements and deadlines
The designer: user-centered design
The backend engineer
The frontend engineer
The QA engineer
DevOps: going live
Maintaining and improving what you shipped

It's around 300 pages, and it moves fast.

What I liked

The running example actually runs. A lot of "big picture" books stay abstract. This one doesn't. You watch the requirements table get written, the personas get invented, the Spring Boot backend get scaffolded, the Vue/Nuxt frontend get wired up, and the whole thing get deployed to Heroku through Travis CI. Seeing the same feature (user registration, for example) pass through the hands of five different roles is the single most valuable thing in the book.

It's honest about messy reality. There's a whole section admitting that role titles mean different things at different companies and that it's normal to be confused. The Scrum-vs-Kanban comparison doesn't pick a winner; it rates each on a strictness scale and then shows the hybrid the authors actually use. That felt refreshingly practical.

The interviews. Several chapters include short interviews with a real product manager, designer, and DevOps engineer. The "biggest screw-up / biggest success" questions in particular give the book a human texture that pure tutorials lack.

The MVP chapter. If you've never internalized the difference between delivering a wheel and delivering a skateboard, chapter 1 will fix that. It's the clearest explanation of "minimum viable" I've read in a book aimed at developers.

What I didn't love

Depth is uneven. The backend and frontend chapters go fairly deep into code, while the DevOps chapter stays more conceptual. If you're reading for the technical content, you'll find the engineering chapters meatier than the rest. If you're reading for the big picture, the code may feel like a detour.

The stack is dated. Java/Spring Boot and Vue 2 with Nuxt are still perfectly reasonable choices, but Travis CI and Heroku's free tier are not what they were in 2018. Read the tooling chapters for the ideas (CI on every push, automated deploys from the main branch, platform-as-a-service tradeoffs), not the specific buttons to click.

It's an overview, by design. No chapter will make you a designer or a DevOps engineer. That's fine, but set expectations accordingly: this is the map, not the territory.

Who should read it

Bootcamp grads and juniors about to join their first team. This will decode half the meetings you'll sit in.
Career changers (QA, support, design, product) who want to understand what engineers actually do all day.
Solo founders planning to build an MVP and wondering which hats they'll need to wear.
Experienced devs who want something to hand to non-technical colleagues. It's approachable without being condescending.

Skip it if you already have a few years on cross-functional teams; you'll nod along but learn little.

Verdict

4 / 5. Not a reference book, and not the place to learn any single technology. But as a guided tour through how software gets made, and especially through how the people who make it depend on each other, it's one of the better ones out there. I'd put it on the same shelf as The Phoenix Project, just less narrative and more hands-on.

Have you read it? What's your go-to "how teams actually work" book for new developers? Drop it in the comments.

Cloud Computing for Beginners: A Simple Guide for Students & New Developers ☁️

Sahinur — Mon, 12 Jan 2026 12:17:59 +0000

Cloud computing is no longer just a buzzword — it’s a core skill for modern developers. Whether you’re a student, a beginner, or someone curious about how applications scale globally, understanding cloud basics can open many doors.

In this article, I’ll explain cloud computing in simple terms, without heavy jargon, and help you take your first step into the cloud.

What Is Cloud Computing? (In Simple Words)

Cloud computing means using computing resources over the internet instead of your own computer or physical servers.

Instead of:

Buying servers
Maintaining hardware
Managing storage manually

You rent:

Servers
Storage
Databases
Networking

👉 All provided by cloud platforms like Microsoft Azure, AWS, and Google Cloud.

Think of the cloud like renting electricity instead of building your own power plant.

Why Should Beginners Learn Cloud Computing?

Here’s why cloud skills matter, even if you’re just starting:

🚀 High Industry Demand

Most modern applications — from startups to enterprises — run on cloud infrastructure.

💼 Career Opportunities

Cloud knowledge is useful for roles like:

Software Engineer
DevOps Engineer
Cloud Engineer

📈 Easy Scalability

Cloud platforms allow applications to scale from 10 users to millions without rebuilding everything.

Core Cloud Concepts You Should Know

1️⃣ Compute

Compute services run your applications and code.

Examples:

Azure Virtual Machines
Azure App Service

2️⃣ Storage

Storage services keep files, images, backups, and logs.

Examples:

Azure Blob Storage

3️⃣ Networking

Networking connects cloud resources securely.

Examples:

Virtual Networks
Load Balancers

4️⃣ Databases

Managed databases remove the pain of setup and maintenance.

Examples:

Azure SQL Database

Cloud Service Models Explained

Understanding these models is very important.

🧱 IaaS – Infrastructure as a Service

You manage:

Operating system
Application software

Cloud provider manages:

Physical hardware

Example:

Virtual Machines

🧩 PaaS – Platform as a Service

You focus on:

Writing code

Cloud provider manages:

Servers
OS
Scaling

Example:

Azure App Service

☁️ SaaS – Software as a Service

You simply use the software.

Examples:

Microsoft 365
Gmail

Why Microsoft Learn Is Perfect for Beginners

Learning cloud from documentation alone can be overwhelming.

That’s why Microsoft Learn is a great starting point:

✅ Free
✅ Beginner-friendly
✅ Hands-on learning
✅ No credit card required

You learn by doing, not just reading.

🔗 Start learning here:

https://learn.microsoft.com?wt.mc_id=studentamb_502522

A Simple Beginner Learning Path

If you’re starting today, follow this order:

Cloud fundamentals
Azure basics
Compute & storage concepts
Deploy a simple application

Consistency matters more than speed.

Final Thoughts

You don’t need to be an expert to start learning cloud computing.

All you need:

Curiosity
Consistency
The right learning resources

Every cloud expert was once a beginner.

Start small, stay consistent, and keep building ☁️🚀

About the Author

Sahinur Islam

Full-Stack Developer | Cloud & DevOps Enthusiast

Microsoft Learn Student Ambassador – Registered Member

When Should You Use AWS Lambda? A Beginner's Perspective

Sahinur — Sun, 11 Jan 2026 11:32:51 +0000

If you're new to cloud computing, you've probably heard the buzz around AWS Lambda and serverless architecture. But here's the million-dollar question: When should you actually use it?

In this article, I'll break down AWS Lambda in simple terms, explain when it's the perfect choice, and when you might want to look elsewhere. Let's dive in!

🤔 What is AWS Lambda, Anyway?

AWS Lambda is Amazon's serverless compute service. In simple terms:

You write code, upload it to Lambda, and AWS runs it for you — no servers to manage, no infrastructure to worry about.

Lambda only runs your code when something triggers it (like an API request, a file upload, or a database change). When there's nothing to do, Lambda sits idle — and you pay nothing.

Key characteristics:

Event-driven: Runs only when triggered
Auto-scaling: Handles 1 request or 10,000 automatically
Pay-per-use: Charged only for execution time (in milliseconds)
Zero server management: AWS handles everything

✅ When Should You Use AWS Lambda?

Here are the scenarios where Lambda truly shines:

1. API Backends & Microservices

Building a REST API? Lambda + API Gateway is a killer combo.

// Simple Lambda function for an API endpoint
exports.handler = async (event) => {
    const userId = event.pathParameters.id;

    // Fetch user from database
    const user = await getUser(userId);

    return {
        statusCode: 200,
        body: JSON.stringify(user)
    };
};

Perfect for:

Mobile app backends
Web application APIs
Microservices architecture

2. File Processing

When users upload files to S3, Lambda can automatically process them.

Use cases:

Image resizing/compression
Video transcoding
PDF generation
CSV/Excel data processing

# Triggered when file is uploaded to S3
def lambda_handler(event, context):
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']

    # Process the uploaded file
    process_file(bucket, key)

    return {'statusCode': 200}

3. Scheduled Tasks (Cron Jobs)

Need to run something every hour? Every day at midnight? Lambda + EventBridge is your friend.

Examples:

Daily database cleanup
Sending scheduled reports
Periodic data synchronization
Health checks

# Using AWS SAM template
Events:
  ScheduledEvent:
    Type: Schedule
    Properties:
      Schedule: rate(1 hour)  # Runs every hour

4. Real-time Data Processing

Process streaming data from Kinesis or DynamoDB Streams.

Use cases:

IoT sensor data processing
Real-time analytics
Log aggregation
Change data capture (CDC)

5. Webhooks & Event Handlers

Respond to external events instantly.

Examples:

Payment gateway callbacks (Stripe, PayPal)
GitHub/GitLab webhooks for CI/CD
Slack bot commands
Third-party API integrations

6. Chatbots & Voice Assistants

Lambda powers many conversational interfaces.

Integrations:

Amazon Lex (chatbots)
Alexa Skills
Telegram/Discord bots

7. Authentication & Authorization

Custom auth logic for your applications.

Use cases:

JWT token validation
Custom authorizers for API Gateway
User signup/signin flows
OAuth callback handlers

❌ When Should You NOT Use AWS Lambda?

Lambda isn't a silver bullet. Here's when you should consider alternatives:

1. Long-Running Processes

Lambda has a 15-minute timeout limit. If your task takes longer, Lambda isn't the right choice.

Better alternatives:

AWS Fargate
AWS Batch
EC2 instances

2. Consistent High Traffic

If your application runs 24/7 with consistent high traffic, Lambda might be more expensive than EC2 or containers.

Rule of thumb: Calculate your costs. Lambda charges per millisecond, while EC2 is hourly. For always-on workloads, EC2 or Fargate often wins.

3. Stateful Applications

Lambda functions are stateless. Each invocation is independent with no shared memory.

Not ideal for:

WebSocket connections (though API Gateway helps)
Session-based applications
Applications requiring persistent connections

4. Latency-Critical Applications

Cold starts can add 100ms to several seconds of latency when Lambda spins up a new container.

Mitigations:

Provisioned Concurrency (costs extra)
Keep functions warm with scheduled pings
Use smaller deployment packages

5. Heavy Compute Workloads

Lambda maxes out at 10GB RAM and 6 vCPUs. For ML training, video rendering, or heavy computation, look elsewhere.

Better alternatives:

EC2 with GPU instances
AWS SageMaker
AWS Batch

6. Complex Monolithic Applications

Lambda works best with small, focused functions. Migrating a large monolithic app to Lambda is painful and often counterproductive.

📊 Quick Decision Matrix

Scenario	Use Lambda?	Alternative
REST API with variable traffic	✅ Yes	-
Image processing on upload	✅ Yes	-
Cron jobs (< 15 min)	✅ Yes	-
Real-time webhooks	✅ Yes	-
24/7 high-traffic web server	❌ No	EC2, Fargate
ML model training	❌ No	SageMaker, EC2
Long-running batch jobs	❌ No	AWS Batch
WebSocket game server	❌ No	EC2, Fargate
Sub-10ms latency required	⚠️ Maybe	EC2

💰 Understanding Lambda Pricing

Lambda's pricing is simple but can surprise you:

You pay for:

Number of requests: $0.20 per 1 million requests
Duration: Based on memory allocated × execution time

Free tier (every month):

1 million requests
400,000 GB-seconds of compute time

Example calculation:

Function specs:
- Memory: 512MB
- Avg execution time: 200ms
- Monthly invocations: 5 million

Cost calculation:
- Requests: (5M - 1M free) × $0.20/1M = $0.80
- Compute: 5M × 0.2s × 0.5GB = 500,000 GB-s
- GB-s cost: (500,000 - 400,000 free) × $0.0000166667 = $1.67

Total: ~$2.47/month

🚀 Getting Started: Your First Lambda Function

Ready to try Lambda? Here's a quick start:

Step 1: Create the Function

// index.js
exports.handler = async (event) => {
    const name = event.queryStringParameters?.name || 'World';

    return {
        statusCode: 200,
        headers: {
            'Content-Type': 'application/json'
        },
        body: JSON.stringify({
            message: `Hello, ${name}!`,
            timestamp: new Date().toISOString()
        })
    };
};

Step 2: Deploy Using AWS CLI

# Zip your code
zip function.zip index.js

# Create the function
aws lambda create-function \
    --function-name HelloWorld \
    --runtime nodejs20.x \
    --handler index.handler \
    --role arn:aws:iam::YOUR_ACCOUNT:role/lambda-role \
    --zip-file fileb://function.zip

Step 3: Test It

aws lambda invoke \
    --function-name HelloWorld \
    --payload '{"queryStringParameters": {"name": "Developer"}}' \
    response.json

cat response.json
# Output: {"message":"Hello, Developer!","timestamp":"2024-01-15T10:30:00.000Z"}

🎯 Best Practices for Beginners

Keep functions small and focused — One function, one job
Minimize cold starts — Use smaller packages, avoid VPC unless necessary
Set appropriate timeouts — Don't use 15 minutes if 10 seconds is enough
Use environment variables — Never hardcode secrets
Monitor with CloudWatch — Set up alarms for errors and duration
Use Layers for dependencies — Share common code across functions

🏁 Conclusion

AWS Lambda is a powerful tool, but it's not for everything. Use it when:

✅ Your workload is event-driven
✅ Traffic is variable or unpredictable
✅ Tasks complete in under 15 minutes
✅ You want zero infrastructure management

Avoid it when:

❌ You need consistent, high-performance compute
❌ Tasks run longer than 15 minutes
❌ Sub-millisecond latency is critical
❌ You're running a stateful monolith

Start small, experiment, and you'll quickly discover where Lambda fits in your architecture. The serverless journey is worth it!

📚 Resources

What's your experience with AWS Lambda? Drop a comment below! 👇

If you found this helpful, please ❤️ and follow for more cloud content!

aws #lambda #serverless #beginners #cloud

DEV Community: Sahinur

Building `aws-ec2-check`: A Small Open-Source AWS Utility with Node.js

The problem

What aws-ec2-check does

Why build another AWS tool?

How it's built

AWS SDK instead of the Console

Security matters

IAM and least privilege

Keeping the CLI simple

Why TypeScript?

Testing the project

What I learned building it

CLI design

AWS authentication

Error handling

Documentation

What I'd like to add next

Why open source?

Try it

Final takeaway

Load Testing My Node.js API on AWS: What I Learned

Why load test?

The setup

Tooling

A simple k6 test

The test stages

Stage 1 — Baseline

Stage 2 — Ramp up

Stage 3 — Peak load

Stage 4 — Recovery

What I measure

P50 latency

P95 latency

P99 latency

Error rate

Throughput

Results

Watching the EC2 instance

The surprise: the API isn't always the bottleneck

A common database problem

What happens when the test gets too aggressive?

Changes I would make after testing

1. Optimize database queries

2. Add pagination

3. Improve connection handling

4. Add caching

5. Scale the application

6. Improve observability

Load testing isn't about finding one magic number

A simple performance checklist

What I learned

Final takeaway

Migrating a Node.js Endpoint to AWS Lambda: What I Would Watch For

Why migrate only one endpoint?

The migration plan

Step 1: Identify the endpoint

Step 2: Separate business logic from Express

Step 3: Add API Gateway

What can break?

Problem 1: Database connections

Problem 2: Cold starts

Problem 3: Environment variables

Problem 4: Express assumptions

Problem 5: Logging changes

How I would reduce migration risk

Testing before production

Is Lambda always better?

What I would measure

Was it worth it?

Final takeaway

IAM Permissions I Got Wrong (And What I Learned)

Mistake 1: Using * just to get it working

Mistake 2: Confusing users and roles

Mistake 3: Giving the wrong resource access

Mistake 4: Forgetting that permissions can come from multiple places

How I approach an AccessDenied error

1. Who is making the request?

2. What action is being attempted?

3. Which resource is being accessed?

What `aws-ec2-check` does

Mistake 1: Using `*` just to get it working