Serverless Data — AWS Learning Lab

Problem

A successful API response did not preserve the message.

The serverless API could receive a contact submission, but the data disappeared when the Lambda invocation ended.

This lab added durable storage while keeping the same event-driven request path. It also exposed an important distinction: writing the correct code does not automatically grant the code permission to use an AWS resource.

Architecture

The API writes through an authorized function.

Persistence path

Contact formSubmission JSON

API GatewayPOST /contact

LambdaPython handler

IAM roleAllow dynamodb:PutItem

DynamoDBContact submissions

The IAM policy does not move data. It authorizes the Lambda execution role to perform one required operation against the intended table.

Lambda transforms the incoming request into an item and calls DynamoDB. AWS evaluates that call against the function’s execution-role policies before DynamoDB accepts the write.

Build

Added storage, then fixed the authorization boundary.

01
Created the DynamoDB table
Added a managed NoSQL data store for contact submissions without introducing a database server to operate.
02
Extended the Lambda handler
Updated the Python function to write each accepted submission to DynamoDB before returning success.
03
Diagnosed the failed write
The first write returned AccessDeniedException for dynamodb:PutItem. The function ran, but its execution role was not authorized to write.
04
Applied least privilege
Added a policy to the Lambda execution role granting the required PutItem action on the intended table rather than broad DynamoDB access.

What I Tested

A submission now survives the request.

01
End-to-end persistence
Submitted the website form and verified that the API completed successfully and the contact record appeared in DynamoDB.
02
Permission failure
Observed the original denied write, identified dynamodb:PutItem as the missing action, and confirmed the request succeeded after the role policy was corrected.
03
Existing browser behavior
Confirmed the persistence change did not break validation, CORS, or the success and error states from the previous API lab.

What I Learned

Identity and permissions are part of application behavior.

01
Execution roles are the function’s AWS identity.
Lambda can only call the services and actions allowed to that role, regardless of what the application code attempts.
02
Access-denied errors are specific evidence.
The caller, resource, and denied action in the error message turn IAM troubleshooting into a focused permissions check.
03
Least privilege can be practical.
The fix did not require administrator access. The function needed one write action against one data resource.