AWS · Lab

AWS Serverless Event Registration System

An asynchronous event registration workflow on AWS with user confirmation and administrator notifications.

AWSLambdaAPI GatewayDynamoDBSQSSESSNS

Role: Cloud Engineer
Timeline: June 2026
Type: Lab
Status: Completed
Infrastructure: AWS · Lambda · API Gateway
Repository: github.com

Problem

Accept registrations quickly, persist their state, and send notifications without keeping the original HTTP request open during email delivery.

A static frontend submits registrations through API Gateway. Separate Lambda functions record the request and process notifications through a queue.

Constraints

The original lab was provisioned through the AWS Console
SES Sandbox requires verified identities
AWS account IDs and private endpoints must remain confidential

Success criteria

The API returns a registration ID and persists a QUEUED record
SQS invokes the sender independently
SES and SNS complete notifications before the state changes to SENT

Architecture

The architecture separates clear responsibilities so each component can be tested, operated, and changed independently.

Amplify + API Gateway

Hosts the static form and exposes the POST /register REST endpoint.

Lambda + DynamoDB

Validates input, creates a registration ID, and stores the QUEUED state.

SQS + SES + SNS

Processes notifications asynchronously and updates the record to SENT.

Implementation

The work is organized into phases with explicit tools and verifiable outputs.

Design
Design the asynchronous workflow
Separate registration intake from notification delivery.
Tools: API Gateway · SQS · Output: Architecture and state flow
Provision
Create AWS resources
Configure DynamoDB, SQS, SNS, SES, API Gateway, and execution roles.
Tools: AWS Console · IAM · Output: Lab environment in us-east-1
Build
Build two Lambda functions
The registration function validates and queues requests; the sender delivers notifications and updates state.
Tools: AWS Lambda · Python 3.13 · Output: Lambda handlers and registration frontend
Secure
Separate permissions
Each Lambda receives only the permissions required for its responsibilities.
Tools: AWS IAM · Output: Two least-privilege IAM policies
Observe
Trace processing
CloudWatch Logs records registration and notification processing.
Tools: CloudWatch Logs · Output: Per-function logs
Optimize
Prepare the next iteration
Document IaC, dead-letter queues, alarms, and automated tests as follow-up work.
Tools: AWS SAM · Terraform · Output: Improvement backlog

Technical decisions

Decision	Choice	Reason
Asynchronous processing	Amazon SQS	Decouples email delivery from registration intake.
State storage	Amazon DynamoDB	Stores the QUEUED to SENT lifecycle without server management.
Notification channels	SES + SNS	Separates user confirmation from administrator notification.

Security

These items describe concrete controls or work that still requires verification.

Each Lambda uses a dedicated IAM role and policy.
Input is validated and credentials are never committed.
Wildcard CORS is limited to the demo and should be restricted in production.

Observability

CloudWatch Logs is enabled for both Lambda functions.
A dead-letter queue and CloudWatch alarms are documented as follow-up work.

Results

Completed the flow from registration form to DynamoDB, SQS, SES, and SNS.
The repository includes application code, IAM policies, deployment steps, testing guidance, and cleanup instructions.

Challenges and lessons learned

Challenge

Sending email during the registration request would increase latency and couple two responsibilities.

Approach

Queue the payload in SQS and use a dedicated sender Lambda.

Lesson

Queues improve separation, but production workloads also need a DLQ and alarms.