DEV Community: Kasun de Silva

Beyond Stateless Lambda: Harnessing MicroVMs for Isolated AI Sandboxes

Kasun de Silva — Tue, 29 Sep 2026 02:23:03 +0000

Here is the updated, complete blog post incorporating the AWS Console location and Terraform code specification as dedicated sections.

Unlocking Next-Gen AI Sandboxes: Building Secure Code Execution with AWS Lambda MicroVMs

Generative AI agents are shifting from passive text generators to active task executors. Whether it’s an agent running multi-step data analyses, generating and testing Python scripts, or compiling code directly from natural language prompts, giving Large Language Models (LLMs) access to code execution has become a cornerstone of modern AI workflows.

However, executing AI-generated code introduces a classic developer dilemma: How do you safely run untrusted code without sacrificing speed or blowing your infrastructure budget?

Traditional solutions often force a compromise. Standard serverless functions are fast and cost-effective, but their strictly stateless nature makes multi-step reasoning loops clunky. On the other hand, traditional container or VM architectures support stateful, long-running processes, but they suffer from slower spin-up times and high idle compute costs.

Enter AWS Lambda MicroVMs a game-changer for AI agent tool execution.

Why Standard Serverless Falls Short for AI Sandboxes

When an AI agent executes code, it rarely does so in a single isolated step. A typical reasoning loop looks like this:

Step 1: The agent writes a script to scrape data from a source and installs a few dependencies.
Step 2: The agent inspects the output, encounters a parsing error, and modifies local files.
Step 3: The agent runs a data cleaning function on the saved output and generates a plot.

In a stateless function environment, retaining memory, installed packages, and local files across these three distinct turns requires complex external storage workarounds. Every invocation risks feeling like starting from scratch.

The AWS Lambda MicroVM Solution

Built on top of Firecracker the hardware-virtualized hypervisor technology designed by AWS Lambda MicroVMs bridge the gap between lightweight serverless compute and stateful virtual machines.

They provide dedicated, stateful sandboxes with several key advantages tailored specifically for dynamic AI workflows:

Hardware-Level Security: Each MicroVM runs inside its own lightweight Linux kernel boundary, creating a complete isolation barrier. Even if an LLM generates destructive or buggy code, the blast radius is strictly confined to that individual sandbox.
Persistent Session Memory: MicroVMs retain full RAM state, local disk directories (/workspace), installed dependencies, and running background processes for up to 8 hours per session.
Sub-Second Suspend & Resume: When an AI agent pauses between execution steps, the MicroVM can automatically pause and store its execution snapshot. When the agent dispatches its next tool call, the sandbox resumes instantly without requiring a full cold boot.
Dynamic Vertical Scaling: Need to process a sudden surge of data? MicroVMs can vertically scale up to 4x their baseline CPU and RAM on the fly during spike demands.

Architectural Deep Dive: An AI Agent Sandbox Workflow

Here is how a production-ready AI code execution pipeline comes together using AWS Lambda MicroVMs and an LLM orchestration layer (like Amazon Bedrock or Anthropic Claude):

The End-to-End Workflow

Trigger: The AI agent encounters a tool call requiring code execution and fires an HTTPS request to Amazon API Gateway.
Control & Routing: A lightweight Launcher Lambda verifies authentication signatures, checks session metadata in Amazon DynamoDB, and requests a MicroVM environment via programmatic control APIs.
Instant Boot: AWS spins up a MicroVM pre-configured with standard runtime binaries (Python, Node, git) using snapshot restoration in sub-second time.
Isolated Execution: The generated script runs inside the guest kernel's /workspace environment. Stdout, stderr, and output artifacts are captured and streamed back to the orchestrator.
Idle Suspend: Once execution finishes, the MicroVM enters an idle phase and automatically suspends its state, ensuring you only pay for active execution time and stored snapshots rather than continuous idle compute.
Continuation or Tear-Down: Subsequent code executions during the same session resume seamlessly from the suspended snapshot. When the session reaches its lifecycle cap or completes, the environment is cleanly destroyed.

Navigating MicroVMs in the AWS Console

Unlike standard Lambda Functions which operate as stateless event-handlers, AWS treats MicroVMs as a distinct, lifecycle-managed compute resource.

To locate and manage them in the AWS Management Console:

Head over to the AWS Lambda main dashboard.
Look at the left-hand navigation menu under the Compute section you’ll find a dedicated MicroVMs tab alongside Functions and Layers.
From this interface, you can manage two core primitives:
MicroVM Images: Build, view, and version snapshot images (restored from S3 base code or Dockerfile builds).
Active Sessions: Monitor running, suspended, or terminated MicroVM instances, inspect auto-suspend triggers, and obtain generated session HTTPS/gRPC endpoints.

Infrastructure as Code: Specifying MicroVMs in Terraform

AWS Lambda MicroVMs feature a distinct API surface from standard functions. In Terraform (using the hashicorp/aws provider), you manage them via aws_lambdamicrovms_microvm and aws_lambda_microvm_image resources rather than aws_lambda_function.

Here is a snippet illustrating how to define an image snapshot and spin up an auto-suspending session sandbox:

# 1. Define the MicroVM Base Image Snapshot
resource "aws_lambda_microvm_image" "ai_sandbox_image" {
  name           = "python-ai-sandbox-image"
  base_image_arn = "arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1"
  build_role_arn = aws_iam_role.microvm_build_role.arn

  code_artifact {
    s3_bucket = "my-ai-agent-artifacts-bucket"
    s3_key    = "sandboxes/python-runtime.zip"
  }

  resources {
    cpu_architecture = "arm64"
    baseline_vcpus   = 2
    baseline_memory  = 4096
  }
}

# 2. Provision the Stateful MicroVM Sandbox Instance
resource "aws_lambdamicrovms_microvm" "agent_session" {
  image_arn          = aws_lambda_microvm_image.ai_sandbox_image.arn
  execution_role_arn = aws_iam_role.microvm_execution_role.arn

  # Idle Policy: Auto-suspend when idle for 5 mins
  idle_policy {
    auto_resume_enabled       = true
    max_idle_duration_seconds = 300
  }

  # Max session lifespan (up to 8 hours)
  maximum_duration_in_seconds = 28800
}

# 3. Output the Dedicated Sandbox HTTPS Endpoint
output "microvm_session_endpoint" {
  description = "Dedicated HTTPS endpoint for AI Agent tool calls"
  value       = aws_lambdamicrovms_microvm.agent_session.endpoint
}

The Verdict

For teams building AI agents, interactive browser IDEs, or multi-tenant SaaS tools that demand secure code execution, AWS Lambda MicroVMs remove the trade-off between strict security and low latency.

By pairing hardware-isolated Firecracker virtual machines with auto-suspend lifecycle controls, you get the security of full virtualization alongside the elasticity and cost benefits of serverless compute.

You can learn more about how AWS Lambda MicroVMs deliver isolated code execution at scale in Introducing AWS Lambda MicroVMs. This official overview video provides additional detail on Firecracker hardware isolation and snapshot-based fast starts for stateful AI workloads.

Architecting an Enterprise Network on AWS Cloud WAN

Kasun de Silva — Thu, 24 Sep 2026 04:31:22 +0000

How to design a multi-region, multi-account AWS network on Cloud WAN, from segments and attachments to single-hop inspection, and the lessons from running one in production.

Most enterprise AWS networks grow the same way. One VPC becomes fifty. One region becomes three or four. A Transit Gateway appears in each region, they get peered, and a team spends a growing share of its week keeping route tables in agreement across all of them. It works, and it gets a little more brittle every quarter.

AWS Cloud WAN is the answer to that pattern. I have run it in production for a network of a few hundred accounts and several hundred VPCs across four regions, and this post is the guide I wish I had at the start: how regions connect, how segments carve up the network, how inspection works, how to attach VPCs at scale, and what to expect operationally. It is a design guide, not a tutorial. There is no console clicking here.

The problem Cloud WAN solves

A Transit Gateway is regional. Run in four regions and you run four of them, peer them in a mesh, and keep the route tables on all four telling a consistent story. Every new VPC is an attachment, a route table association, propagation into the right tables, and often a static route or two. Every new environment or partner multiplies that.

Two problems dominate at scale.

Routing intent is spread everywhere. No single document says "test can reach shared services, and nothing else." That intent lives in route tables in four regions, and you prove it by reading all of them.

Inspection is double-hop. Traffic between VPCs in different regions goes through a firewall leaving the source region and another entering the destination region. Stateful firewalls need to see both directions of a flow, and with independent regional Transit Gateways the only way to guarantee symmetry is to inspect at both ends. Twice the traversals, twice the logs, two rule sets that must agree.

Cloud WAN removes both problems, and that is the reason to adopt it.

Cloud WAN in one paragraph

Cloud WAN gives you a global network, which holds a core network that AWS operates for you. The core network has an edge in each region you choose, and AWS connects those edges over its backbone. You attach VPCs, Transit Gateways, Direct Connect gateways and VPNs to the edges. Every attachment lands in a segment, a routing domain that spans all edges. The whole thing, every segment, every rule about which segment can reach which, and where traffic gets inspected, is described in one versioned JSON document: the core network policy.

If Transit Gateway is a router you configure, Cloud WAN is a WAN you describe.

Reading the diagram

Columns are regional edges. Everything inside a column is attached to that edge.
Rows are segments. A segment exists on every edge, so cards in the same row reach each other across regions for free.
Green links are the shared services hub reaching into each environment. Two-way, never transitive.
Dashed orange arrows are internet egress. Every VPC drains to its region's inspection VPC, which holds the NAT and internet gateway.
Solid orange paths are two production flows to another cloud, inspected once each and exiting through the nearest Direct Connect landing.
The VPNs have no arrows because their path is the same as the orange one, with the VPN in place of the gateway.

The rest of the post explains each of these in turn.

Regions: edges, not peerings

Each region you list in the policy becomes a core network edge. AWS peers every edge to every other edge. You never create an inter-region peering attachment, and you never maintain inter-region routes. When a VPC attaches in Sydney, its CIDR is learned by the edges in Virginia and Oregon automatically, inside whichever segment it joined. Inter-region routing is just intra-segment routing.

The default behaviour is region affinity. Traffic stays in its home region wherever it can and crosses the backbone only when the destination or a policy says so. That gives predictable paths by default, and you override it deliberately when you want a particular region to handle something, such as inspection or egress.

An edge is a router you never see. Every attachment in a region terminates on it, it holds one route table per segment, and AWS peers it to every other edge. It has no internet gateway and no firewall of its own. Anything that needs either has to be a VPC you attach to it, which is why the inspection VPCs carry both jobs below.

Each edge needs its own ASN from a range you reserve in the policy. Pick a private range, keep it out of anything you peer with, and never change it afterwards.

Segments: the routing intent, written down

Segments are where the design lives. A segment is a routing domain that exists on every edge. Attachments in the same segment can reach each other across regions. Attachments in different segments cannot, unless the policy shares routes between them.

An enterprise segment model that works well has four groups.

Group	Purpose	Isolation
Environment	One segment each for test, staging and production workloads	Isolated. A workload segment sees itself and shared services, nothing else.
Shared services	Central logging, DNS, egress, platform tooling	Shared into every environment segment across all regions.
External	VPNs, SaaS platforms and partners that do not fit the internal pattern	One per environment. Isolated, so external parties never see each other.
Inter-cloud	Footprints in other public clouds	One per environment. Isolated, routed through inspection.

Three rules make this model hold.

Shared services is a hub, not a bridge. Every environment segment can reach shared services, but sharing is not transitive. Test cannot reach production by going through shared services. The policy shares one segment's routes into another explicitly, and you only share in one direction: into the hub.

Split external and inter-cloud by environment. One external segment is simpler. Three means a test VPN endpoint can never be a path into production, and inspection rules for each environment stay separate.

Use segment isolation for anything third-party. Isolation is a segment attribute. Set it and attachments inside the segment cannot reach each other, only what you share in. Every partner VPN becomes an island that reaches exactly what you routed to it.

Written out, the reachability of the whole network fits in one table. This is what the policy encodes, and it applies identically on every edge.

Segment	Can reach	Isolated	Inspected
Test	Test and shared services, all regions	Yes	Egress only
Staging	Staging and shared services, all regions	Yes	Egress only
Production	Production and shared services, all regions	Yes	Egress only
Shared services	Every environment segment, all regions	No	Egress only
External (per environment)	Its own environment, via inspection	Yes	Every flow
Inter-cloud (per environment)	Its own environment, via inspection	Yes	Every flow

The segment count stays small. Twelve to fifteen segments covers most enterprises. If you find yourself creating a segment per team, you are rebuilding route tables under a new name.

Attachments: make joining the network boring

At a few hundred accounts, attaching a VPC has to be self-service or your network team becomes a ticket queue. The pattern:

Share the core network to every member account with AWS Resource Access Manager. One share, one organisational unit.
Let the VPC owner create the attachment in their own account, through whatever internal platform or Terraform module they already use.
Have the attachment carry a tag naming its segment. The tag is the only thing the owner controls.
Write an attachment policy in the core network policy that matches the tag and places the attachment in the segment. No human chooses a segment for a VPC.
Let route propagation do the rest. The VPC's CIDR appears in the segment's route table on every edge.

Turn attachment acceptance off for internal segments. If your network team manages both the core network and the accounts that attach to it, a manual approve step adds friction and no security, because segment placement is already decided by the policy, not by whoever created the attachment. Keep acceptance on for external segments where a third party could be on the other end.

Enable appliance mode on attachments to inspection VPCs, and only those. Appliance mode pins both directions of a flow to the same availability zone, which stateful firewalls need. Workload VPCs do not need it and it costs you a cross-AZ hop if you turn it on everywhere.

Inspection: one hop, not two

An inspection VPC is a VPC with a stateful firewall in it, attached to the core network, that traffic is steered through. Cloud WAN steers that traffic with network function groups.

You put inspection VPCs into a group, then in the policy you say which segment-to-segment flows must go via that group. That is a send-via rule, and it is how you inspect east-west traffic between environments, or between an environment and a partner. There is also send-to, which sends a segment's traffic to a group, typically a default route, and is how you do centralised egress.

Egress deserves a sentence of its own because it surprises people. Every segment, shared services included, gets a send-to rule that installs a default route towards the group, and the inspection VPC holds the NAT and internet gateway. Nothing else on the network has a way out. A workload VPC with its own NAT gateway is a hole in the design, so do not build one.

The win is single-hop inspection. Because the core network sees the whole flow end to end, it can send both directions through the same firewall and keep the flow symmetric even when source and destination are in different regions. An inter-region flow crosses one firewall, not two. Fewer traversals, less log volume, one rule set to reason about, and far simpler troubleshooting.

Which region's firewall handles a cross-region flow? The policy decides. You can prefer the region closest to the source, set an explicit priority order, or override per edge. That lets you route a small region's traffic through a neighbour's firewall until the small region justifies its own, and fail over when a firewall needs maintenance.

Design the groups per environment. One group for production inspection, one for lower environments, one for egress. Sharing a firewall between production and test saves money and blurs a boundary you spent the segment model building.

Hybrid and multi-cloud: same edges, same segments

Everything that is not a VPC attaches to the same core network and lands in a segment like anything else.

Other clouds connect over a Direct Connect gateway attachment. Many enterprises deliver those circuits through a connectivity provider rather than dedicated fibre at every site. Land them in the inter-cloud segments and send all their traffic via inspection. Land the same cloud in two regions. Both gateways advertise the same prefixes into the segment, each edge prefers the nearer one, and if a circuit drops its routes withdraw and every edge converges on the other. The two gateways never talk to each other, and a VPC in Oregon does not cross the Pacific to reach a cloud it can exit to locally.
VPNs and partners land in external segments, one per environment, each isolated so partners never share a routing domain.
Existing Transit Gateways can attach as route table attachments. That is a bridge, not a native attachment type, and it is how you keep older things running while you migrate them.

The result is one place to look. A partner VPN, a link to another cloud and a production VPC are rows in the same attachment list, placed by the same policy.

Migrating from Transit Gateway without a big bang

Cloud WAN and Transit Gateway coexist well, and that is the migration.

Build the core network beside the Transit Gateways. Peer each regional Transit Gateway to its local edge. The Transit Gateways' prefixes propagate into Cloud WAN, so Cloud WAN already knows how to reach everything.
Attach VPCs without moving traffic. Each VPC gets a Cloud WAN attachment and its CIDR propagates, but its route tables still point at the Transit Gateway. Verify the routes are learned on every edge before going further.
Cut over with managed prefix lists. Add Cloud WAN routes to VPC route tables using a prefix list, so a growing set of destinations moves to Cloud WAN while the Transit Gateway stays the default. You move routes per environment, per region, and roll back by editing a prefix list.
Flip the default. Once a VPC's traffic is all on Cloud WAN, point its default route at the core network and remove the Transit Gateway attachment.

Go test, then staging, then production. Run Route Analyzer before and after every step to confirm paths, and run synthetic connectivity tests across attachments to catch what Route Analyzer cannot.

Operating it: what to know before you commit

The design above is the good news. These are the things that will shape your day-to-day.

Policy changes take minutes. Applying a new policy version, and rolling one back, takes minutes rather than seconds. On a core network carrying production that is a long time to watch a change land. Test in a lower environment first, and know exactly which version you are rolling back to before you press the button.

Everything is one document. That is the strength and the hazard. A mistake in one attachment rule affects every region at once. Treat the policy like production code: Terraform, pull requests, plan output reviewed, applied by a pipeline, never edited in the console.

The console diff gets noisy. A large policy does not always make a small change look small in the change view. Review the diff in source control first.

Permissions cut across accounts and services. The roles for the team that runs the core network, and for the automation that creates attachments in member accounts, take real least-privilege work. Start that with your security team early, not the week before production cutover.

Observability is on you. Cloud WAN gives you route tables, attachment state and a Route Analyzer. It does not give you flows. Ship VPC flow logs from every attachment and every inspection VPC into one queryable store. That is where you will actually see what the network is doing.

Cost is per edge and per attachment. You pay an hourly rate for each core network edge and each attachment, plus data processing. There is no per-request billing. A dormant region with an edge still costs money, so only list regions you actually use.

Is it worth it?

For a multi-region, multi-account network, yes. You replace a mesh of regional Transit Gateways and their route tables with one policy. You halve firewall traversals for inter-region traffic. Attaching a VPC becomes a tag. And "what can test reach?" is answered by a file instead of a scavenger hunt through four regions.

Cloud WAN is still young and it shows in change velocity and tooling. But the model is right. Describe the WAN, and let AWS run it.

If you are running a Transit Gateway mesh and weighing this up, I am happy to compare notes. Find me on blog.kasun.dev.

Orchestrating Sub-Agents for Cost-Efficient Engineering

Kasun de Silva — Wed, 23 Sep 2026 23:27:05 +0000

How I route Claude Code work to the cheapest model that can do it well, and the exact rules I use.

Kasun de Silva · September 2026

In Claude Code, every subagent you spawn inherits the parent's model unless you say otherwise. If your main session runs on the most capable model, so does the agent you sent to grep sixty repos for a variable name. That is a cron job running on your biggest instance type because it was the one already booted.

I fixed this with one section in my global CLAUDE.md. The idea: one expensive brain, many cheap hands.

The brain is the main session model, Fable 5.1 at the time of writing. It plans, briefs, reviews and commits. It does not grep. The hands are subagents on cheaper models. Each gets one bounded job and one precise brief, does it, reports back, and never touches git. Control plane and data plane, if you like.

The rules

Copy this into ~/.claude/CLAUDE.md and replace "Fable" with whatever your main model is.

# Global rules

## Orchestration and model routing

Fable is the planner, sole decision maker, orchestrator, reviewer and committer. Cheaper models do the bulk of the work under Fable's direction. The quality bar is the highest in every case; delegation never lowers it.

### Always set the model explicitly
Subagents inherit the parent model unless `model` is passed. A delegated task without `model:` runs on Fable and saves nothing. Every `Agent` call must name a model.

| Model | Use for |
|---|---|
| `haiku` | Read-only sweeps: grep/find across repos, locating files or symbols, scanning logs, summarising large tool output. Use `Explore` type. |
| `sonnet` | Implementation from a precise spec: code and Terraform/HCL edits, tests, boilerplate, doc and PR-body drafting, applying review fixes. |
| `opus` | Implementation where the path is unclear: multi-file refactors, debugging with unknown cause, work needing judgement mid-task. |
| Fable (self) | Planning, architecture and design decisions, requirement clarification, code review, anything security- or prod-impacting, final approval and commit. |

Never use `subagent_type: "fork"` for grunt work. A fork inherits the full Fable context and always runs on Fable.

### Do it yourself when delegation costs more
Delegation has fixed overhead: writing the brief, reading the report, reviewing the diff. Do the work directly when:
- the change is small (roughly under 20 lines or a single file edit),
- it is a single-fact lookup and the file is already known,
- the brief would be longer than the work itself,
- the task is conversation, advice or a decision rather than production of code.

### Briefing standard
A subagent gets one precise brief, not a conversation. Every brief includes: exact files and scope, the required approach and conventions, what "done" looks like, what to leave untouched, and the report format (summary of changes plus anything uncertain). A vague brief produces a round-trip, and every round-trip re-bills the brief.

### Review and correction
- Fable reviews every diff a subagent produces before anything is committed. Read the actual diff, not just the agent's summary.
- Deviation from the spec is corrected, always. If the fix is a few lines, Fable applies it directly. If the fix is substantial, send it back to the same agent via `SendMessage` (keeps its context) with the exact change required. Do not start a fresh agent to fix a running agent's work.
- Fable commits, opens PRs and posts review requests. Subagents never commit or push.

### Parallelism
Independent tasks go to separate agents in one message so they run concurrently. Dependent tasks run sequentially through Fable, never chained agent to agent.

### Skills that dispatch agents
Superpowers (subagent-driven-development, dispatching-parallel-agents, requesting-code-review) and any other skill that spawns agents does so without a model. When following such a skill, add `model:` to every Agent call it prescribes: `sonnet` for implementers and spec-compliance reviewers, `haiku` for search. Mechanical review (does the output match the written spec) goes to a Sonnet agent; the judgement layer (is the design right, do the findings matter) stays with Fable in the main context so the same files are not read twice at Fable rates.

The three that matter most

If you only take three things from that block:

Name a model on every agent call. Without it, delegation saves nothing. I also set CLAUDE_CODE_SUBAGENT_MODEL to sonnet in ~/.claude/settings.json as a safety net for the calls I forget.
Do it yourself when delegation costs more. A brief, a report and a review are fixed overhead. Under about twenty lines, the brain does the work directly. Without this rule a multi-agent setup pays twice for one-line changes.
Review the diff, not the summary. Summaries are where "bumped the module version" hides "and reformatted 400 lines". Fixes go back to the same agent so its context is not paid for twice.

What changed

The expensive model now touches a task a few times, for a few minutes of judgement each. Search and edits run on models that cost a fraction of it, often in parallel, so tasks finish sooner as well as cheaper.

Lets Encrypt DNS Challenge with Traefik and AWS Route 53

Kasun de Silva — Mon, 25 May 2026 04:20:01 +0000

So, you're self-hosting awesome apps like Jellyfin, Home Assistant, or your personal blog with Docker. You want that sweet, sweet HTTPS padlock for secure connections, and Let's Encrypt is the obvious choice for free SSL certs. Awesome!

You set up your reverse proxy (maybe Traefik, because it's slick!), point it to your app, and tell it to get a certificate... only to hit a wall. Why? Meet the home networker's nemesis: ISPs blocking incoming port 80.

The Standard Way (and the Wall)

Let's Encrypt's default validation method, HTTP-01, is simple: their servers try to access a special file on your server over standard HTTP (port 80) to prove you control the domain.

Let's Encrypt -> Your Public IP:80 -> Does challenge file exist? -> OK! Cert Issued!

But if your ISP blocks incoming connections on port 80 (super common on residential plans!), Let's Encrypt's request never reaches your server.

Let's Encrypt -> Your Public IP:80 -> [ISP BLOCK] -> Challenge Failed! No Cert! :(

Frustrating, right? Your quest for HTTPS seems doomed... or is it?

The DNS-01 Challenge: A Different Kind of Proof

Enter the DNS-01 challenge – Let's Encrypt's clever workaround. Instead of checking a file via HTTP, it asks you to prove domain ownership by creating a specific DNS TXT record with a unique value.

Let's Encrypt -> Checks Your Domain's DNS Records -> Does specific TXT record exist? -> OK! Cert Issued!

Since this validation happens entirely via DNS lookups (usually port 53, which is almost never blocked inbound for lookups), it completely bypasses the port 80 problem!

The Magic Combo: Traefik + AWS Route 53

Okay, manually creating DNS records every ~90 days sounds tedious. This is where the dynamic duo comes in:

Traefik: Our smart reverse proxy knows how to talk the ACME protocol and request certificates using the DNS-01 method.
AWS Route 53: A robust, API-driven DNS service.

You configure Traefik with AWS API credentials (using an IAM user with just enough permission to modify Route 53 records – security first!). When it's time to issue or renew a cert, Traefik tells Route 53 (via the API) to create the temporary TXT record Let's Encrypt needs. Once Let's Encrypt verifies it, Traefik tells Route 53 to clean it up. Chef's kiss!

The Key Configuration (Traefik + Docker Compose):

In your Traefik service definition within docker-compose.yml, the magic lies in the command arguments for your certificate resolver:

# Snippet from docker-compose.yml command section for Traefik
command:
  # ... other args ...
  # Let's Encrypt Resolver Config
  - "--certificatesresolvers.myresolver.acme.email=your-email@example.com"
  - "--certificatesresolvers.myresolver.acme.storage=/letsencrypt/acme.json"
  # --- THE IMPORTANT PART ---
  - "--certificatesresolvers.myresolver.acme.dnschallenge=true"          # Enable DNS Challenge
  - "--certificatesresolvers.myresolver.acme.dnschallenge.provider=route53" # Tell it to use AWS Route 53
  # ... other args ...

You also need to securely provide your AWS credentials (Access Key ID & Secret) as environment variables, preferably using a .env file.

Conclusion: Problem Solved!

By switching to the DNS-01 challenge and leveraging the automation power of Traefik integrated with the AWS Route 53 API, the infamous port 80 block becomes irrelevant for getting your Let's Encrypt certificates. You get fully automated, secure HTTPS for your self-hosted services without hassle. Now that's cool.

Happy (secure) self-hosting!

Simplify AWS Lambda Deployments Using GitHub Actions

Kasun de Silva — Fri, 15 Aug 2025 00:49:44 +0000

Hey, serverless builders! 🚀 Exciting news from AWS!

AWS has launched a feature that direct support for deploying AWS Lambda functions using GitHub Actions. This new capability significantly streamlines the deployment process, eliminating the need for complex, custom scripting and boilerplate code.

Before this, deploying a Lambda function from a GitHub workflow required manual steps to package code, configure IAM roles, and handle potential errors. Now, a dedicated GitHub Action handles all of this for you with a simple, declarative YAML configuration. This means less friction, faster deployments, and more time for you to focus on building amazing serverless applications.

What's New?

The new "Deploy Lambda Function" GitHub Action simplifies your CI/CD pipeline by providing a direct and secure way to update your Lambda functions.

Declarative Configuration: Define your deployment settings—like runtime, memory, and environment variables—directly in your GitHub Actions workflow file.
Automatic Packaging: The action automatically handles the packaging of your function code, supporting both .zip file and container image deployments.
Seamless IAM Integration: It integrates with AWS IAM using OpenID Connect (OIDC) authentication, which is the most secure way to grant your GitHub workflows temporary, short-lived credentials without ever storing long-lived secrets.

This new workflow is a huge win for developer experience, making it easier than ever to adopt a fully automated, Git-based deployment strategy for your serverless projects.

Step-by-Step Guide: Deploying a Lambda Function with GitHub Actions

Ready to get started? Here's how you can set up a GitHub Actions workflow to automatically deploy your Lambda function.

Prerequisites

A Lambda Function: You need an existing AWS Lambda function. If you don't have one, create it in the AWS Management Console or with the AWS CLI.
IAM Role for OIDC: Configure an IAM role in your AWS account that trusts GitHub's OIDC provider. This role will grant your workflow the permissions it needs to deploy the function. This is a crucial security step!
A GitHub Repository: Your Lambda function code should be in a GitHub repository.

Step 1: Configure IAM for OIDC

First, set up a trusted relationship between your AWS account and GitHub.

Navigate to IAM in the AWS console.
Under Access management, select Identity providers.
Choose Add provider and configure an OpenID Connect provider with the URL: https://token.actions.githubusercontent.com.
Create a new IAM role that uses this provider and grant it the necessary permissions, such as lambda:UpdateFunctionCode and lambda:UpdateFunctionConfiguration.

Step 2: Create Your GitHub Actions Workflow File

In your GitHub repository, create a new file at .github/workflows/deploy.yml. This YAML file defines the deployment process.

name: Deploy Lambda Function

on:
  push:
    branches:
      - main # This workflow runs on pushes to the 'main' branch

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write # Required for OIDC authentication
      contents: read  # Required to check out the repository

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionRole # Replace with your IAM role ARN
          aws-region: us-east-1 # Replace with your AWS region

      - name: Deploy Lambda Function
        uses: aws-actions/aws-lambda-deploy@v1
        with:
          function-name: my-lambda-function # Replace with your function name
          code-artifacts-dir: ./dist # The directory containing your packaged code

Step 3: Push Your Code and Watch it Deploy!

That's it! When you push new code to the main branch of your repository, GitHub Actions will automatically trigger this workflow. The aws-lambda-deploy action will package the code from your specified directory (./dist in this example) and deploy it to your Lambda function.

Beyond the Basics

The aws-lambda-deploy action is highly configurable. You can:

Deploy via Amazon S3: For larger deployment packages, you can specify an S3 bucket to use as an intermediate location.
Configure Function Settings: Update your Lambda function's runtime, memory, timeout, and environment variables directly within the workflow.
Use Dry Run Mode: Test your deployment configuration and permissions without making any changes to the function itself.

With this new feature, AWS is making it simpler and more secure to manage the entire lifecycle of your serverless applications. Happy coding! 💻✨

For more details and advanced examples, check out the AWS Lambda Deploy GitHub Action repository: https://github.com/aws-actions/aws-lambda-deploy.

Lets Encrypt DNS Challenge with Traefik and AWS Route 53

Kasun de Silva — Fri, 15 Aug 2025 00:46:58 +0000

The Standard Way (and the Wall)

Let's Encrypt's default validation method, HTTP-01, is simple: their servers try to access a special file on your server over standard HTTP (port 80) to prove you control the domain.

Let's Encrypt -> Your Public IP:80 -> Does challenge file exist? -> OK! Cert Issued!

But if your ISP blocks incoming connections on port 80 (super common on residential plans!), Let's Encrypt's request never reaches your server.

Let's Encrypt -> Your Public IP:80 -> [ISP BLOCK] -> Challenge Failed! No Cert! :(

Frustrating, right? Your quest for HTTPS seems doomed... or is it?

The DNS-01 Challenge: A Different Kind of Proof

Let's Encrypt -> Checks Your Domain's DNS Records -> Does specific TXT record exist? -> OK! Cert Issued!

Since this validation happens entirely via DNS lookups (usually port 53, which is almost never blocked inbound for lookups), it completely bypasses the port 80 problem!

The Magic Combo: Traefik + AWS Route 53

Okay, manually creating DNS records every ~90 days sounds tedious. This is where the dynamic duo comes in:

Traefik: Our smart reverse proxy knows how to talk the ACME protocol and request certificates using the DNS-01 method.
AWS Route 53: A robust, API-driven DNS service.

The Key Configuration (Traefik + Docker Compose):

In your Traefik service definition within docker-compose.yml, the magic lies in the command arguments for your certificate resolver:

# Snippet from docker-compose.yml command section for Traefik
command:
  # ... other args ...
  # Let's Encrypt Resolver Config
  - "--certificatesresolvers.myresolver.acme.email=your-email@example.com"
  - "--certificatesresolvers.myresolver.acme.storage=/letsencrypt/acme.json"
  # --- THE IMPORTANT PART ---
  - "--certificatesresolvers.myresolver.acme.dnschallenge=true"          # Enable DNS Challenge
  - "--certificatesresolvers.myresolver.acme.dnschallenge.provider=route53" # Tell it to use AWS Route 53
  # ... other args ...

You also need to securely provide your AWS credentials (Access Key ID & Secret) as environment variables, preferably using a .env file.

Conclusion: Problem Solved!

Happy (secure) self-hosting!

Let's Encrypt DNS Challenge with Traefik and AWS Route 53

Kasun de Silva — Fri, 15 Aug 2025 00:46:30 +0000

The Standard Way (and the Wall)

Let's Encrypt's default validation method, HTTP-01, is simple: their servers try to access a special file on your server over standard HTTP (port 80) to prove you control the domain.

Let's Encrypt -> Your Public IP:80 -> Does challenge file exist? -> OK! Cert Issued!

But if your ISP blocks incoming connections on port 80 (super common on residential plans!), Let's Encrypt's request never reaches your server.

Let's Encrypt -> Your Public IP:80 -> [ISP BLOCK] -> Challenge Failed! No Cert! :(

Frustrating, right? Your quest for HTTPS seems doomed... or is it?

The DNS-01 Challenge: A Different Kind of Proof

Let's Encrypt -> Checks Your Domain's DNS Records -> Does specific TXT record exist? -> OK! Cert Issued!

Since this validation happens entirely via DNS lookups (usually port 53, which is almost never blocked inbound for lookups), it completely bypasses the port 80 problem!

The Magic Combo: Traefik + AWS Route 53

Okay, manually creating DNS records every ~90 days sounds tedious. This is where the dynamic duo comes in:

Traefik: Our smart reverse proxy knows how to talk the ACME protocol and request certificates using the DNS-01 method.
AWS Route 53: A robust, API-driven DNS service.

The Key Configuration (Traefik + Docker Compose):

In your Traefik service definition within docker-compose.yml, the magic lies in the command arguments for your certificate resolver:

# Snippet from docker-compose.yml command section for Traefik
command:
  # ... other args ...
  # Let's Encrypt Resolver Config
  - "--certificatesresolvers.myresolver.acme.email=your-email@example.com"
  - "--certificatesresolvers.myresolver.acme.storage=/letsencrypt/acme.json"
  # --- THE IMPORTANT PART ---
  - "--certificatesresolvers.myresolver.acme.dnschallenge=true"          # Enable DNS Challenge
  - "--certificatesresolvers.myresolver.acme.dnschallenge.provider=route53" # Tell it to use AWS Route 53
  # ... other args ...

You also need to securely provide your AWS credentials (Access Key ID & Secret) as environment variables, preferably using a .env file.

Conclusion: Problem Solved!

Happy (secure) self-hosting!

Let's Encrypt DNS-01 Challenge with Traefik and AWS Route 53

Kasun de Silva — Tue, 06 May 2025 00:10:54 +0000

The Standard Way (and the Wall)

Let's Encrypt's default validation method, HTTP-01, is simple: their servers try to access a special file on your server over standard HTTP (port 80) to prove you control the domain.

Let's Encrypt -> Your Public IP:80 -> Does challenge file exist? -> OK! Cert Issued!

But if your ISP blocks incoming connections on port 80 (super common on residential plans!), Let's Encrypt's request never reaches your server.

Let's Encrypt -> Your Public IP:80 -> [ISP BLOCK] -> Challenge Failed! No Cert! :(

Frustrating, right? Your quest for HTTPS seems doomed... or is it?

The DNS-01 Challenge: A Different Kind of Proof

Let's Encrypt -> Checks Your Domain's DNS Records -> Does specific TXT record exist? -> OK! Cert Issued!

Since this validation happens entirely via DNS lookups (usually port 53, which is almost never blocked inbound for lookups), it completely bypasses the port 80 problem!

The Magic Combo: Traefik + AWS Route 53

Okay, manually creating DNS records every ~90 days sounds tedious. This is where the dynamic duo comes in:

Traefik: Our smart reverse proxy knows how to talk the ACME protocol and request certificates using the DNS-01 method.
AWS Route 53: A robust, API-driven DNS service.

The Key Configuration (Traefik + Docker Compose):

In your Traefik service definition within docker-compose.yml, the magic lies in the command arguments for your certificate resolver:

# Snippet from docker-compose.yml command section for Traefik
command:
  # ... other args ...
  # Let's Encrypt Resolver Config
  - "--certificatesresolvers.myresolver.acme.email=your-email@example.com"
  - "--certificatesresolvers.myresolver.acme.storage=/letsencrypt/acme.json"
  # --- THE IMPORTANT PART ---
  - "--certificatesresolvers.myresolver.acme.dnschallenge=true"          # Enable DNS Challenge
  - "--certificatesresolvers.myresolver.acme.dnschallenge.provider=route53" # Tell it to use AWS Route 53
  # ... other args ...

Environment Vars
You also need to securely provide your AWS credentials (Access Key ID & Secret) as environment variables, preferably using a .env file.

# Environment variables for AWS credentials (will use .env file)
environment:
  - AWS_ACCESS_KEY_ID
  - AWS_SECRET_ACCESS_KEY
  - AWS_REGION
  - AWS_HOSTED_ZONE_ID

Complete example config,

# docker-compose.yml
services:
  # Traefik Service (Reverse Proxy & SSL)
  traefik:
    image: "traefik:v2.11" # Pin to a specific stable version
    container_name: "traefik-proxy" # Descriptive container name
    command:
      # Enable Docker provider & disable exposing by default
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      # Define HTTP (80) and HTTPS (443) entry points
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      # Enable Traefik API/Dashboard (for monitoring)
      - "--api.dashboard=true"
      # Configure Let's Encrypt Resolver (named 'myresolver')
      - "--certificatesresolvers.myresolver.acme.email=your-email@example.com" # !! REPLACE THIS with your email !!
      - "--certificatesresolvers.myresolver.acme.storage=/letsencrypt/acme.json"
      # Use DNS-01 challenge with Route53 provider
      - "--certificatesresolvers.myresolver.acme.dnschallenge=true"
      - "--certificatesresolvers.myresolver.acme.dnschallenge.provider=route53"
      # Global Redirect: HTTP -> HTTPS
      - "--entrypoints.web.http.redirections.entrypoint.to=websecure"
      - "--entrypoints.web.http.redirections.entrypoint.scheme=https"
    ports:
      # Expose port 80 for HTTP->HTTPS redirect (optional if ISP blocks)
      - "80:80"
      # Expose port 443 for HTTPS access (ESSENTIAL)
      - "443:443"
    volumes:
      # Mount Docker socket to detect container events
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
      # Persist Let's Encrypt certificates
      - "./letsencrypt:/letsencrypt"
    networks:
      - proxy # Connect to our custom network
    # Environment variables for AWS credentials (will use .env file)
    environment:
      - AWS_ACCESS_KEY_ID
      - AWS_SECRET_ACCESS_KEY
      - AWS_REGION
      - AWS_HOSTED_ZONE_ID
    labels:
      # Enable Traefik for its own dashboard
      - "traefik.enable=true"
      # Dashboard Router Rule (HTTPS)
      - "traefik.http.routers.traefik-dashboard.rule=Host(`traefik.yourdomain.com`)" # !! REPLACE with your dashboard hostname !!
      - "traefik.http.routers.traefik-dashboard.entrypoints=websecure"
      - "traefik.http.routers.traefik-dashboard.service=api@internal"
      # Use Let's Encrypt for the dashboard domain
      - "traefik.http.routers.traefik-dashboard.tls.certresolver=myresolver"
      # Secure the dashboard with Basic Auth
      - "traefik.http.routers.traefik-dashboard.middlewares=auth"
      - "traefik.http.middlewares.auth.basicauth.users=user:$<span class="math-inline">apr1</span><span class="math-inline">abcdefg</span>$yourhashedpassword" # !! REPLACE THIS HASH !!
    restart: unless-stopped

Conclusion: Problem Solved!

Happy (secure) self-hosting!

From Plex to Freedom: My Jellyfin Journey with Traefik & AWS Route 53

Kasun de Silva — Mon, 05 May 2025 08:20:13 +0000

Like many, I relied on Plex for years to manage and stream my personal media library – hundreds of movies and countless TV show episodes. It served me well. However, recent shifts towards monetizing core features, like remote streaming, prompted me to look for alternatives. I wanted a solution that was open-source, powerful, and gave me complete control over my media and its access, without unexpected subscription requirements for basic functionality.

Enter Jellyfin. It's a fantastic, free software media system that puts you in control. But simply installing it isn't enough; I needed secure, easy remote access for myself and my family, just like I had before.

This post details my journey setting up Jellyfin locally using Docker, but making it securely accessible from anywhere using Traefik as a reverse proxy, Let's Encrypt for free SSL certificates, and leveraging AWS Route 53 for seamless and reliable DNS hosting. If you're comfortable with Docker and use AWS for your DNS, this guide is for you!

Why This Stack?

Jellyfin: Awesome open-source media server.
Docker & Docker Compose: Easy deployment, management, and reproducibility of services.
Traefik: A modern, cloud-native reverse proxy that integrates beautifully with Docker. It automatically discovers services and handles SSL certificate management.
Let's Encrypt: Free, automated SSL certificates. Essential for secure HTTPS connections.
AWS Route 53: Reliable DNS hosting. Crucially, its API allows Traefik to perform the Let's Encrypt DNS-01 challenge automatically – perfect if your ISP blocks port 80 (a common issue!).

Prerequisites

A server or machine (like a NAS, Raspberry Pi, or home server) running Docker and Docker Compose.
A registered domain name (we'll use yourdomain.com as an example).
Your domain's DNS hosted on AWS Route 53.
An AWS account with IAM permissions to modify Route 53 records for yourdomain.com.
Basic familiarity with the command line.

The Challenge: Secure Remote Access & The Port 80 Problem

Running Jellyfin locally is easy, but accessing it securely from outside your network requires HTTPS. Let's Encrypt provides free SSL certificates via the ACME protocol. The most common validation method (HTTP-01 challenge) requires your server to be reachable from the internet on port 80. Unfortunately, many residential ISPs block incoming traffic on port 80.

This is where the DNS-01 challenge shines. Instead of checking port 80, Let's Encrypt verifies domain ownership by checking for a specific TXT record in your DNS zone. Since we're using Route 53, Traefik can automatically create and remove these temporary records using the AWS API.

Step 1: AWS Setup - IAM User for Traefik

Traefik needs permission to modify your Route 53 DNS records for yourdomain.com. We'll create a dedicated IAM user with only the necessary permissions (Principle of Least Privilege).

Go to the IAM console in AWS.
Create a new User. Give it a descriptive name (e.g., traefik-route53-manager).
Select "Attach policies directly".

Create a new policy. Use the JSON editor and paste the following policy, replacing YOUR_HOSTED_ZONE_ID with the actual Route 53 Hosted Zone ID for yourdomain.com (you can find this in the Route 53 console):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "route53:GetChange",
                "route53:ListHostedZonesByName"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "route53:ChangeResourceRecordSets",
                "route53:ListResourceRecordSets"
            ],
            "Resource": "arn:aws:route53:::hostedzone/YOUR_HOSTED_ZONE_ID"
        }
    ]
}

> Note: Using ListHostedZonesByName and filtering by resource ARN for ChangeResourceRecordSets scopes down permissions significantly.

Finish creating the policy (give it a name like TraefikRoute53AccessPolicy).
Attach this new policy to the user you created.
Proceed to the "Security credentials" tab for the new user.
Create an "Access key" - select "Application running outside AWS" as the use case.
Carefully copy the Access Key ID and Secret Access Key. You won't see the secret key again! Store these securely for the next steps.

Step 2: Docker Compose Configuration

Now, let's define our services using docker-compose.yml. This file defines the Traefik reverse proxy and the Jellyfin application itself. Remember to replace the example hostnames (jellyfin.yourdomain.com, traefik.yourdomain.com) with your actual desired subdomains.

# docker-compose.yml
services:
  # Traefik Service (Reverse Proxy & SSL)
  traefik:
    image: "traefik:v2.11" # Pin to a specific stable version
    container_name: "traefik-proxy" # Descriptive container name
    command:
      # Enable Docker provider & disable exposing by default
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      # Define HTTP (80) and HTTPS (443) entry points
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      # Enable Traefik API/Dashboard (for monitoring)
      - "--api.dashboard=true"
      # Configure Let's Encrypt Resolver (named 'myresolver')
      - "--certificatesresolvers.myresolver.acme.email=your-email@example.com" # !! REPLACE THIS with your email !!
      - "--certificatesresolvers.myresolver.acme.storage=/letsencrypt/acme.json"
      # Use DNS-01 challenge with Route53 provider
      - "--certificatesresolvers.myresolver.acme.dnschallenge=true"
      - "--certificatesresolvers.myresolver.acme.dnschallenge.provider=route53"
      # Global Redirect: HTTP -> HTTPS
      - "--entrypoints.web.http.redirections.entrypoint.to=websecure"
      - "--entrypoints.web.http.redirections.entrypoint.scheme=https"
    ports:
      # Expose port 80 for HTTP->HTTPS redirect (optional if ISP blocks)
      - "80:80"
      # Expose port 443 for HTTPS access (ESSENTIAL)
      - "443:443"
    volumes:
      # Mount Docker socket to detect container events
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
      # Persist Let's Encrypt certificates
      - "./letsencrypt:/letsencrypt"
    networks:
      - proxy # Connect to our custom network
    # Environment variables for AWS credentials (will use .env file)
    environment:
      - AWS_ACCESS_KEY_ID
      - AWS_SECRET_ACCESS_KEY
      # - AWS_REGION=us-east-1 # Optional: Specify if needed
      # - AWS_HOSTED_ZONE_ID=YOUR_HOSTED_ZONE_ID # Optional
    labels:
      # Enable Traefik for its own dashboard
      - "traefik.enable=true"
      # Dashboard Router Rule (HTTPS)
      - "traefik.http.routers.traefik-dashboard.rule=Host(`traefik.yourdomain.com`)" # !! REPLACE with your dashboard hostname !!
      - "traefik.http.routers.traefik-dashboard.entrypoints=websecure"
      - "traefik.http.routers.traefik-dashboard.service=api@internal"
      # Use Let's Encrypt for the dashboard domain
      - "traefik.http.routers.traefik-dashboard.tls.certresolver=myresolver"
      # Secure the dashboard with Basic Auth
      - "traefik.http.routers.traefik-dashboard.middlewares=auth"
      - "traefik.http.middlewares.auth.basicauth.users=user:$<span class="math-inline">apr1</span><span class="math-inline">abcdefg</span>$yourhashedpassword" # !! REPLACE THIS HASH !!
    restart: unless-stopped

  # Jellyfin Service
  jellyfin:
    image: lscr.io/linuxserver/jellyfin:latest
    container_name: jellyfin
    environment:
      - PUID=1000 # Your user ID
      - PGID=1000 # Your group ID
      - TZ=Etc/UTC # !! REPLACE with Your timezone e.g. Pacific/Auckland !!
    volumes:
      # Map Jellyfin config directory
      - /path/to/jellyfin/config:/config/ # !! REPLACE host path to your config location !!
      # Map Media Libraries
      - /path/to/tvshows:/data/tvshows   # !! REPLACE host path to your TV shows !!
      - /path/to/movies:/data/movies     # !! REPLACE host path to your Movies !!
    networks:
      - proxy # Connect to the same network as Traefik
    restart: unless-stopped
    labels:
      # Enable Traefik management for this container
      - "traefik.enable=true"
      # Jellyfin Router Rule (HTTPS)
      - "traefik.http.routers.jellyfin.rule=Host(`jellyfin.yourdomain.com`)" # !! REPLACE with your Jellyfin hostname !!
      - "traefik.http.routers.jellyfin.entrypoints=websecure" # Use HTTPS entrypoint
      # Use Let's Encrypt resolver defined above
      - "traefik.http.routers.jellyfin.tls.certresolver=myresolver"
      # Tell Traefik which internal port Jellyfin uses
      - "traefik.http.services.jellyfin.loadbalancer.server.port=8096"

# Define the shared network
networks:
  proxy:
    name: proxy

# Define the volume for Let's Encrypt certificates
volumes:
  letsencrypt:

Step 3: Handling Secrets - The `.env` File

Never commit secrets directly into your docker-compose.yml! We'll use a .env file to store the AWS credentials.

In the same directory as your docker-compose.yml, create a file named .env.

Add your AWS keys:

# .env
AWS_ACCESS_KEY_ID=YOUR_ACTUAL_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY=YOUR_ACTUAL_SECRET_ACCESS_KEY

Crucially: Add .env to your .gitignore file to prevent accidentally committing it.
```
# .gitignore
.env
```

Docker Compose will automatically read this file and inject these variables into the Traefik container's environment, as specified in the environment: section of the docker-compose.yml.

Step 4: Securing the Traefik Dashboard

We added basic authentication to the dashboard using Traefik labels. You need to generate a password hash.

Install htpasswd (usually via apache2-utils or httpd-tools).
Run the following, replacing admin and 'YourSecurePassword!' with your desired credentials:
```
htpasswd -nb admin 'YourSecurePassword!'
```
Copy the output (e.g., admin:$apr1$somehash$morehash).

Paste it into the traefik.http.middlewares.auth.basicauth.users label in docker-compose.yml.
Remember to escape the dollar signs ($) by doubling them ($$):

# Example label in docker-compose.yml
_ "traefik.http.middlewares.auth.basicauth.users=admin:$$apr1$$somehash$$morehash" # !! REPLACE user:hash !!

Step 5: DNS Configuration (Route 53)

Before starting, ensure you have A records in Route 53 pointing your chosen hostnames (e.g., jellyfin.yourdomain.com and traefik.yourdomain.com) to the public IP address of the server running Docker.

jellyfin.yourdomain.com -> YOUR_SERVER_PUBLIC_IP
traefik.yourdomain.com -> YOUR_SERVER_PUBLIC_IP

Step 6: Final Checks & Deployment

Placeholders: Ensure you've replaced all placeholders marked with !! REPLACE !! or YOUR_... in the docker-compose.yml and .env files with your actual values (hostnames, email, paths, user IDs, timezone, password hash, AWS keys).
Paths: Double-check the host paths mapped in the volumes section for Jellyfin – point them to your actual config and media library locations.
User/Group ID: Update PUID and PGID in the Jellyfin environment section to match the user/group that owns your media files (use id $USER on Linux to find yours).
Directory: Create the Let's Encrypt volume directory: mkdir ./letsencrypt.
Firewall/Router: Ensure port 443 is forwarded from your router/firewall to the internal IP address of your Docker host machine. Port 80 forwarding is optional now but recommended for the HTTP->HTTPS redirect to work smoothly.
Launch: Run docker compose up -d.
Monitor: Check the Traefik logs, especially on the first run, to ensure successful AWS authentication and certificate acquisition: docker compose logs -f traefik-proxy.

Conclusion

You should now have a fully functional Jellyfin instance accessible securely via https://jellyfin.yourdomain.com (using your actual domain), with automatic SSL certificate management handled by Traefik and Let's Encrypt, leveraging the power and reliability of AWS Route 53 for DNS validation. The Traefik dashboard is also available (and password-protected) at https://traefik.yourdomain.com (again, using your actual domain).

This setup gives me the control and freedom I was seeking after moving from Plex. By combining powerful open-source tools like Jellyfin and Traefik with robust cloud services like AWS Route 53 and IAM, we can build secure, flexible, and non-subscription-based solutions tailored perfectly to our needs.

Happy self-hosting! Let me know about your experiences in the comments below.

CodeBuild Meets GitHub Actions: A Serverless CI Workflow with Lambda

Kasun de Silva — Thu, 27 Feb 2025 23:04:27 +0000

Serverless GitHub Actions? Yes! Learn how to use AWS Lambda/ CodeBuild for Github Actions workflow execution

GitHub Actions provides a powerful CI/CD pipeline, but sometimes you need more control over the environment where your workflows run. AWS CodeBuild now supports Lambda-based self-hosted runners, allowing you to execute GitHub Actions workflows in a cost-efficient, on-demand AWS environment. This guide will walk you through setting up a self-hosted GitHub Actions runner using AWS CodeBuild's Lambda Runner environment.

Prerequisites

Before getting started, ensure you have:

An AWS account with permissions to create CodeBuild projects and Lambda functions
A GitHub repository where you want to run the actions
AWS CLI and GitHub CLI installed on your local machine
An IAM role with necessary permissions for CodeBuild and Lambda execution

Step 1: Create an AWS CodeBuild Project

AWS CodeBuild will serve as our self-hosted GitHub Actions runner. Follow these steps:

1.1 Navigate to AWS CodeBuild

Open the AWS CodeBuild Console
Click Create build project

1.2 Configure Project Settings

Project Name: github-actions-runner
Description: Self-hosted GitHub Actions runner using AWS CodeBuild Lambda Runner
Source: Select GitHub and connect to your repository

1.3 Select Environment

Environment Image: Choose Managed Image
Operating System: Amazon Linux 2
Runtime: AWS Lambda
Compute Type: Lambda Execution Environment
Operating System System: Amazon Linux
Runtime: Python
Image & Version: Select the latest

1.4 Configure IAM Role

Choose New Service Role or select an existing role with permissions to execute CodeBuild, interact with GitHub, and access AWS Lambda.

Attach the following policies if needed:

  {
      "Version": "2012-10-17",
      "Statement": [
          {
              "Effect": "Allow",
              "Action": ["lambda:InvokeFunction"],
              "Resource": "arn:aws:lambda:*:*:function:*"
          },
          {
              "Effect": "Allow",
              "Action": ["codebuild:StartBuild"],
              "Resource": "*"
          }
      ]
  }

Click Create Build Project to finalize.

Step 2: Setup the GitHub action workflow.

Navigate to your GitHub repository
Go to Actions tab and create a simple workflow.
To point the lambda self-hosted runner in place, update your .github/workflows/main.yml to use it: Please note the runs-on: section here that you need to at to the workflow file.

    # The type of runner that the job will run on
    runs-on: 
      - codebuild-gha-runner-lambda-test-${{ github.run_id }}-${{ github.run_attempt }}

Here is a full example of the workflow file.

# This is a basic workflow to help you get started with Actions

name: CI AWS Lambda Pipeline Test

# Controls when the workflow will run
on:
  # Triggers the workflow on push or pull request events but only for the "master" branch
  push:
    branches: [ "master" ]
  pull_request:
    branches: [ "master" ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: 
      - codebuild-gha-runner-lambda-test-${{ github.run_id }}-${{ github.run_attempt }}

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v4

      # Runs a single command using the runners shell
      - name: Run a one-line script
        run: echo Hello, world!

      # Runs a set of commands using the runners shell
      - name: Run a multi-line script
        run: |
          echo Add other actions to build,
          echo test, and deploy your project.

Push changes to your repository, and the self-hosted runner in AWS CodeBuild will pick up the job and the lambda function will run your job.

2.1 Limitations

Lambda compute is designed for speed, optimizing startup times for builds. However, it does have some limitations and does not support the following use cases:

Reserved Capacity
Caching Across Builds
Restricting Runtime with Timeouts
Tools Requiring Root-User Permissions
Long-Running Builds (Lambda has a maximum timeout of 15 minutes)

Using AWS CodeBuild's Lambda Runner for GitHub Actions provides a scalable, cost-efficient alternative to traditional self-hosted runners. You only pay for execution time, and the Lambda-based environment ensures seamless scaling. Try this setup for your CI/CD workflows and enjoy the flexibility of AWS CodeBuild in your GitHub Actions pipelines!

Happy coding! 🚀

Speak the Command, Execute the Lambda

Kasun de Silva — Thu, 19 Dec 2024 22:06:52 +0000

In today's world of voice assistants and smart devices, integrating your AWS Lambda functions with Amazon Alexa opens up a world of possibilities. Imagine being able to trigger a Lambda function with a simple voice command, automating tasks like checking the weather, controlling smart devices, or querying your AWS resources. In this blog post, we’ll walk you through the steps to create a voice-activated Lambda function using Amazon Alexa.

Step 1: Setting Up Your AWS Lambda Function

Before you can trigger a Lambda function with your voice, you need to create and configure the function.

1.1 Create the Lambda Function

Create a new function:

Choose "Author from scratch."
Enter a function name (e.g., WeatherCheckerLambda).
Choose a runtime (e.g., Python 3.9 or Node.js 18.x).
Set up an execution role with basic Lambda permissions. If your function needs to access other AWS services, ensure the role has the appropriate permissions.

Write your function code: Here’s a simple Python example that returns a weather update:

import json

def lambda_handler(event, context):
    # Sample response to be returned by Alexa
    return {
        'version': '1.0',
        'response': {
            'outputSpeech': {
                'type': 'PlainText',
                'text': 'The weather today is sunny with a high of 25 degrees.',
            },
            'shouldEndSession': True
        }
    }

1.2 Configure the Lambda Function

Set up environment variables and resource limits according to your needs.
Test the function using the AWS Lambda console's built-in test feature. This ensures that your function executes as expected before integrating with Alexa.

Step 2: Creating an Alexa Skill

Now that your Lambda function is ready, you’ll create an Alexa skill to trigger it.

2.1 Set Up the Alexa Skill

Create a new skill:

Choose “Create Skill” and select the “Custom” skill type.
Set your skill name (e.g., Weather Checker).
Select other for the experience type.
Choose a template: Start from scratch or use the provided templates for a custom experience.

Hit Create Skill

2.2 Designing the Interaction Model

Invocation Name:

Set an invocation name for your skill (e.g., weather checker).
This is what users will say to start the interaction (e.g., “Alexa, ask weather checker...”).
Hit Build Skill

Create Intents:

Intents represent actions users want to perform. For example, create an intent called GetWeatherIntent.
Under the GetWeatherIntent, add sample utterances like:
- "What is the weather today?"
- "Tell me the weather."
- "Give me today's weather forecast."

Slots: If your skill needs more specific inputs, such as a city name, you can define slots. For this example, a simple weather checker might not need them.

2.3 Configuring the Endpoint

Link the Skill to Your Lambda Function:

In the Alexa Developer Console, navigate to the Endpoint section.
Select AWS Lambda ARN as the service endpoint type.
Paste the ARN of the Lambda function you created earlier.

Skill Permissions:

Ensure your Lambda function’s IAM role has the necessary permissions to execute and return data.

Add Lambda Trigger

Add “Alexa Skills kit” from the “Add triggers” sidebar in aws console. (Shown as in screenshot above)

Next you have to click on the “Alexa Skills kit”, then this will show up

Add your skill ID in the above field.

Moreover, make sure you add this lambda function ARN in your skill’s endpoint. Just paste the ARN in your skill’s endpoint.

Build and Save it.

Step 3: Coding the Lambda Function to Handle Alexa Requests

Your Lambda function needs to be able to handle requests from Alexa and respond appropriately.

3.1 Handle Alexa Requests in Your Lambda Function

Here’s an expanded version of the Lambda function that parses the input and returns a relevant response:

import json

def lambda_handler(event, context):
    # Extracting intent name from Alexa's request
    intent_name = event['request']['intent']['name']

    if intent_name == "GetWeatherIntent":
        # Build response
        return {
            'version': '1.0',
            'response': {
                'outputSpeech': {
                    'type': 'PlainText',
                    'text': 'The weather today is sunny with a high of 25 degrees.',
                },
                'shouldEndSession': True
            }
        }
    else:
        return {
            'version': '1.0',
            'response': {
                'outputSpeech': {
                    'type': 'PlainText',
                    'text': 'I am not sure how to help with that.',
                },
                'shouldEndSession': True
            }
        }

3.2 Testing the Lambda Function

Use the AWS Lambda console to trigger the function manually with test events that simulate Alexa requests.
Enable detailed logging in CloudWatch to troubleshoot any issues and ensure your function handles requests correctly.

Step 4: Testing and Deploying the Alexa Skill

4.1 Testing with the Alexa Simulator

Go to the Alexa Developer Console and open your skill.
Use the Test tab: Here, you can simulate voice commands using the Alexa Simulator. Type or speak phrases like “Alexa, ask weather checker what the weather is today.”
Review responses: Ensure Alexa returns the expected responses, and debug if necessary.

4.2 Testing with a Real Device

Enable your skill on an Alexa-enabled device, such as an Amazon Echo.
Speak the invocation name and command: For example, say “Alexa, ask weather checker what the weather is today.”
Refine based on feedback: Adjust your Lambda function and skill interaction model based on real-world testing.

Step 5: Deploying and Monitoring Your Skill

5.1 Deploying Your Skill

Publish your skill: Once satisfied with the functionality, you can submit your skill for certification through the Alexa Developer Console.
Private or Public: Choose whether to keep the skill private for personal use or make it available to the public.

5.2 Monitoring and Logging

Use AWS CloudWatch: Monitor logs to track Lambda execution, identify errors, and optimize performance.
Skill Analytics: In the Alexa Developer Console, you can also access analytics to see how users interact with your skill.

By following these steps, you’ve successfully created a voice-activated Lambda function using Amazon Alexa. This setup opens the door to endless possibilities, from automating daily tasks to creating rich, voice-controlled applications. Whether you’re developing a personal project or a commercial application, integrating AWS Lambda with Alexa is a powerful way to bring voice capabilities to your cloud services.

Happy coding, and enjoy the convenience of voice-triggered automation!

Mastering AWS Step Functions Error Handling

Kasun de Silva — Thu, 01 Aug 2024 23:18:01 +0000

AWS Step Functions is a powerful orchestration service that enables developers to build and coordinate workflows using a series of steps, such as AWS Lambda functions, ECS tasks, or other AWS services. One of the critical aspects of building robust workflows is handling errors effectively. In this blog post, we'll dive into the different error handling scenarios in AWS Step Functions and provide practical examples to illustrate how to manage them.

Why Error Handling is Important

Error handling ensures your workflows can gracefully handle failures and continue processing without manual intervention. This not only improves the reliability of your applications but also enhances user experience by minimizing downtime and reducing the likelihood of data corruption.

Types of Errors in AWS Step Functions

States.All Errors: Catch-all for any error not explicitly caught by other patterns.
States.Timeout: Triggered when a state exceeds its allowed execution time.
States.TaskFailed: Raised when a task state fails.
States.Permissions: Occurs due to IAM permission issues.
States.ResultPathMatchFailure: When the result path doesn't match.
States.BranchFailed: Raised if a parallel state fails.
States.NoChoiceMatched: No match found for a Choice state.
States.ParameterPathFailure: When a parameter path evaluation fails.

Error Handling Strategies

Retry: Automatically retry a failed state.
Catch: Capture errors and redirect execution to a recovery path.
Timeout: Specify a maximum time a state should run.

Example Workflow

Let's create a Step Functions workflow with a few states to illustrate error handling. Our example will include a Lambda function that might fail, and we'll handle errors using retry and catch mechanisms.

State Machine Graph

Step Function Definition



{
  "Comment": "A simple state machine to demonstrate error handling",
  "StartAt": "Invoke Lambda",
  "States": {
    "Invoke Lambda": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:REGION:ACCOUNT_ID:function:YOUR_LAMBDA_FUNCTION",
      "Retry": [
        {
          "ErrorEquals": ["States.ALL"],
          "IntervalSeconds": 2,
          "MaxAttempts": 3,
          "BackoffRate": 2.0
        }
      ],
      "Catch": [
        {
          "ErrorEquals": ["States.ALL"],
          "Next": "Handle Error"
        }
      ],
      "End": true
    },
    "Handle Error": {
      "Type": "Fail",
      "Error": "LambdaFunctionFailed",
      "Cause": "The Lambda function encountered an error."
    }
  }
}

Error Handling Scenarios

1. Retrying Failed States

The Retry field allows you to retry a failed state. In the example above, the state will retry up to 3 times with exponential backoff if an error occurs.



"Retry": [
  {
    "ErrorEquals": ["States.ALL"],
    "IntervalSeconds": 2,
    "MaxAttempts": 3,
    "BackoffRate": 2.0
  }
]

2. Catching Errors

The Catch field enables you to capture errors and redirect the workflow to a different state, like an error handler or a fallback mechanism.



"Catch": [
  {
    "ErrorEquals": ["States.ALL"],
    "Next": "Handle Error"
  }
]

3. Handling Timeouts

You can specify timeouts for states to prevent them from running indefinitely.



{
  "Type": "Task",
  "Resource": "arn:aws:lambda:REGION:ACCOUNT_ID:function:YOUR_LAMBDA_FUNCTION",
  "TimeoutSeconds": 10
}

Advanced Error Handling

1. Conditional Error Handling with Choice State

You can use the Choice state to direct the workflow based on different error types.



"Catch": [
  {
    "ErrorEquals": ["States.Timeout"],
    "Next": "TimeoutHandler"
  },
  {
    "ErrorEquals": ["States.TaskFailed"],
    "Next": "TaskFailedHandler"
  }
]

Benefits of Conditional Error Handling

Granular Control: Allows you to define different handling strategies for different error types, improving the robustness of your workflow.
Improved Debugging: By routing specific errors to distinct states, you can more easily identify and address issues.
Customised Recovery: Enables tailored recovery actions or notifications based on the nature of the error.

State Machine Graph

Step Function Definition



{
  "Comment": "A simple state machine to demonstrate error handling including timeout",
  "StartAt": "Invoke Lambda",
  "States": {
    "Invoke Lambda": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:REGION:ACCOUNT_ID:function:YOUR_LAMBDA_FUNCTION",
      "TimeoutSeconds": 5,  // Timeout after 5 seconds
      "Retry": [
        {
          "ErrorEquals": ["States.ALL"],
          "IntervalSeconds": 2,
          "MaxAttempts": 3,
          "BackoffRate": 2.0
        }
      ],
      "Catch": [
        {
          "ErrorEquals": ["States.Timeout"],
          "Next": "Handle Timeout"
        },
        {
          "ErrorEquals": ["States.ALL"],
          "Next": "Handle Error"
        }
      ],
      "End": true
    },
    "Handle Timeout": {
      "Type": "Fail",
      "Error": "LambdaTimeoutError",
      "Cause": "The Lambda function timed out."
    },
    "Handle Error": {
      "Type": "Fail",
      "Error": "LambdaFunctionFailed",
      "Cause": "The Lambda function encountered an error."
    }
  }
}

2. Parallel State Error Handling

For workflows with parallel states, each branch can have its own error handling strategy.

Parallel Tasks State:
- The Parallel state starts two branches: "Invoke Lambda A" and "Invoke Lambda B".
- Each branch handles retries, timeouts, and failures independently.
Error Handling in Each Branch:
- Retry: Retries the task up to 3 times with exponential backoff if it fails.
- Timeout: If a task times out, it transitions to a specific error handler.
- Catch: Captures any other errors and transitions to an error handler.
Error Handling for Parallel State:
- The Catch block in the Parallel state catches errors from any branch and transitions to the "Handle Parallel Failure" state if any branch fails.

State Machine Graph

Step Function Definition



{
  "Comment": "A state machine with parallel tasks and error handling",
  "StartAt": "Parallel Tasks",
  "States": {
    "Parallel Tasks": {
      "Type": "Parallel",
      "Branches": [
        {
          "StartAt": "Invoke Lambda A",
          "States": {
            "Invoke Lambda A": {
              "Type": "Task",
              "Resource": "arn:aws:lambda:REGION:ACCOUNT_ID:function:LambdaFunctionA",
              "TimeoutSeconds": 5,
              "Retry": [
                {
                  "ErrorEquals": [
                    "States.ALL"
                  ],
                  "IntervalSeconds": 2,
                  "MaxAttempts": 3,
                  "BackoffRate": 2.0
                }
              ],
              "Catch": [
                {
                  "ErrorEquals": [
                    "States.Timeout"
                  ],
                  "Next": "Handle Timeout A"
                },
                {
                  "ErrorEquals": [
                    "States.ALL"
                  ],
                  "Next": "Handle Error A"
                }
              ],
              "End": true
            },
            "Handle Timeout A": {
              "Type": "Fail",
              "Error": "LambdaTimeoutErrorA",
              "Cause": "Lambda Function A timed out."
            },
            "Handle Error A": {
              "Type": "Fail",
              "Error": "LambdaFunctionFailedA",
              "Cause": "Lambda Function A failed."
            }
          }
        },
        {
          "StartAt": "Invoke Lambda B",
          "States": {
            "Invoke Lambda B": {
              "Type": "Task",
              "Resource": "arn:aws:lambda:REGION:ACCOUNT_ID:function:LambdaFunctionB",
              "TimeoutSeconds": 5,
              "Retry": [
                {
                  "ErrorEquals": [
                    "States.ALL"
                  ],
                  "IntervalSeconds": 2,
                  "MaxAttempts": 3,
                  "BackoffRate": 2.0
                }
              ],
              "Catch": [
                {
                  "ErrorEquals": [
                    "States.Timeout"
                  ],
                  "Next": "Handle Timeout B"
                },
                {
                  "ErrorEquals": [
                    "States.ALL"
                  ],
                  "Next": "Handle Error B"
                }
              ],
              "End": true
            },
            "Handle Timeout B": {
              "Type": "Fail",
              "Error": "LambdaTimeoutErrorB",
              "Cause": "Lambda Function B timed out."
            },
            "Handle Error B": {
              "Type": "Fail",
              "Error": "LambdaFunctionFailedB",
              "Cause": "Lambda Function B failed."
            }
          }
        }
      ],
      "Catch": [
        {
          "ErrorEquals": [
            "States.ALL"
          ],
          "Next": "Handle Parallel Failure"
        }
      ],
      "End": true
    },
    "Handle Parallel Failure": {
      "Type": "Fail",
      "Error": "ParallelStateFailed",
      "Cause": "One or more parallel tasks failed."
    }
  }
}

Effective error handling in AWS Step Functions is crucial for building resilient workflows. By leveraging retry, catch, and timeout strategies, you can ensure your workflows handle failures gracefully and continue processing without manual intervention. With these techniques, you can build robust and reliable applications that can withstand various failure scenarios.

Do you have any questions or additional error handling scenarios you'd like to explore? Let me know in the comments below! Happy coding in AWS!

DEV Community: Kasun de Silva

Beyond Stateless Lambda: Harnessing MicroVMs for Isolated AI Sandboxes

Unlocking Next-Gen AI Sandboxes: Building Secure Code Execution with AWS Lambda MicroVMs

Why Standard Serverless Falls Short for AI Sandboxes

The AWS Lambda MicroVM Solution

Architectural Deep Dive: An AI Agent Sandbox Workflow

The End-to-End Workflow

Navigating MicroVMs in the AWS Console

Infrastructure as Code: Specifying MicroVMs in Terraform

The Verdict

Architecting an Enterprise Network on AWS Cloud WAN

The problem Cloud WAN solves

Cloud WAN in one paragraph

Reading the diagram

Regions: edges, not peerings

Segments: the routing intent, written down

Attachments: make joining the network boring

Inspection: one hop, not two

Hybrid and multi-cloud: same edges, same segments

Migrating from Transit Gateway without a big bang

Operating it: what to know before you commit

Is it worth it?

Orchestrating Sub-Agents for Cost-Efficient Engineering

The rules

The three that matter most

What changed

Lets Encrypt DNS Challenge with Traefik and AWS Route 53

Simplify AWS Lambda Deployments Using GitHub Actions

What's New?

Step-by-Step Guide: Deploying a Lambda Function with GitHub Actions

Prerequisites

Step 1: Configure IAM for OIDC

Step 2: Create Your GitHub Actions Workflow File

Step 3: Push Your Code and Watch it Deploy!

Beyond the Basics

Lets Encrypt DNS Challenge with Traefik and AWS Route 53

Let's Encrypt DNS Challenge with Traefik and AWS Route 53

Let's Encrypt DNS-01 Challenge with Traefik and AWS Route 53

From Plex to Freedom: My Jellyfin Journey with Traefik & AWS Route 53

Why This Stack?

Prerequisites

The Challenge: Secure Remote Access & The Port 80 Problem

Step 1: AWS Setup - IAM User for Traefik

Step 2: Docker Compose Configuration

Step 3: Handling Secrets - The .env File

Step 4: Securing the Traefik Dashboard

Step 5: DNS Configuration (Route 53)

Step 6: Final Checks & Deployment

Conclusion

CodeBuild Meets GitHub Actions: A Serverless CI Workflow with Lambda

Serverless GitHub Actions? Yes! Learn how to use AWS Lambda/ CodeBuild for Github Actions workflow execution

Prerequisites

Step 1: Create an AWS CodeBuild Project

1.1 Navigate to AWS CodeBuild

1.2 Configure Project Settings

1.3 Select Environment

1.4 Configure IAM Role

Step 2: Setup the GitHub action workflow.

2.1 Limitations

Speak the Command, Execute the Lambda

Step 1: Setting Up Your AWS Lambda Function

1.1 Create the Lambda Function

1.2 Configure the Lambda Function

Step 2: Creating an Alexa Skill

2.1 Set Up the Alexa Skill

2.2 Designing the Interaction Model

2.3 Configuring the Endpoint

Step 3: Coding the Lambda Function to Handle Alexa Requests

3.1 Handle Alexa Requests in Your Lambda Function

3.2 Testing the Lambda Function

Step 4: Testing and Deploying the Alexa Skill

4.1 Testing with the Alexa Simulator

4.2 Testing with a Real Device

Step 5: Deploying and Monitoring Your Skill

5.1 Deploying Your Skill

5.2 Monitoring and Logging

Mastering AWS Step Functions Error Handling

Why Error Handling is Important

Types of Errors in AWS Step Functions

Error Handling Strategies

Step 3: Handling Secrets - The `.env` File