DEV Community: Kehinde Abiuwa

Wiring Together a Three-Tier Serverless Web App on AWS (And the CORS Bug That Broke Everything)

Kehinde Abiuwa — Wed, 17 Jun 2026 21:14:55 +0000

After three parts of building individual pieces — a CloudFront frontend, a Lambda API, and a DynamoDB data layer — we now have three working components that have never actually spoken to each other.

This is the part where you find out if your architecture actually holds together. And almost always, the answer is: "not yet, there is a CORS error."

This is the final part of the series. We wire everything together, debug the inevitable integration failures, and end up with a working end-to-end serverless web application on AWS.

All three tiers finally wired together into one working application.

The Complete Architecture

User's Browser
     │
     ▼
Amazon CloudFront  ◄────── S3 Bucket (private, OAC)
     │                     [index.html, style.css, script.js]
     │  GET /users?userId=1
     ▼
Amazon API Gateway (REST API, /prod stage)
     │  Lambda Proxy Integration
     ▼
AWS Lambda (RetrieveUserData)
     │  dynamodb:GetItem  [IAM inline policy, scoped to table ARN]
     ▼
Amazon DynamoDB (UserData table, On-Demand)
     │
     └── { userId: "1", name: "Test User", email: "test@example.com" }

Each tier is independently scalable, independently deployable, and locked down with least-privilege IAM.

The complete three-tier architecture — S3/CloudFront frontend, API Gateway + Lambda logic tier, and DynamoDB data tier.

Step 1: Connect the Presentation Tier to the Logic Tier

The frontend (script.js) has a placeholder URL:

const API_URL = "https://YOUR-API-ID.execute-api.YOUR-REGION.amazonaws.com/prod/users";

I replaced this with the real API Gateway Invoke URL, re-uploaded script.js to S3, and opened the CloudFront URL in my browser.

Immediately: a console error.

Failed to fetch
TypeError: Failed to fetch
    at fetchUser (script.js:14)

Not a CORS error — a completely failed fetch. The URL was still the placeholder because CloudFront was serving the old cached version of script.js.

CloudFront Cache Invalidation

When you update a file in S3, CloudFront continues serving the cached version from its edge locations until the TTL expires (default: 24 hours for the CachingOptimized policy). You need to manually invalidate the cache to force a refresh:

aws cloudfront create-invalidation \
  --distribution-id YOUR-DISTRIBUTION-ID \
  --paths "/script.js"

Or invalidate everything:

aws cloudfront create-invalidation \
  --distribution-id YOUR-DISTRIBUTION-ID \
  --paths "/*"

After the invalidation, I reloaded the page. New error.

Step 2: The CORS Error

Access to fetch at 'https://abc123.execute-api.eu-north-1.amazonaws.com/prod/users?userId=1'
from origin 'https://d1234abcd.cloudfront.net' has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on the requested resource.

This is the most common error in serverless web app development. Let me explain exactly what is happening.

The browser console blocking the request — no Access-Control-Allow-Origin header present.

What CORS Actually Is

CORS (Cross-Origin Resource Sharing) is a browser security mechanism. A browser will refuse to complete a request from origin-A.com to origin-B.com unless origin-B.com explicitly says "I allow requests from origin-A.com." It does this by returning an Access-Control-Allow-Origin header.

In our case:

Frontend origin: https://d1234abcd.cloudfront.net
API origin: https://abc123.execute-api.eu-north-1.amazonaws.com

These are different origins (different hostnames). The browser blocks the API call until the API starts returning the right headers.

This is a browser-enforced mechanism. CORS has no effect on server-to-server requests (curl, Postman, Lambda-to-Lambda). It only applies when a browser makes a cross-origin request. This is why your API worked fine in Postman but fails in the browser.

The Two Places CORS Must Be Configured

With Lambda Proxy Integration, CORS must be configured in two places. Most tutorials only mention one of them.

Place 1: API Gateway

In API Gateway, you enable CORS on the resource. This handles the preflight OPTIONS request that the browser sends before the actual GET. Configure it with:

Access-Control-Allow-Origin: https://d1234abcd.cloudfront.net
Access-Control-Allow-Methods: GET,OPTIONS
Access-Control-Allow-Headers: Content-Type,Authorization

Place 2: Lambda function

With proxy integration, API Gateway passes the raw Lambda response directly to the browser. It does not add any headers that are not in the Lambda response itself. So if your Lambda does not include CORS headers in its response, the browser gets a response without Access-Control-Allow-Origin and blocks it.

Your Lambda must return CORS headers on every response:

const CORS_HEADERS = {
  "Access-Control-Allow-Origin": process.env.ALLOWED_ORIGIN ?? "*",
  "Access-Control-Allow-Methods": "GET,OPTIONS",
  "Access-Control-Allow-Headers": "Content-Type,Authorization",
};

const response = (statusCode, body) => ({
  statusCode,
  headers: { "Content-Type": "application/json", ...CORS_HEADERS },
  body: JSON.stringify(body),
});

The handler must also respond to OPTIONS:

if (event.httpMethod === "OPTIONS") {
  return { statusCode: 200, headers: CORS_HEADERS, body: "" };
}

This is documented in the AWS docs but buried. The conceptual model to remember is: API Gateway handles the preflight. Lambda handles the actual response headers.

Enabling CORS on the API Gateway resource — one of the two places it must be configured.

How Browser CORS Preflight Works

For any cross-origin request with a non-simple method or custom headers, the browser first sends an OPTIONS request:

OPTIONS /users HTTP/1.1
Host: abc123.execute-api.eu-north-1.amazonaws.com
Origin: https://d1234abcd.cloudfront.net
Access-Control-Request-Method: GET
Access-Control-Request-Headers: content-type

Your API must respond:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://d1234abcd.cloudfront.net
Access-Control-Allow-Methods: GET,OPTIONS
Access-Control-Allow-Headers: Content-Type,Authorization

Only then does the browser proceed with the actual GET request. And that GET response must also include Access-Control-Allow-Origin or the browser blocks it even after the preflight succeeded.

Step 3: Verifying End-to-End

After fixing both CORS locations, I:

Redeployed the API Gateway stage (changes to the resource CORS configuration require a new deployment)
Re-uploaded script.js to S3
Ran another CloudFront invalidation
Reloaded the CloudFront URL

Then typed 1 in the User ID field and clicked the button.

{
  "userId": "1",
  "name": "Test User",
  "email": "test@example.com"
}

The Network tab showed:

OPTIONS /users → 200 (preflight)
GET /users?userId=1 → 200 (actual request)

The full three-tier stack was working end-to-end.

The fixed solution — OPTIONS and GET both return 200 and the user data renders.

Deployment Checklist

Here is the checklist I now follow whenever I update any component of this stack:

Change	Actions required
Update `script.js`	Re-upload to S3, create CloudFront invalidation for `/script.js`
Update `index.html`	Re-upload to S3, create CloudFront invalidation
Update Lambda code	Deploy new function version (console or CLI)
Update Lambda env vars	No redeployment needed
Update API Gateway routes	Must create a new Deployment and associate with stage
Update IAM policies	Takes effect immediately

The CloudFront invalidation step is the one people forget most often. After wondering why your changes are not showing up, run aws cloudfront create-invalidation --paths "/*" — that will usually be the fix.

Architecture Decisions: What I Would Do Differently in Production

1. Use a Custom Domain

The CloudFront URL (d1234abcd.cloudfront.net) is not something you want in a production app. You would:

Register a domain in Route 53 (or bring your own)
Request an ACM certificate (free, in us-east-1 for CloudFront)
Add a CNAME alias to your CloudFront distribution
Update the ALLOWED_ORIGIN env var on Lambda to your real domain
Never use "*" for Access-Control-Allow-Origin in production

2. Lock Down CORS

In the code, ALLOWED_ORIGIN defaults to "*". This is fine for development. In production, this should be your specific CloudFront domain. This ensures that other sites cannot trigger your API with a user's browser credentials.

3. Add Structured Logging

The current CloudWatch logs are unstructured strings. For a production API, I would use structured JSON logging:

console.log(JSON.stringify({
  level: "info",
  userId,
  durationMs: Date.now() - startTime,
  found: !!result.Item
}));

This makes CloudWatch Logs Insights queries much more powerful.

4. Add a CloudWatch Alarm on Lambda Errors

aws cloudwatch put-metric-alarm \
  --alarm-name "LambdaErrorRate" \
  --metric-name Errors \
  --namespace AWS/Lambda \
  --dimensions Name=FunctionName,Value=three-tier-app-retrieve-user-data \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 \
  --period 60 \
  --statistic Sum \
  --alarm-actions arn:aws:sns:region:account:my-alert-topic

5. Deploy with Infrastructure as Code

The CloudFormation template in this repository (infrastructure/cloudformation/three-tier-stack.yaml) provisions the entire stack — S3, CloudFront, DynamoDB, Lambda, API Gateway, IAM — in a single command:

aws cloudformation deploy \
  --template-file infrastructure/cloudformation/three-tier-stack.yaml \
  --stack-name three-tier-app \
  --capabilities CAPABILITY_NAMED_IAM \
  --parameter-overrides ProjectName=three-tier-app

Tearing it all down is equally simple:

aws cloudformation delete-stack --stack-name three-tier-app

This is one of the biggest operational advantages of IaC: reproducibility. You can spin up an identical copy of this environment in any region in minutes.

What I Learned From This Series

CORS is a browser mechanism, not an API mechanism. It cannot be tested with curl alone. Always test from a browser when cross-origin requests are involved.
CloudFront caching is aggressive by default. Develop a habit of running cache invalidations after every frontend update, or use asset hashing (main.abc123.js) so updated files have new names and old ones can be cached forever.
Least-privilege IAM is practical, not academic. Scoping a Lambda role to dynamodb:GetItem on a specific table ARN takes three minutes and meaningfully reduces your blast radius.
OAC is the correct way to serve S3 content via CloudFront. There is no reason to make an S3 bucket public if CloudFront is in front of it.
CloudFormation templates are their own documentation. The template in this repository tells you exactly what was provisioned, how components relate to each other, and what every configuration choice was.

Repository

Everything covered in this series is in the GitHub repository:

aws-three-tier-serverless/
├── frontend/          # index.html, style.css, script.js
├── backend/lambda/    # Lambda function code (Node.js ESM)
├── infrastructure/
│   ├── cloudformation/   # Full CloudFormation stack
│   ├── iam/              # IAM policy documents
│   └── s3-bucket-policy.json
└── docs/articles/     # This article series

aws-three-tier-serverless on GitHub

Kehinde Abiuwa — AWS Certified Solutions Architect (Professional) | Microsoft AZ-305

Open to Solutions Architect roles (remote/hybrid).

Least-Privilege IAM for Lambda: Why I Replaced the AWS Managed Policy With My Own

Kehinde Abiuwa — Wed, 17 Jun 2026 21:14:43 +0000

There is a moment in almost every AWS tutorial where the author says "attach AmazonDynamoDBFullAccess to your Lambda role" and moves on.

I understand why. It is fast. It makes the tutorial work. And for a throwaway demo it probably does not matter.

But if you are building anything real, you have just handed your serverless function the keys to every DynamoDB table in your account — including the ability to delete them.

In this article, I want to do something slightly different. I will show you the journey I took: start with the broad managed policy that AWS recommends, understand why it is wrong for production, and then tighten it down to the minimum permissions the function actually needs. This is the most important security lesson I learned while building this three-tier app.

Where We Are in the Series

This is Part 3 of a four-part series building a serverless web app on AWS:

Part	Topic
1	S3 + CloudFront (frontend delivery)
2	Lambda + API Gateway (the REST API)
3	DynamoDB + Least-Privilege IAM (data tier + security)
4	Wiring everything together

In Part 2 we built a Lambda function that calls DynamoDB. We intentionally left IAM incomplete — the function would throw AccessDenied if you called it. This part fixes that properly.

Step 1: Set Up the DynamoDB Table

The data tier is a single DynamoDB table named UserData.

Table design:

Attribute	Type	Role
`userId`	String	Partition key

That is the entire schema — because DynamoDB is schemaless. Each item can have whatever attributes you want. Only the partition key (userId) must be present.

Why userId as the partition key?

DynamoDB stores and retrieves items by their partition key. With userId as the key, looking up a specific user is an O(1) GetItem operation — constant time regardless of how many users are in the table. If we modelled this as a relational table and queried by a non-indexed column, we would be doing a full table scan.

Capacity mode: I used On-Demand (PAY_PER_REQUEST). No need to predict throughput. DynamoDB scales automatically and you pay only for what you use. For a production app with predictable traffic, Provisioned capacity with Auto Scaling is more cost-efficient.

The UserData table created in DynamoDB with userId as the partition key.

Seed data:

{
  "userId": "1",
  "name": "Test User",
  "email": "test@example.com"
}

Step 2: The First IAM Mistake (Intentional)

With the table created, I attached a permission policy to the Lambda execution role.

AWS shows you six DynamoDB-related managed policies. Two of them look like they are for Lambda + DynamoDB:

AWSLambdaDynamoDBExecutionRole
AWSLambdaInvocation-DynamoDB

Do not use either of these. They sound right but are designed for a completely different pattern — DynamoDB Streams, where DynamoDB pushes events to Lambda. They do not grant dynamodb:GetItem on a table. Attaching them does nothing for our use case.

The DynamoDB-related managed policies AWS offers when attaching permissions to the role.

So I attached AmazonDynamoDBReadOnlyAccess instead. And it worked. The Lambda could now retrieve user records.

But I was not done.

The intentional first mistake — attaching the broad AmazonDynamoDBReadOnlyAccess managed policy.

Step 3: Understanding What `AmazonDynamoDBReadOnlyAccess` Actually Allows

Let me show you what this managed policy actually grants:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:BatchGetItem",
        "dynamodb:ConditionCheckItem",
        "dynamodb:DescribeExport",
        "dynamodb:DescribeGlobalTable",
        "dynamodb:DescribeGlobalTableSettings",
        "dynamodb:DescribeImport",
        "dynamodb:DescribeKinesisStreamingDestination",
        "dynamodb:DescribeTable",
        "dynamodb:DescribeTableReplicaAutoScaling",
        "dynamodb:DescribeTimeToLive",
        "dynamodb:GetItem",
        "dynamodb:GetRecords",
        "dynamodb:GetShardIterator",
        "dynamodb:ListContributorInsights",
        "dynamodb:ListExports",
        "dynamodb:ListGlobalTables",
        "dynamodb:ListImports",
        "dynamodb:ListStreams",
        "dynamodb:ListTables",
        "dynamodb:ListTagsOfResource",
        "dynamodb:Query",
        "dynamodb:Scan",
        "dynamodb:GetResourcePolicy"
      ],
      "Resource": "*"
    }
  ]
}

That "Resource": "*" means every DynamoDB table in the account. And the action list includes Scan — which can read every item in every table. It also includes ListTables, DescribeTable, and more.

My Lambda function does exactly one thing: call GetItem on the UserData table. The gap between what the function needs and what this policy grants is enormous.

Step 4: Writing the Least-Privilege Inline Policy

I replaced the managed policy with a custom inline policy scoped to exactly what the function needs:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DynamoDBGetItemOnly",
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem"
      ],
      "Resource": "arn:aws:dynamodb:eu-north-1:123456789012:table/UserData"
    },
    {
      "Sid": "CloudWatchLogs",
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:eu-north-1:123456789012:log-group:/aws/lambda/*"
    }
  ]
}

Two statements. That is all.

The custom inline policy scoped to dynamodb:GetItem on the UserData table only.

dynamodb:GetItem — on the specific UserData table ARN only. No other tables. No other actions.
CloudWatch Logs — so the function can write its execution logs.

Why an inline policy instead of a new managed policy?

Inline policies are attached directly to the role and cannot be accidentally shared with another role. For narrow, function-specific permissions like this, inline is the right choice. Managed policies are better suited for shared, reusable permission sets (like "all Lambda functions need CloudWatch Logs access").

Step 5: Validating the Change

After attaching the inline policy, I re-ran the Lambda test event:

{ "userId": "1" }

Result:

{
  "statusCode": 200,
  "body": "{\"email\":\"test@example.com\",\"name\":\"Test User\",\"userId\":\"1\"}"
}

Then I removed the managed policy. Tested again. Same result.

Then I deliberately tested an error case — a userId that does not exist in the table:

{ "userId": "999" }

Result:

{
  "statusCode": 404,
  "body": "{\"error\":\"No user found with userId: 999\"}"
}

And I checked CloudWatch Logs to confirm there were no AccessDenied errors anywhere.

The Lambda test returning 200 with the user item — confirming the scoped policy works.

Why This Matters Beyond Theory

The principle of least privilege is not just a compliance checkbox. It has real security implications:

Blast radius reduction: If this Lambda function is ever exploited — through a code injection vulnerability, a dependency supply chain attack, or a misconfiguration — the attacker can only call GetItem on UserData. They cannot read your other tables, scan your entire database, or list your table names to understand your data model.

Auditability: When someone reads the IAM policy attached to this function, they immediately understand exactly what it does and what it can access. A "Resource": "*" with 25 actions tells you nothing about intent.

Easier incident response: If you get a security alert about unusual DynamoDB activity and you know the only thing that can touch UserData with GetItem is the RetrieveUserData Lambda, your investigation is much more focused.

Common IAM Mistakes to Avoid

Mistake	Why It Matters
`"Resource": "*"` on data services	Grants access to every table/bucket/secret in the account
Using `FullAccess` managed policies for read-only functions	Allows writes and deletes your function will never need
Not scoping CloudWatch Logs to the function's log group	Allows the function to write to any log group
Attaching policies to users instead of roles	Violates the principle of using roles for service-to-service auth
Not removing unused permissions when code changes	Accumulated permissions that were once needed but no longer are

The DynamoDB Data Model — Key Concepts

Since we are in the data tier, it is worth briefly covering the DynamoDB concepts that matter here:

Partition key (Hash key): Determines which partition of DynamoDB's distributed storage your item lives on. Choose a partition key with high cardinality (many distinct values) to distribute load evenly. userId works well — each user has a unique ID.

GetItem vs Query vs Scan:

Operation	Use case	Cost
`GetItem`	Retrieve exactly one item by its primary key	0.5 RCU per read
`Query`	Retrieve multiple items by partition key + sort key condition	Scales with result set
`Scan`	Read every item in the table	Expensive — avoid in production

Our function uses GetItem with userId as the key. This is the most efficient possible read operation for this use case.

On-demand vs Provisioned capacity:

On-demand billing means DynamoDB handles scaling automatically. You pay per request. Good for unpredictable workloads. Provisioned capacity lets you set read/write capacity units and is cheaper at predictable, high volume. You can switch between modes once per 24 hours.

What's Next

In the final part, we wire all three tiers together — connecting the CloudFront frontend to the API Gateway backend, solving the CORS issues that arise when your frontend and backend live on different domains, and invalidating the CloudFront cache after updating the frontend files.

Part 4 — Building the Complete Three-Tier Web App — coming next in this series.

Architecture Diagram

Code for this series: aws-three-tier-serverless on GitHub

Kehinde Abiuwa — AWS Certified Solutions Architect (Professional) | Microsoft AZ-305

Building a Serverless REST API with AWS Lambda and API Gateway

Kehinde Abiuwa — Wed, 17 Jun 2026 21:13:59 +0000

Part 2 of 4 — Part 1: Static Hosting with S3 and CloudFront | Part 2: Lambda + API Gateway (you are here) | Part 3: DynamoDB and IAM | Part 4: Full App Integration and CORS

The first time I hit a "Missing Authentication Token" error from API Gateway, I assumed the problem was with authentication. So I spent twenty minutes checking IAM permissions, looking for a missing auth header, and rereading the API Gateway docs.

The problem had nothing to do with authentication. I had simply called the wrong URL — the API root instead of the resource path. The error message is genuinely misleading.

This is Part 2 of a four-part series where I build a serverless web app on AWS from scratch. In Part 1, I set up an S3 bucket and CloudFront distribution for the frontend. In this part, we are building the logic tier: a Lambda function wired to API Gateway that will form the backbone of the backend.

What We Are Building

A REST API with a single endpoint:

GET /users?userId={id}
→ Returns user data as JSON from DynamoDB (coming in Part 3)

The complete flow:

Browser / curl
    │
    ▼
API Gateway (REST API)
    │  Routes GET /users → Lambda proxy integration
    ▼
AWS Lambda (RetrieveUserData function)
    │  Queries DynamoDB for the requested userId
    ▼
Amazon DynamoDB
    │
    └── Returns JSON item → Lambda → API Gateway → Browser

Part 1: The Lambda Function

What Lambda Is — and Why It Makes Sense Here

Lambda is compute-on-demand. You give AWS your code, and AWS runs it only when something triggers it. You pay per 100ms of execution, not for idle time.

For a backend API serving variable load, this is compelling:

No servers to patch or scale
Cost is directly proportional to usage (free tier covers 1M requests/month)
The execution role (IAM) controls exactly what the function can access — nothing more

The Code

// backend/lambda/index.mjs
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, GetCommand } from "@aws-sdk/lib-dynamodb";

const client = new DynamoDBClient({ region: process.env.AWS_REGION });
const docClient = DynamoDBDocumentClient.from(client);

const CORS_HEADERS = {
  "Access-Control-Allow-Origin": process.env.ALLOWED_ORIGIN ?? "*",
  "Access-Control-Allow-Methods": "GET,OPTIONS",
  "Access-Control-Allow-Headers": "Content-Type,Authorization",
};

const response = (statusCode, body) => ({
  statusCode,
  headers: { "Content-Type": "application/json", ...CORS_HEADERS },
  body: JSON.stringify(body),
});

export const handler = async (event) => {
  if (event.httpMethod === "OPTIONS") {
    return { statusCode: 200, headers: CORS_HEADERS, body: "" };
  }

  const userId = event.queryStringParameters?.userId;

  if (!userId) {
    return response(400, { error: "Missing required query parameter: userId" });
  }

  try {
    const result = await docClient.send(
      new GetCommand({
        TableName: process.env.TABLE_NAME,
        Key: { userId },
      })
    );

    return result.Item
      ? response(200, result.Item)
      : response(404, { error: `No user found with userId: ${userId}` });
  } catch (err) {
    console.error("DynamoDB error:", err);
    return response(500, { error: "Internal server error" });
  }
};

Three things in this code that are worth understanding properly:

Why DynamoDBDocumentClient instead of DynamoDBClient directly?

The raw DynamoDBClient uses DynamoDB's type-annotated format: { userId: { S: "1" } }. The DynamoDBDocumentClient is a higher-level abstraction that marshals and unmarshals these types automatically, so you work with plain JavaScript objects. Always use DynamoDBDocumentClient unless you have a specific reason not to.

Why handle OPTIONS explicitly?

Modern browsers send a CORS preflight OPTIONS request before any cross-origin GET. If Lambda does not return a 200 with the correct headers on OPTIONS, the actual GET never fires. This is the CORS issue that bites nearly everyone building a serverless API for the first time — and we will cover it in depth in Part 4.

Why process.env.TABLE_NAME instead of a hardcoded table name?

Environment variables decouple your code from your infrastructure. When you deploy the same Lambda to a staging environment with a different table, you change the environment variable — not the code. This is a habit worth building from day one.

The RetrieveUserData Lambda function in the AWS console, showing runtime (Node.js 22), handler, and environment variables.

Part 2: API Gateway

REST API vs HTTP API

API Gateway offers two main flavours. HTTP API is newer, cheaper (~$1/million requests vs ~$3.50), and simpler to configure CORS on. REST API has more options: usage plans, request/response transformations, response caching, and WAF integration.

I am using a REST API here because it maps more directly to what most production APIs require, and the exam (Solutions Architect Professional) tests REST API configuration in detail. For a greenfield project today, I would lean towards HTTP API unless I specifically needed those REST API features.

Resources and Methods

An API is a tree of resources (URL paths) with HTTP methods attached:

/                 ← root resource
└── /users        ← our resource
    ├── GET       ← our method (→ Lambda)
    └── OPTIONS   ← CORS preflight (→ mock integration)

The UserRequestAPI REST API created in the API Gateway console.

The /users resource with its GET method wired to Lambda and OPTIONS configured for CORS preflight.

Lambda Proxy Integration

When you select Lambda Proxy Integration, API Gateway passes the entire HTTP request as a JSON event object to your Lambda and expects Lambda to return a properly shaped response (statusCode, headers, body). This is simpler and more flexible than mapping templates.

The event object Lambda receives looks like this:

{
  "httpMethod": "GET",
  "path": "/users",
  "queryStringParameters": {
    "userId": "1"
  },
  "headers": { "..." },
  "requestContext": { "..." }
}

Our handler reads event.httpMethod and event.queryStringParameters directly — that is the Lambda Proxy Integration contract in action.

Stages and Deployment

Every time you change your API configuration in API Gateway, those changes are not live until you deploy them to a stage. A stage is a named snapshot of your API with its own invoke URL:

https://abc123.execute-api.eu-north-1.amazonaws.com/prod
https://abc123.execute-api.eu-north-1.amazonaws.com/dev

Each stage can have different throttling limits, logging levels, and caching settings. I deployed to a stage named prod.

Deploying the API to the prod stage and the resulting invoke URL.

This is why "Missing Authentication Token" happens. If you call the root of the stage URL (/prod) instead of the resource path (/prod/users), API Gateway does not recognise the route and returns that error. Always include the full resource path.

Part 3: Testing the API

Before connecting the API to the frontend, I tested it directly with curl:

curl "https://abc123.execute-api.eu-north-1.amazonaws.com/prod/users?userId=1"

At this stage, DynamoDB is not set up yet — that is Part 3. But if the API Gateway → Lambda wiring is correct, you will get a JSON error response, not a 403 or an AWS XML error. A JSON response tells you the plumbing is connected and Lambda is running.

I also tested the Lambda function in isolation using the console test editor. Create a test event:

{
  "httpMethod": "GET",
  "queryStringParameters": {
    "userId": "1"
  }
}

This lets you confirm the function logic is working before adding the API Gateway layer to the debugging surface. Test the layers separately first.

Part 4: API Documentation

Once the API is deployed, I exported an OpenAPI (Swagger) specification directly from API Gateway. This gives you a machine-readable description of your entire API:

{
  "swagger": "2.0",
  "info": {
    "title": "UserRequestAPI",
    "version": "2024-01-01T00:00:00Z"
  },
  "host": "abc123.execute-api.eu-north-1.amazonaws.com",
  "basePath": "/prod",
  "schemes": ["https"],
  "paths": {
    "/users": {
      "get": {
        "produces": ["application/json"],
        "parameters": [
          {
            "name": "userId",
            "in": "query",
            "required": true,
            "type": "string"
          }
        ],
        "responses": {
          "200": { "description": "User data returned successfully" },
          "404": { "description": "User not found" }
        }
      }
    }
  }
}

This matters for two reasons:

Any developer consuming your API can understand the contract without asking you
You can import the spec into Postman, Insomnia, or Swagger UI for interactive testing and sharing

The OpenAPI (Swagger) spec exported directly from the API Gateway console.

Architecture Decisions and Trade-offs

Why not use an HTTP API instead of a REST API?

HTTP API is cheaper and has built-in CORS configuration (no manual OPTIONS method needed). For a new project today, I would use HTTP API. The REST API here was chosen to cover the full API Gateway feature surface and because the Solutions Architect Professional exam tests REST API configuration specifically.

Why not deploy the Lambda inside a VPC?

DynamoDB has a public endpoint — Lambda running outside a VPC can reach it without a NAT Gateway. Putting Lambda inside a VPC adds NAT Gateway cost (~$0.045/hour always-on) and configuration complexity without meaningful security benefit for this architecture. If DynamoDB were replaced with an RDS instance in a private subnet, VPC deployment would be required.

Why a single Lambda function for the entire API?

This function does one thing: retrieve a user by ID. Single-responsibility functions are easier to test, deploy independently, and grant precise IAM permissions to. As the app grows, write operations would get separate functions rather than expanding this one. One function per operation is the pattern.

Architecture Diagram

Logic tier: API Gateway routes requests to Lambda via proxy integration. Lambda will query DynamoDB in Part 3.

What's Next

In Part 3, we wire up the data tier: creating a DynamoDB table, seeding it with test records, and tightening the IAM policy from a broad managed policy down to a precise inline policy scoped to a single table and a single action — dynamodb:GetItem on UserData only.

Part 3 → Fetch Data with AWS Lambda and DynamoDB →

kehindeabiuwa-dotcom / aws-three-tier-serverless

Production-grade three-tier serverless web app on AWS — private S3 + CloudFront (OAC), Lambda + API Gateway REST API, and DynamoDB with least-privilege IAM. Deploys in one CloudFormation command.

AWS Three-Tier Serverless Web App

A production-grade, serverless three-tier web application built entirely on AWS managed services — no EC2, no containers, no servers to manage.

Live Architecture: S3 + CloudFront → API Gateway → Lambda → DynamoDB

📖 Full walkthrough: 4-part serverless series on Dev.to

⭐ Found this useful? Star the repo — it helps others discover it and motivates the next part of the series.

Architecture

┌─────────────────────────────────────────────────────────────────┐
│                        PRESENTATION TIER                        │
│                                                                 │
│   Browser  ──►  CloudFront (CDN, HTTPS, edge caching)          │
│                      │  Origin Access Control (OAC / SigV4)    │
│                      ▼                                          │
│              S3 Bucket (private, Block All Public Access ON)    │
│              [index.html · style.css · script.js]               │
└─────────────────────────────────────────────────────────────────┘
                         │  GET /users?userId={id}
                         ▼
┌─────────────────────────────────────────────────────────────────┐
│                          LOGIC TIER                             │
│                                                                 │
│   API Gateway (REST API, /prod stage)                          │
│        │  Lambda Proxy Integration                              │
│        ▼                                                        │
│   Lambda: RetrieveUserData (Node.js 22, ESM)                   │
│

…

View on GitHub

Kehinde Abiuwa — AWS Certified Solutions Architect (Professional) | Microsoft AZ-305
linkedin.com/in/kehinde-abiuwa-b68087247

How I Delivered a Static Website Globally with Amazon S3 and CloudFront (And the Security Mistake I Almost Made)

Kehinde Abiuwa — Tue, 16 Jun 2026 23:01:01 +0000

There is a very common shortcut that thousands of developers take when they want to host a static website on AWS. They create an S3 bucket, turn on "Static Website Hosting," flip off "Block Public Access," add a public-read bucket policy, and call it done.

It works. The site loads. But you have just made your S3 bucket publicly listable to anyone on the internet.

In this article — the first in a four-part series where I build a production-grade serverless web app on AWS — I am going to show you the right way to do it. We will use Amazon CloudFront as the delivery layer and configure Origin Access Control (OAC) so the S3 bucket stays completely private, while users still get a fast, HTTPS-secured experience from edge locations around the world.

What We Are Building in This Series

By the end of Part 4, we will have a working three-tier web application:

Tier	Services
Presentation (frontend)	Amazon S3 + Amazon CloudFront
Logic (backend API)	AWS Lambda + Amazon API Gateway
Data	Amazon DynamoDB

This first part covers the presentation tier — getting the frontend hosted and delivered globally.

The Architecture

User's Browser
      │
      ▼
Amazon CloudFront  ──────────────────────────────────
  (Edge Location)                                    │ OAC (SigV4 signed)
      │                                              ▼
      │                                      Amazon S3 Bucket
      │                                      (private, Block All Public Access ON)
      │◄── cached hit (no S3 call needed) ──────────┘

The key insight is this: CloudFront is the only entity that can read from the S3 bucket. The bucket never needs to be public. This is enforced through Origin Access Control — a feature that makes CloudFront sign every request to S3 using AWS Signature Version 4, and a bucket policy that only permits requests that carry your specific distribution's ARN.

Step 1 — Create the S3 Bucket and Upload Your Files

I created an S3 bucket and uploaded three files:

index.html — the page markup
style.css — styling
script.js — JavaScript that will eventually call our API

Critical: do not touch the Block Public Access settings. Leave them all on. We will not need them off.

The bucket with all three files uploaded — Block Public Access left fully enabled.

Step 2 — Create the CloudFront Distribution

In the CloudFront console, I created a new distribution with these settings:

Setting	Value	Why
Origin domain	S3 bucket (regional domain)	Use the regional domain, NOT the S3 website endpoint
Origin access	Origin Access Control (new OAC)	This is what keeps the bucket private
Default root object	`index.html`	So the root URL `/` serves the page
Viewer protocol policy	Redirect HTTP to HTTPS	Force TLS at the edge
Cache policy	CachingOptimized	AWS-managed policy tuned for S3 origins
HTTP versions	HTTP/2	Multiplexing reduces page load time

Creating the distribution — origin access set to Origin Access Control (OAC), default root object index.html.

Why the regional domain and not the S3 website endpoint?

The S3 website endpoint (your-bucket.s3-website.region.amazonaws.com) does not support OAC. If you set it as your CloudFront origin, you are forced to make the bucket publicly readable. The S3 regional domain (your-bucket.s3.region.amazonaws.com) is what you need.

Step 3 — Set Up Origin Access Control

After creating the distribution, CloudFront shows you a banner: "Update S3 bucket policy." Copy the generated policy. It looks like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipalReadOnly",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/EDFDVBD6EXAMPLE"
        }
      }
    }
  ]
}

The Condition block is the important part. It locks the permission down to your specific distribution — not just any CloudFront distribution in the world. Even another distribution pointing at the same bucket would be rejected.

Go to S3 → your bucket → Permissions → Bucket Policy → paste it in and save.

The OAC setup and the auto-generated bucket policy pasted into S3 → Permissions.

The Error I Hit (and Why You Will Too)

When I first set up the distribution, I left the origin access setting as Public. I thought: CloudFront is in front, so surely it can just read the bucket?

No. CloudFront fetches from S3 as an unauthenticated request when origin access is set to Public. If Block Public Access is on (which it should be), S3 returns a 403 AccessDenied. The CloudFront distribution just serves that 403 to your users.

403 AccessDenied — what CloudFront served while origin access was still set to Public.

The sequence of events that broke things:

Distribution set to Public origin → CloudFront makes unsigned GET request to S3
S3 sees no auth, checks bucket policy → no permission granted to anonymous principal
S3 returns 403 AccessDenied
CloudFront serves the 403 to the user

After switching to OAC and updating the bucket policy:

CloudFront makes SigV4-signed GET request with distribution ARN attached
S3 checks bucket policy → sees cloudfront.amazonaws.com principal + correct ARN → allows s3:GetObject
S3 returns the file
CloudFront caches it at the edge and serves it to the user

Step 4 — Understanding CloudFront Caching

Once the site was live, I ran a comparison between CloudFront delivery and the S3 website endpoint (which I temporarily enabled with a public-read policy just for benchmarking).

CloudFront was meaningfully faster — especially on repeat visits, where it served assets directly from the edge cache with no trip to S3 at all.

CloudFront vs the raw S3 website endpoint — CloudFront wins, especially on cached repeat visits.

Here is why:

Geographic proximity: CloudFront has over 450 edge locations globally. Instead of your user in Lagos hitting an S3 bucket in eu-north-1, they get the response from the nearest edge node.
HTTP/2 multiplexing: Multiple assets (HTML, CSS, JS) download in parallel over a single connection.
Compression: CloudFront automatically compresses with Gzip/Brotli.
Cache hits: On a cache hit, S3 is never contacted. The latency is effectively the edge-to-user round trip only.

TTLs and Cache Invalidation

The CachingOptimized policy sets a default TTL of 86,400 seconds (24 hours). This means if you upload a new index.html, users may see the old version for up to 24 hours unless you run a CloudFront invalidation:

aws cloudfront create-invalidation \
  --distribution-id EDFDVBD6EXAMPLE \
  --paths "/*"

In production, you would version your assets (main.abc123.js) so CloudFront can cache them indefinitely and only invalidate index.html itself when a new deploy goes out.

S3 Static Hosting vs CloudFront — When to Use Each

	S3 Website Endpoint	CloudFront + OAC
HTTPS	No (HTTP only)	Yes (always)
Bucket can be private	No	Yes
Global edge caching	No	Yes
Custom domain + ACM	No	Yes
WAF / DDoS protection	No	Yes (AWS Shield)
Signed URLs / Cookies	No	Yes
Setup complexity	Low	Medium

S3 static hosting is fine for: a quick local demo, a throw-away prototype, or if you are the only person accessing it.

CloudFront is non-negotiable for: anything user-facing, anything requiring HTTPS, anything global, anything you care about securing properly.

What's Next

In Part 2, we will build the logic tier: a Lambda function that queries DynamoDB and an API Gateway REST API that exposes it to the world. We will deal with IAM permissions, proxy integration, stages, and the CORS issues that show up the moment your frontend tries to call your API.

Part 2 — APIs with Lambda + API Gateway — coming next in this series.

Architecture Diagram

All code for this series is available on GitHub: aws-three-tier-serverless

Kehinde Abiuwa — AWS Certified Solutions Architect (Professional) | Microsoft AZ-305

DEV Community: Kehinde Abiuwa

Wiring Together a Three-Tier Serverless Web App on AWS (And the CORS Bug That Broke Everything)

The Complete Architecture

Step 1: Connect the Presentation Tier to the Logic Tier

CloudFront Cache Invalidation

Step 2: The CORS Error

What CORS Actually Is

The Two Places CORS Must Be Configured

How Browser CORS Preflight Works

Step 3: Verifying End-to-End

Deployment Checklist

Architecture Decisions: What I Would Do Differently in Production

1. Use a Custom Domain

2. Lock Down CORS

3. Add Structured Logging

4. Add a CloudWatch Alarm on Lambda Errors

5. Deploy with Infrastructure as Code

What I Learned From This Series

Repository

Least-Privilege IAM for Lambda: Why I Replaced the AWS Managed Policy With My Own

Where We Are in the Series

Step 1: Set Up the DynamoDB Table

Step 2: The First IAM Mistake (Intentional)

Step 3: Understanding What AmazonDynamoDBReadOnlyAccess Actually Allows

Step 4: Writing the Least-Privilege Inline Policy

Step 5: Validating the Change

Why This Matters Beyond Theory

Common IAM Mistakes to Avoid

The DynamoDB Data Model — Key Concepts

What's Next

Architecture Diagram

Building a Serverless REST API with AWS Lambda and API Gateway

What We Are Building

Part 1: The Lambda Function

What Lambda Is — and Why It Makes Sense Here

The Code

Part 2: API Gateway

REST API vs HTTP API

Resources and Methods

Lambda Proxy Integration

Stages and Deployment

Part 3: Testing the API

Part 4: API Documentation

Architecture Decisions and Trade-offs

Architecture Diagram

What's Next

kehindeabiuwa-dotcom / aws-three-tier-serverless

Production-grade three-tier serverless web app on AWS — private S3 + CloudFront (OAC), Lambda + API Gateway REST API, and DynamoDB with least-privilege IAM. Deploys in one CloudFormation command.

AWS Three-Tier Serverless Web App

Architecture

How I Delivered a Static Website Globally with Amazon S3 and CloudFront (And the Security Mistake I Almost Made)

What We Are Building in This Series

The Architecture

Step 1 — Create the S3 Bucket and Upload Your Files

Step 2 — Create the CloudFront Distribution

Step 3 — Set Up Origin Access Control

The Error I Hit (and Why You Will Too)

Step 4 — Understanding CloudFront Caching

S3 Static Hosting vs CloudFront — When to Use Each

What's Next

Architecture Diagram

Step 3: Understanding What `AmazonDynamoDBReadOnlyAccess` Actually Allows