The Model Context Protocol (MCP) is rapidly becoming the "USB-C for AI," allowing LLMs to seamlessly interface with local and remote tools. However, most MCP implementations rely on persistent connections (SSE) or local processes (stdio). What if you want to host your MCP server in a scalable, cost-effective cloud environment without managing a 24/7 server?

Enter Serverless MCP. By leveraging AWS Lambda and a specialized HTTP streaming bridge, we can deploy robust AI tools that only cost money when they are actually being called.

The Challenge: Stdio vs. The Cloud

MCP servers usually communicate in two ways:

1. Stdio: Great for local use (e.g., Claude Desktop), but impossible to host as a web service.

2. SSE (Server-Sent Events): The standard for remote MCP, but problematic for AWS Lambda because Lambda is inherently stateless and struggles with long-lived streaming connections without complex workarounds.

The mcp-http-streamer project solves this by providing a lightweight wrapper that adapts MCP’s JSON-RPC over HTTP, making it compatible with serverless request/response cycles while maintaining the ability to stream tool outputs.

Architecture Overview

The setup involves three main components:

1. The MCP Server: Your core logic (Typescript/Python) using the standard MCP SDK.

2. The Streamer Bridge: A layer that converts incoming HTTP POST requests into the JSON-RPC format the MCP server expects.

3. AWS Lambda + API Gateway: The hosting environment that triggers your code on-demand.

Why Serverless MCP?

1. Zero-Scale: Pay $0 when your AI isn't using the tools.

2. Security: Use AWS IAM and Lambda Authorizers to ensure only your specific AI agent can access your private data or tools.

3. Scale: If your AI agent needs to perform 100 parallel data lookups, Lambda scales instantly to handle the load.

Implementation Guide

To build this, we use the official aws-lambda-go SDK alongside an MCP server implementation.

1. Defining the MCP Server

   First, we set up the basic structure to handle tool definitions.

    package main
   
    import (
        "context"
        "encoding/json"
        "github.com/aws/aws-lambda-go/events"
        "github.com/aws/aws-lambda-go/lambda"
    )
   
    // MCPRequest represents the standard JSON-RPC 2.0 structure
    type MCPRequest struct {
        Method string          `json:"method"`
        Params json.RawMessage `json:"params"`
        ID     interface{}     `json:"id"`
    }
   
    func HandleRequest(ctx context.Context, request events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) {
        var mcpReq MCPRequest
        if err := json.Unmarshal([]byte(request.Body), &mcpReq); err != nil {
            return events.APIGatewayProxyResponse{StatusCode: 400}, nil
        }
   
        // Logic to route MCP methods (e.g., tools/call, tools/list)
        switch mcpReq.Method {
        case "tools/list":
            return handleListTools()
        case "tools/call":
            return handleCallTool(mcpReq.Params)
        default:
            return events.APIGatewayProxyResponse{StatusCode: 404}, nil
        }
    }
   
    func main() {
        lambda.Start(HandleRequest)
    }
   

2. Handling Tool Execution

   Go's struct tags make it incredibly easy to define the schemas that the LLM needs to understand your tool.

    type GetWeatherArgs struct {
        Location string `json:"location"`
    }
   
    func handleCallTool(params json.RawMessage) (events.APIGatewayProxyResponse, error) {
        var args GetWeatherArgs
        json.Unmarshal(params, &args)
   
        // Your tool logic here
        result := fmt.Sprintf("The weather in %s is 72°F and sunny.", args.Location)
   
        responseBody, _ := json.Marshal(map[string]interface{}{
            "result": map[string]interface{}{
                "content": []map[string]string{
                    {"type": "text", "text": result},
                },
            },
        })
   
        return events.APIGatewayProxyResponse{
            StatusCode: 200,
            Body:       string(responseBody),
            Headers:    map[string]string{"Content-Type": "application/json"},
        }, nil
    }
   

Why Go for Serverless MCP?

1. Cold Start Performance: Go binaries are compiled to machine code. Unlike Node.js or Python, which have to parse scripts at startup, Go Lambdas typically start in under 10ms. This is vital for AI UX where latency is already high.

2. Type Safety: MCP relies heavily on specific JSON-RPC structures. Go’s strong typing ensures your tool schemas are strictly followed.

3. Single Binary: Deployment is a simple .zip file containing one executable. No node_modules or virtual environments required.

Deployment Tips

When deploying your Go MCP server to AWS:

1. Use Function URLs: For the simplest setup, use AWS Lambda Function URLs to get an HTTPS endpoint without the overhead of API Gateway.

2. Memory Settings: Since Go is efficient, you can often run these functions at the minimum memory setting (128MB), keeping costs extremely low.

3. Security: Always implement a simple Authorization header check within your Go code to ensure only your specific AI client (like Claude or a custom frontend) can trigger your tools.

Conclusion

By porting the mcp-http-streamer philosophy to Go, you get a production-ready, ultra-fast toolset for your AI agents. You pay nothing when the tools aren't in use, and you get lightning-fast execution when they are.

#go #mcp #ai #agents #serverless #aws #docker

In this article, we will uncover an important part of the puzzle that no one speaks about; which is running your MCP server on AWS Lambda.

Before we start

1. Please ensure you are pro-efficient in one of the popular programming languages, such as; Go, Python, Java, etc.

2. I am comfortable using Go, so I will be using Go to develop the MCP Server.

3. We’ll be using the official MCP library maintained by Anthropic, which is available on GitHub.

4. It is good to have Docker Desktop installed, as we will be containerizing our MCP server for local testing. Docker would also be used to build the final Amazon ECR image so AWS Lambda can run the MCP server.

5. Ensure the LTS version of Go is installed on your machine. Go can be installed on all major operating systems. Please refer here for more information.

6. Ensure you have an IDE installed on your local machine. I will be using VSCode for its simplicity. Please refer here for more information.

Setting up MCP Environment

1. Create your project directory locally

    mkdir ~/path-to-project-directory
   

2. Initialize a new Go project

    go mod init github.com/InspectorGadget/mcp-http-example
   

3. Create main.go in the parent directory

4. Populate the main.go file with the following contents

    package main
   
    func main() {
        // ....add logic here
    }
   

5. Import the go-sdk library from official Model Context Protocol package

    go get github.com/modelcontextprotocol/go-sdk
   

6. Replace the existing lines in main.go to the following

    package main
   
    func main() {
        server := mcp.NewServer(
            &mcp.Implementation{Name: "http-streamer", Version: "v0.0.1"},
            &mcp.ServerOptions{
                GetSessionID: func() string {
                    return uuid.New().String()
                },
            },
        )
   
        // Add new tool
        mcp.AddTool(
            server,
            &mcp.Tool{
                Name:        "greet",
                Description: "say hi to someone",
                InputSchema: json.RawMessage(`{
                    "type": "object",
                    "properties": {
                        "name": { 
                            "type": "string", 
                            "description": "name of the person to greet"
                        }
                    },
                    "required": ["name"]
                }`),
            },
            ...function
        }
   
        // Create HTTPStreamableHandler
        handler := mcp.NewStreamableHTTPHandler(
            func(*http.Request) *mcp.Server { return server },
            &mcp.StreamableHTTPOptions{
                SessionTimeout: 30 * time.Minute,
            },
        )
   
        http.HandleFunc(
            "/mcp", 
            func(w http.ResponseWriter, r *http.Request) {
                switch r.Method {
                case http.MethodGet:
                    w.WriteHeader(http.StatusOK)
                    _, _ = w.Write([]byte("ok"))
                    return
                case http.MethodDelete:
                    w.WriteHeader(http.StatusAccepted)
                    return
                case http.MethodPost:
                    handler.ServeHTTP(w, r)
                    return
                default:
                    w.WriteHeader(http.StatusMethodNotAllowed)
                    return
                }
            },
        )
   
        // Lastly, start your MCP Server
        log.Println("Starting MCP (http-streamer) server on :8080")
        if err := http.ListenAndServe(":8080", nil); err != nil {
            log.Fatal(err)
        }
    }
   

7. Now, the MCP server can be tested locally by running:

    go run .
   

8. To understand how the MCP server interacts with an LLM Model, you can use Claude Desktop locally and register the custom MCP server with it by editing the config file of Claude Desktop.

Preparing the MCP server for ChatGPT or any popular web-hosted tools

In order to ensure the MCP server can be used in popular tools such as ChatGPT, Gemini, Self-hosted Open Web UI with Docker Model Runner / Ollama, etc. We will need to understand how we can get it deployed on the Cloud.

With Cloud, there comes cost. I believe we are all naturally elevated to save even a dollar ($1) when it comes to public cloud. Hence, introducing “Serverless”. I will be using AWS Lambda on AWS for its serverless offering.

1. In order to prepare the MCP, we will need to understand the file structure and how each programming languages compile.

2. Fortunately, Go is a statically compiled language. This means your hundreds of Go files, libraries, etc can be all compiled into one single executable file and exportable to all major operating systems, such as;

   1. .exe (Windows)

   2. .sh (Mac & Linux)

Dockerfile

FROM golang:1.25.3-alpine AS build

# Install git (required for Go modules)
RUN apk add --no-cache git

# Set working directory
WORKDIR /app

# Copy go module files and download dependencies
COPY go.mod ./
# If you have a go.sum file, copy it here as well:
# COPY go.sum ./
RUN go mod download

# Copy the source code
COPY . .

# Build a statically linked Linux binary named 'bootstrap' for Lambda.
RUN CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o bootstrap .

# ------------------ Runtime stage ------------------
FROM alpine:latest AS production

RUN apk add --no-cache ca-certificates

COPY --from=inspectorgadget12/lambda-runtime-adapter:latest /lambda-runtime-adapter /opt/extensions/lambda-adapter

COPY --from=build /app/bootstrap /app/bootstrap
WORKDIR /app

ENV PORT=8080 \
    AWS_LWA_ASYNC_INIT=true \
    AWS_LWA_ENABLE_RESPONSE_STREAMING=true \
    AWS_LWA_INVOKE_MODE=response_stream \ 
    AWS_LWA_READINESS_CHECK_PATH=/mcp \
    AWS_LWA_LOG_LEVEL=debug \
    AWS_REGION=ap-southeast-1

EXPOSE 8080
CMD ["/app/bootstrap"]

1. inspectorgadget12/lambda-runtime-adapter:latest is a custom Container Image which allows your Go backend or runtime to speak to AWS Lambda’s backend services using the Service IP / Address. Along with it, it expects (optionally):

   1. AWS_LWA_ASYNC_INIT - Ensures the Go backend is started asynchronously before Lambda handler receives the HTTP request.

   2. AWS_LWA_ENABLE_RESPONSE_STREAMING - Ensures the MCP response is streamed back to the LLM, enabling smooth streaming either to API Gateway or Lambda Function URL.

   3. AWS_LWA_INVOKE_MODE - Useful especially for Lambda Function URL as it supports the streaming capability.

   4. AWS_LWA_READINESS_CHECK_PATH - A healthcheck path that constantly checks if the Lambda’s backend is actually operational or not.

   5. AWS_LWA_LOG_LEVEL - A useful flag that allows you to further debug your custom runtime on Lambda, and the responses streaming to CloudWatch can be piped to Open Telemetry, Grafana or Prometheus.

   6. AWS_REGION - The AWS region the Lambda function gets deployed to. Not required, but good to have.

2. The MCP’s Docker Container needs a port to be exposed to, and we gave it Port 8080. Please note: Lambda Functions do not expose to any port below port 1000 as the runtime itself does not have root within the Lambda function. Any effort to expose the backend to Port 80 or 443 would not succeed.

3. CMD ["/app/bootstrap"] - Is basically referring to the compiled Go binary that was built during the Image’s build environment.

With this method of Docker Multi-Stage Build, your final Container Image would be lesser than 30 MB which is lightweight and ideal for AWS Lambda so it can start it up easily.

deploy.sh

This shell file is used to deploy the Backend easily to AWS Lambda. This file is responsible for building a latest container image → pushing to Amazon ECR → getting it deployed to AWS Lambda.

#!/bin/bash
set -euo pipefail

# -------------------------------
# CONFIGURATION
# -------------------------------
APP_NAME="mcp-http"
AWS_ACCOUNT_ID="your-aws-account-id"
AWS_REGION="your-target-aws=region"
ECR_REPO="${APP_NAME}-repo"
ROLE_ARN="arn:aws:iam::${AWS_ACCOUNT_ID}:role/your-role"

IMAGE_TAG="latest"
IMAGE_URI="${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/${ECR_REPO}:${IMAGE_TAG}"

# -------------------------------
# BUILD DOCKER IMAGE
# -------------------------------
echo "Building Docker image..."
docker build --platform linux/arm64 --provenance false -t "${ECR_REPO}:${IMAGE_TAG}" .

# -------------------------------
# CREATE (OR VERIFY) ECR REPO
# -------------------------------
if ! aws ecr describe-repositories --repository-names "${ECR_REPO}" --region "${AWS_REGION}" >/dev/null 2>&1; then
  echo "Creating ECR repository: ${ECR_REPO}"
  aws ecr create-repository --repository-name "${ECR_REPO}" --region "${AWS_REGION}"
fi

# -------------------------------
# LOGIN AND PUSH IMAGE
# -------------------------------
echo "Logging in to Amazon ECR..."
aws ecr get-login-password --region "${AWS_REGION}" | \
  docker login --username AWS --password-stdin "${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com"

echo "Pushing image to ECR..."
docker tag "${ECR_REPO}:${IMAGE_TAG}" "${IMAGE_URI}"
docker push "${IMAGE_URI}"

# -------------------------------
# CREATE OR UPDATE LAMBDA FUNCTION
# -------------------------------
if ! aws lambda get-function --function-name "${APP_NAME}" --region "${AWS_REGION}" >/dev/null 2>&1; then
  echo "🪄 Creating new Lambda function..."
  aws lambda create-function \
    --function-name "${APP_NAME}" \
    --package-type Image \
    --code ImageUri="${IMAGE_URI}" \
    --role "${ROLE_ARN}" \
    --architectures arm64 \
    --region "${AWS_REGION}" \
    --environment "Variables={PORT=8080}"
else
  echo "Updating existing Lambda function..."
  aws lambda update-function-code \
    --function-name "${APP_NAME}" \
    --image-uri "${IMAGE_URI}" \
    --region "${AWS_REGION}"
fi

echo "Deployment complete!"

1. Please ensure chmod +x deploy.sh is performed prior to running this bash file.

2. Please ensure AWS CLI is installed, and that you are authenticated to your AWS Environment.

Post deployment

1. Upon a successful deployment, please head to the Lambda function’s configuration page and enable Lambda Function URL with the following options:

   1. Response type: RESPONSE_STREAM

   2. Authentication: OFF (For now)

2. Head to your favorite inferencing tool, I used ChatGPT

3. Please refer to this blog for more information on how to register your custom MCP with ChatGPT.

Conclusion

1. Woila! - if you followed along all the steps listed in this document, you now should be able to prompt your AI Model with your newly registered custom MCP server.

2. MCP libraries are always evolving, since the protocol itself is new. As long as you are kept up-to-date with all the new changes, and amend your code accordingly - You should be all good.

However, you often rely on thought to formulate ideas as work, evaluating your relationships, be creative, and hold interesting conversations. So, how much time do you spend trying to improve the way you think? If you’re anything like most people, probably not much.

Let’s devote more time to evaluating your ideas, values and goals

**So, how good are you at prioritizing?
**If you didn’t know how to answer, then you aren’t!

In life, most of us believe we’re first-rate. As rational people, we like to think to attend to the most important things in life first, and only then turn our attention to less pressing tasks. In other words, we think our priorities are pretty much in order.

But, are they really? Look closely. Many people’s priority are actually mixed up. We spend little time engaging with serious, important questions about the value of our goals — And instead we jump straight to trying to make those goals happen.

Do you ever ask yourself if more money would make you really happy? Or do you just thoughtlessly pursue a greater income? And have you also asked yourself whether you’d be better off single, or do you grudgingly plod on in familiar but unhappy relationships?

But, remember, things don’t have to be that way!

Accept that ideas develop in fits and starts

When you read a book, listen to a speech, or even reading this article :). It’s easy to imagine that the person who composed it came across their ideas and the corresponding words in a straightforward, almost effortless way. Because the words seem to flow together seamlessly, you might think the creative process was breezy and painless.

Please remember that such thought is often “delusional”.

Our brain is a fitful instrument, which doesn’t chug along at full power for hours at a time. It proceeds in fits and starts — Kicking into life briefly, making a sudden leap forward or an interesting new connection, and then lapsing into idleness again for a prolonged stretch.

However, this shouldn’t dispirit us.

Envy can help you identify your true desires

Hmm, envy — It is an emotion we all feel from time to time, but it’s not one we often like to acknowledge. We’re told that it’s wrong to envy others’ successes and talents or luck. Good people, after all, are happy to see others doing well.

But, what if envy has something to teach you after all? What if, instead of repressing the envious thoughts that occurred to you, you examined them and teased out their implications?

Don’t forget that the true value of envy lies in the way it reveals your true ambitions. You feel envy when you identify in others something that you desire and lack. By tracing each envious feeling back to its source, you can come a few steps closer to discovering what it is you truly want from life.

Envy can help you identify your true desires, but always remember, to be in control of it, not to be controlled by it.

Lastly, be skeptical about your own beliefs

You might imagine that effective thinkers rarely doubt their own opinions — and, in a way, that would actually make sense. After all, thinking’s what they’re good at. So, why should they be skeptical about the conclusions they reach?

For an instance, you might assume that persuasive lawyers rarely doubt their arguments, and convincing actors rarely doubt their performances. But they do — and for a good reason. Experiencing doubt is one of the core aspects of thinking well. In fact, the best aspects of thinking well. Thus, the best thinkers are very often the most skeptical.

On the other hand, if you can’t conceive if being wrong, then you can’t examine you own beliefs in a critical manner. And if you can’t interrogate what you believe, then all of your intelligence counts for nothing!

The golden rule towards this section would be that if you want to become a more skeptical and effective thinker, then you need to take in order to start; Genuinely entertain the idea that everything you believe could be wrong.

So, you still don’t believe it?
Good! That means you’re already halfway there.

Good luck!

Introduction

The landscape of AI development is undergoing a fundamental transformation. Local development for applications powered by LLMs is gaining momentum, and for good reason. Privacy concerns, cost optimization, and the need for offline functionality are driving developers away from cloud-based APIs toward local inference solutions.

Enter Docker Model Runner — a beta feature introduced with Docker Desktop 4.40 for macOS on Apple silicon (Now to many other Platforms) that promises to revolutionize how developers build, test, and deploy AI-powered applications. This isn’t just another local inference tool; it’s a complete reimagining of how AI models fit into modern development workflows.

What is Docker Model Runner

Docker Model Runner is designed to make AI model execution as simple as running a container. With this Beta release, we’re giving developers a fast, low-friction way to run models, test them, and iterate on application code that uses models locally, without all the usual setup headaches.

At its core, Docker Model Runner is a lightweight runtime integrated directly into Docker Desktop that allows developers to pull, run, and manage AI models using familiar Docker commands. But there’s a crucial architectural difference that sets it apart from traditional containerized solutions.

Key Characteristics

• Host-Native Execution: Unlike our usual Docker containers, Model Runner doesn’t run the AI model in a Docker container. Instead; Docker Desktop runs the inference engine (currently `llama.cpp`) directly on your host machine.

• OCI Artifact Distribution: Models are packaged as OCI Artifacts, an open standard that allows you to distribute and version them through the same registries and workflows that already use for containers.

• OpenAI API Compatibility: Docker Model Runner exposes an OpenAI-compatible API, making integration with existing tools and libraries seamless.

Host-Native Approach

The most significant architectural decision in Docker Model Runner is its departure from traditional containerization for model execution. When you run a model, Docker calls an Inference Server API endpoint hosted by the Model Runner through Docker Desktop, and provide an OpenAI compatible API. The Inference Server will use `llama.cpp` as the Inference Engine, running as a native host process

This design choice delivers several critical advantages:

• Performance Optimization: By using host-based execution, we avoid the performance limitations of running models inside virtual machines. This translates to significantly faster inference times, especially on Apple Silicon where direct Metal API access is crucial.

• GPU Acceleration: Apple Silicon’s Metal API is used for GPU acceleration, providing native performance without the overhead of virtualization layers.

• Memory Efficiency: The model will stay in memory until another model is requested, or until a pre-defined inactivity timeout (currently 5 minutes) is reached.

API Architecture

GET /engines/llama.cpp/v1/models
POST /engines/llama.cpp/v1/chat/completions
POST /engines/llama.cpp/v1/completions
POST /engines/llama.cpp/v1/embeddings

• From host processes: http://localhost:12434/

• From containers: http://model-runner.docker.internal/

Enabling Docker Model Runner

Run:

docker desktop enable model-runner --tcp 12434

Verifying Docker Model Runner

docker model status

Usage of Docker Model Runner

docker model list - Lists down all the models
docker model pull ai/smollm2 - Pulls a Model from Docker Hub
docker model ls - Lists all download models
docker model rm ai/smollm2 - Removes a model
docker model version - Presents the version of Docker Model Runner
docker model run ai/smollm2 "Explain Cloud Computing" - Running a model with a prompt
docker model run ai/smollm2 - Interactive model with the model

In 2020, Discord introduced two major and useful features which are Slash Commands & Interaction Endpoints. However, there are not many use-cases for both of these features, just yet.

Okay, enough of storytelling. Let’s not go too deep into the history, let’s get right into the “cool stuff” — We have Uncle Google for the history :)

Why AWS?

I’m not going to put in a lot of details on this, as the results or cost would be self-explanatory. So, why AWS? Because they are reliable, cheap, and cost-effective. However, the steps listed below could work on any Virtual Private Server, Dedicated Server, or any Linux-based Servers.

Okay, let’s get started

This is for hosting a standard Python Discord Bot on AWS, I will be walking you through some cheesy boilerplate to get things started. However, I’m assuming that you already have adequate knowledge on developing a Discord Bot, including attaining the relevant Tokens and more!

Step 1

Below is a simple gist on getting started with your own Discord Bot

Step 2

Let’s create our Python Environment, with the installation of the dependency.
To get started, simply run the commands below to giddy things up. (Also, assuming you have adequate knowledge on setting up Virtual Env, etc).

# Assuming you have created the file in Step 1 on a separate folder.
# Note: Activating the venv can be different on Windows. Or with any terminal extensions like fish, etc.

python3 -m venv venv
pip install discord
pip freeze > requirements.txt
source venv/bin/activate

Step 3

Now, assuming that you have gone through all the necessary steps to attain your own Discord Bot Token. If you are unsure, you may visit this link.

Step 4

**That is all on the setting up part. Let’s pack our Code Editor and store it in a safe place. In this step, we’ll be using Amazon EC2 to set up our bot & keep it always online.

Step 5

Let’s now go to your AWS Console.

Search for EC2 in AWS Console

Step 6

Now, let’s choose the EC2 instance of our choice. In this tutorial, I will be choosing “t2.micro”. If you’d like to estimate the cost & compare across all the types of instances AWS has to offer, simply visit this link.

Instance Configuration (Most default):

OS: Ubuntu 20.04 LTS (x86)
vCPU: 1
Memory: 1 GB
Storage: 8 GB

Step 7

Now, once we’ve configured our instance. Let’s look into your security group. Please ensure port 22 is allowed from “Anywhere” as we’ll be using SSH to connect to the EC2. Please refer to the screenshot below.

Step 8

Alright. Once that is selected appropriately, let’s jump into the next step. Let’s now choose our Key Pair (If present) or create a separate Key Pair file.
NOTE: This Key Pair serves as the credential in order for you to log into your EC2. Please do not lose this file. The downloaded Key Pair file will come with the extension of “.pem”.

Step 9

Now, we have got our EC2 fired up. Hold on! Before we move forward, let’s verify if our EC2 is running.

Step 10

Woila! The EC2 server is now live. Let’s try connecting to it.
NOTE: You will have to use the .pem file to authenticate to the Server.

# Open up your Terminal / Favorite SSH Client
# If you are facing issues as "Bad Permission" while trying to authenticate, please change the file permission as below;

chmod 600 discord-ec2.pem

Then, run this command to connect to the EC2 Server.

ssh -i "discord-ec2.pem" ubuntu@Your Public iPv4 DNS

Example:

ssh -i "discord-ec2.pem" ubuntu@ec2-18-140-70-118.ap-southeast-1.compute.amazonaws.com

Step 11

Upon successful authentication, you’ll be directly in the Shell of the EC2.

Step 12

Now, let’s prepare our EC2 for some Rock & Roll.

Firstly, let’s update the dependencies. Simply run the command below in your EC2 Instance:

sudo apt-get update && sudo apt-get upgrade -y

Step 13

Hold on right there!

How do we transfer the file from our Local Machine to the EC2?
Well, you “could” find many other ways of transferring the file to the EC2. In this Tutorial, I will be using rsync to transfer the file to the EC2.

Other methods you could consider:
- GitHub (Pull code from EC2)
- SFTP
- More

Let’s now giddy up rsync on our Local Machine. You may install rsync using Homebrew (Mac) or any other Package Manager for your corresponding Platform.

Example (Mac OS):

brew install rsync

Step 14

Once rsync is installed on your local machine, let’s get the files moving.

Simply run the command below

# Please replace the values accordingly when executing.

rsync -azvv --progress -e "ssh -i discord-ec2.pem" \
/path/to/your/code/folder \
ubuntu@ec2-18-140-70-118.ap-southeast-1.compute.amazonaws.com:~/

Now, that your files are on the Server. Quickly, verify the files with the following commands

cd folder
ls -all

Once all files are intact, let’s set up the Python Environment.

Firstly, create the Python Virtual Environment.

cd path/to/your/code/in/the/server
sudo apt install python3.8-venv -y
python3 -m venv venv

Secondly, let’s activate the newly created Virtual Environment & Install the dependencies

source venv/bin/activate
pip install -r requirements.txt

Lastly, assuming you have replaced the Discord Auth Token with a Token attained from Discord’s Developer Portal. Let’s run it

# Simply run the command below

python3 run.py

Conclusion

All the steps listed are curated in such a way where it can be understood and followed along. Rest assured, your Discord Bot should now be online!

Stay Safe. Happy Coding & Happy Deploying!

Let’s now assume we have 100 IAM Access Keys active currently, and rotating them could be nerve-wrecking because in order to rotate them — You must remember them first!w

It’s better to be safe than sorry. Exposing your AWS Access Keys or Secret Access keys are not fun!

Prerequisites

• A GitHub Account

• An AWS Account

Step 1: Create a new GitHub repository

You know the drill. Just create the repository you’d like to test this with on GitHub.

Alternatively, you can use any existing repositories!

Step 2: Login to your AWS Account

Head to https://console.aws.amazon.com and authenticate with your IAM User.

Note: If you are authenticating through AWS SSO — Then, proceed with the respective AWS SSO login page.

Step 3: Prepare your AWS Environment to support OIDC Authentication

1. Head to the AWS IAM OIDC providers page.

2. Click on “Add provider”.

3. Fill / select the following:
   Provider Type: OpenID Connect
   Provider URL: https://token.actions.githubusercontent.com
   ** Click on “Get thumbprint”
   *Audience: sts.amazonaws.com

4. Head to the AWS IAM roles page.

5. Create a new IAM role with the details as below:
   Role Name: Any name you’d prefer
   Role Policy: Any policy you’d prefer. (I am using AdministratorAccess for testing purposes).
   Role Trust Relationship: (As below)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "<YOUR_OIDC_ARN>"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
                    "token.actions.githubusercontent.com:sub": [
                        "repo:<YOUR_GITHUB_ORG>/<YOUR_REPO_NAME>:ref:refs/heads/<YOUR_BRANCH_NAME>"
                    ]
                }
            }
        }
    ]
}

Upon creation of the IAM role with the appropriate configurations as mentioned above, you may now attach the IAM role to the OIDC provider by;

1. Clicking on your OIDC Provider from the OIDC Providers page.

2. Attaching the IAM role by click on the “Assign role” button on the top right of the page.

Step 4: Setting up your GitHub CI/CD workflow configuration

This is a simple GHA workflow, please update wherever neccessary;

name: "Testing CI/CD"
on:
  workflow_dispatch:
permissions:
  id-token: write # This is required for requesting the JWT
  contents: read # This is required for actions/checkout
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Authenticate to AWS
        uses: aws-actions/configure-aws-credentials@v2
        with:
        role-to-assume: <YOUR_AWS_IAM_ROLE_ARN>
        role-session-name: GitHub_to_AWS_via_FederatedOIDC
        aws-region: <YOUR_AWS_REGION>
      - name: GetCallerIdentity (STS)
        run: |
          aws sts get-caller-identity
        - name: S3 (List)
        run: |
          aws s3 ls

Step 5: Let’s test it out

The above is possible with our approach. No Secret Access Key or Access Keys needed in the GH environment.

Conclusion

Now that we have setup and successfully authenticated to our AWS Account through GHA. You may have some questions, and I had too! Let me answer them for you in numbered points.

1. Is this secure?

Yes. Since we created an IAM Role policy in Step 3 of this document. We have limited the scope, so only GitHub repositories that we own in our GH Organization could exchange STS token among themself.

1. How do we handle rotations? Are there anything to rotate?

To be honest, there is nothing to rotate as we are not dealing with any IAM Access Keys or Secret Access Keys as we’re aiming to get rid of them anyways! It is secure in a way where we don’t even need to store the IAM Access Key / Secret Access Key within our local machine related to CI/CD.

1. Can I add more repo to have access to exchange the STS token so they could also use CI/CD?

Definitely! Referring to our IAM role trust relationship policy — You can add multiple repository names in the following format to “token.actions.githubusercontent.com:sub”.

Example:

"token.actions.githubusercontent.com:sub": [
    "repo:InspectorGadget/assume-role-with-oidc:ref:refs/heads/main",
    "repo:InspectorGadget/assume-role-with-oidc:ref:refs/heads/main"
]

#GoodbyeAccessKeys

#OIDCSecurity

#CI_CD

#AWSIAMRoles

#SecureDevOps

#NoMoreKeys

#IdentityAccessManagement

1. An AWS Account

2. Basic knowledge regarding EFS, ASG, LaunchConfig, ALB, and EC2.

3. We’ll be using **t2.micro** instance type as it is under AWS Free Tier, but I will still use Spot Instance :D.

4. We’ll be deploying our instances in **Public Subnet**, using the default VPC inside of AWS that was created for you by default.

5. Basic VPC Knowledge; CIDR, Subnet, Route Tables, etc

#1: Creating your custom EC2 Security Group

SG #1

Name: efs-sg-default
Description: Allows EFS Access
VPC: AWS Default VPC
Inbound rules
1. NFS -> 0.0.0.0/0
Tags
Name -> Allow EFS
Others
Set it as default

SG #2

Name: alb-sg
Description: Allows HTTP Access via ALB (Port 80)
VPC: AWS Default VPC
Inbound rules:
1. HTTP -> 0.0.0.0/0
Tags:
Name -> Allow HTTP for ALB
Others
Set it as default

SG #3

Name: ec2-sg
Description: SG for EC2
VPC: AWS Default VPC
Inbound rules
1. HTTP -> alb-sg (Select SG)
2. SSH -> 0.0.0.0/0
Tags
Name -> SG for EC2
Others
Set it as default

#2: Creating your EFS (Elastic File System)

Configurations:

Name: Website Data
Availability and durability: One Zone
AZ: ap-southeast-1
Automatic backups: Disabled
Lifecycle management: None
Performance mode: General Purpose
Throughput mode: Bursting
Encryption (Data at rest): Turned on
VPC: default
Subnet: Default Subnet (Depending on the AZ selected)
Security Group: Created from #1 (efs-sg-default)

* Leave everything else as default and create your EFS

#3: Creating Launch Template

Name: httpd-template
Auto Scaling guidance: Optional but I have turned it on
AMI: Amazon Linux 2
Instance type: t2.micro (Free tier eligible)
Key pair: Select any existing Key pair, or create a new one.
Security Group: Select “efs-sg-default” & “ec2-sg” SG created from #1
Storage: Default (8 GB)

Advanced Details
Request Spot Instances: Enabled
IAM instance profile: Select any IAM Role if you have

User Data Script:

#!/bin/bash
sudo yum update -y
sudo yum install httpd -y
sudo systemctl start httpd
sudo systemctl enable httpd
sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport “your_efs_ip”:/ /var/www/html

NOTE:
You may need to replace “your_efs_ip”** with the real ID of your EFS which you may find in the AWS Management Console.

#5: Creating Target Groups for ALB

Choose a target type: Instances
Target group name: httpd-tg
Protocol: HTTP -> Port 80
VPC: AWS Default VPC
Health check protocol: HTTP
Health check path: /

Click on “Next”

Register Instances: Do not select any instances

Finally, create the Target Group

#6: Create Application Load Balancer

Name: httpd-alb
Scheme: Internet-facing
IP address type: IPv4
VPC: AWS Default VPC
Subnet Mappings: Select all
Security Group: Created from #1 (allow-http-for-alb)
Target Group: Created from #5 (HTTP: 80 -> httpd-tg)

And create it!

#7: Create Auto Scaling Group

Auto Scaling group name: httpd-asg
Launch template: Created from #4) (httpd-template)
VPC: AWS Default VPC
AZ: Select all
Attach existing Load Balancer: Created from #6 (httpd-alb)
Desired capacity: 2
Minimum capacity: 1
Maximum capacity: 2
Scaling policies: None for now
Instance scale-in protection: Disabled
Tags:
1. Name -> “HTTPD Instance”

And create it!

Upon a success creation of resources in the steps above, you can now visit the URL of your ALB on the browser and enjoy it ! Your website files are now gathered in all the EC2 instances via EFS, and load balanced.

To add a new file, or change something — All you have is to SSH into one of the instances and change the files. It will be automatically reflected across all the other instances.

We all sometimes face issues when trying to create our own IaC Module, so it could be used by you or your Organization itself. It could be stressful, I totally hear you! There could be tons of ideas flowing through your head, and you’d be longing for an answer or ways to fix it. In this story, I’m here to show you an optimal way to completely eliminate the need of you to touch the CLI (Command Line Interface) on your Machine, unless it’s for running the terraform apply or terraform destroy command, well you could still throw these commands onto your GH repo as a pipeline and watch it roll.

So, once again, I’m here to introduce all of you on a most efficient way to run *bash* scripts using Terraform. It is actually simple, but sometimes we overlook things 😢.

Prerequisites

• Terraform

• AWS CLI

Solution

The null_resource acts as any TF resource does, but without doing anything. Weird? You can think of it as a resource so that you can attach provisioners as a last resort for any manual jobs that needs to be executed. And, this is where the local-exec provisioner comes in hand. It allows us to invoke any local shell command / script.

Example:

resource "null_resource" "say_hello_world" {  
  provisioner "local-exec" {  
    command     = "echo 'Hello, world'"  
    interpreter = ["/bin/bash", "-c"]  
  }  
}

However, it is also possible to extend the current script to a newer level.

`resource "null_resource" "say_hello_world" {  
  triggers {  
    shell_hash = "${sha256(file("${path.module}/hello.sh"))}"  
  }`

 provisioner "local-exec" {  
    command     = "./hello.sh"  
    interpreter = ["/bin/bash", "-c"]  
  }  
}

**Anything that runs under the local-exec provisioner can’t be stored in the TF state. If you need some changes to be made, make sure to include the triggers argument. Adding variables to triggers will prompt for new deployment on every variable’s value update.

Conclusion

So, what are you waiting for? Dive right into it!

An example could be found here.

#HappyDesigning

#HappyCoding

#HappyArchitecting