Skip to main content
This lesson describes a serverless marketing email generator that uses Amazon Bedrock. The application creates marketing email copy from structured user inputs (product name, target audience, features, tone) by invoking a Bedrock foundation model from a Lambda function. The design focuses on a minimal, secure serverless architecture with predictable output formatting so the front-end can render results reliably. The core functional requirement:
  • Build a serverless application that generates a marketing email based on structured user input using Amazon Bedrock.
A presentation slide titled "Marketing Email Generator — Application Requirements" with a teal rounded box that reads: "Build a serverless application that generates a marketing email based on structured user input using Amazon Bedrock."

Inputs (structured)

Users provide a small set of structured fields that the Lambda function converts into a prompt for Bedrock:
  • Product name
  • Target audience
  • Key product features
  • Tone (e.g., professional, casual, enthusiastic)
  • Optional: desired length or email sections (subject line, intro, body, CTA)
A dark presentation slide titled "A Marketing User provides..." showing four blue circular icons labeled Product Name, Target Audience, Key Features, and Tone. Each icon contains a simple white line illustration representing its concept.
This generator is industry-agnostic — the same front-end UI and prompt structure can support multiple verticals by changing the input values.

Non-functional requirements

  • Serverless architecture: use AWS Lambda for compute and API Gateway for the REST API.
  • Secure Bedrock invocation: Lambda assumes an IAM role with least-privilege permissions limited to the Bedrock actions and specific models.
  • Model parameter control: set parameters like maxTokens and temperature to bound response length and variability.
  • Consistent output formatting: enforce a predictable schema or template (for example, JSON with subject, body, and cta) so the UI can parse and display results reliably.
A presentation slide titled "Non-Functional Requirements" with four colored panels listing: "Use a Serverless Architecture", "Invoke Bedrock securely using IAM", "Control response length using model parameters", and "Produce consistent formatting." Each panel has a matching icon (cloud, lock, gauge, documents) and colored borders.
Grant the Lambda function an IAM role scoped to only the Bedrock actions and specific models it requires. Avoid broad permissions — follow least-privilege principles and restrict resource ARNs where possible.

Architectural overview (high level)

  • Front end: static web UI (HTML, CSS, JS) hosted in an S3 bucket (or S3 + CloudFront). The browser renders the UI and collects user inputs.
  • API layer: client-side JavaScript calls a REST API hosted by API Gateway.
  • Compute: API Gateway routes requests to Lambda. Lambda assembles the structured prompt, sets model parameters (for example maxTokens), and calls Amazon Bedrock using the AWS SDK.
  • Response: Bedrock returns generated text; Lambda returns it to API Gateway, which sends it back to the browser. The browser parses and presents the formatted email.
Why use S3 to host the UI?
  • S3 website hosting serves static assets (HTML, images, CSS, client-side JS) without provisioning servers. Use CloudFront in front of S3 if you need TLS, custom domains, lower latency, or caching.
S3 website endpoints do not provide HTTPS by default. Put CloudFront in front of S3 when you require TLS or a custom domain.
Why Lambda + API Gateway?
  • This combination creates a fully serverless backend that scales automatically. Keep prompt assembly and Bedrock API calls inside Lambda to protect credentials and enforce IAM controls.

Prompt structure and model control

Keep prompts modular and explicit. A recommended pattern is to use a short system instruction followed by a structured request block that includes formatting constraints. For predictable parsing, ask the model to return JSON. Example structured prompt (text block sent to the model):
Example model parameters (provider-specific; adjust for Bedrock client):
Note: When you require strict schema output, include explicit formatting instructions (e.g., “Return only JSON, no extra commentary”). If the model supports system messages vs. user messages, place the formatting rules in the system message.

Example Lambda flow (pseudocode)

This snippet shows the conceptual flow inside your Lambda handler:
Ensure the Lambda execution role has only the Bedrock permissions it needs. Example minimal permission statements should be scoped to the Bedrock API actions and the specific model(s) used.

Typical UI flow (end-to-end)

  1. User fills text fields: product name, short description, audience, tone, and optional desired length.
  2. User clicks Generate — the client sends a POST request to the API Gateway endpoint.
  3. API Gateway invokes Lambda with the structured input.
  4. Lambda assembles the prompt, sets model parameters, and calls Amazon Bedrock.
  5. Bedrock returns generated text in the expected format.
  6. Lambda returns the structured output to API Gateway.
  7. The browser receives the JSON and renders the marketing email (subject, intro, body, CTA).

Tips for reliable outputs

  • Use explicit output formatting (prefer JSON) to avoid ambiguous plain-text parsing.
  • Limit variability with temperature when you need consistent messaging.
  • Use maxTokens to bound response length and protect downstream UI layouts.
  • If you need multiple variations, request N outputs in one call or call the model multiple times with the same prompt and different seeds.
Now that the application design and architecture are defined, you can proceed to implement the marketing email generator with the security, formatting, and model controls outlined above. Good luck.

Watch Video

Practice Lab