DEV Community: Dixit R Jain

Building a Zero-Cost SEO Prerender Pipeline for My React SPA on AWS

Dixit R Jain — Fri, 03 Apr 2026 11:03:13 +0000

How I built a self-hosted prerender cache using CloudFront Functions, Lambda, Puppeteer, and S3 — replacing a $49/month service with existing AWS infrastructure.

Inspiration

This blog was inspired by Avinash Dalvi's excellent post on replacing prerender.io with a serverless renderer on AWS. His approach uses Lambda@Edge + API Gateway + a container-based Puppeteer Lambda. I had the same core idea and adapted it to my stack — a React SPA on CloudFront with CDK — making different architectural trade-offs along the way for my use case.

Why Prerendering Matters for SPAs

Already know why SPAs are invisible to crawlers? Skip ahead to The Site.

Your SPA ships an index.html with an empty <div id="root"></div> and a script tag in the body. Browsers execute the JS and render everything. Crawlers and social bots don't — they read the raw HTML and move on.

<!DOCTYPE html>
<html>
  <head><title>Vairaa</title></head>
  <body>
    <div id="root"></div>
    <script src="/assets/index-abc123.js"></script>
  </body>
</html>

The impact is twofold:

SEO: Google can execute JS, but queues it separately, delaying indexing by days or weeks. Pages sit in "Discovered — currently not indexed" limbo. Other search engines don't execute JS at all. You lose rich results, waste crawl budget, and get empty search snippets.
Social sharing: When someone shares your link on WhatsApp, LinkedIn, Slack, or Twitter/X, those platforms fetch the URL and look for Open Graph meta tags in the HTML. If those tags are rendered client-side, the preview card is blank. No title, no image, no description. For a B2B site where link sharing drives leads, that's a conversion killer.

Prerendering fixes this by serving crawlers a fully rendered HTML snapshot — with all content, meta tags, and structured data baked in — while regular users still get the normal SPA experience. Google explicitly documents this as dynamic rendering and approves the pattern. It's not cloaking — you're serving the same content in a different format, not different content to manipulate rankings.

The typical options are SSR (framework rewrite), SSG (doesn't work for dynamic content), a prerender service ($49–$249/month), or self-hosted prerendering. This post is about the last one.

The Site: What I'm Working With

Vairaa is a B2B marketing site for a cocopeat and coir products company specifically focused on Lead Generation. It's not a simple brochure site — it has a full product catalog, a blog, a lead management CRM, a media gallery, and an admin panel for managing all of it.

The tech stack:

Frontend: React 19 + Vite 7 SPA, styled with Tailwind CSS 4, animated with Framer Motion, smooth-scrolled with Lenis. Radix UI primitives for accessible components. TipTap for rich-text blog authoring.
Backend: A single AWS Lambda (Node.js 22, ARM64) handling all API routes — products, categories, blogs, leads, gallery, uploads, site config. Express wraps it locally for dev.
Database: DynamoDB single-table design. Products, categories, blogs, leads, gallery items, site config — all in one table with PK/SK patterns and a GSI for category and status queries.
Infrastructure: AWS CDK v2. CloudFront serves the SPA from S3 (OAC, no public bucket). API Gateway fronts the Lambda. Route53 + ACM for DNS and TLS.

Every content change in the admin panel — updating a product, publishing a blog post, changing site config — is relevant to the prerender story, because each change needs to invalidate and regenerate the cached HTML that crawlers see.

The Problem

The site ships a nearly empty index.html and renders everything client-side. Great for users. Terrible for crawlers. I was about to pay $49/month for prerender.io to fix it, but it felt wrong for a site already running on AWS Lambda, S3, and CloudFront. I already had everything I needed.

Here's every architectural decision and the wrong turns I almost took.

The Architecture in One Sentence

A CloudFront Function detects crawlers by User-Agent, rewrites their request URI to a cached HTML file in S3, and serves it — all transparently, with no redirects, at the same URL.

Decision 1: URI Rewriting, Not Redirecting

My first instinct was to redirect crawlers to a separate endpoint that returns rendered HTML. Something like:

Crawler hits /products/cocopeat-bricks
→ 302 redirect to /api/prerender?path=/products/cocopeat-bricks
→ Lambda renders the page
→ Returns HTML

This is actually what my original setup did for social bots — redirect to /api/og?path=... which returned minimal OG meta tags.

This hurts SEO. When Google follows a redirect, it sees two URLs involved. It may split PageRank signals, flag the redirect as suspicious, or simply not follow it at all. The canonical URL becomes ambiguous.

The correct approach is a transparent URI rewrite. The crawler requests /products/cocopeat-bricks. CloudFront internally fetches /prerender/products/cocopeat-bricks/index.html from S3. The crawler receives a single HTTP 200 response at the original URL. It never sees a redirect. It has no idea any rewriting happened.

This is Google's officially documented dynamic rendering pattern.

Decision 2: Same Bucket, Not a New Origin

Here's where it gets interesting. A CloudFront Function runs at the viewer-request stage. It can rewrite the URI. But it cannot switch the origin — that's a hard CloudFront limitation. Origin selection happens at the behavior level, not the function level.

So I had two options:

Option A: Lambda@Edge — runs at the origin-request stage, can dynamically switch origins. More powerful, but adds latency (~1-5ms per request), costs more, and has a more complex deployment model. This is the approach Avinash used — Lambda@Edge for bot detection + origin switching to a separate API Gateway endpoint that runs Puppeteer.

Option B: Same bucket, path-based routing — store the prerender cache inside the existing static hosting S3 bucket under a prerender/ prefix. The CloudFront Function rewrites /products/cocopeat-bricks → /prerender/products/cocopeat-bricks/index.html. Same origin, just a different path.

I went with Option B. No new infrastructure, no Lambda@Edge cold starts, no extra CDK complexity. The trade-off is that the prerender cache lives alongside your static assets — but since everything is private behind CloudFront OAC anyway, that's a non-issue.

The S3 key structure looks like this:

vairaa-static-prod/
├── index.html                          ← SPA shell
├── assets/                             ← Vite build output
└── prerender/                          ← Our cache
    ├── index.html                      ← Cached: /
    ├── products/
    │   ├── index.html                  ← Cached: /products
    │   └── cocopeat-bricks/
    │       └── index.html              ← Cached: /products/cocopeat-bricks
    └── blogs/
        └── growing-with-coco-peat/
            └── index.html

How This Differs from Avinash's Approach

Avinash's system renders on-demand — a bot hits a URL, Lambda@Edge routes to a Puppeteer Lambda, which renders the page (or serves from S3 cache), and returns the HTML in real-time. The first request for any URL pays the full Puppeteer render cost (~5-10 seconds).

My system pre-renders — the admin triggers a warm-up that renders all pages upfront and stores them in S3. When a bot hits a URL, CloudFront serves the pre-cached HTML directly from S3. No Lambda invocation at all for cache hits. The trade-off is that cache misses serve the SPA shell instead of rendering on-demand.

Both approaches are valid. On-demand is better if you have thousands of pages that change rarely. Pre-rendering is better if you have a manageable page count and want zero-latency bot responses.

Decision 3: The CloudFront Function

The existing CloudFront Function already handled www→non-www redirects. I extended it to also handle crawler detection and URI rewriting.

The key insight: don't redirect social bots to /api/og anymore. Instead, rewrite all crawlers (both search engines and social bots) to the prerender cache.

function handler(event) {
  var request = event.request;
  var host = request.headers.host.value;
  var uri = request.uri;

  // 1. www → non-www redirect (unchanged)
  if (host.startsWith('www.')) {
    return { statusCode: 301, headers: { location: { value: 'https://' + host.slice(4) + uri } } };
  }

  // 2. Detect crawlers
  var ua = (request.headers['user-agent'] || { value: '' }).value.toLowerCase();
  var bots = [
    'googlebot', 'bingbot', 'slurp', 'duckduckbot', 'baiduspider',
    'yandexbot', 'sogou', 'exabot', 'facebot', 'ia_archiver',
    'whatsapp', 'facebookexternalhit', 'twitterbot', 'linkedinbot',
    'slackbot', 'telegrambot', 'discordbot', 'pinterestbot', 'redditbot'
  ];
  var isCrawler = bots.some(function(b) { return ua.indexOf(b) !== -1; });

  // 3. Rewrite URI for crawlers (skip API, assets, files with extensions)
  if (isCrawler && !uri.startsWith('/api/') && !uri.startsWith('/product-assets/') && !uri.match(/\.[a-zA-Z0-9]+$/)) {
    request.uri = uri === '/' ? '/prerender/index.html' : '/prerender' + uri + '/index.html';
  }

  return request; // Always return request, never a redirect response for crawlers
}

Note on the extension regex: The pattern \.[a-zA-Z0-9]+$ skips any URI ending with a file extension (.js, .css, .png, etc.) so static assets aren't rewritten. This could also skip legitimate routes containing dots (e.g., /products/version-2.0). If your slugs contain dots, swap the regex for an explicit extension allowlist like /\.(js|css|png|jpg|svg|ico|woff2?)$/.

Notice the last line: we always return the request object, never a response with a statusCode. That's what makes it a rewrite instead of a redirect.

Decision 4: What Happens on a Cache Miss?

Since the CloudFront Function blindly rewrites the URI without checking if the file exists, what happens when a crawler hits a URL that hasn't been cached yet?

CloudFront fetches /prerender/products/new-product/index.html from S3. The file doesn't exist. S3 returns 404. CloudFront's existing error response configuration kicks in — it serves index.html (the SPA shell) with HTTP 200.

The crawler gets the SPA shell. Not ideal, but not a penalty either. Google will just re-crawl later.

This is acceptable because:

You warm the cache before going live
Cache is automatically regenerated whenever content changes
Cache misses are rare in steady state

If you need zero-miss guarantee with on-demand rendering, Lambda@Edge is the right call (see Avinash's approach). For most sites, pre-rendering with graceful fallback is fine.

Decision 5: Puppeteer, Not Playwright

For this use case — render a React page, capture the HTML, store it — you need Chromium and a page.goto(). Playwright has advantages (better auto-waiting, multi-browser support), but those don't matter here. What matters on Lambda is package size and deployment simplicity.

Puppeteer with @sparticuz/chromium is purpose-built for this:

	Puppeteer + `@sparticuz/chromium`	Playwright
Package size	~50MB compressed	~400MB+
Lambda deployment	Zip (no Docker)	Container image required
Cold start	Faster	Slower
Lambda fit	Purpose-built for Lambda	General-purpose, heavier footprint

@sparticuz/chromium is specifically built and compressed for Lambda's environment. It's the community standard for running Chromium on Lambda. Avinash uses the same stack in his implementation.

Decision 6: Batched Lambda Invocations

My first design fired one Lambda per URL. For a site with 50 pages, that's 50 Lambda cold starts. Each cold start loads Chromium (~3-5 seconds). That's 150-250 seconds of wasted cold start time.

The better approach: batch 10 URLs per Lambda invocation.

URL Manifest (50 URLs)
  → chunk into 5 batches of 10
  → invoke 5 Render_Worker Lambdas with InvocationType: 'Event'
  → each Lambda: launch Chromium ONCE, render 10 URLs parallel

Each Lambda pays the cold start cost once, then reuses the browser instance for all 10 URLs. 5 Lambda invocations instead of 50. All 5 render worker lambdas run in parallel.

With 2048MB memory and a 3-minute timeout (generous headroom for cold start + 10 renders at ~8-15s each), a full site warm-up completes in ~20-30 seconds wall-clock time.

Decision 7: Async Lambda Invocation for Cache Invalidation

When an admin updates a product, the API needs to:

Update DynamoDB
Delete the stale S3 cache entry
Trigger a re-render

Steps 2 and 3 can't run as a background Promise in the same Lambda. When the Lambda returns its HTTP response, the execution context freezes. Any unresolved promises die.

The solution: InvocationType: 'Event' — invoke the Render_Worker Lambda asynchronously. The API Lambda fires the invocation and gets back immediately. The Render_Worker runs on its own lifecycle, with its own timeout, completely independent.

The admin gets their response in milliseconds. The cache regenerates in the background. Lambda retries failed async invocations up to 2 times by default — so even transient failures are handled.

Decision 8: No Meta Tag Injection

Some prerender services inject OG tags and canonical URLs into the captured HTML before storing it. I don't need to do this.

My React app has a proper SEO component that renders all meta tags — canonical, OG, Twitter Card, hreflang, geo tags — as part of the normal React render. When Puppeteer renders the page, those tags are already in the DOM. The captured HTML already has everything.

// This component renders during Puppeteer's page.content() capture
export function SEO({ pageKey, title, url, siteConfig }) {
  return (
    <>
      <title>{fullTitle}</title>
      <link rel="canonical" href={fullUrl} />
      <meta property="og:title" content={fullTitle} />
      <meta property="og:url" content={fullUrl} />
      {/* ... all the tags */}
    </>
  );
}

The canonical URL points to https://vairaa.com/products/cocopeat-bricks — the real URL, not the internal S3 path. Google reads the canonical tag, not the URL it fetched from. So even though CloudFront internally fetched /prerender/products/cocopeat-bricks/index.html, Google indexes https://vairaa.com/products/cocopeat-bricks. Correct.

The Code

The Render Worker Lambda

This is the Lambda that actually launches Chromium, renders pages, and stores the HTML in S3. It receives a batch of URLs and a target bucket name.

// backend/src/render-worker.ts
import { PutObjectCommand } from '@aws-sdk/client-s3';
import { s3Client } from './utils/s3';
import puppeteer from 'puppeteer-core';
import chromium from '@sparticuz/chromium';

export interface RenderWorkerEvent {
  urls: string[];
  bucketName: string;
}

export function urlToS3Key(url: string): string {
  const pathname = new URL(url).pathname;
  if (pathname === '/') return 'prerender/index.html';
  const normalized = pathname.replace(/\/$/, '');
  return `prerender${normalized}/index.html`;
}

export const handler = async (event: RenderWorkerEvent) => {
  const browser = await puppeteer.launch({
    args: [...chromium.args, '--no-sandbox', '--disable-dev-shm-usage'],
    defaultViewport: { width: 1280, height: 800 },
    executablePath: await chromium.executablePath(),
    headless: true,
  });

  try {
    const results = await Promise.allSettled(
      event.urls.map(async (url) => {
        const page = await browser.newPage();
        try {
          await page.goto(url, { waitUntil: 'networkidle0', timeout: 30000 });
          const html = await page.content();
          const key = urlToS3Key(url);
          await s3Client.send(new PutObjectCommand({
            Bucket: event.bucketName,
            Key: key,
            Body: html,
            ContentType: 'text/html; charset=utf-8',
            Metadata: { 'rendered-at': new Date().toISOString() },
          }));
          return url;
        } finally {
          await page.close();
        }
      })
    );

    for (const result of results) {
      if (result.status !== 'fulfilled') {
        const url = event.urls[results.indexOf(result)];
        console.warn(`WARN: render failed for ${url}`, result.reason);
      }
    }
  } finally {
    await browser.close();
  }
};

A few things worth noting:

Promise.allSettled means one failed render doesn't kill the entire batch. We log failures for debugging.
All 10 URLs render concurrently in a single Chromium instance. At 2048MB, this works fine for ~200KB pages. For heavier pages, you could add a concurrency limiter (e.g., a simple semaphore) to cap parallel tabs.

The Cache Manager (Warm-up & Invalidation)

The prerender handler builds the URL manifest, chunks it into batches, and fires off Render Worker Lambdas:

// backend/src/handlers/prerender.ts (key excerpts)

const STATIC_PATHS = [
  '/', '/products', '/about', '/contact', '/blogs', '/gallery',
  '/faqs', '/terms-and-conditions', '/privacy-policy',
  '/shipping-policy', '/landingpage',
];

/** Builds the full URL manifest: static paths + product slugs + blog slugs. */
async function buildUrlManifest(): Promise<string[]> {
  const [productsResult, blogsResult] = await Promise.all([
    listProducts(),
    listBlogs(),
  ]);

  const productPaths = productsResult.items.map(p => `/products/${p.slug}`);
  const blogPaths = blogsResult.items.map(b => `/blogs/${b.slug}`);

  return [...STATIC_PATHS, ...productPaths, ...blogPaths];
}

/** Deletes cache entries and asynchronously invokes Render_Worker to regenerate. */
async function invalidateAndRerender(paths: string[]): Promise<void> {
  // Delete stale S3 entries
  await Promise.all(
    paths.map(path =>
      s3Client.send(new DeleteObjectCommand({
        Bucket: WEBSITE_BUCKET, Key: pathToS3Key(path),
      }))
    )
  );

  // Fire-and-forget: invoke Render_Worker asynchronously
  const urls = paths.map(p => `${SITE_URL}${p}`);
  await lambdaClient.send(
    new InvokeCommand({
      FunctionName: RENDER_WORKER_FUNCTION_NAME,
      InvocationType: 'Event', // async — returns immediately
      Payload: Buffer.from(JSON.stringify({ urls, bucketName: WEBSITE_BUCKET })),
    })
  );
}

// POST /api/admin/prerender/warmup
async function warmupHandler(): Promise<APIGatewayProxyResult> {
  // Check for warmup lock (prevent concurrent warm-ups)
  const lockKey = 'prerender/.warmup-lock';
  try {
    await s3Client.send(new HeadObjectCommand({ Bucket: WEBSITE_BUCKET, Key: lockKey }));
    return { statusCode: 409, body: JSON.stringify({ message: 'Warm-up already in progress' }) };
  } catch { /* Lock doesn't exist — proceed */ }

  // Write lock
  await s3Client.send(new PutObjectCommand({
    Bucket: WEBSITE_BUCKET, Key: lockKey,
    Body: new Date().toISOString(), ContentType: 'text/plain',
  }));

  const manifest = await buildUrlManifest();
  const batches = chunkArray(manifest, 10); // 10 URLs per Lambda invocation

  await Promise.all(
    batches.map((batch) => {
      const urls = batch.map(p => `${SITE_URL}${p}`);
      return lambdaClient.send(
        new InvokeCommand({
          FunctionName: RENDER_WORKER_FUNCTION_NAME,
          InvocationType: 'Event', // all batches fire in parallel
          Payload: Buffer.from(JSON.stringify({ urls, bucketName: WEBSITE_BUCKET })),
        })
      );
    })
  );

  return {
    statusCode: 202,
    body: JSON.stringify({
      message: `Warm-up initiated for ${manifest.length} URLs in ${batches.length} batches`,
      totalUrls: manifest.length,
      totalBatches: batches.length,
    }),
  };
}

The invalidateAndRerender function is what product, blog, and site-config handlers call after any content change. It deletes the stale cache entries and fires the Render Worker to regenerate them — all asynchronously so the admin API response isn't blocked.

The Full Flow

Admin clicks "Warm Up All Pages"
  → POST /api/admin/prerender/warmup
  → API Lambda queries DynamoDB for all product + blog slugs
  → Builds URL manifest: 11 static pages + N products + M blogs
  → Chunks into batches of 10
  → Fires K Render_Worker Lambdas with InvocationType: 'Event'
  → Returns HTTP 202 immediately

Each Render_Worker Lambda (running in parallel):
  → Launches Chromium once
  → For each URL in batch:
      → page.goto(url, { waitUntil: 'networkidle0', timeout: 30000 })
      → html = await page.content()
      → s3.putObject({ Key: 'prerender/products/slug/index.html', Body: html, ... })
  → Closes browser

Later, Googlebot hits /products/cocopeat-bricks:
  → CloudFront viewer-request → CloudFront Function
  → Detects 'googlebot' in User-Agent
  → Rewrites URI: /products/cocopeat-bricks → /prerender/products/cocopeat-bricks/index.html
  → CloudFront fetches from S3
  → Returns full HTML with HTTP 200 at original URL
  → Googlebot indexes complete product page ✓

Admin updates a product:
  → PUT /api/admin/products/:id
  → API Lambda updates DynamoDB
  → invalidateAndRerender(['/products/slug', '/products'])
  → Deletes stale S3 cache entries
  → Fires Render_Worker async (InvocationType: 'Event')
  → Returns HTTP 200 to admin immediately
  → Render_Worker regenerates cache in background

What It Costs

For a site with ~50 pages:

S3 storage: 50 HTML files × ~200KB each = ~10MB. Essentially free.
Lambda invocations: Warm-up fires ~5 invocations. Each content change fires 1-2. At Lambda's free tier (1M invocations/month), this is $0.
CloudFront Function: $0.10 per 1M invocations. For most sites, this rounds to $0.
Puppeteer Lambda: 2048MB × 3 minutes × 10 invocations per warm-up = ~60GB-seconds. Lambda free tier is 400,000 GB-seconds/month. Still $0.

Compare to prerender.io at $49/month minimum.

What I'd Do Differently

Cache miss on-demand render: Right now, a cache miss just serves the SPA shell. A Lambda@Edge function could detect the miss and trigger an on-demand render (or at least queue an async render for next time). I decided this complexity wasn't worth it given how rare cache misses are in steady state, but it's the most architecturally interesting upgrade path.

Cache staleness after deploys: The prerender cache doesn't automatically regenerate when you deploy a new frontend build. If your layout or components change, the cached HTML is stale until the next content edit triggers invalidation. The fix is simple — add a warm-up invocation to your deploy pipeline — but it's worth calling out because it's easy to forget.

Progress tracking: Since warm-up is fully async, the admin UI polls GET /api/admin/prerender/status every 10 seconds and compares cached entry count to manifest total. It works but feels crude. An SQS queue with a progress counter would be more elegant.

Warm-up lock: I'm using a prerender/.warmup-lock S3 object to prevent concurrent warm-ups. It works, but a DynamoDB item with a TTL would be cleaner and auto-expire if a warm-up crashes.

The Admin UI

The admin page gives full visibility and control:

Total cached pages vs. manifest total
Per-page status: Cached or Missing
Last rendered timestamp per page
"Warm Up All Pages" button with live progress
Per-page "Refresh" (synchronous re-render) and "Delete" actions
"Clear All Cache" with confirmation

Results

Google Search Console

Search Performance Before vs After

Impressions jumped significantly after the prerender cache went live.

Page Indexing Before vs After

The inflection point around February 10 — the date the solution was deployed — is hard to miss. Pages that were stuck in "Discovered — currently not indexed" started getting picked up.

Social Link Previews

Wrapping Up

The full system is:

CloudFront Function — crawler detection + URI rewrite (no Lambda@Edge, no redirects)
S3 prerender/ prefix — cache store (no new bucket)
Render_Worker Lambda — puppeteer-core + @sparticuz/chromium, zip deployment, batched rendering
Cache_Manager — API routes for warm-up, status, invalidation
Automatic invalidation — hooks in product/blog/site-config handlers, async Lambda invocation

Total new infrastructure: one Lambda function and some S3 objects. Everything else reuses what's already there.

The key insight that makes it all work: URI rewriting is invisible to crawlers. They see one URL, one HTTP 200 response. Google's dynamic rendering guidelines explicitly approve this pattern. You get full SEO benefit with zero redirect penalty.

If you're running a React SPA + CloudFront setup and paying for prerender.io, this is worth the afternoon it takes to set up.

Building a Zero-Cost SEO Prerender Pipeline for My React SPA on AWS

Dixit R Jain — Fri, 03 Apr 2026 11:03:13 +0000

How I built a self-hosted prerender cache using CloudFront Functions, Lambda, Puppeteer, and S3 — replacing a $49/month service with existing AWS infrastructure.

Inspiration

Why Prerendering Matters for SPAs

Already know why SPAs are invisible to crawlers? Skip ahead to <a The Site.

<!DOCTYPE html>
<html>
  <head><title>Vairaa</title></head>
  <body>
    <div id="root"></div>
    <script src="/assets/index-abc123.js"></script>
  </body>
</html>

The impact is twofold:

SEO: Google can execute JS, but queues it separately, delaying indexing by days or weeks. Pages sit in "Discovered — currently not indexed" limbo. Other search engines don't execute JS at all. You lose rich results, waste crawl budget, and get empty search snippets.
Social sharing: When someone shares your link on WhatsApp, LinkedIn, Slack, or Twitter/X, those platforms fetch the URL and look for Open Graph meta tags in the HTML. If those tags are rendered client-side, the preview card is blank. No title, no image, no description. For a B2B site where link sharing drives leads, that's a conversion killer.

The typical options are SSR (framework rewrite), SSG (doesn't work for dynamic content), a prerender service ($49–$249/month), or self-hosted prerendering. This post is about the last one.

The Site: What I'm Working With

The tech stack:

Frontend: React 19 + Vite 7 SPA, styled with Tailwind CSS 4, animated with Framer Motion, smooth-scrolled with Lenis. Radix UI primitives for accessible components. TipTap for rich-text blog authoring.
Backend: A single AWS Lambda (Node.js 22, ARM64) handling all API routes — products, categories, blogs, leads, gallery, uploads, site config. Express wraps it locally for dev.
Database: DynamoDB single-table design. Products, categories, blogs, leads, gallery items, site config — all in one table with PK/SK patterns and a GSI for category and status queries.
Infrastructure: AWS CDK v2. CloudFront serves the SPA from S3 (OAC, no public bucket). API Gateway fronts the Lambda. Route53 + ACM for DNS and TLS.

The Problem

Here's every architectural decision and the wrong turns I almost took.

The Architecture in One Sentence

A CloudFront Function detects crawlers by User-Agent, rewrites their request URI to a cached HTML file in S3, and serves it — all transparently, with no redirects, at the same URL.

Decision 1: URI Rewriting, Not Redirecting

My first instinct was to redirect crawlers to a separate endpoint that returns rendered HTML. Something like:

Crawler hits /products/cocopeat-bricks
→ 302 redirect to /api/prerender?path=/products/cocopeat-bricks
→ Lambda renders the page
→ Returns HTML

This is actually what my original setup did for social bots — redirect to /api/og?path=... which returned minimal OG meta tags.

This is Google's officially documented dynamic rendering pattern.

Decision 2: Same Bucket, Not a New Origin

So I had two options:

The S3 key structure looks like this:

vairaa-static-prod/
├── index.html                          ← SPA shell
├── assets/                             ← Vite build output
└── prerender/                          ← Our cache
    ├── index.html                      ← Cached: /
    ├── products/
    │   ├── index.html                  ← Cached: /products
    │   └── cocopeat-bricks/
    │       └── index.html              ← Cached: /products/cocopeat-bricks
    └── blogs/
        └── growing-with-coco-peat/
            └── index.html

How This Differs from Avinash's Approach

Both approaches are valid. On-demand is better if you have thousands of pages that change rarely. Pre-rendering is better if you have a manageable page count and want zero-latency bot responses.

Decision 3: The CloudFront Function

The existing CloudFront Function already handled www→non-www redirects. I extended it to also handle crawler detection and URI rewriting.

The key insight: don't redirect social bots to /api/og anymore. Instead, rewrite all crawlers (both search engines and social bots) to the prerender cache.

function handler(event) {
  var request = event.request;
  var host = request.headers.host.value;
  var uri = request.uri;

  // 1. www → non-www redirect (unchanged)
  if (host.startsWith('www.')) {
    return { statusCode: 301, headers: { location: { value: 'https://' + host.slice(4) + uri } } };
  }

  // 2. Detect crawlers
  var ua = (request.headers['user-agent'] || { value: '' }).value.toLowerCase();
  var bots = [
    'googlebot', 'bingbot', 'slurp', 'duckduckbot', 'baiduspider',
    'yandexbot', 'sogou', 'exabot', 'facebot', 'ia_archiver',
    'whatsapp', 'facebookexternalhit', 'twitterbot', 'linkedinbot',
    'slackbot', 'telegrambot', 'discordbot', 'pinterestbot', 'redditbot'
  ];
  var isCrawler = bots.some(function(b) { return ua.indexOf(b) !== -1; });

  // 3. Rewrite URI for crawlers (skip API, assets, files with extensions)
  if (isCrawler && !uri.startsWith('/api/') && !uri.startsWith('/product-assets/') && !uri.match(/\.[a-zA-Z0-9]+$/)) {
    request.uri = uri === '/' ? '/prerender/index.html' : '/prerender' + uri + '/index.html';
  }

  return request; // Always return request, never a redirect response for crawlers
}

Note on the extension regex: The pattern \.[a-zA-Z0-9]+$ skips any URI ending with a file extension (.js, .css, .png, etc.) so static assets aren't rewritten. This could also skip legitimate routes containing dots (e.g., /products/version-2.0). If your slugs contain dots, swap the regex for an explicit extension allowlist like /\.(js|css|png|jpg|svg|ico|woff2?)$/.

Notice the last line: we always return the request object, never a response with a statusCode. That's what makes it a rewrite instead of a redirect.

Decision 4: What Happens on a Cache Miss?

Since the CloudFront Function blindly rewrites the URI without checking if the file exists, what happens when a crawler hits a URL that hasn't been cached yet?

The crawler gets the SPA shell. Not ideal, but not a penalty either. Google will just re-crawl later.

This is acceptable because:

You warm the cache before going live
Cache is automatically regenerated whenever content changes
Cache misses are rare in steady state

If you need zero-miss guarantee with on-demand rendering, Lambda@Edge is the right call (see Avinash's approach). For most sites, pre-rendering with graceful fallback is fine.

Decision 5: Puppeteer, Not Playwright

Puppeteer with @sparticuz/chromium is purpose-built for this:

	Puppeteer + `@sparticuz/chromium`	Playwright
Package size	~50MB compressed	~400MB+
Lambda deployment	Zip (no Docker)	Container image required
Cold start	Faster	Slower
Lambda fit	Purpose-built for Lambda	General-purpose, heavier footprint

@sparticuz/chromium is specifically built and compressed for Lambda's environment. It's the community standard for running Chromium on Lambda. Avinash uses the same stack in his implementation.

Decision 6: Batched Lambda Invocations

My first design fired one Lambda per URL. For a site with 50 pages, that's 50 Lambda cold starts. Each cold start loads Chromium (~3-5 seconds). That's 150-250 seconds of wasted cold start time.

The better approach: batch 10 URLs per Lambda invocation.

URL Manifest (50 URLs)
  → chunk into 5 batches of 10
  → invoke 5 Render_Worker Lambdas with InvocationType: 'Event'
  → each Lambda: launch Chromium ONCE, render 10 URLs parallel

Each Lambda pays the cold start cost once, then reuses the browser instance for all 10 URLs. 5 Lambda invocations instead of 50. All 5 render worker lambdas run in parallel.

With 2048MB memory and a 3-minute timeout (generous headroom for cold start + 10 renders at ~8-15s each), a full site warm-up completes in ~20-30 seconds wall-clock time.

Decision 7: Async Lambda Invocation for Cache Invalidation

When an admin updates a product, the API needs to:

Update DynamoDB
Delete the stale S3 cache entry
Trigger a re-render

Steps 2 and 3 can't run as a background Promise in the same Lambda. When the Lambda returns its HTTP response, the execution context freezes. Any unresolved promises die.

The admin gets their response in milliseconds. The cache regenerates in the background. Lambda retries failed async invocations up to 2 times by default — so even transient failures are handled.

Decision 8: No Meta Tag Injection

Some prerender services inject OG tags and canonical URLs into the captured HTML before storing it. I don't need to do this.

// This component renders during Puppeteer's page.content() capture
export function SEO({ pageKey, title, url, siteConfig }) {
  return (
    <>
      <title>{fullTitle}</title>
      <link rel="canonical" href={fullUrl} />
      <meta property="og:title" content={fullTitle} />
      <meta property="og:url" content={fullUrl} />
      {/* ... all the tags */}
    </>
  );
}

The Code

The Render Worker Lambda

This is the Lambda that actually launches Chromium, renders pages, and stores the HTML in S3. It receives a batch of URLs and a target bucket name.

// backend/src/render-worker.ts
import { PutObjectCommand } from '@aws-sdk/client-s3';
import { s3Client } from './utils/s3';
import puppeteer from 'puppeteer-core';
import chromium from '@sparticuz/chromium';

export interface RenderWorkerEvent {
  urls: string[];
  bucketName: string;
}

export function urlToS3Key(url: string): string {
  const pathname = new URL(url).pathname;
  if (pathname === '/') return 'prerender/index.html';
  const normalized = pathname.replace(/\/$/, '');
  return `prerender${normalized}/index.html`;
}

export const handler = async (event: RenderWorkerEvent) => {
  const browser = await puppeteer.launch({
    args: [...chromium.args, '--no-sandbox', '--disable-dev-shm-usage'],
    defaultViewport: { width: 1280, height: 800 },
    executablePath: await chromium.executablePath(),
    headless: true,
  });

  try {
    const results = await Promise.allSettled(
      event.urls.map(async (url) => {
        const page = await browser.newPage();
        try {
          await page.goto(url, { waitUntil: 'networkidle0', timeout: 30000 });
          const html = await page.content();
          const key = urlToS3Key(url);
          await s3Client.send(new PutObjectCommand({
            Bucket: event.bucketName,
            Key: key,
            Body: html,
            ContentType: 'text/html; charset=utf-8',
            Metadata: { 'rendered-at': new Date().toISOString() },
          }));
          return url;
        } finally {
          await page.close();
        }
      })
    );

    for (const result of results) {
      if (result.status !== 'fulfilled') {
        const url = event.urls[results.indexOf(result)];
        console.warn(`WARN: render failed for ${url}`, result.reason);
      }
    }
  } finally {
    await browser.close();
  }
};

A few things worth noting:

Promise.allSettled means one failed render doesn't kill the entire batch. We log failures for debugging.
All 10 URLs render concurrently in a single Chromium instance. At 2048MB, this works fine for ~200KB pages. For heavier pages, you could add a concurrency limiter (e.g., a simple semaphore) to cap parallel tabs.

The Cache Manager (Warm-up & Invalidation)

The prerender handler builds the URL manifest, chunks it into batches, and fires off Render Worker Lambdas:

// backend/src/handlers/prerender.ts (key excerpts)

const STATIC_PATHS = [
  '/', '/products', '/about', '/contact', '/blogs', '/gallery',
  '/faqs', '/terms-and-conditions', '/privacy-policy',
  '/shipping-policy', '/landingpage',
];

/** Builds the full URL manifest: static paths + product slugs + blog slugs. */
async function buildUrlManifest(): Promise<string[]> {
  const [productsResult, blogsResult] = await Promise.all([
    listProducts(),
    listBlogs(),
  ]);

  const productPaths = productsResult.items.map(p => `/products/${p.slug}`);
  const blogPaths = blogsResult.items.map(b => `/blogs/${b.slug}`);

  return [...STATIC_PATHS, ...productPaths, ...blogPaths];
}

/** Deletes cache entries and asynchronously invokes Render_Worker to regenerate. */
async function invalidateAndRerender(paths: string[]): Promise<void> {
  // Delete stale S3 entries
  await Promise.all(
    paths.map(path =>
      s3Client.send(new DeleteObjectCommand({
        Bucket: WEBSITE_BUCKET, Key: pathToS3Key(path),
      }))
    )
  );

  // Fire-and-forget: invoke Render_Worker asynchronously
  const urls = paths.map(p => `${SITE_URL}${p}`);
  await lambdaClient.send(
    new InvokeCommand({
      FunctionName: RENDER_WORKER_FUNCTION_NAME,
      InvocationType: 'Event', // async — returns immediately
      Payload: Buffer.from(JSON.stringify({ urls, bucketName: WEBSITE_BUCKET })),
    })
  );
}

// POST /api/admin/prerender/warmup
async function warmupHandler(): Promise<APIGatewayProxyResult> {
  // Check for warmup lock (prevent concurrent warm-ups)
  const lockKey = 'prerender/.warmup-lock';
  try {
    await s3Client.send(new HeadObjectCommand({ Bucket: WEBSITE_BUCKET, Key: lockKey }));
    return { statusCode: 409, body: JSON.stringify({ message: 'Warm-up already in progress' }) };
  } catch { /* Lock doesn't exist — proceed */ }

  // Write lock
  await s3Client.send(new PutObjectCommand({
    Bucket: WEBSITE_BUCKET, Key: lockKey,
    Body: new Date().toISOString(), ContentType: 'text/plain',
  }));

  const manifest = await buildUrlManifest();
  const batches = chunkArray(manifest, 10); // 10 URLs per Lambda invocation

  await Promise.all(
    batches.map((batch) => {
      const urls = batch.map(p => `${SITE_URL}${p}`);
      return lambdaClient.send(
        new InvokeCommand({
          FunctionName: RENDER_WORKER_FUNCTION_NAME,
          InvocationType: 'Event', // all batches fire in parallel
          Payload: Buffer.from(JSON.stringify({ urls, bucketName: WEBSITE_BUCKET })),
        })
      );
    })
  );

  return {
    statusCode: 202,
    body: JSON.stringify({
      message: `Warm-up initiated for ${manifest.length} URLs in ${batches.length} batches`,
      totalUrls: manifest.length,
      totalBatches: batches.length,
    }),
  };
}

The Full Flow

Admin clicks "Warm Up All Pages"
  → POST /api/admin/prerender/warmup
  → API Lambda queries DynamoDB for all product + blog slugs
  → Builds URL manifest: 11 static pages + N products + M blogs
  → Chunks into batches of 10
  → Fires K Render_Worker Lambdas with InvocationType: 'Event'
  → Returns HTTP 202 immediately

Each Render_Worker Lambda (running in parallel):
  → Launches Chromium once
  → For each URL in batch:
      → page.goto(url, { waitUntil: 'networkidle0', timeout: 30000 })
      → html = await page.content()
      → s3.putObject({ Key: 'prerender/products/slug/index.html', Body: html, ... })
  → Closes browser

Later, Googlebot hits /products/cocopeat-bricks:
  → CloudFront viewer-request → CloudFront Function
  → Detects 'googlebot' in User-Agent
  → Rewrites URI: /products/cocopeat-bricks → /prerender/products/cocopeat-bricks/index.html
  → CloudFront fetches from S3
  → Returns full HTML with HTTP 200 at original URL
  → Googlebot indexes complete product page ✓

Admin updates a product:
  → PUT /api/admin/products/:id
  → API Lambda updates DynamoDB
  → invalidateAndRerender(['/products/slug', '/products'])
  → Deletes stale S3 cache entries
  → Fires Render_Worker async (InvocationType: 'Event')
  → Returns HTTP 200 to admin immediately
  → Render_Worker regenerates cache in background

What It Costs

For a site with ~50 pages:

S3 storage: 50 HTML files × ~200KB each = ~10MB. Essentially free.
Lambda invocations: Warm-up fires ~5 invocations. Each content change fires 1-2. At Lambda's free tier (1M invocations/month), this is $0.
CloudFront Function: $0.10 per 1M invocations. For most sites, this rounds to $0.
Puppeteer Lambda: 2048MB × 3 minutes × 10 invocations per warm-up = ~60GB-seconds. Lambda free tier is 400,000 GB-seconds/month. Still $0.

Compare to prerender.io at $49/month minimum.

What I'd Do Differently

Warm-up lock: I'm using a prerender/.warmup-lock S3 object to prevent concurrent warm-ups. It works, but a DynamoDB item with a TTL would be cleaner and auto-expire if a warm-up crashes.

The Admin UI

The admin page gives full visibility and control:

Total cached pages vs. manifest total
Per-page status: Cached or Missing
Last rendered timestamp per page
"Warm Up All Pages" button with live progress
Per-page "Refresh" (synchronous re-render) and "Delete" actions
"Clear All Cache" with confirmation

Results

Google Search Console

Search Performance Before vs After

Impressions jumped significantly after the prerender cache went live.

Page Indexing Before vs After

The inflection point around February 10 — the date the solution was deployed — is hard to miss. Pages that were stuck in "Discovered — currently not indexed" started getting picked up.

Social Link Previews

Wrapping Up

The full system is:

CloudFront Function — crawler detection + URI rewrite (no Lambda@Edge, no redirects)
S3 prerender/ prefix — cache store (no new bucket)
Render_Worker Lambda — puppeteer-core + @sparticuz/chromium, zip deployment, batched rendering
Cache_Manager — API routes for warm-up, status, invalidation
Automatic invalidation — hooks in product/blog/site-config handlers, async Lambda invocation

Total new infrastructure: one Lambda function and some S3 objects. Everything else reuses what's already there.

If you're running a React SPA + CloudFront setup and paying for prerender.io, this is worth the afternoon it takes to set up.

From Zero to Production: The Complete AWS Serverless Full-Stack Journey

Dixit R Jain — Tue, 27 Jan 2026 19:11:49 +0000

Introduction
What We've Built
Full Stack Architecture
The Complete CDK Stack
Frontend Integration
One-Command Deployment
Production Hardening
Monitoring & Observability
Cost Analysis
Next Steps
Conclusion
References

Introduction

Quick Links:

📂 Source Code: GitHub Repository

🚀 Live Demo: https://dmcechq7isaw7.cloudfront.net/

We've come a long way, haven't we?

In Part 1, we launched a static website with S3 and CloudFront.
In Part 2, we built a REST API with API Gateway and Lambda.
In Part 3, we added data persistence with DynamoDB.

But here's the thing – they were separate pieces. Three different stacks. Three deployments. What if I told you we could combine everything into a single, elegant, production-ready deployment?

One command. One stack. Complete application.

This is the grand finale of our Serverless Web Mastery series. Today, we're going to:

Combine all components into a single CDK stack
Configure CloudFront to route between frontend and API
Implement production-ready patterns
Deploy everything with one command
Discuss monitoring, security, and cost optimization

Let's ship this thing to production! 🚀

What We've Built

By the end of this tutorial, you'll have:

┌─────────────────────────────────────────────────────────────┐
│               Contact Form for Lead Generation              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Production HTTPS website via CloudFront                    │
│  REST API with full CRUD operations                         │
│  Persistent data storage in DynamoDB                        │
│  Automatic scaling from 0 to millions of users              │
│  Infrastructure as Code with AWS CDK                        │
│  ~$0-2/month for small to medium traffic                    │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Features

For Users:

Beautiful, responsive contact form
Instant form submission
Success/error feedback
Mobile-friendly design

For Developers:

One-command deployment
Environment-agnostic configuration
Structured logging
Health check endpoints

For Admins:

Query leads by email, status, or ID
Update lead status (new → contacted → converted)
Delete processed leads
View all leads with filters

Full Stack Architecture

Here's our complete architecture:

                         ┌──────────────────┐
                         │      Users       │
                         └────────┬─────────┘
                                  │
                                  ▼
                    ┌──────────────────────────┐
                    │       CloudFront         │
                    │    (HTTPS, Caching)      │
                    └──────────────────────────┘
                                  │
            ┌─────────────────────┼─────────────────────┐
            │                     │                     │
      /static/* ──────────────┐   │   ┌────────────── /api/*
            │                 │   │   │               │
            ▼                 │   │   │               ▼
    ┌───────────────┐         │   │   │       ┌───────────────┐
    │   S3 Bucket   │         │   │   │       │  API Gateway  │
    │               │         │   │   │       │   (REST)      │
    │  index.html   │         │   │   │       └───────┬───────┘
    │  styles.css   │         │   │   │               │
    │  app.js       │         │   │   │               ▼
    └───────────────┘         │   │   │       ┌───────────────┐
                              │   │   │       │    Lambda     │
                              │   │   │       │   Functions   │
                              │   │   │       └───────┬───────┘
                              │   │   │               │
                              │   │   │               ▼
                              │   │   │       ┌───────────────┐
                              │   │   │       │   DynamoDB    │
                              │   │   │       │    Table      │
                              │   │   │       └───────────────┘
                              │   │   │
                              └───┴───┘

Why CloudFront for Both?

Traditional approach:

Frontend: https://d1234.cloudfront.net
API: https://abc123.execute-api.amazonaws.com
Problem: CORS headaches, separate deployments, inconsistent caching

Our approach:

Frontend: https://d1234.cloudfront.net/*
API: https://d1234.cloudfront.net/api/*
Benefits: Same domain = no CORS, unified caching, simpler code

The Complete CDK Stack

Here's our unified stack:

import * as cdk from "aws-cdk-lib";
import * as s3 from "aws-cdk-lib/aws-s3";
import * as cloudfront from "aws-cdk-lib/aws-cloudfront";
import * as origins from "aws-cdk-lib/aws-cloudfront-origins";
import * as s3deploy from "aws-cdk-lib/aws-s3-deployment";
import * as dynamodb from "aws-cdk-lib/aws-dynamodb";
import * as lambda from "aws-cdk-lib/aws-lambda";
import * as lambdaNodejs from "aws-cdk-lib/aws-lambda-nodejs";
import * as apigateway from "aws-cdk-lib/aws-apigateway";
import { Construct } from "constructs";

export class FullIntegrationStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // ============================================
    // Data Layer
    // ============================================
    const leadsTable = new dynamodb.Table(this, "LeadsTable", {
      tableName: "ContactFormLeads-Prod",
      partitionKey: { name: "leadId", type: dynamodb.AttributeType.STRING },
      billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
      pointInTimeRecovery: true,
      removalPolicy: cdk.RemovalPolicy.RETAIN, // Keep data!
    });

    // GSIs for query patterns
    leadsTable.addGlobalSecondaryIndex({
      indexName: "email-index",
      partitionKey: { name: "email", type: dynamodb.AttributeType.STRING },
      sortKey: { name: "createdAt", type: dynamodb.AttributeType.STRING },
    });

    // ============================================
    // API Layer
    // ============================================
    const leadsHandler = new lambdaNodejs.NodejsFunction(this, "LeadsHandler", {
      runtime: lambda.Runtime.NODEJS_22_X,
      entry: path.join(__dirname, "../../lambda/handlers/leads.ts"),
      handler: "handler",
      description: "Leads CRUD operations with DynamoDB",
      environment: {
        TABLE_NAME: leadsTable.tableName,
      },
      bundling: {
        minify: true,
        sourceMap: true,
      },
    });

    leadsTable.grantReadWriteData(leadsHandler);

    const api = new apigateway.RestApi(this, "Api", {
      restApiName: "Contact Form API",
      deployOptions: { stageName: "v1" },
      defaultCorsPreflightOptions: {
        allowOrigins: apigateway.Cors.ALL_ORIGINS,
        allowMethods: apigateway.Cors.ALL_METHODS,
      },
    });

    const apiResource = api.root.addResource("api");
    const leads = apiResource.addResource("leads");
    leads.addMethod(
      "POST",
      new apigateway.LambdaIntegration(leadsHandler, { proxy: true }),
    );
    leads.addMethod(
      "GET",
      new apigateway.LambdaIntegration(leadsHandler, { proxy: true }),
    );

    // ============================================
    // Frontend Layer
    // ============================================
    const websiteBucket = new s3.Bucket(this, "WebsiteBucket", {
      blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
      removalPolicy: cdk.RemovalPolicy.DESTROY,
      autoDeleteObjects: true,
    });

    // ============================================
    // CloudFront: Unified Entry Point
    // ============================================
    const distribution = new cloudfront.Distribution(this, "Distribution", {
      defaultRootObject: "index.html",

      // Default: S3 static files
      defaultBehavior: {
        origin: origins.S3BucketOrigin.withOriginAccessControl(websiteBucket),
        viewerProtocolPolicy: cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
        cachePolicy: cloudfront.CachePolicy.CACHING_OPTIMIZED,
      },

      // /api/*: Route to API Gateway
      additionalBehaviors: {
        "/api/*": {
          origin: new origins.HttpOrigin(
            `${api.restApiId}.execute-api.${this.region}.amazonaws.com`,
            { originPath: "/v1" },
          ),
          viewerProtocolPolicy: cloudfront.ViewerProtocolPolicy.HTTPS_ONLY,
          cachePolicy: cloudfront.CachePolicy.CACHING_DISABLED,
          originRequestPolicy:
            cloudfront.OriginRequestPolicy.ALL_VIEWER_EXCEPT_HOST_HEADER,
          allowedMethods: cloudfront.AllowedMethods.ALLOW_ALL,
        },
      },
    });

    // Deploy frontend
    new s3deploy.BucketDeployment(this, "Deploy", {
      sources: [s3deploy.Source.asset("../frontend")],
      destinationBucket: websiteBucket,
      distribution,
      distributionPaths: ["/*"],
    });

    // Outputs
    new cdk.CfnOutput(this, "URL", {
      value: `https://${distribution.domainName}`,
    });
  }
}

Key Insight: CloudFront Path Routing

The magic is in additionalBehaviors:

additionalBehaviors: {
  '/api/*': {
    origin: new origins.HttpOrigin(
      `${api.restApiId}.execute-api.${this.region}.amazonaws.com`,
      { originPath: '/v1' }
    ),
    // ...
  },
},

This routes:

https://cloudfronturl.com/api/leads → https://apigateway/v1/leads

The frontend simply calls /api/leads – no hard-coded URLs!

Frontend Integration

Smart API Configuration

const CONFIG = {
  // Automatically detect environment
  API_ENDPOINT:
    window.location.hostname === "localhost"
      ? "http://localhost:3000" // Local dev
      : "/api", // Production
};

Retry with Exponential Backoff

async function submitToAPI(formData, attempt = 1) {
  try {
    const response = await fetch(`${CONFIG.API_ENDPOINT}/leads`, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify(formData),
    });

    if (!response.ok) throw new Error(`HTTP ${response.status}`);
    return response.json();
  } catch (error) {
    if (attempt < 3) {
      // Exponential backoff: 1s, 2s, 4s
      await delay(1000 * Math.pow(2, attempt - 1));
      return submitToAPI(formData, attempt + 1);
    }
    throw error;
  }
}

One-Command Deployment

cd part-4-full-integration/cdk
npm install
npx cdk deploy

That's it. One command. Everything deployed.

Output:

✅  ContactFormFullStack

Outputs:
ContactFormFullStack.WebsiteURL = https://d1234567abcdef.cloudfront.net
ContactFormFullStack.ApiEndpoint = https://abc123xyz.execute-api.us-east-1.amazonaws.com/v1/
ContactFormFullStack.TableName = ContactFormLeads-Prod

Open the WebsiteURL – your application is live! 🎉

Production Hardening

Before going live, consider these enhancements:

1. Custom Domain

import * as acm from 'aws-cdk-lib/aws-certificatemanager';
import * as route53 from 'aws-cdk-lib/aws-route53';

// Create certificate in us-east-1
const certificate = new acm.Certificate(this, 'Cert', {
  domainName: 'contact.yourdomain.com',
  validation: acm.CertificateValidation.fromDns(hostedZone),
});

// Add to distribution
domainNames: ['contact.yourdomain.com'],
certificate,

2. WAF Protection

import * as wafv2 from "aws-cdk-lib/aws-wafv2";

const webAcl = new wafv2.CfnWebACL(this, "WebAcl", {
  scope: "CLOUDFRONT",
  defaultAction: { allow: {} },
  rules: [
    {
      name: "RateLimitRule",
      priority: 1,
      action: { block: {} },
      statement: {
        rateBasedStatement: {
          limit: 1000, // requests per 5 minutes
          aggregateKeyType: "IP",
        },
      },
      visibilityConfig: {
        /* ... */
      },
    },
  ],
});

3. Specific CORS Origins

defaultCorsPreflightOptions: {
  allowOrigins: ['https://contact.yourdomain.com'],
  allowMethods: ['GET', 'POST', 'PUT', 'DELETE'],
},

4. Lambda Security

// Principle of least privilege
leadsTable.grantReadWriteData(leadsHandler); // ✅ Specific table
// NOT: grantFullAccess()  // ❌ Too broad

Monitoring & Observability

CloudWatch Dashboard

import * as cloudwatch from "aws-cdk-lib/aws-cloudwatch";

const dashboard = new cloudwatch.Dashboard(this, "Dashboard", {
  dashboardName: "ContactForm-Production",
});

dashboard.addWidgets(
  new cloudwatch.GraphWidget({
    title: "API Requests",
    left: [api.metricCount()],
  }),
  new cloudwatch.GraphWidget({
    title: "Lambda Duration",
    left: [leadsHandler.metricDuration()],
  }),
  new cloudwatch.GraphWidget({
    title: "DynamoDB Throttles",
    left: [leadsTable.metricThrottledRequests()],
  }),
);

Alarms

new cloudwatch.Alarm(this, "ErrorAlarm", {
  metric: leadsHandler.metricErrors(),
  threshold: 10,
  evaluationPeriods: 1,
  alarmDescription: "Lambda errors exceeded threshold",
});

Cost Analysis

Let's break down the total monthly cost:

Service	Usage	Free Tier	Cost
S3	100MB, 50K requests	5GB, 20K GET	$0.02
CloudFront	10GB, 100K requests	1TB, 10M	$0.00
API Gateway	50K requests	1M	$0.00
Lambda	50K invocations, 5s average	1M, 400K GB-s	$0.00
DynamoDB	1GB, 50K writes	25GB, 25 WCU	$0.00
CloudWatch	Basic metrics	Always free	$0.00
Total			~$0.02/month

For a high-traffic site (1M monthly visitors): ~$10-20/month

Compare to traditional hosting: $50-200/month minimum

Next Steps

Now that you've mastered serverless web development, consider:

1. Add Email Notifications

Use SES to send confirmation emails when leads are created.

2. Implement Authentication

Add Cognito for admin dashboard access.

3. Add File Uploads

Accept resume/document uploads stored in S3.

4. Build an Admin Dashboard

Create a separate protected area to manage leads.

5. Add Analytics

Integrate CloudWatch Logs Insights or third-party analytics.

Conclusion

🎉 Congratulations! You've completed the Serverless Web Mastery series!

You've built a complete, production-ready serverless application:

✅ Part 1: S3 + CloudFront for static hosting
✅ Part 2: API Gateway + Lambda for serverless API
✅ Part 3: DynamoDB for persistent storage
✅ Part 4: Full integration with production patterns

What you've learned:

Infrastructure as Code with AWS CDK
Modern frontend development
REST API design
NoSQL database patterns
Cost optimization techniques
Production deployment best practices

The best part? This entire stack follows the serverless-first approach:

Zero servers to manage
Automatic scaling
Pay-per-use pricing
Built-in high availability

Related Posts:

GitHub Repository: aws-serverless-website-tutorial

Thank you for joining me on this serverless journey. Now go build something amazing!

Happy coding! 🚀

References

Persistence Made Easy: AWS DynamoDB Deep Dive for Serverless Applications

Dixit R Jain — Tue, 27 Jan 2026 18:53:03 +0000

Introduction
Why DynamoDB for Serverless?
Table Design Fundamentals
Setting Up the Stack
CRUD Operations with AWS SDK v3
Global Secondary Indexes
Query vs Scan
Gotchas & Common Pitfalls
Best Practices
Cost Considerations
Conclusion
References

Introduction

Quick Links:

📂 Source Code: GitHub Repository

🚀 Live Demo: https://dmcechq7isaw7.cloudfront.net/

Remember that contact form API we built in Part 2? It worked great, but there was a sneaky problem – our data vanished every time Lambda recycled!

Picture this nightmare: A Fortune 500 company submits a partnership inquiry through your contact form. You celebrate. But when you check for the lead later... nothing. The Lambda function recycled, and that million-dollar opportunity evaporated into thin air.

Not ideal.

Today, we're fixing this by adding DynamoDB – a fully managed, serverless NoSQL database that scales from zero to millions of requests per second. Your leads will persist forever (or until you delete them).

In this third part of our AWS Serverless Web Mastery series, you'll learn:

How to design DynamoDB tables for serverless applications
CRUD operations using AWS SDK v3
Global Secondary Indexes (GSIs) for flexible queries
Production patterns for error handling and performance

Let's make your data bulletproof!

Why DynamoDB for Serverless?

Perfect Serverless Companion

Feature	Benefit
Serverless	No servers to manage, automatic scaling
Pay-per-request	$0 when idle, perfect for variable workloads
Single-digit millisecond latency	Fast responses regardless of scale
Built-in security	Encryption at rest and in transit
Event-driven	DynamoDB Streams trigger Lambda functions

The Competition

Database	Serverless?	Cold Start Issue?	Scaling
DynamoDB	✅ Yes	❌ None	Instant
RDS	❌ No	N/A	Minutes
Aurora Serverless v2	✅ Yes	Minutes	Seconds
MongoDB Atlas	⚠️ Partial	Minutes	Minutes

For serverless applications, DynamoDB is the clear winner.

Table Design Fundamentals

Think Access Patterns, Not Entities

Unlike relational databases where you normalize data, DynamoDB is designed around access patterns. Before creating your table, ask:

How will I retrieve data?
What queries do I need?
What filters will I apply?

Our Access Patterns

For our Contact Form, we need:

Access Pattern	Solution
Get lead by ID	Primary key lookup
List all leads	Scan (acceptable for admin)
Find leads by email	GSI on email
Filter by status	GSI on status

Table Design

┌─────────────────────────────────────────────────────────────┐
│                    ContactFormLeads Table                   │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Primary Key: leadId (String)                               │
│                                                             │
│  Attributes:                                                │
│  ├── name (String)                                          │
│  ├── email (String)                                         │
│  ├── company (String, optional)                             │
│  ├── subject (String)                                       │
│  ├── message (String)                                       │
│  ├── status (String: new/contacted/qualified/converted)     │
│  ├── createdAt (String, ISO timestamp)                      │
│  └── updatedAt (String, ISO timestamp)                      │
│                                                             │
│  GSI: email-index                                           │
│  ├── Partition Key: email                                   │
│  └── Sort Key: createdAt                                    │
│                                                             │
│  GSI: status-index                                          │
│  ├── Partition Key: status                                  │
│  └── Sort Key: createdAt                                    │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Why This Design?

leadId as partition key: Unique IDs ensure even distribution and fast lookups
No sort key on main table: Simple key structure for CRUD operations
GSIs for query patterns: Enable efficient queries without scanning

Setting Up the Stack

CDK Infrastructure

Create lib/dynamodb-stack.ts:

import * as cdk from "aws-cdk-lib";
import * as dynamodb from "aws-cdk-lib/aws-dynamodb";
import * as lambda from "aws-cdk-lib/aws-lambda";
import * as lambdaNodejs from "aws-cdk-lib/aws-lambda-nodejs";
import * as apigateway from "aws-cdk-lib/aws-apigateway";
import { Construct } from "constructs";

export class DynamoDbStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // ============================================
    // DynamoDB Table
    // ============================================
    const leadsTable = new dynamodb.Table(this, "LeadsTable", {
      tableName: "ContactFormLeads",

      // Partition key only - simple design for CRUD
      partitionKey: {
        name: "leadId",
        type: dynamodb.AttributeType.STRING,
      },

      // On-demand = auto-scaling, pay-per-request
      billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,

      // Point-in-time recovery for data protection
      pointInTimeRecovery: true,

      // Encryption at rest
      encryption: dynamodb.TableEncryption.AWS_MANAGED,

      // DESTROY for dev (RETAIN for production!)
      removalPolicy: cdk.RemovalPolicy.DESTROY,
    });

    // GSI for querying by email
    leadsTable.addGlobalSecondaryIndex({
      indexName: "email-index",
      partitionKey: {
        name: "email",
        type: dynamodb.AttributeType.STRING,
      },
      sortKey: {
        name: "createdAt",
        type: dynamodb.AttributeType.STRING,
      },
      projectionType: dynamodb.ProjectionType.ALL,
    });

    // GSI for filtering by status
    leadsTable.addGlobalSecondaryIndex({
      indexName: "status-index",
      partitionKey: {
        name: "status",
        type: dynamodb.AttributeType.STRING,
      },
      sortKey: {
        name: "createdAt",
        type: dynamodb.AttributeType.STRING,
      },
      projectionType: dynamodb.ProjectionType.ALL,
    });

    // Lambda Function with DynamoDB access
    const leadsHandler = new lambdaNodejs.NodejsFunction(this, "LeadsHandler", {
      runtime: lambda.Runtime.NODEJS_22_X,
      entry: path.join(__dirname, "../lambda/handlers/leads.ts"),
      handler: "handler",
      description: "Leads CRUD operations with DynamoDB",
      timeout: cdk.Duration.seconds(30),
      memorySize: 256,
      logRetention: logs.RetentionDays.ONE_WEEK,
      environment: {
        TABLE_NAME: leadsTable.tableName,
        EMAIL_INDEX: "email-index",
        STATUS_INDEX: "status-index",
      },
      bundling: {
        minify: true,
        sourceMap: true,
      },
    });

    // Grant read/write permissions
    leadsTable.grantReadWriteData(leadsHandler);

    // ... API Gateway setup (same as Part 2)
  }
}

Key Points

billingMode: PAY_PER_REQUEST: Scales automatically, no capacity planning
grantReadWriteData(): CDK automatically creates the IAM policy
Environment variables: Pass table name to Lambda

CRUD Operations with AWS SDK v3

Setting Up the Client

import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import {
  PutItemCommand,
  GetItemCommand,
  UpdateItemCommand,
  DeleteItemCommand,
  QueryCommand,
  ScanCommand,
} from "@aws-sdk/client-dynamodb";
import { marshall, unmarshall } from "@aws-sdk/util-dynamodb";

const dynamoClient = new DynamoDBClient({});
const TABLE_NAME = process.env.TABLE_NAME!;

Create (PutItem)

async function createLead(leadData: CreateLeadRequest): Promise<Lead> {
  const lead: Lead = {
    leadId: `lead_${Date.now()}_${Math.random().toString(36).slice(2)}`,
    name: leadData.name.trim(),
    email: leadData.email.toLowerCase().trim(),
    company: leadData.company?.trim(),
    subject: leadData.subject,
    message: leadData.message.trim(),
    status: "new",
    createdAt: new Date().toISOString(),
    updatedAt: new Date().toISOString(),
  };

  const command = new PutItemCommand({
    TableName: TABLE_NAME,
    Item: marshall(lead, { removeUndefinedValues: true }),
    // Prevent accidental overwrites
    ConditionExpression: "attribute_not_exists(leadId)",
  });

  await dynamoClient.send(command);
  return lead;
}

Key Points:

marshall() converts JS objects to DynamoDB format
removeUndefinedValues: true handles optional fields
ConditionExpression prevents duplicate IDs (though unlikely)

Read (GetItem)

async function getLeadById(leadId: string): Promise<Lead | null> {
  const command = new GetItemCommand({
    TableName: TABLE_NAME,
    Key: marshall({ leadId }),
  });

  const response = await dynamoClient.send(command);

  if (!response.Item) {
    return null;
  }

  return unmarshall(response.Item) as Lead;
}

Key Points:

GetItem is extremely fast (single-digit milliseconds)
unmarshall() converts DynamoDB format back to JS

Update (UpdateItem)

async function updateLead(
  leadId: string,
  updates: UpdateLeadRequest,
): Promise<Lead | null> {
  // Build update expression dynamically
  const updateExpressions: string[] = [];
  const expressionAttributeNames: Record<string, string> = {};
  const expressionAttributeValues: Record<string, any> = {};

  // Always update timestamp
  updateExpressions.push("#updatedAt = :updatedAt");
  expressionAttributeNames["#updatedAt"] = "updatedAt";
  expressionAttributeValues[":updatedAt"] = new Date().toISOString();

  // Add fields that have values
  if (updates.status !== undefined) {
    updateExpressions.push("#status = :status");
    expressionAttributeNames["#status"] = "status";
    expressionAttributeValues[":status"] = updates.status;
  }

  // ... add other fields similarly

  const command = new UpdateItemCommand({
    TableName: TABLE_NAME,
    Key: marshall({ leadId }),
    UpdateExpression: `SET ${updateExpressions.join(", ")}`,
    ExpressionAttributeNames: expressionAttributeNames,
    ExpressionAttributeValues: marshall(expressionAttributeValues),
    ConditionExpression: "attribute_exists(leadId)",
    ReturnValues: "ALL_NEW",
  });

  try {
    const response = await dynamoClient.send(command);
    return unmarshall(response.Attributes!) as Lead;
  } catch (error: any) {
    if (error.name === "ConditionalCheckFailedException") {
      return null; // Item doesn't exist
    }
    throw error;
  }
}

Key Points:

Use expression attribute names (#status) for reserved words
Dynamic expressions allow partial updates
ReturnValues: 'ALL_NEW' returns the updated item

Delete (DeleteItem)

async function deleteLead(leadId: string): Promise<boolean> {
  const command = new DeleteItemCommand({
    TableName: TABLE_NAME,
    Key: marshall({ leadId }),
    ConditionExpression: "attribute_exists(leadId)",
  });

  try {
    await dynamoClient.send(command);
    return true;
  } catch (error: any) {
    if (error.name === "ConditionalCheckFailedException") {
      return false; // Item doesn't exist
    }
    throw error;
  }
}

Global Secondary Indexes

Query by Email (GSI)

async function getLeadsByEmail(email: string): Promise<Lead[]> {
  const command = new QueryCommand({
    TableName: TABLE_NAME,
    IndexName: "email-index",
    KeyConditionExpression: "email = :email",
    ExpressionAttributeValues: marshall({
      ":email": email.toLowerCase(),
    }),
    // Newest first
    ScanIndexForward: false,
  });

  const response = await dynamoClient.send(command);
  return (response.Items || []).map((item) => unmarshall(item) as Lead);
}

Filter by Status (GSI)

async function getLeadsByStatus(status: string): Promise<Lead[]> {
  const command = new QueryCommand({
    TableName: TABLE_NAME,
    IndexName: "status-index",
    KeyConditionExpression: "#status = :status",
    ExpressionAttributeNames: {
      "#status": "status", // 'status' is a reserved word
    },
    ExpressionAttributeValues: marshall({
      ":status": status,
    }),
    ScanIndexForward: false,
  });

  const response = await dynamoClient.send(command);
  return (response.Items || []).map((item) => unmarshall(item) as Lead);
}

Query vs Scan

The Critical Difference

Operation	Performance	Use Case
Query	O(n) - reads matched items only	Specific key lookups
Scan	O(N) - reads ENTIRE table	Full table access

Example: Finding "new" leads

❌ Slow: Scan with Filter

// This reads EVERY item in the table!
const command = new ScanCommand({
  TableName: TABLE_NAME,
  FilterExpression: "#status = :status",
  ExpressionAttributeNames: { "#status": "status" },
  ExpressionAttributeValues: marshall({ ":status": "new" }),
});

✅ Fast: Query with GSI

// This reads only matching items
const command = new QueryCommand({
  TableName: TABLE_NAME,
  IndexName: "status-index",
  KeyConditionExpression: "#status = :status",
  ExpressionAttributeNames: { "#status": "status" },
  ExpressionAttributeValues: marshall({ ":status": "new" }),
});

The difference at scale:

1 million leads, 100 are "new"
Scan: Reads 1,000,000 items → $$$, slow
Query: Reads 100 items → Pennies, fast

Gotchas & Common Pitfalls

1. Reserved Words

Problem: status, name, data are reserved words.

// ❌ This fails
UpdateExpression: 'SET status = :status'

// ✅ Use expression attribute names
UpdateExpression: 'SET #status = :status',
ExpressionAttributeNames: { '#status': 'status' }

2. Empty Strings

Problem: DynamoDB doesn't allow empty strings in certain contexts.

// ❌ This fails for empty company
Item: {
  company: "";
}

// ✅ Use removeUndefinedValues and check for empty
marshall(lead, { removeUndefinedValues: true });

// Or explicitly handle
company: leadData.company?.trim() || undefined;

3. Conditional Check Failures

Problem: ConditionExpression throws on failure.

try {
  await dynamoClient.send(command);
} catch (error: any) {
  if (error.name === "ConditionalCheckFailedException") {
    // Handle gracefully (item doesn't exist or condition failed)
    return null;
  }
  throw error;
}

4. Large Items

Problem: DynamoDB has a 400KB item size limit.

Solution: Store large content (like file attachments) in S3, store the S3 URL in DynamoDB.

Best Practices

1. Use On-Demand for Variable Workloads

billingMode: dynamodb.BillingMode.PAY_PER_REQUEST;

No capacity planning, automatic scaling, pay only for what you use.

2. Enable Point-in-Time Recovery

pointInTimeRecovery: true;

Protects against accidental deletes. Can restore to any point in the last 35 days.

3. Use Batch Operations for Bulk Actions

For multiple items, use BatchGetItem and BatchWriteItem:

import { BatchWriteCommand } from "@aws-sdk/lib-dynamodb";

// Write up to 25 items at once
const command = new BatchWriteCommand({
  RequestItems: {
    [TABLE_NAME]: leads.map((lead) => ({
      PutRequest: { Item: lead },
    })),
  },
});

Check out my DynamoDB Batch Operations blog for detailed patterns.

4. Design for Even Distribution

Avoid "hot" partitions by choosing well-distributed partition keys:

// ✅ Good - even distribution
partitionKey: { name: 'leadId', type: STRING }

// ❌ Bad - hot partitions (if most leads are 'new')
partitionKey: { name: 'status', type: STRING }

Cost Considerations

Pricing Model

Operation	On-Demand Cost
Write (1KB)	$0.625 per million
Read (4KB)	$0.125 per million
Storage	$0.25 per GB/month
GSI Writes	Same as table
GSI Reads	Same as table

Real-World Example

For a contact form with:

1,000 leads/month (writes)
10,000 reads/month (admin dashboard)
1GB storage

Monthly Cost:

Writes: 0.001M × $0.625 = $0.000625
Reads: 0.01M × $0.125 = $0.00125
Storage: 1GB × $0.25 = $0.25
Total: ~$0.25/month (essentially free!)

Conclusion

Your contact form now has a rock-solid persistence layer! 🎉

In this part, you learned:

✅ DynamoDB table design for serverless
✅ Global Secondary Indexes for flexible queries
✅ CRUD operations with AWS SDK v3
✅ Query vs Scan performance implications
✅ Production-ready error handling

Your leads are now safely stored and can be queried efficiently. No more data disappearing when Lambda recycles!

In Part 4, we'll bring everything together – frontend, API, and database – into a complete, production-ready application with:

Full frontend-backend integration
Environment configuration
Monitoring and alerting
Production deployment checklist

Related Posts:

GitHub Repository: aws-serverless-website-tutorial

See you until next time. Happy coding! 🚀

References

Powering Your App with Serverless APIs: AWS API Gateway & Lambda Integration

Dixit R Jain — Tue, 27 Jan 2026 18:35:13 +0000

Introduction
Why API Gateway + Lambda?
What We're Building
Project Setup
Creating Lambda Functions
Building the API Gateway
CORS Configuration Deep Dive
Deployment
Testing Your API
Connecting to the Frontend
Gotchas & Common Pitfalls
Best Practices
Cost Considerations
Conclusion
References

Introduction

Quick Links:

📂 Source Code: GitHub Repository

🚀 Live Demo: https://dmcechq7isaw7.cloudfront.net/

In Part 1, we launched a beautiful contact form website using S3 and CloudFront. But there's a problem – our form doesn't actually do anything yet. Click "Send Message" and... nothing happens. The data just vanishes into the void.

Today, we're going to change that.

Imagine you're building a lead generation system for your business. Every contact matters. You need a reliable, scalable backend that can handle one request or a million – without breaking a sweat or your budget. That's exactly what API Gateway and Lambda deliver.

In this second part of our Serverless Web Mastery series, we'll transform our static website into a dynamic application by creating a fully-functional REST API. By the end of this post, you'll have an API that can create, read, update, and delete leads – all without managing a single server.

Let's make that form come alive!

Why API Gateway + Lambda?

Before diving into code, let's understand why this combination is so powerful:

🔌 API Gateway Benefits

Feature	What It Does
Managed Infrastructure	No servers to patch or scale
Built-in Security	API keys, throttling, WAF integration
Request Validation	Validate requests before hitting Lambda
CORS Handling	Browser security headers, automatic OPTIONS
Monitoring	CloudWatch integration out of the box

⚡ Lambda Benefits

Feature	What It Does
Pay-per-use	Billed only when your code runs
Auto-scaling	0 to thousands of concurrent executions
No Cold Servers	No idle instances burning money
Multiple Runtimes	Node.js, Python, Go, Rust, and more
Integration	Direct access to 200+ AWS services

💰 The Cost Advantage

Traditional server: ~$40-100/month (even when idle)
Serverless (1000 requests/day): ~$0.50/month

That's a 99% cost reduction for most small to medium workloads!

What We're Building

Our Contact Form API will have these endpoints:

┌─────────────────────────────────────────────────────────────┐
│                       API Endpoints                         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   GET    /health         → Health check (monitoring)        │
│   POST   /leads          → Create a new lead                │
│   GET    /leads          → List all leads (admin)           │
│   GET    /leads/{id}     → Get specific lead                │
│   PUT    /leads/{id}     → Update a lead                    │
│   DELETE /leads/{id}     → Delete a lead                    │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Architecture Overview:

                    ┌─────────────────┐
                    │   CloudFront    │
                    │  (Part 1 Site)  │
                    └────────┬────────┘
                             │
                             ▼
┌───────────────────────────────────────────────────────┐
│                    API Gateway                        │
│                   (REST API)                          │
│                                                       │
│  • CORS configuration                                 │
│  • Request throttling                                 │
│  • CloudWatch logging                                 │
└───────────────────────────────────────────────────────┘
                             │
           ┌─────────────────┼─────────────────┐
           ▼                 ▼                 ▼
    ┌─────────────┐   ┌─────────────┐   ┌─────────────┐
    │   Health    │   │    Leads    │   │   Future    │
    │   Handler   │   │   Handler   │   │  Handlers   │
    │   (Lambda)  │   │   (Lambda)  │   │   (Lambda)  │
    └─────────────┘   └─────────────┘   └─────────────┘

Project Setup

Let's create the Part 2 directory structure:

cd aws-serverless-website-tutorial
mkdir -p part-2-api-lambda/{cdk,lambda/handlers}
cd part-2-api-lambda/cdk

Create package.json:

{
  "name": "api-lambda-cdk",
  "version": "1.0.0",
  "scripts": {
    "build": "tsc",
    "deploy": "cdk deploy",
    "destroy": "cdk destroy"
  },
  "dependencies": {
    "aws-cdk-lib": "^2.170.0",
    "constructs": "^10.4.2"
  },
  "devDependencies": {
    "@types/node": "^22.10.0",
    "typescript": "~5.7.0",
    "aws-cdk": "^2.170.0"
  }
}

Install dependencies:

npm install

Creating Lambda Functions

Health Check Handler

A simple health check is essential for monitoring. Create lambda/handlers/health.ts:

import {
  APIGatewayProxyEvent,
  APIGatewayProxyResult,
  Context,
} from "aws-lambda";

interface HealthResponse {
  status: "healthy" | "degraded" | "unhealthy";
  timestamp: string;
  version: string;
  region: string;
}

export const handler = async (
  event: APIGatewayProxyEvent,
  context: Context,
): Promise<APIGatewayProxyResult> => {
  console.log("Health check requested", {
    requestId: context.awsRequestId,
  });

  const response: HealthResponse = {
    status: "healthy",
    timestamp: new Date().toISOString(),
    version: "1.0.0",
    region: process.env.AWS_REGION || "unknown",
  };

  return {
    statusCode: 200,
    headers: {
      "Content-Type": "application/json",
      "Access-Control-Allow-Origin": "*",
    },
    body: JSON.stringify(response),
  };
};

Why a health endpoint?

Load balancers need it
Monitoring systems poll it
Quick verification during deployment

Leads Handler

Now for the main event – our leads CRUD handler. Create lambda/handlers/leads.ts:

import {
  APIGatewayProxyEvent,
  APIGatewayProxyResult,
  Context,
} from "aws-lambda";

// Lead interface
interface Lead {
  id: string;
  name: string;
  email: string;
  company?: string;
  subject: string;
  message: string;
  status: "new" | "contacted" | "qualified" | "converted";
  createdAt: string;
  updatedAt: string;
}

// In-memory storage (replaced with DynamoDB in Part 3)
const leadsStorage: Map<string, Lead> = new Map();

// Generate unique ID
function generateId(): string {
  return `lead_${Date.now()}_${Math.random().toString(36).substring(2, 9)}`;
}

// Validate create request
function validateCreateRequest(body: any): { valid: boolean; error?: string } {
  if (!body.name || body.name.length < 2) {
    return { valid: false, error: "Name is required (min 2 characters)" };
  }
  if (!body.email || !body.email.includes("@")) {
    return { valid: false, error: "Valid email is required" };
  }
  if (!body.message || body.message.length < 10) {
    return { valid: false, error: "Message is required (min 10 characters)" };
  }
  return { valid: true };
}

// Create standardized response
function createResponse(
  statusCode: number,
  body: object,
): APIGatewayProxyResult {
  return {
    statusCode,
    headers: {
      "Content-Type": "application/json",
      "Access-Control-Allow-Origin": "*",
      "Access-Control-Allow-Headers": "Content-Type",
      "Access-Control-Allow-Methods": "GET,POST,PUT,DELETE,OPTIONS",
    },
    body: JSON.stringify(body),
  };
}

// Main handler
export const handler = async (
  event: APIGatewayProxyEvent,
  context: Context,
): Promise<APIGatewayProxyResult> => {
  const { httpMethod, pathParameters, body } = event;
  const leadId = pathParameters?.id;

  console.log("Request:", {
    method: httpMethod,
    leadId,
    requestId: context.awsRequestId,
  });

  try {
    switch (httpMethod) {
      // Create new lead
      case "POST": {
        const parsedBody = JSON.parse(body || "{}");
        const validation = validateCreateRequest(parsedBody);

        if (!validation.valid) {
          return createResponse(400, {
            success: false,
            error: validation.error,
          });
        }

        const now = new Date().toISOString();
        const lead: Lead = {
          id: generateId(),
          name: parsedBody.name.trim(),
          email: parsedBody.email.toLowerCase().trim(),
          company: parsedBody.company?.trim(),
          subject: parsedBody.subject || "general",
          message: parsedBody.message.trim(),
          status: "new",
          createdAt: now,
          updatedAt: now,
        };

        leadsStorage.set(lead.id, lead);
        console.log("Lead created:", lead.id);

        return createResponse(201, {
          success: true,
          data: lead,
          message: "Lead created successfully",
        });
      }

      // List all leads
      case "GET": {
        if (leadId) {
          const lead = leadsStorage.get(leadId);
          if (!lead) {
            return createResponse(404, {
              success: false,
              error: "Lead not found",
            });
          }
          return createResponse(200, { success: true, data: lead });
        }

        const leads = Array.from(leadsStorage.values());
        return createResponse(200, {
          success: true,
          data: leads,
          message: `Found ${leads.length} lead(s)`,
        });
      }

      // Update lead
      case "PUT": {
        if (!leadId) {
          return createResponse(400, {
            success: false,
            error: "Lead ID required",
          });
        }

        const lead = leadsStorage.get(leadId);
        if (!lead) {
          return createResponse(404, {
            success: false,
            error: "Lead not found",
          });
        }

        const updates = JSON.parse(body || "{}");
        const updatedLead: Lead = {
          ...lead,
          ...updates,
          updatedAt: new Date().toISOString(),
        };

        leadsStorage.set(leadId, updatedLead);
        return createResponse(200, { success: true, data: updatedLead });
      }

      // Delete lead
      case "DELETE": {
        if (!leadId) {
          return createResponse(400, {
            success: false,
            error: "Lead ID required",
          });
        }

        const deleted = leadsStorage.delete(leadId);
        if (!deleted) {
          return createResponse(404, {
            success: false,
            error: "Lead not found",
          });
        }

        return createResponse(200, { success: true, message: "Lead deleted" });
      }

      default:
        return createResponse(405, {
          success: false,
          error: "Method not allowed",
        });
    }
  } catch (error) {
    console.error("Error:", error);
    return createResponse(500, {
      success: false,
      error: "Internal server error",
    });
  }
};

Important Note: This uses in-memory storage for simplicity. In Part 3, we'll replace this with DynamoDB for persistent storage.

Building the API Gateway

Now let's wire everything together with CDK. Create lib/api-lambda-stack.ts:

import * as cdk from "aws-cdk-lib";
import * as lambda from "aws-cdk-lib/aws-lambda";
import * as apigateway from "aws-cdk-lib/aws-apigateway";
import * as logs from "aws-cdk-lib/aws-logs";
import * as lambdaNodejs from "aws-cdk-lib/aws-lambda-nodejs";
import { Construct } from "constructs";
import * as path from "path";

export class ApiLambdaStack extends cdk.Stack {
  public readonly api: apigateway.RestApi;

  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // ============================================
    // Lambda Functions
    // ============================================

    // Health Check Handler
    const healthHandler = new lambdaNodejs.NodejsFunction(
      this,
      "HealthHandler",
      {
        runtime: lambda.Runtime.NODEJS_22_X,
        entry: path.join(__dirname, "../../lambda/handlers/health.ts"),
        handler: "handler",
        description: "Health check endpoint",
        timeout: cdk.Duration.seconds(10),
        memorySize: 128,
        logRetention: logs.RetentionDays.ONE_WEEK,
        // Environment variables
        environment: {
          NODE_ENV: "production",
          LOG_LEVEL: "INFO",
        },
        bundling: {
          minify: true,
          sourceMap: true,
        },
      },
    );

    // Leads Handler
    const leadsHandler = new lambdaNodejs.NodejsFunction(this, "LeadsHandler", {
      runtime: lambda.Runtime.NODEJS_22_X,
      entry: path.join(__dirname, "../../lambda/handlers/leads.ts"),
      handler: "handler",
      description: "Leads CRUD operations",
      timeout: cdk.Duration.seconds(30),
      memorySize: 256,
      logRetention: logs.RetentionDays.ONE_WEEK,
      environment: {
        NODE_ENV: "production",
        LOG_LEVEL: "INFO",
      },
      bundling: {
        minify: true,
        sourceMap: true,
      },
    });

    // ============================================
    // API Gateway
    // ============================================
    this.api = new apigateway.RestApi(this, "ContactFormApi", {
      restApiName: "Contact Form API",
      description: "Serverless API for contact form",

      deployOptions: {
        stageName: "prod",
        loggingLevel: apigateway.MethodLoggingLevel.INFO,
        metricsEnabled: true,
        throttlingBurstLimit: 100,
        throttlingRateLimit: 50,
      },

      // CORS - Critical for browser requests!
      defaultCorsPreflightOptions: {
        allowOrigins: apigateway.Cors.ALL_ORIGINS,
        allowMethods: apigateway.Cors.ALL_METHODS,
        allowHeaders: ["Content-Type", "Authorization"],
        allowCredentials: true,
      },
    });

    // ============================================
    // API Routes
    // ============================================

    // Health endpoint: GET /health
    const apiResource = this.api.root.addResource('api');
    const healthResource = apiResource.addResource('health');
    healthResource.addMethod('GET', new apigateway.LambdaIntegration(healthHandler, {
        proxy: true, // Use Lambda Proxy Integration
    }));

    // Leads endpoints
    const leadsResource = apiResource.addResource('leads');

    // POST /leads - Create a new lead
    leadsResource.addMethod('POST', new apigateway.LambdaIntegration(this.leadsHandler, {
        proxy: true,
    }));

    // GET /leads - List all leads
    leadsResource.addMethod('GET', new apigateway.LambdaIntegration(this.leadsHandler, {
        proxy: true,
    }));

    // Single lead endpoints: /leads/{id}
    const leadByIdResource = leadsResource.addResource('{id}');

    // GET /leads/{id} - Get specific lead
    leadByIdResource.addMethod('GET', new apigateway.LambdaIntegration(this.leadsHandler, {
        proxy: true,
    }));

    // PUT /leads/{id} - Update a lead
    leadByIdResource.addMethod('PUT', new apigateway.LambdaIntegration(this.leadsHandler, {
        proxy: true,
    }));

    // DELETE /leads/{id} - Delete a lead
    leadByIdResource.addMethod('DELETE', new apigateway.LambdaIntegration(this.leadsHandler, {
        proxy: true,
    }));

    // ============================================
    // Outputs
    // ============================================
    new cdk.CfnOutput(this, "ApiEndpoint", {
      value: this.api.url,
      description: "API Gateway endpoint URL",
    });
  }
}

Deep Dive: Proxy vs. Non-Proxy Integration

You'll notice we used { proxy: true } in our Lambda integration. What does this mean?

Lambda Proxy Integration (Recommended)

How it works: API Gateway passes the entire HTTP request (headers, body, query params) to your Lambda function as a JSON object.
Your Responsibility: Your Lambda must return a response in a specific format: { statusCode: 200, body: "..." }.
Pros: Full control over the response, access to all request details, easier to test locally.

Non-Proxy Integration

How it works: API Gateway transforms the incoming request using "Mapping Templates" before sending it to Lambda, and transforms the Lambda's response before sending it back to the client.
Pros: Decouples your backend logic from HTTP details.
Cons: Velocity Template Language (VTL) is hard to debug and maintain.

For modern serverless applications, Proxy Integration is the standard because it keeps the infrastructure simple (no VTL) and moves the logic into the code (TypeScript), which is where we want it!

CORS Configuration Deep Dive

CORS (Cross-Origin Resource Sharing) is often the #1 source of frustration when building APIs. Let me save you hours of debugging:

What is CORS?

When your frontend (hosted on d123.cloudfront.net) makes a request to your API (abc.execute-api.amazonaws.com), browsers block this by default. CORS headers tell the browser "it's okay, allow this request."

What Headers Do We Need?

'Access-Control-Allow-Origin': '*'  // or specific domain
'Access-Control-Allow-Methods': 'GET,POST,PUT,DELETE,OPTIONS'
'Access-Control-Allow-Headers': 'Content-Type,Authorization'
'Access-Control-Allow-Credentials': 'true'  // if using cookies

API Gateway CORS vs Lambda CORS

You need CORS in both places:

API Gateway - Handles OPTIONS preflight requests
Lambda Response - Includes headers in actual responses

// In CDK (API Gateway level)
defaultCorsPreflightOptions: {
  allowOrigins: apigateway.Cors.ALL_ORIGINS,
  allowMethods: apigateway.Cors.ALL_METHODS,
}

// In Lambda (Response level)
return {
  headers: {
    'Access-Control-Allow-Origin': '*',
  },
  // ... rest of response
};

Production Tip

Replace * with your specific domain:

allowOrigins: ['https://yourdomain.com'],

Deployment

Deploy your API:

cd part-2-api-lambda/cdk
npm install
npx cdk deploy

You'll see outputs like:

✅  ContactFormApiStack

Outputs:
ContactFormApiStack.ApiEndpoint = https://abc123xyz.execute-api.us-east-1.amazonaws.com/prod/

🎉 Your API is live!

Testing Your API

Using curl

# Health check
curl https://YOUR_API/health

# Create a lead
curl -X POST https://YOUR_API/leads \
  -H "Content-Type: application/json" \
  -d '{
    "name": "John Doe",
    "email": "john@example.com",
    "subject": "general",
    "message": "Testing the API!"
  }'

# List leads
curl https://YOUR_API/leads

Using Postman

Import this collection for easy testing:

Create new request
Set URL to your API endpoint
Set method (GET, POST, etc.)
For POST/PUT, add JSON body
Send!

Connecting to the Frontend

Update your Part 1 frontend app.js:

const CONFIG = {
  // Replace with your actual API endpoint
  API_ENDPOINT: "https://abc123xyz.execute-api.us-east-1.amazonaws.com/prod",
};

async function submitToAPI(formData) {
  const response = await fetch(`${CONFIG.API_ENDPOINT}/leads`, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify(formData),
  });

  if (!response.ok) {
    const error = await response.json();
    throw new Error(error.error || "Failed to submit form");
  }

  return response.json();
}

Now your form actually works! 🎉

Gotchas & Common Pitfalls

1. CORS Errors

Problem: "Access to fetch has been blocked by CORS policy"

Solution: Check both:

API Gateway CORS configuration
Lambda response headers

// Make sure both have matching headers!

2. 502 Bad Gateway

Problem: API returns 502 error

Causes:

Lambda threw an unhandled exception
Lambda timed out
Response format incorrect

Solution: Check CloudWatch logs:

aws logs tail /aws/lambda/YourFunctionName --follow

3. Lambda Proxy Integration Response Format

Problem: API Gateway doesn't understand Lambda response

Solution: Always return this exact format:

return {
  statusCode: 200,  // Number, not string!
  headers: { ... },
  body: JSON.stringify({ ... }),  // Must be string!
};

4. Path Parameters Not Working

Problem: pathParameters is null or undefined

Solution: Ensure the path parameter is defined in API Gateway:

const leadById = leads.addResource("{id}"); // Note the curly braces!

Best Practices

1. Use Lambda Proxy Integration

Always use proxy integration for flexibility:

new apigateway.LambdaIntegration(handler, {
  proxy: true, // This is the default, but be explicit
});

2. Implement Request Validation

Validate early, fail fast:

function validateRequest(body: any): { valid: boolean; error?: string } {
  if (!body.email) return { valid: false, error: "Email required" };
  if (!isValidEmail(body.email))
    return { valid: false, error: "Invalid email" };
  // ... more validations
  return { valid: true };
}

3. Consistent Error Responses

Use a standard error format:

interface ErrorResponse {
  success: false;
  error: string;
  code?: string;
}

4. Add Request Throttling

Protect your API from abuse:

deployOptions: {
  throttlingBurstLimit: 100,  // Max concurrent requests
  throttlingRateLimit: 50,    // Requests per second
}

5. Enable CloudWatch Logging

Debugging is impossible without logs:

logRetention: logs.RetentionDays.ONE_WEEK,

Cost Considerations

Let's break down the costs:

Service	Free Tier	Cost After
API Gateway	1M requests/month	$3.50 per million
Lambda Requests	1M requests/month	$0.20 per million
Lambda Duration	400K GB-seconds	~$0.0000167/GB-second
CloudWatch Logs	5GB ingestion/month	$0.50/GB

Real-World Example

For a contact form receiving 1,000 submissions/day:

API Gateway: 30K requests/month → Free
Lambda: 30K invocations, ~100ms each → Free
Total: $0/month (within free tier!)

Even at 100K submissions/day, you're looking at ~$5/month.

Conclusion

Congratulations! 🎉 You've built a production-ready REST API with:

✅ Multiple Lambda functions
✅ RESTful API Gateway endpoints
✅ CORS configuration for browser access
✅ Input validation
✅ Error handling
✅ CloudWatch logging
✅ Request throttling

But wait – there's a catch. Our current implementation uses in-memory storage, which means data is lost when Lambda recycles.

In Part 3, we'll fix this by adding DynamoDB for persistent storage. You'll learn:

DynamoDB table design
CRUD operations with AWS SDK v3
Batch operations for performance (check out my DynamoDB Batch Operations blog)
Proper error handling and retries

If you're stuck on any CDK issues, my AWS CDK Debugging Guide has got you covered.

GitHub Repository: aws-serverless-website-tutorial

See you until next time. Happy coding! 🚀

References

Launching Your First Serverless Website: Mastering S3 Static Hosting with AWS CDK

Dixit R Jain — Tue, 27 Jan 2026 17:30:00 +0000

Introduction
Why Serverless Static Hosting?
What We're Building
Prerequisites
Project Setup
Creating the CDK Stack
Building the Frontend
Deployment
Custom Domain Setup
Gotchas & Common Pitfalls
Best Practices
Cost Considerations
Conclusion
References

Introduction

Quick Links:

📂 Source Code: GitHub Repository

🚀 Live Demo: https://dmcechq7isaw7.cloudfront.net/

Picture this: You've just built a beautiful landing page for your startup, a portfolio showcasing your work, or in our case, a sleek contact form for capturing leads. Now comes the daunting question – where do you host it? Traditional servers? That means dealing with patching, scaling, and those dreaded 3 AM alerts when traffic spikes.

What if I told you there's a way to host your website that scales automatically to millions of users, costs pennies, requires zero server management, and delivers content at lightning speed from edge locations worldwide?

Welcome to the world of serverless static hosting with AWS S3 and CloudFront.

In this first part of our Serverless Web Mastery series, we'll transform a simple contact form into a globally-distributed, production-ready website using Infrastructure as Code. No more clicking through AWS consoles – we'll define everything in TypeScript using AWS CDK.

Let's dive in!

Why Serverless Static Hosting?

Before we write any code, let's understand why this architecture is a game-changer:

🚀 Performance

Content served from 400+ CloudFront edge locations worldwide
Sub-100ms latency for users globally
Automatic compression and HTTP/2 support

💰 Cost Efficiency

Pay only for what you use (storage + requests)
No idle servers burning money 24/7
AWS Free Tier covers most small to medium sites

🔒 Security

HTTPS by default with CloudFront
S3 bucket completely private (no public access)
DDoS protection via AWS Shield Standard (included free!)

📈 Scalability

Handles millions of requests without configuration
No capacity planning or auto-scaling rules needed
Zero downtime deployments

🛠️ Simplicity

No servers to patch or manage
One command deployment with CDK
Infrastructure defined as version-controlled code

What We're Building

Throughout this series, we're building a Contact Form for Lead Generation – a real-world application that captures visitor information and stores it in a database.

In Part 1, we'll create:

┌─────────────────────────────────────────────────────┐
│                   Architecture                      │
├─────────────────────────────────────────────────────┤
│                                                     │
│   User  ──────►  CloudFront  ──────►  S3 Bucket     │
│          HTTPS      CDN         Private Storage     │
│                                                     │
│   Features:                                         │
│   ✓ HTTPS everywhere                                │
│   ✓ Global edge caching                             │
│   ✓ Automatic compression                           │
│   ✓ Origin Access Control                           │
│                                                     │
└─────────────────────────────────────────────────────┘

In future parts:

Part 2: API Gateway + Lambda for form submission
Part 3: DynamoDB for data persistence
Part 4: Full integration and production deployment

Prerequisites

Before we begin, ensure you have:

Node.js 22.x or later (Download)
AWS CLI configured with credentials (Setup Guide)
AWS CDK installed globally:

  npm install -g aws-cdk

An AWS Account with appropriate permissions

Bootstrap Your AWS Account

If you haven't used CDK in your account before, bootstrap it:

cdk bootstrap aws://YOUR_ACCOUNT_ID/YOUR_REGION

Replace YOUR_ACCOUNT_ID and YOUR_REGION with your values (e.g., us-east-1).

Project Setup

Let's create our project structure:

mkdir aws-serverless-website-tutorial
cd aws-serverless-website-tutorial
mkdir -p part-1-s3-static-hosting/{cdk,frontend}
cd part-1-s3-static-hosting/cdk

Initialize the CDK project:

npx cdk init app --language typescript

Wait – we're going to do this a bit differently. Instead of the default template, let's create a clean, well-organized structure.

Create package.json:

{
  "name": "s3-website-cdk",
  "version": "1.0.0",
  "description": "CDK stack for S3 static website hosting with CloudFront",
  "main": "bin/app.js",
  "scripts": {
    "build": "tsc",
    "watch": "tsc -w",
    "cdk": "cdk",
    "synth": "cdk synth",
    "deploy": "cdk deploy",
    "destroy": "cdk destroy"
  },
  "dependencies": {
    "aws-cdk-lib": "^2.170.0",
    "constructs": "^10.4.2"
  },
  "devDependencies": {
    "@types/node": "^22.10.0",
    "typescript": "~5.7.0",
    "aws-cdk": "^2.170.0"
  }
}

Install dependencies:

npm install

Creating the CDK Stack

Now for the exciting part – defining our infrastructure!

CDK Entry Point

Create bin/app.ts:

#!/usr/bin/env node
import "source-map-support/register";
import * as cdk from "aws-cdk-lib";
import { S3WebsiteStack } from "../lib/s3-website-stack";

const app = new cdk.App();

// Create the S3 Website Stack
new S3WebsiteStack(app, "ContactFormWebsiteStack", {
  // Add meaningful tags for resource management
  tags: {
    Project: "ServerlessWebMastery",
    Part: "1-S3StaticHosting",
    Environment: "Development",
  },
  description:
    "Serverless Web Mastery Part 1: S3 Static Website with CloudFront",
});

app.synth();

The Main Stack

Here's where the magic happens. Create lib/s3-website-stack.ts:

import * as cdk from "aws-cdk-lib";
import * as s3 from "aws-cdk-lib/aws-s3";
import * as cloudfront from "aws-cdk-lib/aws-cloudfront";
import * as origins from "aws-cdk-lib/aws-cloudfront-origins";
import * as s3deploy from "aws-cdk-lib/aws-s3-deployment";
import { Construct } from "constructs";
import * as path from "path";

export class S3WebsiteStack extends cdk.Stack {
  public readonly websiteBucket: s3.Bucket;
  public readonly distribution: cloudfront.Distribution;

  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // ============================================
    // S3 Bucket for Static Website Files
    // ============================================
    this.websiteBucket = new s3.Bucket(this, "WebsiteBucket", {
      // Block ALL public access - CloudFront is our only entry point
      blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,

      // Enable versioning for rollback capability
      versioned: true,

      // Encryption at rest
      encryption: s3.BucketEncryption.S3_MANAGED,

      // Cleanup on stack deletion (use RETAIN for production!)
      removalPolicy: cdk.RemovalPolicy.DESTROY,
      autoDeleteObjects: true,

      // CORS for API calls (we'll use this in Part 2)
      cors: [
        {
          allowedHeaders: ["*"],
          allowedMethods: [s3.HttpMethods.GET, s3.HttpMethods.HEAD],
          allowedOrigins: ["*"],
          maxAge: 3000,
        },
      ],
    });

    // ============================================
    // CloudFront Distribution
    // ============================================
    this.distribution = new cloudfront.Distribution(
      this,
      "WebsiteDistribution",
      {
        defaultBehavior: {
          // Origin Access Control - the modern, secure way
          origin: origins.S3BucketOrigin.withOriginAccessControl(
            this.websiteBucket,
          ),

          // Always redirect HTTP to HTTPS
          viewerProtocolPolicy:
            cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,

          // Optimized caching for static content
          cachePolicy: cloudfront.CachePolicy.CACHING_OPTIMIZED,

          // Allow standard methods
          allowedMethods: cloudfront.AllowedMethods.ALLOW_GET_HEAD_OPTIONS,

          // Enable compression
          compress: true,
        },

        // Default page
        defaultRootObject: "index.html",

        // Handle SPA routing - return index.html for 404s
        errorResponses: [
          {
            httpStatus: 403,
            responseHttpStatus: 200,
            responsePagePath: "/index.html",
            ttl: cdk.Duration.minutes(5),
          },
          {
            httpStatus: 404,
            responseHttpStatus: 200,
            responsePagePath: "/index.html",
            ttl: cdk.Duration.minutes(5),
          },
        ],

        // Use cheaper edge locations (US, Canada, Europe)
        priceClass: cloudfront.PriceClass.PRICE_CLASS_100,

        // Enable HTTP/2 and HTTP/3 for better performance
        httpVersion: cloudfront.HttpVersion.HTTP2_AND_3,

        comment: "Contact Form Static Website - Serverless Web Mastery",
      },
    );

    // ============================================
    // Deploy Frontend Files
    // ============================================
    new s3deploy.BucketDeployment(this, "DeployWebsite", {
      sources: [s3deploy.Source.asset(path.join(__dirname, "../../frontend"))],
      destinationBucket: this.websiteBucket,

      // Invalidate CloudFront cache after deployment
      distribution: this.distribution,
      distributionPaths: ["/*"],
    });

    // ============================================
    // Outputs
    // ============================================
    new cdk.CfnOutput(this, "WebsiteURL", {
      value: `https://${this.distribution.distributionDomainName}`,
      description: "Website URL (CloudFront HTTPS)",
    });

    new cdk.CfnOutput(this, "DistributionId", {
      value: this.distribution.distributionId,
      description: "CloudFront Distribution ID",
    });

    new cdk.CfnOutput(this, "BucketName", {
      value: this.websiteBucket.bucketName,
      description: "S3 Bucket Name",
    });
  }
}

Let me break down what's happening here:

S3 Bucket Configuration

blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL;

Why? Security best practice. Our bucket is completely private. CloudFront accesses it via Origin Access Control (OAC), not public URLs.

Origin Access Control

origin: origins.S3BucketOrigin.withOriginAccessControl(this.websiteBucket);

Why? OAC is the modern replacement for Origin Access Identity (OAI). It's more secure and supports additional features like SigV4 signing.

Error Responses for SPAs

errorResponses: [
  {
    httpStatus: 404,
    responseHttpStatus: 200,
    responsePagePath: "/index.html",
  },
];

Why? If you're building a Single Page Application (SPA) with client-side routing, this ensures that deep links like /about or /contact return index.html instead of a 404.

Building the Frontend

Our contact form needs three files. Here's a glimpse (see the GitHub repository for complete code):

index.html

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Contact Us | Lead Generation Form</title>
    <link
      href="https://fonts.googleapis.com/css2?family=Inter:wght@300;400;500;600;700&display=swap"
      rel="stylesheet"
    />
    <link rel="stylesheet" href="styles.css" />
  </head>
  <body>
    <!-- Hero Section -->
    <section class="hero">
      <h1>Get in Touch with <span class="gradient-text">Our Team</span></h1>
      <p>Fill out the form below and we'll get back to you within 24 hours.</p>
    </section>

    <!-- Contact Form -->
    <form id="contactForm" class="contact-form">
      <div class="form-group">
        <label for="name">Full Name</label>
        <input type="text" id="name" required />
      </div>

      <div class="form-group">
        <label for="email">Email Address</label>
        <input type="email" id="email" required />
      </div>

      <div class="form-group">
        <label for="message">Message</label>
        <textarea id="message" required></textarea>
      </div>

      <button type="submit">Send Message</button>
    </form>

    <script src="app.js"></script>
  </body>
</html>

The complete frontend includes:

Modern glassmorphism design
Dark theme with gradient animations
Form validation
Responsive layout
Accessibility features

Deployment

With everything in place, deployment is a single command:

cd part-1-s3-static-hosting/cdk
npm install
npx cdk deploy

You'll see output like:

✅  ContactFormWebsiteStack

Outputs:
ContactFormWebsiteStack.WebsiteURL = https://d1234abcd.cloudfront.net
ContactFormWebsiteStack.BucketName = contactformwebsitestack-websitebucket-xyz123
ContactFormWebsiteStack.DistributionId = E1234ABCD

Open the WebsiteURL – your website is live! 🎉

Custom Domain Setup

Want to use your own domain like contact.yourcompany.com? Here's how:

Prerequisites

Domain registered in Route 53 (or hosted zone created)
ACM certificate in us-east-1 (required for CloudFront)

Code Changes

Add to your stack:

import * as acm from "aws-cdk-lib/aws-certificatemanager";
import * as route53 from "aws-cdk-lib/aws-route53";
import * as targets from "aws-cdk-lib/aws-route53-targets";

// Custom domain configuration
const domainName = "contact.yourcompany.com";
const hostedZoneDomain = "yourcompany.com";

// Look up your hosted zone
const hostedZone = route53.HostedZone.fromLookup(this, "Zone", {
  domainName: hostedZoneDomain,
});

// Create SSL certificate
const certificate = new acm.Certificate(this, "Certificate", {
  domainName: domainName,
  validation: acm.CertificateValidation.fromDns(hostedZone),
});

// Add to CloudFront distribution
this.distribution = new cloudfront.Distribution(this, "WebsiteDistribution", {
  // ... existing config ...
  domainNames: [domainName],
  certificate: certificate,
});

// Create DNS record pointing to CloudFront
new route53.ARecord(this, "AliasRecord", {
  zone: hostedZone,
  recordName: "contact",
  target: route53.RecordTarget.fromAlias(
    new targets.CloudFrontTarget(this.distribution),
  ),
});

Gotchas & Common Pitfalls

1. CloudFront Propagation Time

Problem: After deployment, the website shows "Access Denied" or returns 403.

Solution: CloudFront distributions take 5-15 minutes to propagate. Wait and retry.

2. Caching Issues

Problem: Updated files aren't appearing on the website.

Solution: Our CDK deployment automatically invalidates the cache. If you manually upload files, create an invalidation:

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

3. Region Mismatch for ACM

Problem: ACM certificate not found when adding custom domain.

Solution: CloudFront requires certificates in us-east-1. Create your certificate there, even if your stack is in another region:

const certificate = acm.Certificate.fromCertificateArn(
  this,
  "Certificate",
  "arn:aws:acm:us-east-1:ACCOUNT:certificate/CERT_ID",
);

4. S3 Bucket Already Exists

Problem: Deployment fails with "bucket already exists."

Solution: Bucket names are globally unique. Either:

Let CDK auto-generate the name (default)
Choose a unique name with your account/project prefix

Best Practices

1. Use Origin Access Control (OAC), Not OAI

OAC is the modern, more secure approach. It supports:

KMS encryption on S3
All S3 regions
Additional request headers

2. Enable Versioning for Rollbacks

versioned: true;

If a deployment goes wrong, you can restore previous versions.

3. Set Appropriate Cache TTLs

CloudFront caches by default. For frequently changing content, consider:

cachePolicy: new cloudfront.CachePolicy(this, 'CustomCachePolicy', {
  defaultTtl: cdk.Duration.hours(1),
  maxTtl: cdk.Duration.days(1),
  minTtl: cdk.Duration.minutes(1),
}),

4. Use DESTROY Only for Development

For production, use:

removalPolicy: cdk.RemovalPolicy.RETAIN;

This prevents accidental data loss.

Cost Considerations

Let's break down the costs:

Service	Free Tier	Typical Cost
S3 Storage	5GB/month	$0.023/GB
S3 Requests	20K GET, 2K PUT	$0.0004 per 1K GET
CloudFront Transfer	1TB/month	$0.085/GB (to Internet)
CloudFront Requests	10M/month	$0.0075 per 10K HTTPS

Real-World Example

For a small contact form website with:

100MB of static files
50,000 monthly visitors
5 requests per visit

Estimated Monthly Cost: $0 (well within free tier!)

For a high-traffic site with 1 million monthly visitors: ~$15-25/month

Conclusion

Congratulations! 🎉 You've just deployed a production-ready static website with:

✅ HTTPS encryption (free!)
✅ Global CDN distribution
✅ Automatic scaling
✅ Infrastructure as Code
✅ One-command deployments

This is just the beginning. In Part 2, we'll add a serverless backend with API Gateway and Lambda to actually process those form submissions.

If you liked this blog and found it helpful, check out my other AWS blogs:

GitHub Repository: aws-serverless-website-tutorial

See you until next time. Happy coding! 🚀

References

Unlocking Next-Gen Serverless Performance: A Deep Dive into AWS LLRT

Dixit R Jain — Sun, 24 Mar 2024 20:17:49 +0000

Introduction
Key Features
LLRT vs. Node.js
Benchmarking
AWS SDK V3 with LLRT
Use Cases
Configure Lambda functions to use LLRT
Compatibility
Limitations and Considerations
Conclusion
References

Introduction

The transition to serverless computing signifies a pivotal shift in application deployment, focusing more on code development than on managing infrastructure. This shift underscores the need for innovations that not only reduce latency but also enhance performance. AWS LLRT emerges as a significant advancement in this domain, offering a lightweight JavaScript runtime that outperforms traditional runtimes like Node.js in efficiency and reduced resource utilization. Designed specifically to address the 'cold start' problem in serverless computing, LLRT ensures rapid startup times, thus enhancing user experience and aligning cost-effectiveness with superior performance. This development marks a paradigm shift in application responsiveness to operational demands, prioritizing speed and efficiency in serverless architectures

Key Features

Swift Cold-Starts: LLRT provides a significant boost in performance, offering over 10x faster startup times, which is crucial for serverless applications where cold starts can impact the user experience.

Efficiency: By optimizing for low latency and efficient memory usage, LLRT ensures that applications are not only fast but also cost-effective, with up to 2x lower overall costs.

Specialized for Serverless Workload: LLRT is designed specifically for serverless computing, in contrast to general-purpose runtimes such as Node.js, Bun, or Deno.

LLRT vs. Node.js

The primary distinction between LLRT and Node.js lies in their architecture and design principles. Built on QuickJS, LLRT is significantly lighter than Node.js, contributing to its quicker cold start times and reduced initialization periods. This optimization benefits serverless applications in terms of both performance and cost.

LLRT's design focuses on supporting key Node APIs without aiming for full Node.js API parity. It prioritizes APIs crucial for serverless functions while offering full or partial support for built-in Node libraries, such as buffer, stream, and fetch.

Technically, LLRT distinguishes itself by employing Rust for its performance and safety features and leveraging Tokio for efficient, event-driven, non-blocking I/O operations. This unique combination allows for concurrent task management without the complexities of multithreading, thereby enhancing system resource efficiency.

At its core, LLRT utilizes QuickJS—a compact and fast JavaScript engine that eschews complex JIT compilation in favor of immediate script execution. This characteristic is especially beneficial for serverless functions, which necessitate fast, sporadic execution times.

Benchmarking

Cold-Start Comparison: LLRT demonstrates significantly faster startup times compared to Node.js, indicating a 12x to 18x speed improvement. Below benchmark is captured for Lambda Function doing Dynamo PUT Operation.

Warm-Start Comparison: LLRT also shows a faster warm-start time compared to Node.js, with up to a 2x to 3x speed improvement. Again, below benchmark is captured for the same Lambda Function doing Dynamo PUT Operation.

These benchmarks suggest that LLRT offers a promising alternative to NodeJS for specific use cases requiring fast startup times and efficient handling of HTTP requests, especially in cost-sensitive environments due to its lower resource consumption and potentially lower operational costs on AWS Lambda.

For a detailed exploration of the benchmarks and their implications for AWS Lambda users, you can refer to this article on learnaws.io.

AWS SDK V3 with LLRT

LLRT incorporates many AWS SDK clients and utilities, finely tuned for optimal performance. These included SDK clients are engineered for best performance without compromising compatibility, replacing some JavaScript dependencies with native implementations for tasks like Hash calculations and XML parsing. For SDK packages not bundled with LLRT, they should be included with your source code, marking specific packages as external. Here is the list AWS SDK packages bundled within the LLRT Runtime.

Use Cases

AWS Low Latency Runtime (LLRT) enhances serverless applications by offering rapid startup times and efficient execution, critical for performance-sensitive environments. It's ideal for:

Microservices Architecture: Facilitates scalable, flexible cloud applications by enabling individual Lambda functions with quick startup times for each microservice.

Real-Time Data Processing: Essential for platforms like financial trading or live gaming, where LLRT minimizes latency in streaming data processing.

IoT and Edge Computing: Supports environments with strict resource and response time requirements, allowing for immediate data processing from sensors or device control.

API Endpoints: Improves responsiveness of client applications by reducing latency in serverless API requests and responses, enhancing user experience.

Batch Processing: Enables timely execution of time-sensitive batch jobs, such as media processing tasks, by ensuring serverless functions start and complete quickly without significant delays.

Configure Lambda functions to use LLRT

We have 5 ways to configure LLRT as runtime for the lambda function:

Custom runtime (recommended)

Choose Custom Runtime on Amazon Linux 2023 and package the LLRT bootstrap binary together with your JS code.

For most use cases, utilizing LLRT as a custom runtime provides the optimal balance between performance and flexibility. Here's how to set it up:

Download the Latest LLRT Release: Download the last LLRT release from here
Package Your Function with LLRT: Create a deployment package by including your JavaScript code and the LLRT binary. Ensure that your project structure adheres to the AWS Lambda requirements for custom runtimes.
Deploy Your Lambda Function: Use the AWS Management Console, AWS CLI, or AWS SDKs to create a new Lambda function. Specify the runtime as Custom Runtime on Amazon Linux 2023, and upload your deployment package. Set the handler information according to your function’s entry point.

Using a layer

Choose Custom Runtime on Amazon Linux 2023, upload llrt-lambda-arm64.zip or llrt-lambda-x64.zip as a layer and add to your function

Bundle LLRT in a container image

You can package the LLRT runtime into a container image using below Dockerfile

FROM --platform=arm64 busybox
WORKDIR /var/task/
COPY app.mjs ./
ADD https://github.com/awslabs/llrt/releases/latest/download/llrt-container-arm64 /usr/bin/llrt
RUN chmod +x /usr/bin/llrt

ENV LAMBDA_HANDLER "app.handler"

CMD [ "llrt" ]

Using AWS SAM

You can refer example project to set up a lambda
instrumented with a layer containing the llrt runtime using AWS SAM.

Using AWS CDK

You can use cdk-lambda-llrt construct library to deploy LLRT Lambda functions with AWS CDK.

import { LlrtFunction } from "cdk-lambda-llrt";

const handler = new LlrtFunction(this, "Handler", {
  entry: "lambda/index.ts",
});

See Construct Hub and its examples for more details.

Compatibility

LLRT supports ES2020, making it a modern runtime capable of running contemporary JavaScript code.

Note
Although LLRT supports ES2020 it's NOT a drop in replacement for Node.js. Consult Compatibility matrix and API for more details.
All dependencies should be bundled for a browser platform and mark included @aws-sdk packages as external.

Limitations and Considerations

While LLRT offers numerous advantages, it's important to recognize its limitations. LLRT is most effective for smaller serverless functions focused on tasks like data transformation, real-time processing, and AWS service integrations. It's designed to complement existing components rather than serve as a comprehensive replacement for all use cases. Additionally, LLRT's experimental status means it is subject to change and is intended for evaluation purposes.

Conclusion

AWS LLRT represents a significant step forward in serverless computing, offering developers a powerful tool for building high-performance, efficient serverless applications. By addressing the specific needs of serverless environments, LLRT enables faster application startups and lower operational costs, making it an attractive option for developers looking to optimize their serverless applications.

If you liked this blog and found it helpful, do check out my other blogs on AWS:

For those interested in exploring LLRT further, the AWS Labs GitHub repository provides detailed documentation, examples, and resources to get started.

See you until next time. Happy coding!.

References

LLRT GitHub Repository
LLRT Lambda Tuturial
LLRT Benchmarking

Unlocking DynamoDB's Hidden Potential: Elevate Your Serverless Game with Batch Operations Mastery

Dixit R Jain — Fri, 26 Jan 2024 16:10:51 +0000

This is my second blog under Master Dynamo Series. In my previous blog, we have explored what DynamoDB is and how it can be effectively leveraged for building Scalable and High-Performance Applications. In this blog, we will be diving further deep into the scalability and high performance aspect by utilizing batch operations.

Imagine wrestling with DynamoDB intricacies while navigating the world of AWS Lambda functions. You're trying to handle a massive load of data, but there's a catch – you've got to cram in a ton of read and write operations within a tight 15-minute window. It's like tiptoeing on the edge, risking a mission failure if you hit that 15-minute limit before your 100k+ records are dealt with.

We've all been there in the chaos of serverless DynamoDB struggles. But fear not! Today, I'm unveiling the secret sauce that not only solves this puzzle but also cuts down your Lambda costs. Say hello to DynamoDB Batch Operations – the superhero that makes data handling in serverless setups not just possible but surprisingly easy and fun.

Join me on a journey to explore the magic of DynamoDB Batch Operations, where efficiency meets simplicity, turning your serverless data tasks into a breeze.

Introduction
BatchGet Operation
BatchWrite Operation
Concurrent Calls and Parallelization
Gotchas
Best Practices
Save Costs
Conclusion
References

Introduction

DynamoDB, a cornerstone of AWS's vast array of services, is a highly scalable and fully managed NoSQL database service. It is designed to deliver fast and predictable performance, making it an ideal choice for applications that require consistent, single-digit millisecond latency at any scale. Its flexible data model and reliable performance make it a popular choice for mobile, web, gaming, ad tech, IoT, and many other applications that need to operate at large scale.

DynamoDB plays a vital role in our infrastructure, and optimising its operations is essential for maintaining cost-effectiveness and performance. Individual read and write operations can become bottlenecks, leading to increased Lambda runtime, costs and also sometimes hits 15 minutes hard timeout limit of lambda execution. Batch operations offer a solution by consolidating multiple requests into a single call, reducing the overhead associated with individual operations.

BatchGet Operation

BatchGet is a DynamoDB operation that allows fetching multiple items from one or more tables using a single call. This operation is particularly beneficial when there is a need to retrieve several items in parallel, minimizing the time it takes to complete multiple GetItem requests.

Benefits of BatchGet:

Reduced request/response overhead
Faster data retrieval for multiple items
Improved parallelization

Example: Retrieving multiple items with BatchGet in JavaScript

// Importing required modules from AWS SDK for JavaScript
import { DynamoDBClient, BatchGetCommand } from '@aws-sdk/client-dynamodb';

// Creating a new instance of DynamoDB client for interacting with the service.
// The region is specified where your DynamoDB resources reside.
const dynamoDbClient = new DynamoDBClient({ region: 'your_region' });

// Name of the DynamoDB table you want to interact with.
const tableName = 'your_table_name';

// Array of keys which you want to retrieve from the table.
// Each key is an object that represents the Primary Key (Partition key i.e., P.K and Sort key i.e., SK) of the item in your table.
const keysToGet = [{ PK: 'value1', SK: 'Abc' },
                   { PK: 'value2', SK: 'Bcd' },
                   { PK: 'value3', Sk: 'Def' }];

// Creating a new command representing a BatchGet operation.
// It allows retrieval of multiple items from one or more tables.
const command = new BatchGetCommand({
  RequestItems: {
    [tableName]: {
      Keys: keysToGet,  // Providing keys of the items to be retrieved
    },
  },
});

// Sending the command to DynamoDB service using the client.
// Response will contain the information about the items successfully retrieved.
const response = await dynamoDbClient.send(command);

// Printing the retrieved items on the console.
// "Responses" attribute of the response contains the items retrieved, indexed by table name.
console.log(response.Responses![tableName]);

This JavaScript code utilizes the AWS SDK to interact with Amazon's DynamoDB service. It starts by creating an instance of the DynamoDBClient and defines the table name from which data is to be fetched. It then outlines a set of primary keys (PartitionKey and SortKey) in keysToGet array for the items to retrieve from the DynamoDB table. The BatchGetCommand is created with these specified keys and passed to the send method of the DynamoDB client. The resultant response contains the requested items from DynamoDB, which are logged to the console.

BatchWrite Operation

BatchWrite is a powerful operation designed for putting new items or deleting existing items in a single call. It is not intended for updating existing items. For updating existing items, we recommend using the UpdateItem operation.

Advantages of BatchWrite:

Reduced request/response overhead.
Faster data writing for multiple items.
Efficient handling of large-scale data changes.

Limitation of BatchWrite for Updates:

BatchWrite can't be used to update existing items directly.

Simple Hack: To compensate for this limitation, we just need to use concurrent Update calls. Although it might not be as performant as Batch Operations. It still offers a better alternative to deal with delay introduced by single update operation.

Example: Writing multiple items with BatchWrite in JavaScript

// Creating an instance of DynamoDBClient with the desired region 
const dynamoDbClient = new DynamoDBClient({ region: 'your_region' });

// Defining the name of the DynamoDB table you want to interact with
const tableName = 'your_table_name';

// Defining the array of items you want to write into the DynamoDB table
// Each item is an object, which includes primary keys (Partition Key i.e., PK and Sort Key i.e., SK) and other attributes
const itemsToWrite = [
  { PK: 'value1', SK: 'new_value1', attribute1: 'abc1'},
  { PK: 'value2', SK: 'new_value2', attribute1: 'abc2'},
  { PK: 'value3', SK: 'new_value3', attribute1: 'abc3'},
];

// Creating a BatchWriteCommand with the defined items
// The map function is used to format each item in the itemsToWrite array into an appropriate format for a PutRequest
const command = new BatchWriteCommand({
  RequestItems: {
    [tableName]: itemsToWrite.map((item) => ({
      PutRequest: { Item: item },
    })),
  },
});

// Sending the command to the DynamoDB Client using the 'send' method and waiting for the response
const response = await dynamoDbClient.send(command);

// Outputting the result of the operation to the console
console.log(response);

This JavaScript code uses the AWS SDK to write data into Amazon's DynamoDB service. An instance of DynamoDBClient is created initially and the table name where the data should be written to is defined. An array itemsToWrite is declared with several objects each containing primary keys (PK and SK) and an additional attribute. A BatchWriteCommand is constructed with these items transformed into a format suitable for a PUT request. This command is then passed to the send method of the DynamoDB client. The response from this operation, which contains details of the write transaction, is logged to the console.

Concurrent Calls and Parallelization

To further enhance performance, consider making multiple BatchGet or BatchWrite calls concurrently. This approach takes advantage of parallelisation, allowing DynamoDB to process requests more efficiently. We can use bluebird npm package which provides an utility method map for making concurrent calls. We can use this utility method to make concurrent batchGet and batchWrite requests. We can also implement our own similar concurrent execution logic in vanilla javascript. However, thats on you to decide how you would want to work it out.

Example: Implementing concurrent BatchGet calls in JavaScript using Bluebird.map

import { DynamoDBClient, BatchGetCommand } from '@aws-sdk/client-dynamodb'; // Import required AWS SDK modules 
import BlueBird from "bluebird"; // import Bluebird for utilizing concurrency feature 

// Create an instance of the AWS DynamoDB Client for a particular region 
const dynamoDbClient = new DynamoDBClient({ region: 'your_region' });
const tableName = 'your_table_name'; // The table to fetch data from

// An array containing sets of primary keys and sort keys for fetching items from DynamoDB. Each set has upto 100 items.
const keysSets = [
  [
    { PK: 'value1', SK: 'abc1' }, 
    { PK: 'value2', SK: 'abc2' },
    // ... add more items as needed up to 100 items per set
    { PK: 'value100', SK: 'abc100' }  
  ],
  [
    { PK: 'value101', SK: 'abc101' },
    { PK: 'value102', SK: 'abc102' },
        // upto 100 items
    { PK: 'value200', SK: 'abc200' }
  ],
  //... add more sets as needed
];

// Function to make BatchGet requests to DynamoDB with provided keys
const batchGet = async (keysToGet: any[]) => {
  const command = new BatchGetCommand({
    RequestItems: {
      [tableName]: {
        Keys: keysToGet,
      },
    },
  });

  // Send the BatchGet request and retrive its response.
  const response = await dynamoDbClient.send(command);
  return response.Responses[tableName]; // Return fetched items
};

// This array stores final results of all batch get operations
const finalResult = []

// Loop through keysSet executing batchGet function concurrently for each set using Bluebird's map method
await BlueBird.map(
  keysSets,
  async (keysToGet) => {
    const batchResult = await batchGet(keysToGet); // Perform BatchGet operation
    finalResult.push(...batchResult); // Add fetched items to the final result
  },
  { concurrency: 10 } // Limit concurrency to 10 - adjust as per your use-case
);

// Console log the final result after all batch get operations are done.
console.log(finalResult);

This JavaScript code uses the AWS SDK to read multiple items from an AWS DynamoDB table concurrently. Initially, it imports necessary modules and creates a DynamoDB client for a specific AWS region. It then specifies the table name and defines a nested array keysSets, which comprises primary keys (PK) and sort keys (SK). Following the AWS limitation, each sub-array holds up to 100 keys. A function batchGet is defined that uses BatchGetCommand to fetch data with the provided keys from the specified table. Then, using Bluebird's map method, the code performs concurrent batch get operations on the keySets array, with a controlled concurrency level of 10 requests at a time. The retrieved results for each operation are stored in the finalResult array, which is finally logged in the console.

Gotchas

Until now, we've delved into the potential of batch operations and concurrent executions against DynamoDB. However, there are a few pitfalls we must be mindful of to ensure seamless operations; otherwise, we risk encountering issues.

Let's explore key considerations when implementing Batch Operations:

Maximum Payload Size: DynamoDB imposes limits on the size of the payload for batch operations. The total size of the request payload, including all items, attribute names, and attribute values, must be within the allowed limits. Ensure that your batch operations comply with the following constraints:

BatchGet Limit: The total size of all items retrieved in a BatchGet operation must not exceed 16 MB. For example, if you ask to retrieve 100 items, but each individual item is 300 KB in size, the system returns 52 items (so as not to exceed the 16 MB limit). It also returns an appropriate UnprocessedKeys value so you can get the next page of results. If desired, your application can include its own logic to assemble the pages of results into one dataset.
BatchWrite Limit: The total size of all items written in a BatchWrite operation must not exceed 16 KB. While individual items can be up to 400 KB once stored, it's important to note that an item's representation might be greater than 400KB while being sent in DynamoDB's JSON format for the API call

Maximum Items in the Collection: In addition to payload size limitations, DynamoDB has constraints on the number of items processed in a single batch operation:

BatchGet Limit: Each BatchGet request can retrieve up to 100 items. If you need to retrieve more items, you must make multiple requests.
BatchWrite Limit: Each BatchWrite request can include up to 25 items. If you need to write more items, you must split the operation into multiple requests.

Unprocessed Items: Batch operations may return unprocessed items, especially in scenarios where the payload size or item count exceeds DynamoDB limits. It's crucial to handle unprocessed items by implementing retries or adjusting batch sizes to ensure all items are processed successfully.

Atomicity for BatchWrite: While BatchWrite is an atomic operation, meaning that all items in the request are processed together as a single unit, keep in mind that individual items within the batch may fail. DynamoDB will attempt to process all items, but if any item fails, the entire batch operation fails. Ensure proper error handling and retry mechanisms to address individual item failures.

Consistency: Batch operations do not provide the same level of consistency guarantees as single-item operations. When using BatchGet, retrieved items may not reflect the latest changes in the database, as the operation does not guarantee strongly consistent reads.

Limited Support for Conditional Writes: BatchWrite supports conditional writes on a per-item basis, but conditional expressions are limited compared to individual conditional writes. Be cautious when relying heavily on conditional writes within a batch operation.

Performance Considerations: While batch operations can improve performance, excessive use or misuse may lead to throttling or increased latency. Monitor DynamoDB performance metrics and adjust batch sizes accordingly to maintain optimal performance.

Partition Key Considerations: We know that DynamoDB internally stores the data across multiple partitions and if single batch happens to have same partition key for all records in the batch, it might lead to throttling as single partition in DynamoDb has max read and write capacity units allocated. It is always to suggested to choose partition key pattern which distributes data across multiple partition to take maximum benefit of distributed system.

Best Practices

Having delved into the potential pitfalls, it is advisable to follow these best practices when implementing BatchGet and BatchWrite operations:

Batch operations have limits on the number of items or payload size; be aware of and plan for these limitations. Find your sweet spot based on analysis of your payload size and carefully crafting primary key to make sure the load is distributed across multiple partitions to extract best performance out of the distributed system. Monitor and adjust batch sizes based on DynamoDB performance and table characteristics.
Handle errors and retries appropriately to ensure robustness. It is always recommended you perform bulk reads or writes in a loop using the exponential backoff algorithm so as to handle exceptions and to process the unprocessed items.

Save Costs

You may be wondering, "How do we truly save costs on read and write operations when the overall cost remains constant compared to individual requests?" You're correct in pointing that out. However, have you considered the substantial reduction in Lambda execution time achieved through the implementation of batch operations?

Let me illustrate this with a practical example from my professional experience. In scenarios where reading 80k records would typically consume over 12 minutes of Lambda execution time, the introduction of batching brought about a remarkable transformation. The same workload was efficiently processed in a little over 40 seconds. The impact on execution time alone is a compelling reason to embrace batch operations, contributing not only to cost savings but also significantly optimizing overall performance.

Conclusion

In the realm of serverless DynamoDB struggles, where orchestrating massive data loads within tight timeframes feels like walking on a tightrope, DynamoDB Batch Operations emerge as the unsung heroes. As we've uncovered the intricacies of BatchGet and BatchWrite operations, along with strategies for concurrent calls and parallelization, a new paradigm for efficient and cost-effective data handling in serverless architectures unfolds.

In conclusion, DynamoDB Batch Operations don't just solve a puzzle; they redefine the rules of the game. By seamlessly blending efficiency and simplicity, they empower you to conquer the challenges of serverless DynamoDB interactions, making data handling not just possible but downright enjoyable. As you embark on your journey with DynamoDB Batch Operations, may your serverless endeavors be swift, cost-effective, and devoid of unnecessary complexities.

If you liked this blog and found it helpful, do check out my other blogs on AWS:

See you until next time. Happy coding!.

References

AWS Step Functions: The Conductor of Your Microservices Orchestra

Dixit R Jain — Sat, 08 Jul 2023 11:57:41 +0000

Introduction

In the realm of microservices and distributed applications, coordinating different components can be a complex task. AWS Step Functions, a serverless orchestration service, simplifies this process by ensuring each microservice plays its part at the right time, much like a conductor in an orchestra. In this blog post, we'll delve into the world of AWS Step Functions and how they can streamline your application workflows.

What are AWS Step Functions?

AWS Step Functions is a serverless workflow service that orchestrates and visualizes complex processes. It uses the Finite State Machines (FSM) model, which guarantees no infinite loops occur, a costly operation in terms of resources. AWS Step Functions are like a roadmap for your application, guiding it from one step to the next, ensuring it reaches its final destination successfully.

Why Use AWS Step Functions?

AWS Step Functions offer several benefits. They provide a visual console to see your application's workflow, making it easier to understand and manage. They handle error retries automatically, reducing the need for complex error-handling code. They also maintain the application state, allowing you to focus on the business logic rather than the infrastructure. With AWS Step Functions, you can coordinate distributed components smoothly and efficiently.

AWS Step Functions Components

AWS Step Functions are composed of state machines, states, tasks, and transitions.

State Machines: A state machine is the overall workflow that your application will follow. It's the roadmap that guides your application from start to finish.
States: States are the steps or stages in your workflow. They represent the different parts of your application's journey. There are eight types of states in AWS Step Functions: Task, Choice, Fail, Succeed, Pass, Wait, Parallel, and Map. Each state type has a specific role in the workflow.
Tasks: Tasks are the activities that occur at each state. They could be anything from executing a Lambda function to waiting for a specific time.
Transitions: Transitions are the routes between states. They define the order in which tasks are executed.

Key Features of AWS Step Functions

AWS Step Functions offer several key features that make them a powerful tool for orchestrating microservices:

Integration with AWS Services: AWS Step Functions integrate seamlessly with other AWS services, allowing you to incorporate machine learning programs with AWS SageMaker, batch computing capabilities with AWS Batch, serverless ETL through AWS Glue, and more.
Error Handling: AWS Step Functions automatically manage errors and exceptions with built-in try/catch and retry capabilities. This feature ensures your workflows continue to run smoothly even when unexpected issues arise.
Support for Callback Patterns and Workflow Execution Events: AWS Step Functions support callback patterns, allowing you to pause a workflow until an external event occurs. They also support workflow execution events, which can trigger other AWS services when a workflow starts or ends.
Visual Workflow: AWS Step Functions provide a visual console that allows you to see your application's workflow. This feature makes it easier to understand and manage your workflows.

AWS Step Functions in Action: An Example

Let's consider a practical example. Imagine a user uploads data to your application. This data needs to be validated, processed, stored, and then the user needs to be notified.

This process can be broken down into states and tasks:

Validate Data: The user data is validated. The task is to check the data for any inconsistencies or errors.
Process Data: The validated data is processed. The task could be a Lambda function that modifies the data based on certain criteria.
Store Data: The processed data is stored permanently. The task is to move the data from temporary to permanent storage.
Notify User): The user is notified that their data has been processed. The task is to send a notification to the user.

    +---------------------+
    |    Validate Data    |
    +----------+----------+
               |
               |
               v
    +---------------------+
    |    Process Data     |
    +----------+----------+
               |
               |
               v
    +---------------------+
    |     Store Data      |
    +----------+----------+
               |
               |
               v
    +---------------------+
    |    Notify User      |
    +---------------------+

We can use AWS CDK to define our AWS Step Functions state machine for this workflow. Here's a simplified TypeScript code snippet for this workflow:

import * as cdk from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as sfn from 'aws-cdk-lib/aws-stepfunctions';
import * as tasks from 'aws-cdk-lib/aws-stepfunctions-tasks';

export class StepFunctionsStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // Define the Lambda functions
    const validateDataLambda = new lambda.Function(this, 'ValidateDataLambda', {
      runtime: lambda.Runtime.NODEJS_18_X,
      code: lambda.Code.fromAsset('lambda'),
      handler: 'validate.handler',
    });

    const processDataLambda = new lambda.Function(this, 'ProcessDataLambda', {
      runtime: lambda.Runtime.NODEJS_18_X,
      code: lambda.Code.fromAsset('lambda'),
      handler: 'process.handler',
    });

    const storeDataLambda = new lambda.Function(this, 'StoreDataLambda', {
      runtime: lambda.Runtime.NODEJS_18_X,
      code: lambda.Code.fromAsset('lambda'),
      handler: 'store.handler',
    });

    const notifyUserLambda = new lambda.Function(this, 'NotifyUserLambda', {
      runtime: lambda.Runtime.NODEJS_18_X,
      code: lambda.Code.fromAsset('lambda'),
      handler: 'notify.handler',
    });

    // Define the states
    const validateData = new tasks.LambdaInvoke(this, 'Validate Data', {
      lambdaFunction: validateDataLambda,
      outputPath: '$.Payload',
    });

    const processData = new tasks.LambdaInvoke(this, 'Process Data', {
      lambdaFunction: processDataLambda,
      outputPath: '$.Payload',
    });

    const storeData = new tasks.LambdaInvoke(this, 'Store Data', {
      lambdaFunction: storeDataLambda,
      outputPath: '$.Payload',
    });

    const notifyUser = new tasks.LambdaInvoke(this, 'Notify User', {
      lambdaFunction: notifyUserLambda,
      outputPath: '$.Payload',
    });

    // Define the workflow
    const definition = sfn.Chain
      .start(validateData)
      .next(processData)
      .next(storeData)
      .next(notifyUser);

    // Create the state machine
    new sfn.StateMachine(this, 'StateMachine', {
      definition,
      timeout: cdk.Duration.minutes(5),
    });
  }
}

In this code, we're defining four AWS Lambda functions, one for each step in our workflow. We then define the states for our state machine using these Lambda functions. The sfn.Chain.start() method is used to define the order of the states. Finally, we create the state machine with a timeout of 5 minutes.

Please note that you need to replace 'lambda' in lambda.Code.fromAsset('lambda') with the path to your Lambda function code. The handler should be the name of your exported function in your Lambda code.

This is a simplified example and doesn't include error handling or more complex state types like Choice or Parallel. You can add these to your state machine as needed.

Deep Dive into States

Let's delve deeper into the different types of states in AWS Step Functions:

Task State: This is the most common type of state. It represents a single unit of work that is performed in a workflow. This could be a computation, an analysis, a call to another service, etc. In our example, each of our four states (Validate Data, Process Data, Store Data, Notify User) are task states.
Choice State: This state allows for conditional branching in the workflow. It's like an "if" statement in programming. The workflow can proceed along different paths based on the output of a previous state.
Fail State: This state stops the execution of the state machine and marks it as a failure. It's useful for handling errors in your workflow.
Succeed State: This state stops the execution of the state machine and marks it as a success. It's typically used at the end of a workflow to indicate that all tasks have been completed successfully.
Pass State: This state does nothing and passes its input to its output, without performing any work. It's useful for testing and debugging.
Wait State: This state causes the state machine to delay for a specified time. It's useful for cases where you need to wait for a certain period before proceeding to the next task.
Parallel State: This state allows for multiple branches of the workflow to be executed at the same time. It's useful for cases where tasks can be performed concurrently to speed up the overall execution time.
Map State: This state can dynamically iterate over a list of values and run a set of steps for each value. It's useful for cases where you need to perform the same set of tasks for each item in a list.

Each of these states plays a unique role in a workflow and can be combined in various ways to create complex workflows. AWS Step Functions also provides a visual interface that allows you to see these states and transitions, making it easier to understand and manage your workflows.

Best Practices for Using AWS Step Functions

When using AWS Step Functions, there are a few best practices to keep in mind:

Error Handling: AWS Step Functions automatically handle errors and retries. You can customize this behavior to suit your needs.
Parallel States: Use parallel states to perform multiple tasks simultaneously. This can significantly improve the efficiency of your workflows.
Monitoring: Monitor your workflows with AWS CloudWatch. This can help you identify and resolve issues quickly.

Conclusion

In the rapidly evolving world of cloud computing, AWS Step Functions stand out as a robust and versatile service for orchestrating microservices and distributed applications. With its ability to seamlessly integrate with other AWS services, automate error handling, and visually represent workflows, AWS Step Functions can significantly simplify your application architecture.

The practical example we discussed illustrates how AWS Step Functions can be used to manage a user data processing workflow. By leveraging the AWS CDK, we were able to define our state machine and visualize our workflow, demonstrating the power and flexibility of AWS Step Functions.

As we continue to build more complex and distributed systems, services like AWS Step Functions will become increasingly important. By providing a high level of abstraction and automation, AWS Step Functions allow us to focus on what really matters: delivering value to our users.

So, whether you're building a simple application or a complex, distributed system, consider giving AWS Step Functions a try. You might find that it's the missing piece in your cloud computing puzzle. Happy orchestrating!

References

AWS Step Functions - Developer Guide. Available at: https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html
AWS Step Functions - Pricing. Available at: https://aws.amazon.com/step-functions/pricing/
AWS CDK - AWS Construct Library. Available at: https://docs.aws.amazon.com/cdk/latest/guide/constructs.html
AWS Lambda - Developer Guide. Available at: https://docs.aws.amazon.com/lambda/latest/dg/welcome.html
AWS Step Functions - Use Case Examples. Available at: https://aws.amazon.com/step-functions/use-cases/
AWS CDK - TypeScript Workshop. Available at: https://cdkworkshop.com/20-typescript.html

Lost in AWS CDK? Here's Your Map for Debugging Like a Pro

Dixit R Jain — Sun, 02 Jul 2023 09:59:11 +0000

Greetings, fellow AWS adventurers! We all know that embarking on a journey through the vast landscape of the Amazon Web Services (AWS) can sometimes feel like navigating through a dense jungle. The AWS Cloud Development Kit (CDK), a powerful Infrastructure as Code tool, is like our trusty machete, slashing through the undergrowth and making the path clearer. But what happens when our machete hits a snag? That's right, we debug!

Today, we'll be exploring the thrilling world of debugging AWS CDK. Fasten your seatbelts, because we're about to dive into some real-life examples!

1. Addressing Synth Errors

Let's start with an all-too-common scenario: you're trying to synth your CDK stack, but it's throwing errors that you just can't make sense of. Fear not, this is a familiar path for many of us.

import * as cdk from 'aws-cdk-lib';
import * as s3 from 'aws-cdk-lib/aws-s3';
const s3 = cdk.s3;
const app = new cdk.app(); // should be new cdk.App();
new s3.bucket(app, "MyBucket", { versioned: true }); // should be new s3.Bucket(app, "MyBucket", { versioned: true });
cfn.synth();

A common mistake here is forgetting to capitalize the App and Bucket constructs. Remember, in Javascript, class names should start with an uppercase letter.

2. Stack Trace Debugging

The stack trace is like your trusty compass, guiding you to the exact location of the error. Let's take a look at a typical stack trace error:

Error: 'bucketName' failed to satisfy constraint: Member must satisfy regular expression pattern: [a-zA-Z0-9.\-_]{1,255}

The stack trace points you to the problematic parameter, in this case, 'bucketName'. Make sure the name adheres to the stated pattern.

3. Missing Permissions

When AWS gives you an AccessDenied error, it's like a giant 'Keep Out' sign. In this case, your AWS CDK might be trying to access resources it doesn't have permission for.

const myBucket = new s3.Bucket(this, 'MyBucket');
new s3deploy.BucketDeployment(this, 'DeployWebsite', {
  sources: [s3deploy.Source.asset('./website-dist')],
  destinationBucket: myBucket,
});

You need to ensure that the AWS profile used has the necessary permissions to create and manage S3 buckets. Check your IAM roles and policies in the AWS Console.

Also, consider this common scenario:

import * as cdk from 'aws-cdk-lib';
import * as s3 from 'aws-cdk-lib/aws-s3';
import * as lambda from 'aws-cdk-lib/aws-lambda';

export class MyCdkStack extends cdk.Stack {
  constructor(scope, id, props) {
    super(scope, id, props);

    const bucket = new s3.Bucket(this, 'MyBucket');

    const myFunction = new lambda.Function(this, 'MyFunction', {
      runtime: lambda.Runtime.NODEJS_14_X,
      code: lambda.Code.fromAsset('lambda'),
      handler: 'index.handler',
    });

    // Oops! We forgot to give the Lambda function the necessary permissions to read from the S3 bucket.
  }
}

In this case, your Lambda function won't be able to access the S3 bucket until you've granted the necessary permissions.

4. Logical Errors

Sometimes the path seems clear, but you still end up at the wrong destination. That's often the case with logical errors.

const table = new dynamodb.Table(this, 'MyTable', {
  partitionKey: { name: 'id', type: dynamodb.AttributeType.STRING },
});
table.addGlobalSecondaryIndex({
  indexName: 'MyIndex',
  partitionKey: { name: 'id', type: dynamodb.AttributeType.STRING },
});

Here, we're trying to add a global secondary index (GSI) with the same partition key as the base table. DynamoDB doesn't allow this, so we need to choose a different attribute for the GSI partition key.

Likewise, consider below code

import * as cdk from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as apigateway from 'aws-cdk-lib/aws-apigateway';

export class MyCdkStack extends cdk.Stack {
  constructor(scope, id, props) {
    super(scope, id, props);

    const myFunction = new lambda.Function(this, 'MyFunction', {
      runtime: lambda.Runtime.NODEJS_14_X,
      code: lambda.Code.fromAsset('lambda'),
      handler: 'index.handler',
    });

    const api = new apigateway.RestApi(this, 'MyApi');
    const resource = api.root.addResource('mypath');

    const integration = new apigateway.LambdaIntegration(myFunction);

    // Incorrect: The Lambda function is not correctly set as the handler.
    resource.addMethod('GET'); // It should have been resource.addMethod('GET', integration);
  }
}

In this case, the code compiles and the stack deploys, but the API Gateway doesn't trigger the Lambda function as expected due to a logical error.

5. The Unknown

The last category is for those moments when you're lost in the dark, and even Google can't help you. At these times, your best bet is to turn on the AWS CDK debug logging.

export DEBUG=*
cdk deploy

This command will output a wealth of information about what AWS CDK is doing behind the scenes, which can help you navigate even the murkiest swamps of confusion.

You can also debug AWS CDK applications by running them in the language they're written in, such as TypeScript or Python. For TypeScript, you'd execute the JavaScript file in debug mode. Here's a simple way to do it in VSCode:

First, make sure you have a .vscode/launch.json file in your project's root folder. If not, create it:

mkdir .vscode/
touch .vscode/launch.json

Then, modify launch.json as follows:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "pwa-node",
      "request": "launch",
      "name": "Launch Program",
      "skipFiles": [
        "<node_internals>/**"
      ],
      "runtimeArgs": [
        "-r", "./node_modules/ts-node/register/transpile-only"
      ],
      "args": [
        "${workspaceFolder}/bin/cdk.ts"
      ]
    }
  ]
}

Make sure the ${workspaceFolder}/bin/cdk.ts matches the entry point for your application in the bin folder. Then, simply put in your breakpoints and debug as usual.

However, remember that when debugging your code, CDK tokens will still be represented as "tokens" and not their actual values. Tokens represent values that can only be resolved at a later time in the lifecycle of an app. For example, the name of an Amazon S3 bucket that you define in your AWS CDK app is only allocated by AWS CloudFormation when you deploy your app.

And that's a wrap, folks! Next time you're lost in the AWS jungle, remember: the AWS CDK is your trusty machete, and these debugging tips are your survival guide. So, go ahead and explore with confidence! Happy debugging!

Dive into AWS DynamoDB: A NoSQL Database for Scalable and High-Performance Applications

Dixit R Jain — Thu, 22 Jun 2023 15:27:28 +0000

Introduction:

In today's fast-paced world, organizations require highly scalable and efficient databases to handle large volumes of data. AWS DynamoDB, a fully managed NoSQL database service provided by Amazon Web Services (AWS), offers a robust solution for building applications that demand low-latency, high-throughput data storage and retrieval. In this blog, we will explore the key features of DynamoDB and delve into its various use cases.

Understanding AWS DynamoDB:

AWS DynamoDB is a fully managed NoSQL database that provides seamless scalability, low-latency performance, and automatic scaling capabilities. It is designed to handle massive workloads and can easily scale up or down based on the application's demands. DynamoDB is a key-value store with flexible document data models, making it suitable for a wide range of use cases.

Key offerings of AWS DynamoDB:

Fully managed: DynamoDB takes care of administrative tasks such as hardware provisioning, setup, configuration, software patching, and backups, allowing developers to focus on application development.
Scalability and performance: DynamoDB offers automatic scaling to handle any workload. It can scale up or down to accommodate fluctuations in traffic and data volumes, ensuring consistent performance.
Low-latency response: With its distributed architecture, DynamoDB ensures low-latency access to data, making it ideal for applications that require real-time responsiveness.
Flexible data models: DynamoDB supports both key-value and document data models, enabling developers to store and retrieve structured, semi-structured, and unstructured data.
Built-in security: DynamoDB integrates with AWS Identity and Access Management (IAM) for fine-grained access control. It also provides encryption at rest and in transit to secure data.
Global replication: DynamoDB offers global tables, allowing data to be replicated across multiple AWS regions, providing low-latency access for global applications.

Understanding Keys in AWS DynamoDB:

Keys play a crucial role in data modeling and access patterns in DynamoDB. Let's explore the two main types of keys used in DynamoDB:

Primary Key:
The primary key uniquely identifies each item in a DynamoDB table and consists of one or two attributes:

a. Partition Key (Hash Key): It is a single attribute that DynamoDB uses to partition data across multiple storage nodes. DynamoDB distributes data based on the partition key value, allowing for high throughput and scalability. It's essential to choose a partition key that evenly distributes the data and avoids "hot" partitions that could lead to performance bottlenecks.
b. Composite Key (Partition Key + Sort Key): Also known as a composite primary key or a range key, it consists of a partition key and a sort key. Together, they define the item's storage location and enable rich querying capabilities. The combination of partition key and sort key allows sorting and querying data within a specific partition efficiently.

Secondary Indexes:
DynamoDB provides two types of secondary indexes to support additional querying flexibility:

a. Global Secondary Index (GSI): GSI enables querying on non-key attributes independently of the primary key. It has its own partition key and sort key, allowing different access patterns and alternative sorting options. Developers can create up to 20 GSIs per table.
b. Local Secondary Index (LSI): LSI uses the same partition key as the base table but defines a different sort key. It allows querying within a specific partition and provides an alternative sort order for the items. Each table can have up to five LSIs.

By utilizing primary keys and secondary indexes effectively, developers can optimize data retrieval and enable a variety of access patterns in DynamoDB.

DynamoDB Streams: Real-time Data Processing and Change Capture

DynamoDB Streams is a feature that captures a time-ordered sequence of item-level modifications made to DynamoDB tables. It enables real-time data processing and change capture by providing a stream of events that can be consumed by applications or AWS services.

Key features of DynamoDB Streams include:

Change capture: Streams captures every insert, update, or delete operation in a DynamoDB table, allowing you to track changes to the data.
Real-time event processing: Applications can process the stream of events in real-time and take actions based on the changes, such as triggering downstream processes or updating search indexes.
Scalable and durable: Streams automatically scales to handle high-throughput workloads and provides durability by storing events for up to 24 hours, ensuring reliable data capture.

DynamoDB Accelerator (DAX): In-Memory Caching for Faster Access

DynamoDB Accelerator (DAX) is an in-memory cache for DynamoDB that delivers fast read performance by reducing the response time from milliseconds to microseconds.

Key features of DAX include:

In-memory caching: DAX caches frequently accessed data in memory, eliminating the need to fetch data from DynamoDB, thereby reducing read latency.
Automatic data synchronization: DAX keeps the cached data synchronized with the underlying DynamoDB table, ensuring data consistency.
Scalability and high availability: DAX is a fully managed service that automatically scales to handle read traffic and provides high availability with built-in replication across multiple Availability Zones.

Use Cases for AWS DynamoDB:

Web and mobile applications: DynamoDB is an excellent choice for powering user profiles, session management, and storing user-generated content, providing low-latency and scalable data storage.
Gaming: DynamoDB can handle massive amounts of gaming data, including player profiles, game states, and leaderboard information. It ensures fast and consistent performance during peak usage.
Internet of Things (IoT): With its ability to handle large volumes of sensor data and provide low-latency access, DynamoDB is well-suited for IoT applications, including data ingestion and real-time analytics.
Ad tech: DynamoDB can store and retrieve ad campaign data, user clickstream information, and targeting preferences. Ad tech platforms can benefit from DynamoDB's low-latency access, scalable performance, and flexible data models for efficient ad serving.
E-commerce: DynamoDB can serve as the backend for product catalogs, inventory management, and order processing systems in e-commerce applications. It handles high-traffic scenarios, provides fast product searches, and ensures consistency in inventory updates.
Real-time analytics: With its ability to handle high write and read throughput, DynamoDB is suitable for real-time analytics use cases. It can store and process event data, sensor data, and logs, enabling near real-time insights and decision-making.

Conclusion:

AWS DynamoDB is a powerful NoSQL database that offers seamless scalability, high performance, and flexible data models. By understanding its key features, utilizing effective data modeling techniques with primary and secondary keys, and exploring various use cases, developers can leverage DynamoDB to build scalable, low-latency applications across diverse domains.

While we have discussed some common use cases such as web and mobile applications, gaming, IoT, ad tech, e-commerce, and real-time analytics, it's important to note that the applications of DynamoDB are not limited to these specific domains. DynamoDB's flexibility and scalability make it a suitable choice for a wide range of applications requiring high-performance data storage and retrieval.

Whether you are building collaborative applications, content management systems, financial platforms, or data-intensive solutions, DynamoDB empowers you to handle massive workloads, ensure low-latency access, and deliver exceptional performance.

Embrace the power of DynamoDB, experiment with its features, and unleash its potential to drive innovation and success in your applications, regardless of the industry or use case.

Remember, DynamoDB provides a robust foundation for your data management needs, allowing you to scale and accelerate your applications while focusing on delivering value to your users.

DEV Community: Dixit R Jain

Building a Zero-Cost SEO Prerender Pipeline for My React SPA on AWS

Inspiration

Why Prerendering Matters for SPAs

The Site: What I'm Working With

The Problem

The Architecture in One Sentence

Decision 1: URI Rewriting, Not Redirecting

Decision 2: Same Bucket, Not a New Origin

How This Differs from Avinash's Approach

Decision 3: The CloudFront Function

Decision 4: What Happens on a Cache Miss?

Decision 5: Puppeteer, Not Playwright

Decision 6: Batched Lambda Invocations

Decision 7: Async Lambda Invocation for Cache Invalidation

Decision 8: No Meta Tag Injection

The Code

The Render Worker Lambda

The Cache Manager (Warm-up & Invalidation)

The Full Flow

What It Costs

What I'd Do Differently

The Admin UI

Results

Google Search Console

Social Link Previews

Wrapping Up

Building a Zero-Cost SEO Prerender Pipeline for My React SPA on AWS

Inspiration

Why Prerendering Matters for SPAs

The Site: What I'm Working With

The Problem

The Architecture in One Sentence

Decision 1: URI Rewriting, Not Redirecting

Decision 2: Same Bucket, Not a New Origin

How This Differs from Avinash's Approach

Decision 3: The CloudFront Function

Decision 4: What Happens on a Cache Miss?

Decision 5: Puppeteer, Not Playwright

Decision 6: Batched Lambda Invocations

Decision 7: Async Lambda Invocation for Cache Invalidation

Decision 8: No Meta Tag Injection

The Code

The Render Worker Lambda

The Cache Manager (Warm-up & Invalidation)

The Full Flow

What It Costs

What I'd Do Differently

The Admin UI

Results

Google Search Console

Social Link Previews

Wrapping Up

From Zero to Production: The Complete AWS Serverless Full-Stack Journey

Table of Contents

Introduction

What We've Built

Features

Full Stack Architecture

Why CloudFront for Both?

The Complete CDK Stack

Key Insight: CloudFront Path Routing

Frontend Integration

Smart API Configuration

Retry with Exponential Backoff

One-Command Deployment

Production Hardening

1. Custom Domain

2. WAF Protection

3. Specific CORS Origins

4. Lambda Security

Monitoring & Observability

CloudWatch Dashboard

Alarms

Cost Analysis

Next Steps

1. Add Email Notifications

2. Implement Authentication

3. Add File Uploads

4. Build an Admin Dashboard