DEV Community: Kasun de Silva

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

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!

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!

De-Bugging with Amazon Q and Generative AI

Kasun de Silva — Fri, 19 Jul 2024 01:08:02 +0000

Serverless functions are the superheroes of the cloud, scaling effortlessly and saving you precious server management time. But even superheroes need a good debugging sidekick, and that’s where Amazon Q steps in. This innovative service from AWS harnesses the power of generative AI to take your serverless debugging to a whole new level.

What Makes Amazon Q So Special?

Traditional debugging can be a challenging and time-consuming process, especially in complex codebases. Amazon Q stands out by using generative AI to assist with your code debugging. Instead of manually hunting for bugs, Q analyzes your code to identify patterns and potential issues proactively. Imagine having a smart assistant that understands your code’s nuances, offering insights and suggestions as you write, helping you catch and fix problems before they escalate.

Here’s How Amazon Q Can Supercharge Your Debugging:

Identify Anomalies in Code: Amazon Q can scan your Python code and highlight unusual patterns or potential bugs. For instance, if a specific function call tends to cause unexpected behaviour, Q can flag it for your attention, saving you valuable time in pinpointing the root cause.
Predict Code Issues: Leveraging generative AI, Amazon Q can learn from past code errors and identify patterns that might lead to future problems. Q can analyse your codebase and warn you of potential issues before they occur, preventing bugs and keeping your applications running smoothly.
Generate Debugging Insights: Struggling to decipher a cryptic error in your code? Q can analyse the context of the error within your codebase and generate potential explanations and solutions to help you resolve the issue faster. It can suggest fixes and improvements, making your debugging process more efficient and effective.

Real-world Example: Debugging a Lambda Function with a DeadLock issue and get Amazon Q to fix it.

Let’s say you have a Lambda function that has potential issue’s with deadlocks and space for improvements, Here’s how Amazon Q can help:

The Problematic Code

Let’s start with a simple Python script that uses threading and locks:

import json
import threading
import time

# Shared resources
lock = threading.Lock()

# Thread function
def thread_routine(thread_name):
    print(f"{thread_name}: attempting to acquire lock")
    with lock:
        print(f"{thread_name}: acquired lock")
        time.sleep(1)  # Simulate some processing
        # Do something with the resources

def lambda_handler(event, context):
    # Create threads
    thread1 = threading.Thread(target=thread_routine, args=("Thread 1",))
    thread2 = threading.Thread(target=thread_routine, args=("Thread 2",))

    # Start threads
    thread1.start()
    thread2.start()

    # Join threads to wait for their completion
    thread1.join()
    thread2.join()

    return {
        'statusCode': 200,
        'body': json.dumps('Hello from Lambda!')
    }

# Test the lambda_handler function locally
if __name__ == "__main__":
    lambda_handler({}, {})

Identifying Issues with Amazon Q

To identify issues with the above code, follow these steps:

Install Amazon Q in Visual Studio Code: Ensure you have the Amazon Q extension installed. This can be done from the Visual Studio Code Marketplace.
Analyze the Code: Open your Python script in Visual Studio Code. Amazon Q will automatically analyse the code and highlight potential issues.

Review the Suggestions: Amazon Q provides detailed suggestions and explanations. In our script, Amazon Q identifies a potential deadlock situation caused by the order in which locks are acquired in the two threads.

import json
import threading

# Shared resources
lock1 = threading.Lock()
lock2 = threading.Lock()

# Thread function that acquires locks in a consistent order
def thread_routine(thread_id):
    print(f"Thread {thread_id}: attempting to acquire lock1")
    with lock1:
        print(f"Thread {thread_id}: acquired lock1")
        print(f"Thread {thread_id}: attempting to acquire lock2")
        with lock2:
            print(f"Thread {thread_id}: acquired lock2")
            # Do something with the resources

def lambda_handler(event, context):
    # Create threads
    thread1 = threading.Thread(target=thread_routine, args=(1,))
    thread2 = threading.Thread(target=thread_routine, args=(2,))

    # Start threads
    thread1.start()
    thread2.start()

    # Join threads to wait for their completion
    thread1.join()
    thread2.join()

    return {
        'statusCode': 200,
        'body': json.dumps('Hello from Lambda!')
    }

# Test the lambda_handler function locally
if __name__ == "__main__":
    lambda_handler({}, {})

In the refactored code, Amazon Q suggested to use a single lock to ensure that only one thread can access the shared resource at a time, preventing deadlock.

Feel free to reach out if you have any questions or need further assistance with Amazon Q or any other development tools. Let’s make coding smoother and more efficient together!

This is just one example of how Amazon Q can streamline your serverless debugging process. By leveraging the power of generative AI, you can spend less time wrestling with errors and more time building amazing serverless applications.

Coding with a Cyborg: The Rise of the Amazon Q

Kasun de Silva — Fri, 10 May 2024 07:46:25 +0000

Introducing the Amazon Q VS Code Extension: Your AI Copilot

Imagine having an AI assistant whispering coding insights in your ear as you write. That’s the magic of Amazon Q! It has a VS Code extension seamlessly integrates with your development environment, offering real-time code completion, error detection, and even the ability to generate code snippets based on your natural language descriptions.

Building A Lambda function with Amazon Q’s Help

Let’s use Amazon Q to streamline building our Lambda function. Here’s a glimpse of the workflow:

Fire Up VS Code and Install the Amazon Q Extension: This is a breeze — just search for “Amazon Q” in the VS Code extension marketplace and hit install.
Project structure - Let's say we are going create a lambda function and deploy it via terraform. we can use the following basic project structure.

.
├── main.tf
└── send-email-lambda
    └── send-email.py

Craft Your Natural Language Request: Describe what you want the function to do, I’m going to ask: Write a lambda function that can be used to send notifications when certain events occur. For example, a function could be triggered to send an email when a new order is placed on an e-commerce website
Witness the Power of AI: Amazon Q analyses your request and generates the basic Lambda function code, including boilerplate and event handling.

Copy the lambda code and put that in the send-email.py file.

Adding SMS Functionality with Amazon Q’s Guidance

Now, let’s extend the Lambda to send SMS notifications as well. Here’s where Amazon Q shines again:

New Feature: Add a comment # Send SMS after the send email section of your code and press enter. Amazon Q will start suggesting you code blocks as you go in to new lines.

AI to the Rescue: Amazon Q taps into its knowledge base and suggests relevant code snippets or documentation links to achieve your goal.

Terraform Takes the Wheel for Deployment

With the Lambda function primed, it’s time to deploy it using Terraform’s infrastructure as code (IaC). Terraform lets you define your infrastructure in code, ensuring consistent and automated deployments. You can use Amazon Q within VS Code to help you write the Terraform code for creating the Lambda function, IAM roles, and SNS topics needed for email and SMS notifications.

Craft Your Natural Language Request: Describe what you want the function to do, and this time I’m going to ask:
Write a terraform code that creates a zip file of this “send-email-lambda/send-email.py” python code and deploy it to my aws account

The Final Frontier: Deployment and Beyond!

Once the Terraform code is ready, simply run terraform apply to deploy your serverless notification machine to the cloud. This is just a taste of the possibilities! With Amazon Q as your AI partner, you can craft complex applications with unprecedented ease.

Remember, this is just the beginning; explore Amazon Q’s capabilities and see how it can transform your coding experience!

Happy Coding with Amazon Q

Boost Your Lambdas with Powertools

Kasun de Silva — Fri, 26 Apr 2024 04:15:51 +0000

AWS Lambda Powertools for Python is a comprehensive suite of utilities designed to enhance the development of serverless applications using AWS Lambda. It simplifies logging, tracing, metric gathering, and more, allowing developers to focus more on business logic rather than boilerplate code. In this blog post, we’ll explore the key features of AWS Lambda Powertools for Python and provide an example of deploying a Lambda function using Terraform with the Powertools layer.

Key Features of AWS Lambda Powertools for Python

1. Logger

The Logger utility simplifies logging setup across Lambda functions, providing structured logging as JSON out of the box. It automatically captures key information like cold start and function ARN, and supports logging correlation IDs for distributed tracing.

from aws_lambda_powertools import Logger

logger = Logger()

@logger.inject_lambda_context
def lambda_handler(event, context):
    logger.info("Processing event")
    return {"statusCode": 200}

2. Tracer

Tracer is built on top of AWS X-Ray and provides decorators to trace Lambda function handlers and methods effortlessly. It captures cold starts, annotates errors correctly, and traces downstream calls to other AWS services.

from aws_lambda_powertools import Tracer

tracer = Tracer()

@tracer.capture_lambda_handler
def handler(event, context):
    # Your business logic here
    pass

3. Metrics

The Metrics utility provides a straightforward way to capture custom business metrics using Amazon CloudWatch. It batches and flushes the metrics at the end of the function execution to minimize the number of calls made to CloudWatch.

from aws_lambda_powertools import Metrics
from aws_lambda_powertools.metrics import MetricUnit

metrics = Metrics()

@metrics.log_metrics
def lambda_handler(event, context):
    metrics.add_metric(name="SuccessfulBookings", unit=MetricUnit.Count, value=1)
    return {"statusCode": 200}

4. Utilities

AWS Lambda Powertools also includes several other utilities like Parameters for retrieving and caching parameter values from AWS Systems Manager or AWS Secrets Manager, Idempotency to ensure Lambda functions are idempotent, and Feature Flags to manage feature toggling.

Deploying a Lambda Function with Terraform and Powertools Layer

To deploy an AWS Lambda function with the Powertools layer using Terraform, you first need to define your infrastructure as code. Below is a basic example of how you can set up a Lambda function with the AWS Lambda Powertools layer.

provider "aws" {
  region = "us-east-1"
}

resource "aws_lambda_function" "my_lambda" {
  function_name = "MyLambdaFunction"
  handler       = "lambda_function.lambda_handler"
  runtime       = "python3.8"
  role          = aws_iam_role.lambda_exec_role.arn

  filename      = "path_to_your_lambda_deployment_package.zip"

  layers = [
    "arn:aws:lambda:us-east-1:017000801446:layer:AWSLambdaPowertoolsPython:2"
  ]
}

resource "aws_iam_role" "lambda_exec_role" {
  name = "lambda_execution_role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Principal = {
          Service = "lambda.amazonaws.com"
        }
        Effect = "Allow"
      },
    ]
  })
}

output "lambda_arn" {
  value = aws_lambda_function.my_lambda.arn
}

This Terraform script sets up a basic Lambda function with the AWS Lambda Powertools layer. It defines the necessary IAM role for the Lambda function to execute and outputs the ARN of the Lambda function after deployment.

AWS Lambda Powertools for Python is a powerful toolkit that can significantly simplify the development and maintenance of serverless applications on AWS. By using its features, developers can ensure that their applications are robust, scalable, and easy to manage. You can read more about AWS Lambda Powertools in the following link.

Happy Coding!

Lambda Layers: The Secret Weapon of Savvy Serverless Developers

Kasun de Silva — Fri, 15 Mar 2024 00:04:28 +0000

When it comes to serverless development with AWS Lambda, keeping your code clean and efficient is essential. Lambda functions themselves have size limitations, and including all your dependencies within the function code can quickly bloat them. This is where Lambda layers come in — a powerful tool for streamlining your development process.

What are Lambda Layers?

Imagine a Lambda layer as a self-contained zip archive. This archive can hold various things, including:

Library dependencies: Instead of bundling libraries with your function code, store them in a layer. This keeps your deployment packages leaner and easier to manage.
Custom runtimes: Need a specific runtime environment for your function? Layers can provide that too.
Configuration files: Separate your function’s core logic from configuration details by storing them in a layer.

Benefits of Using Lambda Layers

Smaller Deployment Packages: By offloading dependencies to layers, you keep your function code concise and reduce deployment times.

Improved Code Maintainability: Separating function code from dependencies makes it easier to update and manage each independently.

Reusability: Layers can be attached to multiple functions, promoting code reuse and consistency across your serverless application.

Standardized Runtimes: Manage custom runtimes through layers, continuing a consistent environment for your functions.

Simple Layer Example
Let’s say you have a Lambda function that needs to make API requests. You can create a layer containing the requests library. Here's a basic example:

Create a directory: Create a folder named python for your layer.
Install the library: Inside the python directory, run pip install requests -t . This installs the requests library into the current directory.
Zip the directory: Use the zip command (or your OS's equivalent) to create a zip archive of the python directory. Name it something descriptive, like my_requests_layer.zip.

Now you have a layer containing the requests library! You can upload this zip file to AWS Lambda and reference it in your function code.

Using the Layer in Your Lambda Function

Once you have uploaded your layer to AWS Lambda, follow these steps to use it in your Lambda function:

Navigate to Lambda functions in the AWS console.
Click on the “Layers” section from the left menu.
Click “Create layer”, upload your zip file and hit “Create”.

Let’s Create a Lambda functions that using the requests library from a layer:

import json
import requests

def lambda_handler(event, context):
  url = "https://api.example.com/data"

  # Using the requests library from the layer
  response = requests.get(url)
  data = json.loads(response.text)

  return {
      "statusCode": 200,
      "body": json.dumps(data)
  }

Create a new Lambda function using above code example.
In the “code” tab scroll all the way to bottom and find the Layers section.

Click on “Add Layer”

Select “Custom layers” and chose the “python_requests” layer you just uploaded.
Click “Add”

Then the custom layer you just created will be attached to your function.

In this example, the function imports requests without needing it installed within the function code itself. This keeps the deployment package lean and leverages the reusable layer.

Getting Started with AWS Lambda Layers

Using Lambda layers is straightforward. You create a zip archive containing your desired dependencies or configurations, upload it to AWS, and then reference it in your Lambda function code. Layers are versioned, so you can control exactly which version of the layer your function uses.

Here are some additional resources to get you started:

AWS Lambda Layers Documentation: https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html
Using Lambda layers to simplify your development process: https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html

Lambda layers are a valuable asset for any serverless developer on AWS. By leveraging layers, you can create cleaner, more manageable codebases, improve deployment efficiency, and promote code reuse across your serverless applications. So next time you’re building serverless functions with AWS Lambda, consider using layers to simplify your workflow and streamline your development process.

DEV Community: Kasun de Silva

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

Example Workflow

Error Handling Scenarios

1. Retrying Failed States

2. Catching Errors

3. Handling Timeouts

Advanced Error Handling

1. Conditional Error Handling with Choice State

2. Parallel State Error Handling

De-Bugging with Amazon Q and Generative AI

What Makes Amazon Q So Special?

Here’s How Amazon Q Can Supercharge Your Debugging:

Real-world Example: Debugging a Lambda Function with a DeadLock issue and get Amazon Q to fix it.

Identifying Issues with Amazon Q

Coding with a Cyborg: The Rise of the Amazon Q

Introducing the Amazon Q VS Code Extension: Your AI Copilot

Building A Lambda function with Amazon Q’s Help

Adding SMS Functionality with Amazon Q’s Guidance

Terraform Takes the Wheel for Deployment

The Final Frontier: Deployment and Beyond!

Boost Your Lambdas with Powertools

Key Features of AWS Lambda Powertools for Python

1. Logger

2. Tracer

3. Metrics

4. Utilities

Deploying a Lambda Function with Terraform and Powertools Layer

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