DEV Community: Randy M. Alonzo

⚡ AWS Lambda Can Run for 90 Minutes Now — But Should It?

Randy M. Alonzo — Thu, 17 Sep 2026 16:27:22 +0000

⚡ AWS Lambda Can Run for 90 Minutes Now — But Should It?

For years, AWS learners eventually memorized one number:

⏱️ 15 minutes.

Need a function to run for 5 minutes?

Lambda could handle it.

Need 10 minutes?

Still possible.

Need 20, 30, or 60 minutes?

Now you were probably reconsidering the architecture.

Then AWS changed the equation.

On September 9, 2026, AWS announced that Lambda Managed Instances can support function executions of up to:

🔥 90 MINUTES

for asynchronous and supported Event Source Mapping invocations.

That is six times the familiar 15-minute limit.

But there is a much more important question than:

“Can Lambda run for 90 minutes?”

The real question is:

🤔 Should your workload run inside Lambda for 90 minutes?

That is where this update becomes an architecture discussion rather than just a product announcement.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🚨 First: This Is NOT “Every Lambda Function Now Runs for 90 Minutes”

This distinction matters.

The new 90-minute maximum applies specifically to:

✅ AWS Lambda Managed Instances

and to:

✅ Asynchronous invocations

✅ Supported Event Source Mapping invocations

It does not mean every Lambda function suddenly received a 90-minute timeout.

Synchronous Lambda invocations still retain the familiar:

⏱️ 15-minute maximum.

The Lambda initialization phase on Managed Instances also remains limited to 15 minutes.

And some Event Source Mapping integrations, including Amazon MQ and Amazon DocumentDB, remain subject to the 15-minute limit.

So the accurate statement is not:

“Lambda now runs for 90 minutes.”

A better statement is:

“Lambda Managed Instances can now support up to 90-minute execution for specific asynchronous and Event Source Mapping workloads.”

That detail changes everything.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🧠 What Are Lambda Managed Instances?

Before discussing the longer timeout, it helps to understand the environment where it applies.

Lambda Managed Instances extend the Lambda programming model while allowing functions to run using managed EC2-based capacity.

AWS continues handling infrastructure responsibilities such as:

⚙️ Instance lifecycle

🔄 Scaling

🩹 Operating system and runtime patching

🌐 Routing

⚖️ Load balancing

while developers continue working with familiar Lambda concepts such as:

⚡ Functions

📜 Handlers

🔐 Execution roles

🌐 VPC configuration

📊 CloudWatch monitoring

Lambda Managed Instances are especially interesting for workloads that benefit from:

🖥️ Specialized compute

📈 Predictable or steady-state usage

⚙️ Greater compute configuration flexibility

💰 EC2-based pricing characteristics

⏱️ And now, significantly longer continuous execution.

This is not simply “normal Lambda with a bigger timer.”

It represents another compute option inside the AWS ecosystem.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🔥 Why the 15-Minute Limit Mattered

The old timeout forced an important architecture decision.

Imagine you have a job that normally requires:

25 minutes.

Traditional Lambda execution could not simply continue until completion.

You had to rethink the workload.

Maybe you:

🔄 Split the task into smaller Lambda functions.

📬 Used queues between processing stages.

🧩 Introduced Step Functions.

📦 Moved processing into containers.

⚙️ Used AWS Batch.

🖥️ Ran the workload on EC2.

Sometimes that restructuring improved the architecture.

Sometimes it added complexity mainly because the workload could not complete inside the Lambda execution window.

The new 90-minute option changes that trade-off for some workloads.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🧪 What Kinds of Workloads Could Benefit?

AWS specifically highlights examples such as:

📊 Data processing

🎥 Media transcoding

💰 Financial calculations

🤖 AI inference

⚙️ Batch processing

🌐 Web crawling

📁 Large file transfers

Imagine a data-processing task that consistently takes:

22 minutes.

Previously:

❌ Too long for a standard 15-minute Lambda execution.

Now:

✅ Potentially feasible on Lambda Managed Instances when invoked through a supported asynchronous pattern.

That can reduce the need to break a naturally continuous computation into artificial pieces solely because of the previous timeout.

But convenience introduces another question.

What happens when that 22-minute job fails at minute 21?

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

💥 The Longer Your Function Runs, the More Expensive Failure Becomes

Suppose your function performs a 45-minute AI inference job.

Everything works for:

10 minutes.

20 minutes.

30 minutes.

Then at minute 39:

💥 Something fails.

Maybe:

🌐 An external dependency disconnects.

🔑 A temporary credential expires.

📡 A network connection dies.

🧠 The process throws an exception.

🗄️ A downstream service becomes unavailable.

Now what?

If your workload simply starts again from the beginning, you may repeat almost 40 minutes of expensive computation.

That is why a longer timeout changes more than the maximum runtime.

It increases the importance of:

🔁 Retry behavior

🧠 Idempotency

💾 Checkpointing

📊 Observability

🔐 Credential lifetime

🌐 Connection lifetime

💰 Failure cost

Longer-running serverless workloads require more deliberate failure design.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🔁 Idempotency Becomes Even More Important

Imagine an SQS message triggers your Lambda function.

The function:

1️⃣ Reads the message.

2️⃣ Processes a large dataset.

3️⃣ Writes results into a database.

4️⃣ Sends a notification.

Now imagine the function fails after writing the database result but before completing the invocation.

The event may eventually be retried.

What happens when the same job runs again?

Does it:

✅ Detect that the operation already completed?

or:

❌ Write duplicate records?

❌ Charge the customer twice?

❌ Send duplicate notifications?

❌ Process the same file again?

That is the idea behind idempotency.

An idempotent operation can safely be repeated without creating unintended duplicate effects.

With longer execution windows, the consequences of poorly designed retries can become more expensive.

The takeaway:

⏱️ Longer timeout

does not reduce the importance of good distributed-system design.

It increases it.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

💾 This Is Where Durable Functions Become Interesting

AWS also supports Lambda durable functions.

Durable functions introduce checkpointing concepts that allow execution progress to be preserved.

Imagine a long-running workload:

Step 1

↓

15 minutes of processing

↓

💾 Checkpoint

↓

Step 2

↓

20 minutes of processing

↓

💾 Checkpoint

↓

Step 3

Now suppose the underlying execution experiences a failure during Step 3.

Without useful checkpointing:

🔄 Start everything again.

With durable execution:

💾 Previously completed work can be recognized during recovery.

AWS describes durable functions as using checkpoints to track execution progress and replay execution while skipping completed work.

That becomes particularly valuable when re-running earlier computation would be expensive.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🤖 Example: Long AI Inference

Imagine an inference workload takes approximately:

40 minutes.

At minute 35:

💥 Infrastructure failure.

Starting again from minute zero means repeating 35 minutes of computation.

For expensive workloads, that can hurt:

💰 Cost

⏱️ Latency

📈 Throughput

😵 Operational reliability

A durable approach can make checkpointing part of the design.

The important architecture question becomes:

“Can the workload safely restart?”

If yes:

A normal retry model may be enough.

If no:

Consider checkpointing or another execution model.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📨 What Happens With Asynchronous Lambda Invocations?

For asynchronous invocations, Lambda can apply retry behavior when a function fails or times out.

That means architects need to think carefully about what happens when long-running work is retried.

Questions worth asking:

❓ Can the same event safely execute twice?

❓ Does processing create external side effects?

❓ Should failed events go to a dead-letter queue?

❓ Should an on-failure destination be configured?

❓ What should happen after repeated failure?

❓ Can processing resume instead of restart?

Long execution makes these questions more consequential.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📬 SQS + 90-Minute Lambda Requires Careful Configuration

SQS is a natural companion for asynchronous processing.

Architecture:

📨 Amazon SQS

↓

⚡ Lambda Managed Instance

↓

🧠 Long-running processing

↓

🗄️ Store result

But there is an important timing relationship.

The queue's visibility timeout needs to accommodate the Lambda processing window and retry behavior.

AWS currently recommends configuring the SQS visibility timeout to at least:

6 × the Lambda function timeout.

So imagine configuring:

Lambda timeout:

90 minutes

Then the queue visibility timeout needs careful planning around that execution duration.

Why?

Because you do not want the same SQS message becoming visible again while the original invocation is still processing it.

Longer Lambda execution means surrounding services must also be configured with longer-running processing in mind.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📦 Batch Failure Handling Matters Too

Imagine an Event Source Mapping sends several records to your function.

The batch contains:

Record 1 ✅

Record 2 ✅

Record 3 ❌

Record 4 ✅

Record 5 ✅

Without careful failure handling, one bad record can cause successful records to be processed again.

For supported event sources, AWS provides partial batch failure capabilities.

That allows your application to communicate:

“These records succeeded.”

“These records failed.”

Then only failed records need to be retried.

With workloads that may run for tens of minutes, avoiding unnecessary reprocessing becomes even more valuable.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🌐 Long-Lived Network Connections Become a Real Architecture Concern

A five-second Lambda function usually does not make you think much about connection longevity.

A 70-minute function should.

Imagine your function connects to:

🗄️ Amazon RDS

⚡ Amazon ElastiCache

🌐 External APIs

🔌 Third-party databases

🚪 Services through a NAT Gateway

Now ask:

Will this connection remain valid for the full execution?

AWS recommends reviewing idle connection behavior when designing long-running Managed Instance functions.

For example, downstream services may terminate idle connections.

Network infrastructure may have its own idle timeout.

A connection that works during a short Lambda invocation may behave differently across an hour-long job.

This means long-running functions should be built assuming:

Connections can disappear.

Clients may need reconnection logic.

Retries need to be safe.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🔑 Temporary Credentials Have Lifetimes Too

Long-running Lambda functions may interact with:

🔐 Temporary AWS credentials

🎟️ Authentication tokens

🌐 Third-party API tokens

🗄️ Temporary database credentials

Ask:

Will these credentials remain valid throughout the entire execution?

If not:

How will they be refreshed?

This is another subtle consequence of increasing execution duration.

Something that easily survives a 3-minute function may expire during a 75-minute process.

AWS specifically recommends reviewing temporary credentials and tokens for long-running Managed Instance functions.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🌍 DNS Can Change During Long Executions

Another subtle concern:

DNS.

An application may resolve:

api.example.com

at the beginning of execution.

But what happens if the destination changes later?

DNS records have TTL values.

Long-running applications should respect those TTL values rather than assuming one DNS result remains valid indefinitely.

AWS SDKs generally handle this appropriately, but custom clients deserve attention.

Again:

Long-running Lambda begins to resemble some operational concerns traditionally associated with persistent applications.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

⚡ So Should Everything Move to 90-Minute Lambda?

No.

And that is probably the most important part of this update.

The increased timeout expands your architectural options.

It does not eliminate the other options.

The right question is:

“What execution model matches this workload?”

Let us compare.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

⚡ Option #1 — Lambda Managed Instances

Consider this approach when:

✅ Your application already fits the Lambda programming model.

✅ Processing is event-driven.

✅ Execution is asynchronous.

✅ The job naturally completes within the supported window.

✅ You want Lambda's managed operational model.

✅ Longer continuous execution removes unnecessary architectural fragmentation.

✅ Specialized compute or Managed Instance economics fit the workload.

Questions to ask:

❓ Is the workload idempotent?

❓ What happens if execution fails near completion?

❓ How are retries handled?

❓ Are connections and credentials safe for the entire duration?

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🔄 Option #2 — AWS Step Functions

Step Functions becomes interesting when the real problem is not:

“How long can one piece of code run?”

but instead:

“How should multiple pieces of work coordinate?”

Step Functions supports workflows involving:

🔀 Branching

🔁 Retries

🛑 Error handling

⏳ Waiting

📨 Service integrations

🔄 Multiple processing steps

📞 Callback patterns

For example:

Receive file

↓

Validate

↓

Process

↓

Wait for external result

↓

Transform

↓

Store output

↓

Notify user

That may be easier to understand as a workflow than as one enormous 80-minute function.

Step Functions also supports Retry and Catch behavior for handling task failures.

The decision is architectural:

One long computation?

Several coordinated steps?

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📦 Option #3 — Amazon ECS + AWS Fargate

Maybe your workload is already containerized.

Maybe you require:

🐳 Custom container behavior

🖥️ Greater runtime control

📦 Larger application dependencies

⚙️ Long-running worker processes

🔧 More control over CPU and memory configuration

AWS Fargate allows ECS workloads to run containers without requiring you to manage EC2 server clusters directly.

That can be attractive when:

The application naturally behaves like a containerized worker rather than an event-driven function.

Instead of asking:

“Can I force this workload into Lambda?”

ask:

“Which compute abstraction naturally matches the application?”

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

⚙️ Option #4 — AWS Batch

For true batch workloads, AWS Batch deserves consideration.

AWS Batch is designed to plan, schedule, and run batch-computing workloads while managing underlying compute capacity.

That can be useful for:

🧮 Scientific workloads

🤖 Machine learning processing

📊 Analytics

🧪 Simulation

🎞️ Large-scale media processing

📦 Queued compute jobs

If your problem fundamentally looks like:

“Here are thousands of compute jobs. Schedule and execute them efficiently.”

then the workload may align naturally with AWS Batch.

Again:

Longer Lambda does not mean every batch workload should become a Lambda workload.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🧠 Architecture Decision: Ask About the Workload, Not the Trend

Instead of asking:

“Which AWS service is best?”

ask questions like:

⏱️ How long does processing take?

📈 Is traffic steady or bursty?

📦 Is the application containerized?

🔄 Is the workload one computation or many coordinated steps?

💥 What happens when execution fails?

📬 How does work enter the system?

💾 Does the workload need checkpoints?

🔐 What credentials are involved?

🌐 Does the workload maintain long-lived connections?

💰 What does the cost profile look like?

📊 How will I monitor it?

🧪 Can processing safely run more than once?

Architecture decisions become much clearer when they begin with requirements instead of service popularity.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📊 A Quick Decision Framework

⚡ Lambda Managed Instances

Think:

Event-driven + continuous asynchronous execution + Lambda programming model.

🔄 Step Functions

Think:

Workflow orchestration + multiple steps + retries + branching + waiting.

📦 ECS / Fargate

Think:

Containerized workload + runtime control + long-running process.

⚙️ AWS Batch

Think:

Queued batch jobs + compute-intensive processing + scheduling at scale.

These services can also work together.

Architecture is not always:

A versus B.

Sometimes it is:

A + B + C.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🏗️ Example Architecture #1 — Long Data Processing Job

Imagine:

An S3 upload triggers processing of a very large file.

Architecture:

🪣 Amazon S3

↓

📨 Amazon SQS

↓

⚡ Lambda Managed Instance

↓

📊 Process dataset

↓

🪣 Store output in S3

↓

📈 CloudWatch

Typical processing time:

35–50 minutes.

Now ask:

✅ Is processing idempotent?

✅ Is the SQS visibility timeout configured correctly?

✅ Can the job safely restart?

✅ Are downstream connections resilient?

✅ Are metrics and logs sufficient?

✅ Is Lambda Managed Instances the right cost model?

This is where the new capability becomes genuinely useful.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

💥 Failure Scenario #1 — Minute 47 Failure

Imagine the job normally takes 50 minutes.

At minute:

the function fails.

The event is retried.

What happens?

Option A:

🔄 Repeat the entire 47 minutes.

Option B:

💾 Resume from a checkpoint.

Option C:

📦 Use another architecture where job state is managed differently.

There is no universal answer.

But the failure should be designed before production.

Do not wait until minute 47 to discover your recovery strategy.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

💥 Failure Scenario #2 — Duplicate Delivery

The same event executes twice.

Does your workload:

✅ recognize the duplicate?

or:

❌ create duplicate output?

For example:

A financial workload should not accidentally process the same transaction twice.

A file processor should not create multiple inconsistent copies.

A notification system should avoid sending the same message repeatedly.

Long-running execution does not change the fundamental rule:

Design distributed systems expecting retries and duplicates.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

💥 Failure Scenario #3 — External API Dies Midway

Your Lambda function processes data for 30 minutes.

Then it calls an external API.

The API returns:

500 Internal Server Error.

What happens next?

Ask:

🔁 Should you retry?

⏱️ How long should you wait?

📈 Should exponential backoff be used?

🚫 When should you stop?

💾 Should progress be checkpointed before the call?

📨 Should the failed job move to another queue?

This is why “90 minutes” is not simply a timeout configuration.

It becomes a reliability-design problem.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

💥 Failure Scenario #4 — Authentication Token Expires

Your job obtains a temporary token.

Token lifetime:

60 minutes.

Function execution:

75 minutes.

At minute 65:

🔐 Authentication begins failing.

The Lambda function itself is still running.

But its dependency is no longer accessible.

The lesson:

Longer compute duration requires reviewing assumptions made by every dependency around that compute.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🧪 A Student-Friendly Hands-On Lab

You do not need to immediately create a 90-minute production workload.

Instead, build a simulation.

Create a long-running asynchronous processing flow.

For example:

📨 SQS

↓

⚡ Lambda

↓

🧠 Process several simulated steps

↓

📊 Write progress into logs

↓

🗄️ Save result

Example stages:

Step 1 — Validate input

Step 2 — Load data

Step 3 — Process chunk A

Step 4 — Process chunk B

Step 5 — Save results

Then deliberately introduce:

💥 An exception during Step 4.

Observe:

📊 CloudWatch logs.

📨 Retry behavior.

🔁 Duplicate processing.

⏱️ Execution duration.

Then modify your design.

Add:

🆔 Idempotency keys.

💾 Checkpointing.

📬 Failure destinations.

📊 Better structured logs.

Now the exercise teaches architecture, not just Lambda syntax.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📈 Monitoring Matters More When Jobs Take Longer

Imagine a 2-second Lambda function.

If it fails, you usually discover quickly.

Now imagine a function that runs for:

68 minutes.

You do not want to discover at minute 68 that nothing useful happened.

Observability becomes critical.

Monitor:

⏱️ Duration

❌ Errors

🚫 Throttles

📈 Resource utilization

🧠 Application progress

📜 Logs

🔄 Retry behavior

For Lambda Managed Instances, AWS also exposes capacity-provider-level metrics such as CPU and memory utilization.

Long-running execution should produce enough telemetry to answer:

“Is useful work actually progressing?”

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

💰 What About Cost?

Longer execution does not automatically mean cheaper or more expensive architecture.

The answer depends on:

⚙️ Compute configuration

📈 Utilization

⏱️ Duration

🔢 Concurrency

📦 Workload pattern

💳 Pricing model

📊 Steady-state versus bursty traffic

AWS specifically notes that Lambda Managed Instances are particularly suited to steady-state workloads with predictable high-volume traffic, while default Lambda capacity may still be more cost-effective for burstier workloads.

That means:

“90 minutes exists”

is not enough information to make a cost decision.

Measure your workload.

Model the alternatives.

Then decide.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

⚠️ Do Not Set Every Timeout to 90 Minutes

Another tempting response to the announcement is:

“Great! Set everything to 5,400 seconds.”

Please don't.

Timeouts are also safety mechanisms.

Imagine buggy code enters an unintended loop.

A short timeout limits how long the problem continues.

A very generous timeout allows the problem to consume resources much longer.

Set the timeout based on realistic workload behavior.

For example:

Expected duration:

12 minutes

Maybe the correct timeout is:

15 or 20 minutes.

Not automatically:

90 minutes.

Configuration should reflect expected execution, not the maximum number AWS allows.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🎤 Turn This Update Into an Interview Discussion

Imagine an interviewer asks:

“A workload runs asynchronously for about 40 minutes. AWS Lambda Managed Instances now support up to 90-minute execution. Would you use Lambda?”

A weak answer:

“Yes, because Lambda supports 90 minutes now.”

A stronger answer:

“I would first evaluate the workload characteristics. If it is event-driven, naturally fits the Lambda programming model, runs asynchronously, and can safely handle retries and duplicate execution, Lambda Managed Instances could be a good option. I would also evaluate idempotency, connection and credential lifetimes, checkpointing requirements, observability, and cost. If the workload is really a multi-step orchestration, containerized worker, or large batch-processing job, I would also compare Step Functions, ECS/Fargate, or AWS Batch before deciding.”

That demonstrates:

🧠 Architecture thinking

⚡ Lambda knowledge

🔄 Workflow awareness

📦 Container knowledge

⚙️ Batch-compute awareness

💥 Failure analysis

💰 Cost awareness

🔐 Operational thinking

Much stronger than memorizing:

“Lambda maximum timeout = 90 minutes.”

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🔥 The Bigger Lesson

The biggest Lambda update is not simply:

15 minutes → 90 minutes.

The bigger change is:

AWS architects now have another compute decision to make.

Previously, exceeding 15 minutes could immediately eliminate Lambda from certain designs.

Now some of those workloads deserve another look.

But every expanded capability also expands the architecture questions.

Longer execution introduces more responsibility around:

🔁 Retries

💾 Recovery

🔐 Credentials

🌐 Connections

📊 Monitoring

💰 Cost

🧠 Idempotency

💥 Failure handling

A higher limit gives you flexibility.

It does not remove the need for engineering judgment.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🎯 Final Thoughts

I think the most interesting part of AWS Lambda's new 90-minute capability is not the number itself.

It is the conversation it creates.

For years:

Long-running workload?

Lambda probably was not the first choice.

Now the answer becomes:

“Maybe.”

And “maybe” is where architecture becomes interesting.

Do not choose Lambda because the timeout increased.

Do not reject Lambda because you remember the old 15-minute limitation.

Instead:

📋 Understand the workload.

🧠 Understand the failure model.

⏱️ Understand the execution characteristics.

🔄 Understand retries.

💾 Understand recovery.

📊 Understand observability.

💰 Understand cost.

Then choose the compute model that actually fits.

That is the difference between:

Knowing AWS services

and

Designing with AWS services.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

☁️ Your Turn — Architecture Challenge

Imagine this workload:

📊 Data-processing job

⏱️ Typical duration: 35–50 minutes

📨 Triggered asynchronously

💥 Occasionally fails around minute 30

💰 Reprocessing is moderately expensive

📈 Workload arrives consistently throughout the day

What architecture would you investigate first?

⚡ Lambda Managed Instances

🔄 AWS Step Functions

📦 ECS + AWS Fargate

⚙️ AWS Batch

🧩 A combination of them?

And more importantly:

Why?

💬 Share the architecture you would choose and the trade-offs that would drive your decision.

There may not be one universally correct answer.

That is exactly what makes the discussion valuable. 🚀

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📚 AWS Resources Behind This Article

• AWS announcement: 90-minute function timeout on Lambda Managed Instances

• AWS Compute Blog: Announcing 90-minute function timeout on AWS Lambda Managed Instances

• AWS Lambda documentation: Configuring function timeout

• AWS Lambda documentation: Managed Instances best practices

• AWS Step Functions documentation: Service integrations and error handling

• Amazon ECS documentation: AWS Fargate architecture

• AWS Batch documentation: What is AWS Batch?

Always verify current service limits, supported invocation types, pricing, and regional availability in the latest AWS documentation before designing production workloads.

⚡ No Server to Manage: Build Your First AWS Serverless API with Lambda + DynamoDB

Randy M. Alonzo — Thu, 17 Sep 2026 16:17:51 +0000

⚡ No Server to Manage: Build Your First AWS Serverless API with Lambda + DynamoDB

You have probably heard the word:

“Serverless.”

At first, it sounds strange.

How can an application run without a server?

The answer is simple:

Servers still exist.

You just are not provisioning, patching, maintaining, and operating a traditional application server in the same way.

Instead, you focus more on:

🧠 Application logic

🌐 Requests

🔐 Permissions

🗄️ Data

📊 Monitoring

AWS handles much of the underlying infrastructure required to run your function.

For a student learning cloud computing, this creates a great opportunity.

You can build something small...

but still learn how multiple AWS services communicate with each other.

That is exactly what we are going to do.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🎯 What We Are Building

We are going to create a simple:

Student Learning Tracker API

The API will allow us to save learning records such as:

👤 Student ID

📚 Topic

✅ Status

📝 Notes

🕒 Timestamp

For example:

{
"studentId": "student001",
"topic": "AWS IAM",
"status": "completed",
"notes": "Practiced least privilege and AccessDenied troubleshooting"
}

Instead of storing this information inside a traditional server application, we will connect several AWS services.

Our architecture will look like this:

👨‍💻 Client

↓

🌐 Amazon API Gateway

↓

⚡ AWS Lambda

↓

🗄️ Amazon DynamoDB

↓

📤 JSON Response

Behind the scenes, we will also use:

🔐 AWS IAM

for permissions

and

📊 Amazon CloudWatch

for logs and troubleshooting.

This one small project already introduces several important cloud concepts.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🧠 What “Serverless” Actually Means

Serverless does not mean:

“There are literally no servers.”

It means that you do not directly manage the servers running your application logic.

With AWS Lambda, you upload your code.

Then AWS handles much of the infrastructure required to run that code when it is invoked.

That changes the developer's focus.

Instead of spending most of your time thinking:

Which virtual machine should I create?

How much CPU do I need?

How do I patch the operating system?

How do I keep the server running?

You begin thinking more about:

⚡ What should this function do?

📥 What request does it receive?

🗄️ What data does it need?

🔐 What permissions does it require?

📤 What response should it return?

📊 How will I troubleshoot it?

That is a different way of designing applications.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🏗️ Understanding the Architecture First

Before touching the AWS console, understand what each service will do.

🌐 Amazon API Gateway

This will provide the HTTP endpoint our client can call.

For example:

POST /entries

or:

GET /entries/{entryId}

⚡ AWS Lambda

This contains our application logic.

It will:

Receive the request

↓

Understand which route was called

↓

Process the data

↓

Communicate with DynamoDB

↓

Return a response

🗄️ Amazon DynamoDB

This stores our learning records.

Each record becomes an item inside a DynamoDB table.

🔐 AWS IAM

This controls what the Lambda function is actually allowed to do.

Our function should not automatically receive unlimited AWS permissions.

It should receive only the permissions required for this project.

📊 Amazon CloudWatch

This helps us observe what happens when the function runs.

If something fails, logs become one of our most useful troubleshooting tools.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

💰 Before Building: Think About Cost

Before creating cloud resources, develop one habit early:

Always know what you are creating.

Even when experimenting with small learning projects:

💳 Review the pricing model.

📊 Monitor your account.

🔔 Configure budget notifications where appropriate.

🗑️ Remove resources you no longer need.

🧠 Understand which resources remain active after you close your browser.

Cloud engineering is not only about making systems work.

It is also about operating resources responsibly.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🗄️ STEP #1 — Create the DynamoDB Table

Let's start with the data layer.

Create a DynamoDB table.

Suggested table name:

student-learning-tracker

For this project, use:

Partition key:

entryId

Type:

String

Why entryId?

Because every learning record should have its own unique identifier.

A record might eventually look like this:

entryId:
"e7f2..."

studentId:
"student001"

topic:
"AWS Lambda"

status:
"in-progress"

notes:
"Building my first serverless API"

timestamp:
"2026-09-17T15:30:00Z"

Using a unique entry ID makes it straightforward to retrieve one specific learning record later.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🧩 Understanding the DynamoDB Item

DynamoDB stores data as items.

You can think of an item as similar to one record.

Example:

entryId
→ Unique identifier

studentId
→ Who owns the entry

topic
→ What they are learning

status
→ planned / in-progress / completed

notes
→ Additional information

timestamp
→ When the entry was created

This is intentionally simple.

A beginner project should teach you the architecture before adding unnecessary complexity.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🔐 STEP #2 — Understand the Lambda Execution Role

This is where our previous IAM article becomes useful.

Your Lambda function needs permission to communicate with DynamoDB.

But the function should not contain hardcoded AWS access keys.

Instead:

⚡ Lambda Function

↓

🎭 Execution Role

↓

📜 IAM Permissions

↓

🗄️ DynamoDB

For this project, our function needs only a few DynamoDB actions.

For example:

dynamodb:PutItem

dynamodb:GetItem

And ideally, those actions should apply only to:

student-learning-tracker

rather than every DynamoDB table in the account.

That is least privilege in practice.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📜 Example IAM Permission

Conceptually, the DynamoDB permission might look like this:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:PutItem",
"dynamodb:GetItem"
],
"Resource": "YOUR_DYNAMODB_TABLE_ARN"
}
]
}

Replace:

YOUR_DYNAMODB_TABLE_ARN

with the ARN of the table you created.

Do not blindly copy broad permissions simply because they make the project work.

Ask:

What actions does this function actually need?

For our first version:

Write one item.

Read one item.

That is enough.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

⚠️ One IAM Detail Worth Knowing

There is an AWS-managed policy called:

AWSLambdaDynamoDBExecutionRole

The name can sound like:

“This lets my Lambda write items into DynamoDB.”

But that policy is primarily intended for Lambda functions working with DynamoDB Streams.

For our application, where Lambda directly performs actions such as:

dynamodb:PutItem

and

dynamodb:GetItem

we need the corresponding table permissions.

Always inspect what a policy actually grants.

Do not rely only on its name.

That habit will save you from many IAM problems later.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

⚡ STEP #3 — Create the Lambda Function

Now create your Lambda function.

Suggested name:

student-learning-api

Choose a Python runtime.

For the execution role:

Use a role that includes basic Lambda logging permissions and the DynamoDB permissions required by this project.

Next, create an environment variable:

Key:

TABLE_NAME

Value:

student-learning-tracker

Why use an environment variable?

Because we do not want to hardcode configuration everywhere inside the application.

Our code can simply read:

TABLE_NAME

from the environment.

That also makes the function easier to reuse in different environments later.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

💻 STEP #4 — Add the Lambda Code

Here is a simple example.

The function supports:

POST /entries

and

GET /entries/{entryId}

Python example:

import json
import os
import uuid
from datetime import datetime, timezone

import boto3

dynamodb = boto3.resource("dynamodb")
table = dynamodb.Table(os.environ["TABLE_NAME"])

def response(status_code, body):
return {
"statusCode": status_code,
"headers": {
"content-type": "application/json"
},
"body": json.dumps(body)
}

def lambda_handler(event, context):

route_key = event.get("routeKey", "")

if route_key == "POST /entries":

    try:
        body = json.loads(event.get("body") or "{}")
    except json.JSONDecodeError:
        return response(
            400,
            {"message": "Invalid JSON body"}
        )

    required_fields = [
        "studentId",
        "topic",
        "status"
    ]

    missing = [
        field
        for field in required_fields
        if not body.get(field)
    ]

    if missing:
        return response(
            400,
            {
                "message": "Missing required fields",
                "fields": missing
            }
        )

    item = {
        "entryId": str(uuid.uuid4()),
        "studentId": body["studentId"],
        "topic": body["topic"],
        "status": body["status"],
        "notes": body.get("notes", ""),
        "timestamp": datetime.now(
            timezone.utc
        ).isoformat()
    }

    table.put_item(Item=item)

    return response(
        201,
        item
    )


if route_key == "GET /entries/{entryId}":

    path_parameters = (
        event.get("pathParameters") or {}
    )

    entry_id = path_parameters.get("entryId")

    if not entry_id:
        return response(
            400,
            {"message": "entryId is required"}
        )

    result = table.get_item(
        Key={
            "entryId": entry_id
        }
    )

    item = result.get("Item")

    if not item:
        return response(
            404,
            {"message": "Entry not found"}
        )

    return response(
        200,
        item
    )


return response(
    404,
    {"message": "Route not found"}
)

Do not worry if every line does not immediately make sense.

The important thing is understanding the flow.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🔎 Reading the Code as an Architecture

Let's simplify it.

First:

dynamodb = boto3.resource("dynamodb")

This creates the DynamoDB service resource used by the code.

Then:

table = dynamodb.Table(os.environ["TABLE_NAME"])

This tells our function which table to use.

Then:

route_key = event.get("routeKey", "")

This helps determine which API route triggered the function.

If the request is:

POST /entries

we:

📥 Parse the request body.

✅ Validate required fields.

🆔 Generate a unique entry ID.

🕒 Add a timestamp.

🗄️ Write the item into DynamoDB.

📤 Return the created item.

If the request is:

GET /entries/{entryId}

we:

📥 Read entryId from the URL.

🔎 Search DynamoDB.

📦 Retrieve the item.

📤 Return the item as JSON.

That is already a real API workflow.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🧪 STEP #5 — Test Lambda Before Adding API Gateway

This is an important troubleshooting habit.

Do not connect every service immediately.

First test the function independently.

Why?

Because if everything is connected at once and the application fails, you now have multiple possible failure points.

Is it:

API Gateway?

Lambda?

IAM?

DynamoDB?

The event structure?

The table?

The Region?

Instead:

Build one layer.

Test it.

Then add another layer.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🧪 Example POST Test Event

Because the final HTTP API will provide a route key and body, you can simulate something similar.

Example:

{
"routeKey": "POST /entries",
"body": "{\"studentId\":\"student001\",\"topic\":\"AWS Lambda\",\"status\":\"in-progress\",\"notes\":\"Building my first serverless API\"}"
}

Run the Lambda test.

Expected result:

201

and an item containing something similar to:

{
"entryId": "...",
"studentId": "student001",
"topic": "AWS Lambda",
"status": "in-progress",
"notes": "Building my first serverless API",
"timestamp": "..."
}

Now open DynamoDB.

Check the table.

You should see the item.

That proves:

⚡ Lambda executed.

🔐 IAM allowed the write.

🗄️ DynamoDB stored the item.

Before we even create the public API.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

💥 What If Lambda Returns AccessDeniedException?

Excellent.

Now you have a troubleshooting exercise.

The question is:

Who is making the DynamoDB request?

The Lambda execution role.

Then ask:

Does that role allow:

dynamodb:PutItem

on:

the correct DynamoDB table ARN?

Check:

🎭 Execution role

📜 Attached permissions

⚙️ Required action

📦 Resource ARN

🌎 AWS Region

This directly connects to the IAM concepts we learned earlier.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🌐 STEP #6 — Create the API Gateway HTTP API

Now we need an HTTP endpoint.

Create an API in:

Amazon API Gateway

For a beginner serverless application, an HTTP API provides a clean way to connect HTTP routes to Lambda.

Add your Lambda function as the integration.

Our request flow becomes:

👨‍💻 Client

↓

🌐 API Gateway

↓

⚡ Lambda

↓

🗄️ DynamoDB

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🛣️ STEP #7 — Create the Routes

Create two routes.

First:

POST /entries

Purpose:

Create a new learning record.

Second:

GET /entries/{entryId}

Purpose:

Retrieve one learning record.

Connect both routes to:

student-learning-api

Now the Lambda function can inspect the route key and decide what logic to execute.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📤 STEP #8 — Test the POST Endpoint

After deployment, API Gateway gives you an invoke URL.

Conceptually:

https://YOUR_API_ID.execute-api.REGION.amazonaws.com

Your POST endpoint becomes:

https://YOUR_API_URL/entries

Example request:

curl -X POST "YOUR_API_URL/entries" \
-H "content-type: application/json" \
-d '{
"studentId": "student001",
"topic": "AWS Lambda",
"status": "completed",
"notes": "Built my first Lambda API"
}'

Expected response:

{
"entryId": "...",
"studentId": "student001",
"topic": "AWS Lambda",
"status": "completed",
"notes": "Built my first Lambda API",
"timestamp": "..."
}

Congratulations.

At that point:

🌐 An HTTP request entered API Gateway.

⚡ API Gateway invoked Lambda.

🔐 Lambda used its execution role.

🗄️ Lambda wrote data into DynamoDB.

📤 Lambda returned JSON.

You just connected four AWS services into one working application.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📥 STEP #9 — Test the GET Endpoint

Copy the entryId from the POST response.

Now request:

GET /entries/{entryId}

Example:

curl "YOUR_API_URL/entries/YOUR_ENTRY_ID"

Expected response:

{
"entryId": "...",
"studentId": "student001",
"topic": "AWS Lambda",
"status": "completed",
"notes": "Built my first Lambda API",
"timestamp": "..."
}

Now you have:

CREATE

and

READ

functionality.

You could later extend the project with:

✏️ UPDATE

🗑️ DELETE

📋 LIST

🔎 QUERY

🔐 AUTHENTICATION

But do not rush.

Understand the basic architecture first.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📊 STEP #10 — Use CloudWatch Logs

This is where the project becomes especially useful for troubleshooting.

Lambda invocation logs can be sent to:

Amazon CloudWatch Logs

when the execution role has the required logging permissions.

Instead of guessing why the function failed, inspect the logs.

You can also deliberately add useful messages inside your code.

For example:

print("Processing POST /entries")

or:

print(f"Reading entry: {entry_id}")

Do not log passwords, tokens, personal secrets, or sensitive data.

Logging should help you troubleshoot.

Not create another security problem.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

💥 TROUBLESHOOTING LAB #1 — AccessDeniedException

Scenario:

API Gateway works.

Lambda runs.

But DynamoDB fails.

CloudWatch shows:

AccessDeniedException

Ask:

👤 Who made the request?

Lambda execution role.

⚙️ What action failed?

Maybe:

dynamodb:PutItem

📦 Which resource?

Your DynamoDB table.

Likely investigation:

🔐 Execution role

📜 IAM policy

📦 Table ARN

🌎 Region

This is exactly why IAM knowledge matters.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

💥 TROUBLESHOOTING LAB #2 — ResourceNotFoundException

Suppose Lambda reports:

ResourceNotFoundException

Possible causes:

❌ TABLE_NAME contains the wrong value.

❌ DynamoDB table exists in another Region.

❌ You renamed or deleted the table.

❌ Your code points toward a resource that does not exist.

Check:

🗄️ Exact table name

🌎 Region

⚙️ Environment variable

📦 Resource existence

Do not immediately edit the IAM policy.

ResourceNotFound is not the same error as AccessDenied.

Different symptom.

Different investigation.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

💥 TROUBLESHOOTING LAB #3 — API Returns 500

Your browser or API client receives:

500 Internal Server Error

Do not panic.

Start tracing the request.

🌐 Did API Gateway receive it?

↓

⚡ Was Lambda invoked?

↓

📊 What appears in CloudWatch Logs?

↓

💥 Did the code throw an exception?

↓

🗄️ Did DynamoDB return an error?

Logs can reveal errors such as:

JSON parsing failures

Missing environment variables

DynamoDB exceptions

Programming errors

Unexpected event structures

This is where observability turns guessing into evidence.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

💥 TROUBLESHOOTING LAB #4 — Invalid JSON

Try sending:

{
studentId: student001
}

That is not valid JSON.

Our function attempts:

json.loads(...)

and should return:

400

with something like:

Invalid JSON body

This teaches another important lesson:

Not every application failure is an AWS infrastructure problem.

Sometimes the request itself is wrong.

Always identify the failure layer.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

💥 TROUBLESHOOTING LAB #5 — Lambda Works, API Gateway Doesn't

This scenario is particularly educational.

Lambda works when tested directly.

But the API endpoint fails.

What changed?

The application logic may be fine.

Now investigate the integration layer.

Check:

🌐 API Gateway route

⚡ Lambda integration

🛣️ Route key

📥 Event structure

🔐 Permission for API Gateway to invoke Lambda

📊 CloudWatch logs

This is why testing each layer independently is so useful.

You can say:

Lambda works.

DynamoDB works.

The failure appears only when API Gateway enters the path.

You have already reduced the troubleshooting scope.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🌍 TROUBLESHOOTING LAB #6 — Browser Says CORS Error

Your API works through a terminal tool.

But your web application cannot call it.

The browser reports a CORS problem.

Now you are dealing with another layer.

CORS determines which origins can make browser-based requests to the API.

If you later connect this API to a frontend, configure CORS intentionally.

Do not blindly allow everything in a production application.

Instead, understand:

🌐 Which frontend origin needs access?

⚙️ Which HTTP methods are required?

📋 Which headers are required?

Security configuration should match the application.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🔐 Security: Do Not Stop at “It Works”

A working API is only the beginning.

Ask:

Who should be allowed to use this endpoint?

Our learning version may be intentionally simple.

A real application may require authentication and authorization.

Possible options can include:

🔐 IAM authorization

👤 Amazon Cognito

🔑 JWT-based authorization

or another architecture appropriate to the application.

Also think about:

🧹 Input validation

🚦 Rate limiting and throttling

📜 Logging

🔐 Least-privilege IAM

🔒 Encryption

🗄️ Data sensitivity

🧾 Auditability

Security should not be something added only at the end.

It should be part of how you think about the design.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🔑 Never Put AWS Access Keys in the Lambda Code

Do not write:

AWS_ACCESS_KEY_ID = "..."

AWS_SECRET_ACCESS_KEY = "..."

inside your application.

Lambda already supports execution roles.

The application can receive temporary credentials through the AWS environment based on that role.

This is one of the major advantages of using IAM roles correctly.

Your application code should describe:

What the application does.

IAM should describe:

What the application is allowed to do.

Keep those responsibilities separate.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🛡️ Practice Least Privilege

Our Lambda does not need:

AdministratorAccess

It does not need:

FullAccess to every DynamoDB table.

For this version, it might only need:

dynamodb:PutItem

dynamodb:GetItem

on:

student-learning-tracker

That is much closer to good cloud security.

When the project grows, add permissions intentionally.

Do not start with everything.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🧠 Think About Failure Before Production

Ask yourself:

What happens if DynamoDB is unavailable?

What happens if the request body is malformed?

What happens if an item does not exist?

What happens if a user sends a huge request?

What happens if Lambda throws an exception?

What happens if permissions change?

What happens if someone repeatedly calls the API?

These questions move you from:

“I made a tutorial work.”

toward:

“I am thinking about how a system behaves.”

That difference matters.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📊 Observe the Entire Request Path

When the system works:

👨‍💻 Client

↓

🌐 API Gateway

↓

⚡ Lambda

↓

🔐 IAM authorization

↓

🗄️ DynamoDB

↓

⚡ Lambda

↓

🌐 API Gateway

↓

📤 Client

When something fails, identify where the request stopped.

For example:

Client

↓

API Gateway

↓

Lambda

↓

❌ AccessDeniedException

Likely investigation:

Lambda execution role

Or:

Client

↓

API Gateway

↓

❌ Lambda never invoked

Likely investigation:

API route or integration

Or:

Client

↓

❌ Browser CORS failure

Likely investigation:

API CORS configuration

Troubleshooting becomes easier when you can visualize the architecture.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🧪 Intentionally Break the Application

Once everything works, break it.

Seriously.

In a controlled lab environment, try:

💥 Remove dynamodb:PutItem.

💥 Change TABLE_NAME to the wrong table.

💥 Send malformed JSON.

💥 Request an entry that does not exist.

💥 Change the API route.

💥 Remove required integration permissions.

Then observe:

🚨 Error

↓

📊 Evidence

↓

🔎 Investigation

↓

🧠 Hypothesis

↓

🛠️ Fix

↓

✅ Retest

A working tutorial teaches you the happy path.

A broken tutorial teaches you troubleshooting.

You need both.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📝 Document the Project Like an Engineer

Do not finish the project and immediately forget it.

Create a GitHub repository.

Your README could contain:

📌 Project Name

Student Learning Tracker Serverless API

🎯 Objective

Build a beginner-friendly serverless API using AWS managed services.

🏗️ Architecture

Client

↓

API Gateway

↓

Lambda

↓

DynamoDB

☁️ AWS Services Used

API Gateway

AWS Lambda

Amazon DynamoDB

AWS IAM

Amazon CloudWatch

🔐 Security

Lambda execution role

Least-privilege DynamoDB access

No hardcoded AWS credentials

🧪 API Routes

POST /entries

GET /entries/{entryId}

💥 Problems Encountered

AccessDenied

Incorrect table name

Malformed JSON

API integration errors

🔎 Troubleshooting

Describe how each problem was isolated and resolved.

📚 Lessons Learned

Explain what you actually understand now that you did not understand before.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📸 Add Evidence to Your GitHub Project

Useful screenshots could include:

🏗️ Architecture diagram

🗄️ DynamoDB table structure

⚡ Lambda function configuration

🌐 API Gateway routes

📊 CloudWatch logs

🧪 Successful API test

🚨 One failed test and its resolution

But be careful.

Do not expose:

❌ Access keys

❌ Secret keys

❌ Tokens

❌ Passwords

❌ Sensitive account data

❌ Private information

Screenshots should prove your work without leaking credentials.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🎤 Turn the Project Into an Interview Story

Instead of saying:

“I know Lambda and DynamoDB.”

You could say:

“I built a serverless Student Learning Tracker API using API Gateway, Lambda, DynamoDB, IAM, and CloudWatch. API Gateway exposed POST and GET routes, Lambda handled the application logic, and DynamoDB stored the records. I configured the Lambda execution role with only GetItem and PutItem permissions for the required table. During testing I intentionally removed PutItem, reproduced an AccessDeniedException, used CloudWatch logs to identify the authorization failure, restored the least-privilege permission, and verified the API again.”

That one project demonstrates:

⚡ Lambda

🌐 APIs

🗄️ Databases

🔐 IAM

📊 Monitoring

🔎 Troubleshooting

🧠 Architecture thinking

🗣️ Technical communication

That is much stronger than simply saying:

“Familiar with AWS.”

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🧩 How This Connects to AWS Certification Learning

This project helps turn several certification concepts into something real.

When you study:

AWS Lambda

you now remember the function you deployed.

When you study:

IAM roles

you remember the execution role that needed DynamoDB permissions.

When you study:

DynamoDB

you remember your table and partition key.

When you study:

API Gateway

you remember the HTTP routes.

When you study:

CloudWatch

you remember reading logs after an application failure.

Theory becomes easier to remember when it has a story attached to it.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🚀 Where You Can Take This Project Next

Once the basic API works, you can extend it gradually.

Possible Version 2 features:

✏️ Update an entry

DELETE /entries/{entryId}

🗑️ Delete an entry

DELETE /entries/{entryId}

📋 List learning entries

GET /entries

🔎 Filter by student or topic

👤 Add authentication

🌐 Build a frontend

📊 Add custom monitoring

🔐 Improve authorization

🏗️ Deploy through Infrastructure as Code

Do not add all of these on Day 1.

Build in layers.

Version 1 should teach you the foundation.

Version 2 should teach you the next problem.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🧹 Clean Up When You Finish

Cloud learning also means knowing how to remove infrastructure.

When you no longer need the lab:

🗑️ Remove the API Gateway API.

🗑️ Delete the Lambda function.

🗑️ Delete the DynamoDB table if the data is no longer needed.

🗑️ Remove unnecessary IAM policies and roles.

📊 Review CloudWatch log groups.

💰 Check your billing dashboard.

A project is not finished until you understand its lifecycle.

Create.

Operate.

Troubleshoot.

Clean up.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🌱 The Bigger Lesson

At first, this project looks like:

“Build a Lambda function.”

But it is actually teaching much more.

🌐 API Gateway teaches you how clients reach backend logic.

⚡ Lambda teaches event-driven compute.

🗄️ DynamoDB teaches managed NoSQL storage.

🔐 IAM teaches service-to-service authorization.

📊 CloudWatch teaches observability.

💥 Failures teach troubleshooting.

📝 GitHub teaches documentation.

🎤 Explaining the project teaches communication.

One project.

Multiple skills.

That is why I prefer learning AWS through small systems instead of memorizing isolated service definitions.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🎯 Final Thoughts

You do not need to build the next massive cloud platform to start learning serverless architecture.

Start with:

One API.

One Lambda function.

One DynamoDB table.

One IAM role.

A few routes.

Some logs.

Then make it work.

Break it.

Understand why it broke.

Fix it.

Document what you learned.

That cycle matters more than simply getting a green success message.

The real goal is not:

“I followed a Lambda tutorial.”

The goal is:

“I understand how an HTTP request travels through my AWS architecture, what permissions each component requires, where failures can occur, and how I would troubleshoot them.”

That is practical cloud learning.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

☁️ Your Turn

Imagine this scenario:

🌐 API Gateway receives the request.

⚡ Lambda runs.

📊 CloudWatch confirms the function was invoked.

🗄️ The DynamoDB table exists.

But Lambda returns:

AccessDeniedException

What would you investigate first?

🎭 The Lambda execution role?

⚙️ The DynamoDB action?

📦 The table ARN?

🌎 The Region?

📜 An explicit deny?

Or something else?

💬 Share how you would troubleshoot it.

And if you build your own serverless project:

Do not just share the finished architecture.

Share the problem that taught you the most. 🚀

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📚 Official AWS References

AWS Lambda + API Gateway Tutorial:
https://docs.aws.amazon.com/lambda/latest/dg/services-apigateway-tutorial.html

AWS Lambda Execution Roles:
https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html

AWS Lambda CloudWatch Logs:
https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html

Amazon DynamoDB Getting Started:
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GettingStartedDynamoDB.html

AWS Student Rewards: A Practical Starting Guide for Students Building a Cloud Career ☁️🧑🏻‍💻

Randy M. Alonzo — Sun, 06 Sep 2026 04:50:32 +0000

🎓 Why AWS Student Rewards caught my attention

If you're a university student interested in cloud computing, IT, cybersecurity, DevOps, data, or artificial intelligence, AWS Student Rewards is worth understanding.

The program combines something I think is especially useful for students:

Learning + hands-on practice + community participation + certification preparation.

Instead of simply completing a course and moving on, students can participate in AWS Builder Center, earn community badges, receive learning benefits, gain AWS Credits, and work toward an AWS Foundational Certification exam voucher.

But there are several details worth understanding before starting.

☁️ What is AWS Student Rewards?

AWS Student Rewards is a program available through AWS Builder Center for eligible, verified higher-education students.

The journey is roughly:

Verify student status
↓
Complete your Builder Center profile
↓
Unlock AWS Skill Builder Premium
↓
Participate in Builder Center
↓
Earn badges
↓
Reach Student Rewards milestones
↓
Work toward an AWS Foundational Certification

AWS currently uses SheerID for student verification. Most verification attempts may be completed quickly, while some students can be asked for additional documentation.

Official AWS Student Rewards announcement:
https://builder.aws.com/content/3I1qkUtKhwU6K1VaGkfYRwtbz3o/introducing-student-rewards-on-aws-builder-center

🎁 What can verified students earn?

The current Student Rewards structure is:

Student verification + completed profile
→ 12 months of AWS Skill Builder Premium

7 Builder Center badges
→ $10 AWS Credits

14 Builder Center badges
→ Additional $20 AWS Credits

21 Builder Center badges
→ AWS Foundational Certification exam voucher

That means the badge milestones can provide a total of $30 in AWS Credits, while the 21-badge milestone unlocks the certification exam voucher.

The 12-month Skill Builder Premium benefit is especially interesting because AWS says it includes access to 900+ courses, hands-on labs, certification preparation, and game-based learning.

🏅 What are the 21 badges?

This is an important distinction.

The badges involved in Student Rewards are AWS Builder Center community/activity badges.

They are not the same as:

• AWS Certifications
• Skill Builder course-completion badges
• Certification exam badges
• Technical credentials

Builder Center badges can be earned through activities such as publishing articles, commenting, maintaining engagement, completing profile activities, and participating in the community.

So I would not approach the program as:

“How can I collect 21 badges as quickly as possible?”

A better mindset is:

Learn → participate → build → document → help others → earn badges naturally.

That makes the time spent on Builder Center valuable even beyond the rewards.

🚀 How I would start

Use an AWS Builder ID you plan to keep

Try to avoid creating unnecessary duplicate accounts.

Your badges, profile activity, articles, Wishes, and Student Rewards progress are things you may want associated with one long-term Builder Center identity.

Keeping everything organized from the beginning can prevent confusion later.

Complete student verification

Go through the official Student Rewards verification process and provide accurate information.

Pay particular attention to your:

• Full name
• University or college
• Email address
• Enrollment information

Your information should match your legitimate student records as closely as possible.

AWS currently uses SheerID to perform the verification.

⚠️ What if student verification fails?

A failed automated verification does not necessarily mean the end of the process.

Some verification attempts may require additional documentation.

If you encounter a problem, I recommend:

Check that your information matches your university records.
Follow the instructions provided during verification.
Contact the appropriate verification support channel when necessary.
Keep any case or reference numbers.
Avoid repeated verification attempts across unnecessary accounts.
Keep your primary AWS Builder Center identity consistent.

This is one part of the process I am learning about myself, and I think documenting these challenges can also help future students avoid the same confusion.

📚 Use Skill Builder before you receive the exam voucher

One mistake would be waiting until badge 21 before studying.

If you successfully unlock the 12-month Premium benefit, start learning immediately.

Use it to build foundational knowledge around areas such as:

• AWS Cloud concepts
• Compute
• Storage
• Networking
• Databases
• Identity and security
• Cloud economics
• Artificial intelligence
• Machine learning
• Generative AI

The certification voucher should be the result of your learning journey, not the beginning of it.

☁️ Which certification could you work toward?

AWS currently has Foundational-level certifications including:

AWS Certified Cloud Practitioner

A strong starting point for people who want broad knowledge of the AWS Cloud, including services, security, architecture concepts, pricing, billing, and cloud fundamentals.

AWS Certified AI Practitioner

A foundational credential focused on AI, machine learning, generative AI, foundation models, responsible AI, security, compliance, and AWS AI concepts.

AWS Certified AI Practitioner documentation:
https://docs.aws.amazon.com/aws-certification/latest/ai-practitioner-01.html

The Student Rewards benefit is described by AWS as a Foundational Certification exam voucher.

Before scheduling an exam, always check the terms associated with the voucher you actually receive.

🛠️ Don't stop at certification preparation

Certifications can help demonstrate structured knowledge.

But practical experience makes that knowledge much stronger.

If you're studying AWS, try combining your learning with small projects.

For example:

Learn Amazon S3

→ Build a static website or storage project.

Learn Amazon EC2

→ Deploy and configure a small virtual server.

Learn AWS Lambda

→ Build a simple serverless function.

Learn IAM

→ Practice users, roles, permissions, and least-privilege concepts.

Learn databases

→ Build something using an AWS database service.

Then document what you did.

A student portfolio containing:

AWS Certification + Projects + GitHub + Technical Articles

can communicate much more than a certification badge by itself.

✍️ Builder Center can become part of your portfolio

Publishing articles here isn't only about earning badges.

It is also an opportunity to practice explaining technical concepts.

You could write about:

• Something you learned in AWS Skill Builder
• A project you completed
• An AWS service you experimented with
• A problem you encountered
• A certification topic you finally understood
• Mistakes you made while building
• Advice for other students starting with AWS

Being able to explain what you learned clearly is itself a valuable professional skill.

🧠 Don't chase badges without gaining skills

The rewards are attractive.

AWS Credits? Useful.

Skill Builder Premium? Valuable.

Certification exam voucher? Definitely worth pursuing.

But the greatest value comes from what you can do after earning them.

Instead of optimizing only for:

“How quickly can I get 21 badges?”

I would rather optimize for:

“How much stronger can my AWS knowledge become while earning those 21 badges?”

That difference matters.

🌱 A better student cloud roadmap

My personal approach would look something like this:

Verify

Confirm student eligibility.

Learn

Use AWS Skill Builder.

Build

Create small hands-on AWS projects.

Participate

Contribute genuinely to Builder Center.

Document

Write articles and project notes.

Prepare

Study systematically for the certification exam.

Certify

Use the voucher when properly prepared.

Continue building

Move beyond foundational knowledge into deeper AWS skills.

That turns Student Rewards into something much bigger than a voucher.

🎯 Final thoughts

AWS Student Rewards gives students an interesting opportunity to combine education, community, practical cloud learning, and certification preparation in one ecosystem.

I'm currently going through this journey myself.

My goal isn't simply to reach 21 badges.

I want to use the process to:

• Learn AWS properly
• Build practical cloud projects
• Improve my technical communication
• Document what I learn
• Prepare for an AWS certification
• Create evidence of real skills that I can eventually show employers

The certification voucher may be one of the rewards at the end of the journey.

But the knowledge, projects, documentation, and experience developed along the way can be worth even more.

☁️ What about you?

If you're participating in AWS Student Rewards:

Which AWS Foundational Certification are you planning to pursue?

And more importantly:

What are you planning to build with AWS while working toward it?

Let's learn, build, and grow together. 🚀