DEV Community: SURYANSH GUPTA

Hands-On AWS CI/CD: CodeBuild, CodeDeploy, CodePipeline & Zero-Downtime Blue/Green Releases

SURYANSH GUPTA — Sat, 06 Jun 2026 15:06:52 +0000

Introduction

If you've ever wondered how production teams ship code dozens of times a day without breaking things (or how they recover fast when they do), the answer almost always comes down to a solid CI/CD pipeline. In this post, I'm going to walk you through exactly how I built one end-to-end on AWS — from pushing code to a Git repository all the way through automated build, test, deploy, rollback, and finally a blue/green deployment strategy.

Here's what the full pipeline looks like at a high level:

Git Push → S3 (source) → AWS CodeBuild (build + test) → AWS CodeDeploy → EC2 (production)
                                    ↑
                           AWS CodePipeline orchestrates it all

Let's go step by step.

Prerequisites

Before diving in, here's what was already in place in this lab environment (you'd provision these yourself in a real project):

An EC2 instance used as a development environment
A self-hosted Gitea SCM (Git-based source control)
An Auto Scaling Group with 2 EC2 production instances
An Application Load Balancer (ALB) targeting those instances
The CodeDeploy Agent pre-installed on production instances
IAM roles for CodeBuild, CodeDeploy, and CodePipeline

The application itself is a simple Node.js + Express app with an AngularJS frontend. It has:

A gulp-based build process
Karma + Jasmine unit tests
A dev mode (port 3000) and production mode (port 8080)

Step 1 — Committing Code to the Git Repository

The first step in any CI/CD pipeline is getting your code into source control. I connected to the EC2 dev instance via EC2 Instance Connect (browser-based SSH — no key pair needed), then:

# Navigate into the app directory and run the tests first
cd app
npm test

# Verify the app runs locally in dev mode
NODE_ENV=development DEBUG=aws-code-services:* npm start
# App is now accessible at http://<EC2-IP>:3000

Once tests passed and the app looked good, I set up Git credentials and pushed to the remote repo:

# Configure Git identity
git config --global user.email student@platform.qa.com
git config --global user.name student
git config --global credential.helper store
echo "http://student:LabPassword123@<SCM-IP>:3000" > ~/.git-credentials

# Clone the empty remote repo
git clone http://<SCM-IP>:3000/student/app-repo.git
cd app-repo

# Copy the app source into the repo
cp -R ../app/. .

# Stage, commit, and push
git add -A
git commit -m "app v1.0"
git push

At this point, app v1.0 is live in the remote SCM repository. The SCM was configured to automatically zip and upload the source to an S3 bucket (code-build-source-*) whenever a push lands — this is the bridge between the self-hosted SCM and CodeBuild, which doesn't natively support self-hosted Git.

Step 2 — Automated Build with AWS CodeBuild

With source code in S3, AWS CodeBuild picks it up and runs the build. The entire build is defined in a buildspec.yml file at the root of the project:

version: 0.2

phases:
  install:
    runtime-versions:
      nodejs: 18
    commands:
      - npm install   # Install ALL dependencies (including dev)

  pre_build:
    commands:
      - npm test      # Run automated unit tests
      - npm prune --production  # Remove dev dependencies

  build:
    commands:
      - npm run build # Production build via gulp (minification, bundling)

artifacts:
  files:
    - '**/*'          # Package everything for CodeDeploy

What's happening in each phase:

Phase	What it does
`install`	Pulls in the Node.js runtime and installs all npm dependencies
`pre_build`	Runs unit tests; if they fail, the build stops here. Then strips dev deps.
`build`	Runs the gulp production build — minifies and bundles frontend assets
`artifacts`	Packages the entire working directory into a ZIP and uploads to S3

The CodeBuild project was configured to:

Use an AWS-managed Docker container (no infrastructure to manage)
Store build artifacts in a dedicated S3 bucket (code-build-artifacts-*)
Log everything to Amazon CloudWatch Logs for debugging

I triggered a manual build to verify the setup, watched the phase details, and confirmed the artifact landed in S3. ✅

Step 3 — Configuring AWS CodeDeploy

This is where the actual deployment to EC2 happens. CodeDeploy uses an appspec.yml at the project root to know how to deploy:

version: 0.0
os: linux

files:
  - source: /
    destination: /home/ec2-user/app

hooks:
  ApplicationStop:
    - location: scripts/stop_server.sh
      timeout: 300

  ApplicationStart:
    - location: scripts/start_server.sh
      timeout: 300

  ValidateService:
    - location: scripts/validate_service.sh
      timeout: 300

The lifecycle hooks are critical:

ApplicationStop — gracefully stops any running instance of the Node server
ApplicationStart — starts the server in production mode on port 8080
ValidateService — curls port 8080 and fails the deployment if the app doesn't respond

If any hook script returns a non-zero exit code, CodeDeploy fails the deployment and triggers a rollback automatically.

Creating the Deployment Application and Groups

In the CodeDeploy console, I created an application named lab-app and two deployment groups:

In-place deployment group (in-place):

Targets the Auto Scaling Group (lab-app-prod-asg)
Uses CodeDeployDefault.OneAtATime — updates one instance at a time, keeping the other serving traffic
ALB integration with connection draining enabled
Automatic rollback on failure ✅

Blue/green deployment group (blue-green):

Same ASG and ALB configuration
CodeDeploy provisions fresh EC2 instances for every deployment (no config drift)
Original instances kept running until cutover completes
Traffic switches via the ALB — zero downtime
Automatic rollback on failure ✅

Step 4 — Wiring It All Together with AWS CodePipeline

CodePipeline is the orchestrator that connects source → build → deploy into a single automated workflow.

I created a pipeline named lab-app with these stages:

[Source] → [Build] → [Production]
  S3         CodeBuild   CodeDeploy (in-place)

Pipeline configuration highlights:

Source stage: Watches the S3 bucket (code-build-source-*) for source.zip changes. When a new zip lands, the pipeline fires.
Build stage: Delegates to the lab-app CodeBuild project. The output BuildArtifact is passed downstream.
Production stage: I added this manually after creating the pipeline (you can't rename stages, so skip the default "Deploy" to avoid the misleading label). It runs a CodeDeploy action pointing at the lab-app application and in-place deployment group. Automatic rollback on stage failure is enabled.

One important note: the Pipeline checks S3 periodically for changes. In production, you'd configure EventBridge (CloudWatch Events) for near-instant triggers, or use a native SCM integration if you're on GitHub, GitLab, or BitBucket.

Step 5 — Following a Successful Deployment

With the pipeline in place, I triggered it manually via Release change and watched each stage:

Source → Succeeded (green) — latest source.zip pulled from S3
Build → Succeeded — CodeBuild ran all phases, artifact uploaded
Production → In Progress — CodeDeploy started the in-place rollout

Clicking into the CodeDeploy deployment view showed the lifecycle events per instance in real time:

BeforeAllowTraffic → ApplicationStop → ApplicationStart → ValidateService → AfterAllowTraffic

Since OneAtATime was configured, one instance was taken out of the ALB at a time, upgraded, validated, then returned to service before the second instance was touched. The app stayed available throughout.

Final verification: I grabbed the ALB DNS name and loaded it in the browser. No "development mode" banner — confirmed production mode. Refreshing showed different server IPs alternating, proving both instances were serving traffic behind the load balancer. ✅

Step 6 — Intentional Failure and Automatic Rollback

This is where it gets interesting. I simulated a bad deployment by pushing v1.1 — a version where someone accidentally changed the server's listening port from 8080 to 80.

cp -R commits/v1_1/. app-repo/
cd app-repo
git add -A
git commit -m "app v1.1"
git push

The pipeline triggered automatically. CodeBuild passed (the unit tests didn't catch a port misconfiguration — a realistic scenario). The deployment reached the ValidateService hook, which tried to curl localhost:8080... and got a connection refused.

What happened next, automatically:

ValidateService script failed → deployment failed on instance 1
CodeDeploy's OneAtATime config meant instance 2 was skipped — it never received the broken version
CodeDeploy triggered an automatic rollback — a new deployment was initiated using the last successful revision
The rollback deployment showed Initiating event: codeDeployRollback in the deployment history

The app was never fully broken in production. Only one instance briefly served the broken version, and it was rolled back before any real user impact. This is exactly why the ValidateService hook exists — your automated unit tests can't catch everything, but a post-deploy smoke test can.

Step 7 — Blue/Green Deployment

Finally, I switched the pipeline to use the blue-green deployment group and pushed v1.2 — a legitimate new feature (message emphasis toggles in the accumulator app).

cp -R commits/v1_2/. app-repo/
cd app-repo
git add -A
git commit -m "app v1.2"
git push

The blue/green deployment flow:

New (green) instances provisioned — CodeDeploy creates fresh EC2 instances from the ASG configuration
App installed on green instances — v1.2 deployed and validated on the new instances
Traffic rerouted — ALB gradually shifts traffic from blue (original) to green (new), OneAtATime
Original (blue) instances retained — kept running for rollback capability

Watching the CodeDeploy console during this was genuinely satisfying: you could see the replacement instances appear, the lifecycle events complete, and traffic start routing to them — while the original instances continued serving users without interruption.

Final verification: Refreshed the app. New feature (emphasis toggles) was visible. Server IPs in the bottom corner were different from before — confirming entirely new instances were serving traffic, not the same ones from the in-place deployment. That's immutable infrastructure in action.

Key Takeaways

Concept	What You Learned
`buildspec.yml`	Defines CodeBuild phases: install → pre_build → build → artifacts
`appspec.yml`	Defines CodeDeploy lifecycle hooks: stop → start → validate
In-place deployment	Rolling update on existing instances; faster but risks config drift
Blue/green deployment	New instances every time; zero-downtime cutover; immutable infra
Automatic rollback	`ValidateService` hook + rollback config = self-healing pipeline

Architecture Diagram

Developer (EC2 dev-instance)
        │
        │ git push
        ▼
    SCM (Gitea)
        │
        │ webhook → uploads source.zip
        ▼
    Amazon S3 (source bucket)
        │
        │ triggers CodePipeline
        ▼
  AWS CodePipeline
   ┌────┴────────────────────────────────┐
   │                                     │
[Source]     [Build]              [Production]
  S3    →  CodeBuild        →    CodeDeploy
           (build + test)        (in-place or
           artifact → S3          blue/green)
                                      │
                              ┌───────┴───────┐
                              │               │
                           Instance 1    Instance 2
                           (EC2, prod)   (EC2, prod)
                              └───────┬───────┘
                                      │
                           Application Load Balancer
                                      │
                                   Users

What's Next

This pipeline covers the core CI/CD loop. From here, you could extend it with:

Manual approval stage in CodePipeline before production (for regulated environments)
SNS notifications on pipeline success/failure
CloudWatch alarms tied to CodeDeploy to trigger rollbacks on metrics (not just script failures)
EventBridge rules for instant pipeline triggers instead of S3 polling
Parameter Store / Secrets Manager integration in the buildspec for managing environment variables securely

Built as part of the AWS CI/CD hands-on lab. Published under the AWS Builders community.

Tags: #aws #devops #cicd #codepipeline #codedeploy #codebuild #cloud #awscommunity

I Built a Bot That Updates My EKS Nodes While I Sleep — Here's How

SURYANSH GUPTA — Sat, 30 May 2026 10:03:45 +0000

TL;DR: Manual EKS AMI updates are slow, risky, and easy to forget. I wired together EventBridge, Lambda, Amazon Bedrock (Claude 3.5 Haiku), GitHub PRs, ArgoCD, and Karpenter into a pipeline that detects new AMIs, runs AI risk analysis, opens a PR for human review, and rolls out nodes automatically — zero downtime, full audit trail.

The problem every EKS team hits eventually

You're running production Kubernetes on AWS. You know you're supposed to keep worker nodes patched. But between sprints, incidents, and everything else — checking for new EKS-optimized AMIs falls through the cracks.

When you finally do an update, there's a whole ritual: find the new AMI ID, read through the release notes, assess any CVEs, draft a PR, wait for approvals, then carefully roll out nodes without taking down your workloads.

It's not rocket science — it's just slow, manual, and one of those tasks that always feels lower priority than the thing currently on fire.

What if the whole thing ran itself?

The solution in one sentence

Twice a day, a Lambda checks for new EKS AMIs. If one exists, Bedrock analyzes the risk and opens a GitHub PR. A human reviews it. Merging the PR triggers ArgoCD + Karpenter to roll out the new nodes with zero downtime.

The magic is that the only thing a human needs to do is read the AI's analysis and merge (or close) the PR. Everything else — detection, analysis, branch creation, notification, node rollout — is automated.

Architecture: Three clean phases

Phase 1 — Detection

An EventBridge scheduled rule fires at 9 AM and 9 PM UTC every day. It triggers a Lambda that:

Queries AWS SSM Parameter Store for the latest EKS-optimized AMI ID (/aws/service/eks/optimized-ami/1.34/amazon-linux-2023/recommended/image_id)
Compares it against what's currently committed in your GitHub repository (your source of truth)
If they differ — new AMI exists → triggers the Step Functions workflow

No new AMI? The Lambda exits quietly. Nothing else happens.

Phase 2 — AI Analysis + Pull Request

This is where it gets interesting. AWS Step Functions orchestrates three Lambda functions in sequence:

Lambda 1 — bedrock-analyzer

Fetches the real AMI release notes from GitHub (awslabs/amazon-eks-ami) and sends them to Amazon Bedrock running Claude 3.5 Haiku with this prompt:

Analyze this Amazon EKS AMI update using the actual release notes.
New AMI ID: {ami_id}
Previous AMI ID: {previous_ami}

ACTUAL EKS AMI RELEASE NOTES:
{release_notes}

Respond in JSON with:
- risk_score: 1–10
- recommendation: APPROVE or REJECT
- summary: one-line summary of actual changes
- pr_description: full markdown PR body with CVEs, package versions,
  risk assessment, and review guidance

The output is a structured JSON object with a risk score and a ready-to-paste PR description.

Lambda 2 — gitops-updater

Uses GitHub App credentials (stored in AWS Secrets Manager) to:

Create a new branch
Update the Karpenter EC2NodeClass YAML with the new AMI ID
Open a Pull Request with the full Bedrock analysis embedded in the description

Lambda 3 — send-notification

Fires an SNS email to the team: "New AMI detected, PR #N is open for your review." Includes the PR link and the one-line AI summary.

The human's job: Read the AI analysis. Check the YAML diff (it's literally one line — the AMI ID). Merge to approve, close to reject.

Phase 3 — GitOps Deployment

After the PR is merged:

ArgoCD detects the commit on main, auto-syncs the updated EC2NodeClass manifest to the EKS cluster
Karpenter sees the new AMI ID in the EC2NodeClass, provisions new EC2 nodes with the updated AMI, then gracefully drains the old nodes
Workloads migrate to new nodes. Zero downtime.

The whole rollout happens without anyone touching kubectl.

What the PR actually looks like

This is what your team sees in GitHub:

## EKS AMI Update — ami-04b406d4e6eaca578

**AI Risk Score: 2/10 — APPROVE**

### What changed
- Go updated to 1.25.9
- Kernel updated to 6.12.79-101.147.amzn2023
- No new CVEs introduced

### CVE Assessment
No critical or high-severity CVEs in this update. Two previously
known CVEs (CVE-2024-XXXX, CVE-2024-YYYY) are patched.

### Review guidance
This is a routine kernel + runtime update. Low risk. Recommend
merging during business hours with normal monitoring in place.

---
*Merge this PR to trigger ArgoCD + Karpenter rollout.*
*Close this PR to skip this AMI version.*

Your reviewer doesn't need to dig through release notes. The AI already did it.

CloudFormation: everything in one stack

The whole solution deploys from a single CloudFormation template. Here's what it provisions:

Resource	Purpose
AWS Secrets Manager	GitHub App credentials
Amazon SNS + subscription	Email alerts
5 IAM roles	Per-function least-privilege
4 Lambda functions	Detector, analyzer, PR creator, notifier
Amazon Bedrock Guardrail	Content filtering on AI output
Step Functions state machine	Orchestrates analyze → PR → notify
EventBridge rule	Twice-daily schedule

Deploy it:

aws cloudformation create-stack \
  --stack-name eks-ami-update \
  --template-body file://cloudformation-template.yaml \
  --capabilities CAPABILITY_NAMED_IAM \
  --parameters \
    ParameterKey=NotificationEmail,ParameterValue=your@email.com \
    ParameterKey=GitHubAppId,ParameterValue=<app-id> \
    ParameterKey=GitHubAppInstallationId,ParameterValue=<install-id> \
    ParameterKey=GitHubAppPrivateKey,ParameterValue=$(base64 -i app.pem | tr -d '\n') \
    ParameterKey=GitHubRepoOwner,ParameterValue=<your-org> \
    ParameterKey=GitHubRepoName,ParameterValue=<your-repo> \
    ParameterKey=GitHubFilePath,ParameterValue=karpenter-configs/clusters/your-cluster/nodeclass.yaml \
    ParameterKey=GitHubBranch,ParameterValue=main \
    ParameterKey=EKSVersion,ParameterValue=1.34

Takes about 2–3 minutes. Confirm the SNS subscription email when it arrives.

Prerequisites checklist

Before deploying, you need:

[ ] An existing EKS cluster (v1.34+)
[ ] Karpenter installed and configured
[ ] ArgoCD installed with auto-sync enabled
[ ] A GitHub repository for Karpenter configs
[ ] A GitHub App installed on that repo (you need App ID, Installation ID, and Private Key)
[ ] Amazon Bedrock enabled in your region (enable Claude 3.5 Haiku access in the Bedrock console)
[ ] AWS CLI + kubectl configured

Important: Fork the aws-samples repository to your own account — you need write access to configure the GitHub App. Deploy your EC2NodeClass config to the repo before running the stack.

Testing it without waiting for an AMI release

Don't want to wait up to 12 hours for the schedule to fire? Trigger it manually:

aws lambda invoke \
  --function-name eks-ami-detector \
  --payload '{}' \
  --cli-binary-format raw-in-base64-out \
  /tmp/response.json && cat /tmp/response.json

Check your inbox. You should get an SNS email with the risk analysis and PR link within a couple of minutes.

After merging, verify the ArgoCD sync:

# Update your kubeconfig
aws eks update-kubeconfig --region <region> --name <cluster-name>

# Check ArgoCD sync policy
kubectl get application karpenter-nodeclass -n argocd \
  -o jsonpath='{.spec.syncPolicy}'

# Verify the AMI ID was applied
kubectl get ec2nodeclass default -o yaml | grep ami-

Common issues and how to fix them

SNS subscription not confirmed — Check your spam folder. The confirmation email comes from AWS and sometimes gets filtered.

GitHub App auth failure — Double-check the App is installed on the correct repository with read/write permissions. Regenerate the private key in GitHub if needed and re-run the CloudFormation update.

Bedrock access denied — Go to the Amazon Bedrock console → Model access → enable Claude 3.5 Haiku in your region. This is a manual step that's easy to miss.

ArgoCD not syncing — Verify the Application resource has spec.syncPolicy.automated set. Check that the repo URL and path match exactly.

Step Functions failures — Check CloudWatch Logs for the failing Lambda. 99% of the time it's an IAM permission issue or a missing secret.

Why this architecture is worth copying

A few design decisions I want to highlight:

GitHub PRs as the approval interface — Engineers already live in GitHub. Using a PR as the human gate means no new tool to learn, built-in commenting, and a permanent audit trail in Git history. The PR description IS the change record.

AI analysis on real release notes — The Bedrock prompt fetches actual release notes from the awslabs/amazon-eks-ami repo. It's not making things up — it's summarizing real content. The risk score is grounded in actual CVE and package data.

Karpenter over managed node groups — Karpenter watches the EC2NodeClass for changes and handles the node lifecycle automatically. You don't need to write any drain/cordon scripts.

Least-privilege IAM — Each Lambda has its own role with only the permissions it needs. The CF template provisions five separate roles. This matters in production.

Guardrails on Bedrock — The solution includes a Bedrock Guardrail for content filtering on the AI output. Belt and suspenders.

Cleaning up

aws cloudformation delete-stack --stack-name eks-ami-update

What I'd add next

A few things that would make this even better:

Slack notification instead of (or in addition to) SNS email — PR link directly in your #platform channel
Dry-run mode — run the full pipeline but don't actually open a PR, just log the analysis
Multi-cluster support — one stack managing AMI updates across dev/staging/prod with different approval thresholds per environment
Custom risk criteria — tune the Bedrock prompt to your org's specific compliance requirements (PCI-DSS, SOC 2, etc.)
Automatic REJECT on critical CVEs — skip the PR entirely and alert the team if the risk score is 8+

Get the code

Fork the repo, follow the README, and deploy:

👉 GitHub: suryansh639/sample-eks-ami-gitops-pipeline

The CloudFormation template, Lambda code, and example Karpenter configs are all there.

Wrapping up

The goal wasn't to remove humans from the loop — it was to remove the boring part of the loop. The AI reads the release notes. The AI writes the PR description. The human decides. The automation executes.

That's the right split. And it means your nodes actually get updated on time, every time, with a full audit trail and no 2 AM surprises.

If you try this out, drop a comment — I'd love to hear what customizations you make.

What Is an Agent Harness? And Why Every AI Agent Needs One

SURYANSH GUPTA — Sat, 09 May 2026 07:28:09 +0000

If you've spent any time building with AI lately, you've probably heard the word "agent" thrown around a lot. But here's something that doesn't get talked about nearly as much: before you can have a real AI agent, you need a harness.

I know that term might sound unfamiliar or even a little abstract. When I first came across it, I had the same reaction. But once it clicked, I couldn't unsee it — and I genuinely think it's one of the most important concepts to understand if you want to go beyond just calling an LLM API and actually building something that does things autonomously.

Let's break it all down from scratch.

The Problem With "Just Using a Model"

Picture this: you've got API access to a powerful model like Claude or GPT-4. You send it a prompt, it sends back a response. That's great for chatbots and one-shot completions — but what if you want the model to:

Browse the web and pull real-time data?
Execute Python code to analyze that data?
Remember what you told it last week?
Coordinate across multiple steps — each one depending on the last?
Call your internal APIs or tools?

A raw model, on its own, can't do any of that. It can talk about doing those things, but it has no way to actually carry them out. It's like hiring a brilliant analyst who has no laptop, no internet, and can only communicate by passing notes. The intelligence is there — the infrastructure is not.

That missing infrastructure is the harness.

So, What Exactly Is an Agent Harness?

An agent harness is everything you build around a model to transform it from a text-generator into an agent that can act in the real world.

The cleanest formula I've come across is:

Agent = Model + Harness

Anything in your agent that isn't the model itself — is part of the harness.

In concrete terms, the harness typically includes:

The orchestration loop — the logic that takes a user message, asks the model what to do, runs that action, feeds the result back, and repeats until the task is complete.
Tool connections — the plumbing that lets the model call a browser, run code, query a database, or hit an external API.
Memory — short-term context within a session AND long-term memory that persists across sessions.
Context management — deciding what information goes into the prompt at each step (you can't just keep appending forever — models have token limits).
Compute and sandboxing — somewhere safe for the agent to run code without blowing up your system.
Authentication — so your agent can securely call external APIs without leaking credentials.
Observability — logs, traces, and debugging tools so you know what happened when things go sideways at 2 AM.
Session management — the ability for users to pause and resume, pick up right where they left off.

Look at any AI-powered product you use today — Claude Code, GitHub Copilot, Cursor, Perplexity — and behind the scenes, there's a harness doing all of this work. The model is just one piece of a much larger machine.

Why Harness Building Has Been So Painful

Here's the honest reality: building a harness from scratch is hard and time-consuming.

If you've done it before, you know the drill. You pick a framework — LangGraph, LlamaIndex, CrewAI, Strands Agents — and start writing code. You wire up your tools. You manage your prompt structure carefully so the model doesn't get confused. You add error handling for when tool calls fail. You build retry logic. You handle streaming output. You set up logging. You package everything into a container, provision some compute, and deploy it.

And then you realize you need session persistence. So you add a database. And then you realize you need the agent to authenticate with an external API. So you set up credential management. And now you need to understand why the agent went down a weird reasoning path, so you add tracing.

For a straightforward use case, this might take a few days. For a complex one, it could take weeks — and a whole team.

This is the real barrier to building with AI agents. Not the model. The harness.

Enter Managed Harnesses: The Agent Factory Model

Tooling has finally started catching up to this problem. The idea behind a managed harness is simple: instead of writing all that orchestration and infrastructure code yourself, you declare what your agent needs as configuration, and the service builds the harness for you.

Think of it like the difference between setting up your own server (writing harness code from scratch) versus using a managed cloud service (declaring config and letting the platform handle the rest).

Amazon Bedrock AgentCore is one of the services taking this approach. With AgentCore's harness feature, you define your agent in a JSON config file — model, system prompt, tools, memory settings — and the platform compiles that into a fully running agent, handling all the infrastructure underneath.

Under the hood, AgentCore harness uses Strands Agents (AWS's open-source agent SDK) to assemble the orchestration loop, tool execution, memory management, context handling, and streaming. Then it runs the whole thing inside an isolated microVM — its own dedicated CPU, memory, and filesystem — without you provisioning a single server.

Let's Build Something: An AI Trends Analyst in Minutes

To make this concrete, here's how you'd go from zero to a working AI agent using AgentCore harness — and yes, this genuinely takes about 5 minutes.

The Goal

Build an agent that browses HackerNews and dev.to, pulls today's top AI and developer tools posts, clusters them by topic, and produces a ranked summary with a chart — all autonomously.

Step 1: Install the CLI

npm install -g @aws/agentcore@preview

Step 2: Create Your Agent Config Interactively

agentcore create

This command walks you through a set of prompts — which model to use, which tools to enable, authentication type, and so on. At the end, it generates a config file like this:

{
  "name": "TrendsAgentHarness",
  "model": {
    "provider": "bedrock",
    "modelId": "global.anthropic.claude-sonnet-4-6"
  },
  "tools": [
    {
      "type": "agentcore_browser",
      "name": "browser"
    },
    {
      "type": "agentcore_code_interpreter",
      "name": "code-interpreter"
    }
  ],
  "skills": [],
  "authorizerType": "AWS_IAM"
}

That's it. The browser tool lets the agent navigate real websites. The code interpreter gives it a Python sandbox to crunch data and generate charts.

Step 3: Write Your System Prompt

Edit the system-prompt.md file that was created alongside the config:

Your job is to keep a pulse on what the AI and dev community is buzzing 
about right now. Every session, head over to HackerNews and dev.to, 
scrape today's hottest posts, then use the code interpreter to make sense 
of it all — cluster the topics, rank them by how often they show up, and 
summarize the top 5 in plain language. Throw in a bar chart. No fluff.

The system prompt is your agent's personality and operating instructions. This is where you define what it does, how it thinks, and what output you expect from it.

Step 4: Deploy It

agentcore deploy

Behind the scenes, this takes your config and system prompt, assembles a Strands Agents program, and deploys it into a managed microVM environment. No Dockerfile, no Kubernetes, no EC2 instance. Just one command.

Step 5: Invoke It

agentcore invoke --harness TrendsAgentHarness \
  --session-id "$(uuidgen)" \
  "What's trending in IT today?"

What happens when you run this:

The agent opens a browser and navigates to HackerNews.
It scrolls through and reads the top posts.
It does the same on dev.to.
It pulls all the results into the code interpreter.
It runs Python to cluster topics, calculate frequency, and build a bar chart.
It streams a formatted summary back to your terminal.

All of this runs in an isolated microVM that spins up for this session and tears down when it's done. No cross-session data leakage, no noisy neighbors.

What Comes Built In

Here's a breakdown of what AgentCore harness gives you without any extra setup:

Capability	What It Actually Means For You
Isolated microVM per session	Your agent gets its own CPU, memory, and filesystem. Sessions are completely isolated from each other.
Shell access	The agent can run shell commands directly without going through the model's reasoning loop — faster and cheaper.
Persistent filesystem	Mid-session, the agent can save files, pause, and resume exactly where it left off.
Model-agnostic routing	Switch between Bedrock, OpenAI, and Google Gemini. You can even change providers mid-session and the conversation context stays intact.
Built-in browser tool	Powered by AgentCore Browser — the agent can navigate real websites, not just search APIs.
Built-in code interpreter	A full Python sandbox. The agent can write and execute code, generate charts, process files, and more.
MCP server support	Connect to any MCP-compatible tool server — Slack, Notion, GitHub, whatever your workflow needs.
AgentCore Gateway	Connect to APIs you've registered centrally, so credentials are managed outside the agent.
Custom tool definitions	Define your own inline function tools for the agent to call.
Skills	Package domain knowledge as markdown + scripts and give your agent expert-level context on demand.
Full observability	Every action is auto-traced via AgentCore Observability, so you can debug and audit everything that happened.

Agent Skills: Teaching Your Agent Domain Expertise

One feature worth calling out specifically is skills. An agent skill is a bundle of markdown instructions and (optionally) scripts that gives your agent deep knowledge about a specific domain or workflow.

Think of it this way: you can train a general model on your specific context. For example:

A skill that teaches the agent how to work with your internal data format.
A skill that walks the agent through your company's API conventions.
A skill that gives the agent step-by-step knowledge of how to process Excel reports your way.

You package the skill into the agent's environment, point the harness at it, and the agent picks it up and uses it automatically when relevant. No fine-tuning. No custom model training. Just structured knowledge the agent can reference.

The Escape Hatch: When You Outgrow Config

One question you might be asking: "What happens when my use case gets complex enough that a config file isn't enough?"

That's a fair and important question. Maybe you need:

Custom multi-agent orchestration where agents hand off tasks to each other.
Specialized routing logic based on the content of a message.
A fully custom memory layer with your own vector database.
Integration with internal infrastructure that doesn't fit a standard pattern.

AgentCore harness has an answer for this: export to code.

When you need full control, you can export your harness configuration to Strands Agents code. You get the equivalent Python program that AgentCore was running for you — fully readable, fully editable — and you can extend it however you need. You stay on the same platform, just with more control.

This is a smart design. You start with the fast path (config), and you graduate to the custom path (code) only when you actually need it. You're not locked into one or the other.

Common Questions Answered

Do I need to build a harness if I'm just using Claude.ai or ChatGPT?

No. Those are consumer products where someone else already built the harness for you. You need to build your own when you're creating custom agents — ones that call your specific tools, connect to your internal systems, maintain state, or run autonomously over multiple steps.

Is a harness the same as an agent framework?

Not quite. A framework (like Strands Agents, LangGraph, or CrewAI) gives you the building blocks — tool interfaces, loop patterns, model connectors. A harness is the fully assembled, running system: framework code plus compute, sandboxing, memory, auth, and observability. You use a framework to build a harness, or you use a managed service to build one for you.

Can I build a harness without a framework?

Technically yes, but you'd be writing the entire orchestration loop, tool dispatch, error recovery, and context management from scratch. Frameworks exist precisely so you don't have to. It's a bit like writing raw socket code instead of using Express.js — possible, but almost never the right call.

Is the browser tool expensive on tokens?

Yes, it does consume more tokens than simpler tools since it's processing full web pages. For the trends analyst use case, it's absolutely worth it. For agents that need lighter-weight data fetching, you might want to explore API-based tools or MCP servers that return structured data instead.

Why This Matters for the Community

For a long time, building a production-grade AI agent required deep expertise across model APIs, orchestration frameworks, cloud infrastructure, and security. That's a lot of disciplines to combine, and it's been a genuine barrier for developers who want to experiment and build.

Managed harness services like AgentCore change that equation. The gap between "I have an idea for an agent" and "I have a running agent" is now measured in minutes for straightforward use cases. That's genuinely exciting.

It also means the interesting work shifts. Instead of spending your energy on infrastructure plumbing, you can focus on:

What should your agent actually do?
What domain knowledge does it need?
What tools should it have access to?
How should it reason and communicate?

Those are the questions worth spending your time on.

Where to Go From Here

AgentCore harness is currently in public preview in four AWS regions: US West (Oregon), US East (N. Virginia), Europe (Frankfurt), and Asia Pacific (Sydney).

Here are the resources to get started:

The trends analyst agent described in this post — browsing HackerNews, clustering AI topics, generating a chart — took about 5 minutes from idea to first working invocation. The JSON config is 15 lines. The system prompt is 5 lines.

What would you build with 5 minutes and a config file? I'd love to see what the community comes up with. Drop your ideas or experiments in the comments.

If this post helped you understand agent harnesses better, consider sharing it with someone who's been struggling to wrap their head around the agent architecture puzzle. And if you're already building harnesses the hard way, maybe it's time to let the factory do some of that work for you.

Cut Amazon Bedrock Costs with a 3-Layer Caching Pipeline on AWS Lambda + ElastiCache

SURYANSH GUPTA — Tue, 05 May 2026 03:46:22 +0000

If you're building AI-powered apps on AWS, you've probably felt the sting of Bedrock inference costs. Every token counts — and when users hammer your app with similar or identical questions, you're paying for the same answer over and over again.

In this post I'll walk through a three-layer caching and optimization pipeline I built inside a single Lambda function backed by ElastiCache (Redis). By the end, you'll have a pattern that can dramatically reduce Bedrock calls in any support chatbot, internal knowledge assistant, or document Q&A tool you're shipping.

Here's what we're building:

User prompt → Hash Check → Semantic Check → Prompt Compression → Bedrock → Cache Write
                  ↓               ↓
             hash_hit        semantic_hit

Architecture at a Glance

Component	Role
AWS Lambda (Python)	Caching logic, embedding, compression
Amazon ElastiCache (Redis 7.1)	Persistent shared memory across invocations
Amazon Bedrock (Nova Micro)	Foundation model, only called on a true miss
Titan Embeddings v2	Converts prompts to semantic vectors

Because Lambda is stateless, every invocation starts fresh with zero memory of prior calls. ElastiCache fills that gap — it's the shared brain that persists across invocations and across different users hitting your function simultaneously.

Layer 1 — Hash-Based Caching: The Fastest Win

Before anything touches Bedrock, we check whether we've already answered this exact question.

The trick is normalizing the prompt first — lowercase, collapse whitespace — so " What is MACHINE LEARNING? " and "what is machine learning?" produce the same SHA-256 fingerprint and share one cache entry.

def normalize(prompt: str) -> str:
    return " ".join(prompt.lower().split())

def compute_hash(prompt: str) -> str:
    return hashlib.sha256(normalize(prompt).encode()).hexdigest()

On every invocation, we check Redis with the hash: prefix before doing anything else:

hash_key = HASH_PREFIX + compute_hash(prompt)
cached = redis_client.get(hash_key)
if cached:
    return {"response": cached, "cache": "hash_hit"}

A hash hit costs you a single Redis GET — no embedding call, no Bedrock invocation, no tokens burned. This is the fastest and cheapest path through the entire pipeline.

When does this shine? Any FAQ-style workload where users repeatedly ask the same questions. Support bots. Help center chatbots. Internal HR assistants.

Layer 2 — Semantic Similarity Caching: Catching Paraphrases

Hash-based caching misses paraphrases. "What is machine learning?" and "How would you define machine learning?" are semantically identical but produce completely different hashes.

Semantic caching solves this with vector embeddings. We convert every prompt to a list of floats that encodes its meaning, then compare incoming prompts to stored vectors using cosine similarity.

def embed(prompt: str) -> np.ndarray:
    bedrock = boto3.client("bedrock-runtime", region_name="us-west-2")
    response = bedrock.invoke_model(
        modelId=EMBED_MODEL_ID,
        body=json.dumps({"inputText": prompt}),
        contentType="application/json",
        accept="application/json"
    )
    body = json.loads(response["body"].read())
    return np.array(body["embedding"], dtype=np.float32)

def cosine_similarity(a: np.ndarray, b: np.ndarray) -> float:
    norm_a, norm_b = np.linalg.norm(a), np.linalg.norm(b)
    if norm_a == 0 or norm_b == 0:
        return 0.0
    return float(np.dot(a, b) / (norm_a * norm_b))

Since Redis stores bytes, not arrays, we serialize the vector with struct.pack before writing and unpack it on read:

def serialize_embedding(vector: np.ndarray) -> bytes:
    return struct.pack(f"{len(vector)}f", *vector)

def deserialize_embedding(data: bytes) -> np.ndarray:
    n = len(data) // 4
    return np.array(struct.unpack(f"{n}f", data), dtype=np.float32)

In the handler, after a hash miss we embed the incoming prompt and scan stored vectors:

query_vector = embed(prompt)
stored = load_embeddings()
best_score, best_response = 0.0, None

for _, vector, response in stored:
    score = cosine_similarity(query_vector, vector)
    if score > best_score:
        best_score = score
        best_response = response

if best_score >= SIMILARITY_THRESHOLD:
    return {"response": best_response, "cache": "semantic_hit", "score": round(best_score, 4)}

The SIMILARITY_THRESHOLD environment variable (default 0.90) is your dial for how aggressive the matching should be. Lower it to 0.80 and you'll catch more paraphrases at the risk of serving a slightly off response. Tune it against your own traffic.

💡 In practice, I've seen semantic_hit catch prompts like "Explain ML to me" against a cached answer for "What is machine learning?" with a score around 0.94 — well above threshold, and a completely avoided Bedrock call.

Layer 3 — Prompt Compression: Saving Tokens on Every Miss

Even with two cache layers, some prompts will always be new. Prompt compression squeezes cost out of every genuine cache miss by stripping filler language before the prompt reaches Bedrock.

Filler phrases like "Could you please", "I was wondering if", or "As an AI language model" consume tokens without improving the model's response. We maintain a simple list and strip them at runtime:

FILLER_PHRASES = [
    "please could you",
    "i was wondering if",
    "could you please",
    "i would like you to",
    "as an ai",
    "can you please",
    # ... extend this list based on your traffic patterns
]

def compress(prompt: str) -> str:
    compressed = prompt.lower()
    for phrase in FILLER_PHRASES:
        compressed = compressed.replace(phrase, "")
    compressed = " ".join(compressed.split())

    original_tokens = len(prompt.split())
    compressed_tokens = len(compressed.split())
    print(f"[compression] original: {original_tokens} tokens, "
          f"compressed: {compressed_tokens} tokens, "
          f"saved: {original_tokens - compressed_tokens}")

    return compressed

The CloudWatch log line gives you a measurable view of the savings on every miss — you can query these logs over time to identify your most common filler patterns and keep optimizing the list.

One critical design decision: compression runs after both cache checks, not before.

If you compressed first, you'd alter the prompt before hashing it — so "Could you please explain ML?" and "Explain ML" would hash to the same key on the second call but different keys on the first, breaking cache consistency. The original prompt is always used for cache lookups; compression is purely a token cost optimization that only fires when a Bedrock call is actually going to happen.

The Full Pipeline in `lambda_handler`

Putting it all together, the handler becomes a clean sequential pipeline:

def lambda_handler(event, context):
    prompt = event.get("prompt", "").strip()

    # Layer 1: Exact hash match — fastest path, zero AI calls
    hash_key = HASH_PREFIX + compute_hash(prompt)
    cached = redis_client.get(hash_key)
    if cached:
        return {"response": cached.decode(), "cache": "hash_hit"}

    # Layer 2: Semantic similarity — catches paraphrases
    query_vector = embed(prompt)
    stored = load_embeddings()
    best_score, best_response = 0.0, None
    for _, vector, response in stored:
        score = cosine_similarity(query_vector, vector)
        if score > best_score:
            best_score, best_response = score, response
    if best_score >= SIMILARITY_THRESHOLD:
        return {"response": best_response, "cache": "semantic_hit", "score": round(best_score, 4)}

    # Layer 3: Compress before sending to Bedrock
    compressed_prompt = compress(prompt)
    response_text = call_bedrock(compressed_prompt)

    # Write back both hash and embedding for future hits
    redis_client.set(hash_key, response_text.encode(), ex=CACHE_TTL_SECONDS)
    embed_key = EMBED_PREFIX + compute_hash(prompt)
    store_embedding(embed_key, query_vector, response_text)

    return {"response": response_text, "cache": "miss"}

Key Observations from Testing

Prompt	Cache Result	Bedrock Call?
`"What is machine learning?"` (1st call)	`miss`	✅ Yes
`"What is machine learning?"` (2nd call)	`hash_hit`	❌ No
`" What is MACHINE LEARNING? "`	`hash_hit`	❌ No
`"How would you define machine learning?"`	`semantic_hit (0.94)`	❌ No
`"Could you please explain what machine learning is?"`	`miss` → compressed	✅ Yes (fewer tokens)

When to Use This Pattern

This three-layer pipeline is most valuable when:

Query volume is high — the cost savings on cache hits compound quickly at scale
Users tend to ask similar questions — support bots, knowledge bases, FAQ tools
Prompts are verbose — compression delivers more savings when users write long-winded queries
Latency matters — a Redis GET is orders of magnitude faster than a Bedrock roundtrip

It's less impactful for highly creative or unique queries (content generation, code synthesis) where every prompt is genuinely different and semantic similarity won't trigger often.

What I'd Do Differently in Production

A few things worth considering as you take this pattern to prod:

Replace the linear embedding scan with a proper vector search (Redis Stack's HNSW index, or OpenSearch with k-NN). Scanning every stored embedding is fine at low volume but doesn't scale.
Instrument cache hit rates with CloudWatch metrics so you can track ROI over time and justify the ElastiCache spend.
Tune SIMILARITY_THRESHOLD per use case. A support bot can be aggressive (0.85); a medical or legal assistant should be conservative (0.95+).
Analyze your CloudWatch compression logs weekly and update FILLER_PHRASES based on real traffic patterns.
Add a warm-up step for known common queries — pre-populate the cache on deploy so the very first user gets a cache hit.

Wrapping Up

Three layers, one Lambda function, one ElastiCache cluster. Together they cover the most common sources of Bedrock cost:

Layer	What it eliminates
Hash caching	Exact duplicate calls
Semantic caching	Paraphrased duplicate calls
Prompt compression	Excess tokens on every genuine miss

The pattern is modular — you can adopt any one layer independently, and each one pays for itself at a different traffic threshold. Start with hash caching (zero additional AWS cost beyond ElastiCache), add semantic caching once you see recurring paraphrases in your logs, and layer in prompt compression as your prompt corpus grows longer.

If you're building on Amazon Bedrock, this is one of the highest-ROI architectural patterns you can drop into an existing Lambda-based backend with minimal rework.

Built and tested as part of an AWS hands-on lab. All code runs on Python 3.12, Redis 7.1, and Amazon Bedrock Nova Micro via a cross-region inference profile.

Have questions or want to share your own caching numbers? Drop them in the comments below 👇