AI-powered development platform on AWS: Coder on Amazon EKS, with serverless Fargate workspaces and Coder Agents backed by Amazon Bedrock.
This repository deploys a complete AI-assisted development environment via a single CloudFormation stack. Two capabilities are the focus of this platform:
- Fargate workspaces — developer workspaces run on AWS Fargate (serverless pods), with persistent home directories backed by Amazon EFS. No worker nodes to manage or scale for workspace compute.
- Coder Agents — the built-in agentic coding assistant (GA in Coder 2.37), wired to
Amazon Bedrock (native) and the Bedrock OpenAI-compatible endpoint (
/openai/v1) so agents run entirely on AWS-hosted models.
See Deployment to run it in your own AWS account.
This platform is purpose-built to operationalize the AWS AI-Driven Development Life Cycle (AI-DLC) — AWS's methodology for adopting agentic AI across the software lifecycle while keeping humans in control. AI-DLC structures work into a three-phase, human-approved workflow — Inception (the what and why), Construction (the how), and Review (did it work) — where AI agents plan, implement, and review, and engineers make the decisions at every phase gate. Agents pause and ask when they need clarification, and requirements stay traceable down to the code they produce.
The hard part of adopting AI-DLC is not the agents — it is giving them a place to act safely. That is what this repository provides:
- A governed execution surface. Agentic “Construction” means agents run commands, install dependencies, and execute generated code. Doing that on Firecracker microVM-isolated Fargate workspaces confines each agent run to a disposable, single-tenant VM — the blast radius of an autonomous action is one sandbox.
- Enterprise guardrails by construction. Workspaces inherit scoped IAM roles, run inside your VPC, use models served through Amazon Bedrock, and are provisioned from version- controlled, reviewable templates. Access, networking, models, and tooling are all things the enterprise defines — not the agent.
- Centralized, auditable AI access. Coder Agents route through admin-configured Bedrock providers and models, so model choice, usage, and budgets are governed centrally rather than per-developer.
For highly regulated industries (financial services, healthcare, public sector), the primary barrier to agentic AI is not capability but control, isolation, and auditability. Running AI-DLC on this platform addresses those directly: VM-level isolation per workspace (Firecracker), no shared kernels, data and inference kept within AWS accounts and Regions you control, IAM/VPC boundaries around every agent, and human approval gates built into the methodology. AWS's own Responsible AI Policy — review agent output and costs — maps cleanly onto AI-DLC's human-in-the-loop phase gates.
The same properties let any size enterprise scale agentic development effectively: start small with disposable sandboxes, keep humans deciding intent and reviewing output, and grow agent autonomy as confidence in the guardrails grows — without standing up bespoke isolation or governance infrastructure.
Learn more about AI-DLC:
- AWS DevOps Blog — AI-Driven Development Life Cycle (methodology)
awslabs/aidlc-workflows— adaptive AI-DLC workflow rules for AI coding agents (Kiro, Amazon Q, Claude Code, Cursor, Copilot, and more)aws-samples/sample-collaborative-ai-dlc— collaborative AI-DLC platform (reference implementation)
Workspaces are scheduled onto an EKS Fargate profile (coder-workspaces, selector
namespace=coder-ws) instead of EC2 worker nodes. Because Fargate does not support EBS
volumes, persistent storage uses Amazon EFS mounted ReadWriteMany.
AWS Fargate runs every pod inside a dedicated Firecracker microVM. Each workspace therefore gets hardware-virtualized, single-tenant isolation — its own kernel and a minimal, purpose-built virtualization boundary — rather than sharing a kernel with neighboring containers, while still booting in a fraction of a second.
That combination of strong isolation + fast, ephemeral startup is exactly what you want for cloud sandboxes used by both human developers and agentic AI:
- Blast-radius containment — an autonomous agent running commands, installing packages, or executing generated code is confined to a single-use microVM, not a shared host.
- Clean, reproducible environments — workspaces are disposable; spin one up per developer, per task, or per agent run and throw it away.
- Defense in depth — VM-level isolation layers on top of Kubernetes namespaces, IAM scoping, and VPC network controls.
This makes the platform a safe execution surface for letting AI agents build — not just suggest — inside guardrails the enterprise controls.
| Component | Purpose |
|---|---|
EKS Fargate profile coder-workspaces |
Runs every workspace pod in the coder-ws namespace serverlessly |
| Dedicated Fargate subnets (2 AZs) | Private subnets for Fargate pod ENIs |
| EFS file system (encrypted, elastic throughput) | Persistent /home/coder per workspace, survives restarts |
| EFS mount targets + NFS security group | Reachable from Fargate pods over port 2049 within the VPC |
efs-static StorageClass (efs.csi.aws.com) |
Binds each workspace PVC to its EFS access point |
FargatePodExecutionRole |
Pulls images and runs pods under AmazonEKSFargatePodExecutionRolePolicy |
Workspace templates create an EFS access point + PV/PVC per workspace and mount it at
/home/coder. Tools installed outside the home directory live in the container image.
Coder Agents (GA in Coder 2.37) are configured during deployment via the coderd Terraform
provider (no console clicks required). Two AI providers are provisioned:
| Provider (name) | Type | Endpoint | Models |
|---|---|---|---|
bedrock ("AWS Bedrock") |
Bedrock (native, Pod Identity IAM) | bedrock-runtime.us-east-1 |
Claude Opus 4.6 (default), Claude Haiku 4.5 (small/fast) |
openai-compat ("OpenAI-compatible (AWS Bedrock)") |
OpenAI-compatible (Bedrock native OpenAI endpoint) | bedrock-runtime.us-east-1/openai/v1 |
OpenAI GPT-5.6 Sol, xAI Grok 4.6 |
Notes:
- Anthropic, OpenAI, and xAI models use cross-region inference profile IDs (
global./us.) and are served from us-east-1, independent of the stack's deployment region. - Native Bedrock credentials come from the
coderdpod IAM role (EKS Pod Identity), so no static access keys are stored for thebedrockprovider. - The OpenAI-compatible provider authenticates with an Amazon Bedrock API key (a
bedrock.amazonaws.comIAM service-specific credential) generated automatically and stored in Secrets Manager. - Provider and model configuration is applied declaratively by the
ai-providers/Terraform (thecoderdprovider) during the CodeBuild deploy step, replacing the earlier direct/api/v2/ai/providersand/api/experimental/chats/model-configsAPI calls. - The AWS Knowledge MCP server (remote, streamable HTTP) is registered for Coder Agents
via
coderd_agents_mcp_server, giving agents AWS docs, API references, and Well-Architected guidance out of the box.
Templates live in templates/ and are deployed via Terraform + the Coder
provider (see GitOps Workflow). Each template's description and
README.md describe its capabilities so Coder Agents can pick the right environment.
| Template | Display Name | Best for |
|---|---|---|
awshp-k8s-challenge-agent |
AWS Workshop - AI Agent Development | Build & deploy AI agents to AWS. Pre-loaded agent frameworks (Strands, LangGraph, LangChain, LlamaIndex, Lyzr), AWS CDK/CLI + Bedrock. Optimized for Coder Agents. |
awshp-k8s-base-claudecode |
AWS Workshop — Kubernetes with Claude Code | Claude Code routed through the Coder AI Gateway (session-logged); code-server + VS Code Desktop. |
awshp-k8s-base-codex |
AWS Workshop — Kubernetes with OpenAI Codex | OpenAI Codex CLI (GPT-5.6 Sol via the Coder AI Gateway); VS Code Web + VS Code Desktop. |
awshp-k8s-base-kirocli |
AWS Workshop — Kubernetes with Kiro CLI | Kiro CLI AI assistant + Kiro IDE for interactive development. |
All templates run on Fargate with EFS-backed persistent home directories.
The Codex template ships a citizen-builder set of
AWS Labs MCP servers — IaC (CloudFormation + CDK),
pricing, Serverless, and CloudWatch — run on demand via uvx. The Claude Code and
Kiro CLI templates ship observability / LLM-tooling MCP servers (Fiddler GenAI,
LangSmith, LlamaCloud), each enabled only when its API key is provided. General AWS API
access is provided by the AWS CLI (v2) and boto3, which the agents drive directly from the
shell.
- AWS account with permissions to create EKS, VPC, Aurora, CloudFront, EFS, ECR, CodeBuild, IAM, Lambda, and Secrets Manager resources
- AWS CLI configured
- Sufficient quotas for EKS, Aurora PostgreSQL, CloudFront, and VPC resources (NAT Gateways, EIPs)
- Amazon Bedrock model access enabled in us-east-1 for the configured Claude (Anthropic), OpenAI, and xAI models
- OpenAI GPT models are AWS Marketplace models and need a one-time account-level agreement
(subscription) before they can be invoked; without it, invocation fails with
HTTP 403("...not authorized to perform the required AWS Marketplace actions...") even for an admin identity. The deploy now creates this agreement automatically (CodeBuild callsbedrock:CreateFoundationModelAgreementfor the configured OpenAI models), and the workspace/ API-key IAM identities are grantedaws-marketplace:ViewSubscriptions/Subscribe. If you prefer, you can pre-enable it in the Bedrock console → Model access. Anthropic and xAI models do not require a Marketplace agreement. To add more OpenAI models later, seeai-providers/README.md.
- OpenAI GPT models are AWS Marketplace models and need a one-time account-level agreement
(subscription) before they can be invoked; without it, invocation fails with
- A Coder Premium license (supplied via the
CoderLicenseKeyparameter) is required for coderd HA (2 replicas) and the Coder Agents MCP-servers API - Deploy the image pipeline stack before the core stack (see Deployment)
Deployment is a two-stack process. The image pipeline stack must be deployed first — it builds the container images the Fargate workspaces run on and publishes them to ECR. The core Coder stack then references those images by URI, so it depends on the pipeline having run successfully.
codebuild_image_pipeline.yaml -> builds & pushes ECR images -> coder_deployment.yaml
(Step 1, run first) (coder-workspace-*:latest) (Step 2)
This stack creates three ECR repositories, a CodeBuild project, and a Lambda-backed custom resource that runs the build automatically on stack create. It builds and pushes the images used by the Fargate templates:
| ECR repository | Built from | Used by template |
|---|---|---|
<EKSClusterName>/coder-workspace-claude-code |
images/coder-workspace-claude-code/ |
awshp-k8s-base-claudecode, awshp-k8s-base-codex |
<EKSClusterName>/coder-workspace-kiro-cli |
images/coder-workspace-kiro-cli/ |
awshp-k8s-base-kirocli |
<EKSClusterName>/coder-workspace-challenge |
images/coder-workspace-challenge/ |
awshp-k8s-challenge-agent |
- Create a stack from
infrastructure/codebuild_image_pipeline.yaml. - Set parameters:
EKSClusterName— must match the value you will use for the core stack (defaultcoder-aws-cluster); the ECR repository names are derived from it.GitRepoURL— repository containing theimages/Dockerfiles (default is this repo).GitBranch— branch to build from (defaultmain).
- Acknowledge IAM resource creation and create the stack.
- The custom resource starts the CodeBuild job automatically and waits for it to finish.
Confirm success in the CodeBuild console (project
<EKSClusterName>-workspace-image-build) and verify each ECR repository has alatestimage before continuing.
Important: Deploy this stack in the same AWS account and Region as the core stack, and use the same
EKSClusterName. The core stack builds the image URIs by convention (<account>.dkr.ecr.<region>.amazonaws.com/<EKSClusterName>/coder-workspace-*:latest); if the repositories are missing or empty, workspaces will fail to start with image-pull errors.To rebuild images later (e.g., after changing a Dockerfile), start the
<EKSClusterName>-workspace-image-buildCodeBuild project again — no stack update needed.
- Open the AWS CloudFormation console and create a stack from
infrastructure/coder_deployment.yaml. - Set the required parameters:
CoderAdminEmail,CoderAdminUser,CoderAdminPassword,CoderAdminName
- Optional parameters (defaults shown):
EKSClusterName(coder-aws-cluster) — use the same value as Step 1,KubernetesVersion(1.35),CoderVersion(2.37.0),CoderLicenseKey(empty — supply a Coder Premium license to enable HA and the MCP-servers API),CoderGitOpsTemplateRepoURL,RetryFlag(False)
- Acknowledge IAM resource creation and create the stack (~30–45 minutes).
The stack provisions networking, Aurora PostgreSQL, the EKS cluster (Auto Mode + Fargate profile), EFS storage, installs Coder via Helm, configures CloudFront, deploys templates (pointing at the ECR images from Step 1), and configures Coder Agents providers/models.
Monitor progress in the CloudFormation Events tab and the CodeBuild logs
(/aws/codebuild/CodeBuild-<StackName>).
When the stack completes, use these CloudFormation Outputs:
CoderURL— CloudFront URL for the Coder dashboardCoderAdminEmail/CoderAdminPassword(also in Secrets Manager viaCoderAdminPasswordSecretArn)CoderSessionTokenSecretArn— API token secret
Log in at CoderURL, then create a workspace from one of the templates.
Templates are versioned by Git SHA and applied with the Coder Terraform provider. The stack
runs templates/templates_gitops.sh automatically;
template metadata (name, display name, description, icon, image, EFS id) is defined in
templates/template_versions.tf.
# Manual template update
cd templates/
export TF_VAR_coder_url="https://your-coder-url"
export TF_VAR_coder_token="your-session-token"
export TF_VAR_coder_gitsha="$(git log -1 --format=%H)"
terraform apply -auto-approve- Coder — v2.37.x control plane with Coder Agents (GA) and the AI Gateway; runs HA (2 coderd replicas, requires a Premium license)
- EKS — Auto Mode (control plane + system workloads) with a dedicated Fargate profile for workspaces
- Aurora PostgreSQL Serverless v2 — Coder database (encrypted, KMS)
- CloudFront + Network Load Balancer — secure global access to Coder
- VPC — public/private/Fargate subnets across 2 AZs, NAT gateways for egress
- EFS — persistent workspace home directories (Fargate-compatible)
- ECR — three
coder-workspace-*repositories holding the Fargate workspace images built by the image pipeline stack - Secrets Manager — admin password, session token, Bedrock (OpenAI-compatible) API key
- IAM —
<EKSClusterName>-workshop-userworkspace role (Bedrock, S3, Secrets Manager, EKS, EFS, etc.)
| Symptom | Checks |
|---|---|
| Stack creation fails | CodeBuild logs /aws/codebuild/CodeBuild-<StackName>; service quotas; IAM permissions |
Cannot reach CoderURL |
CloudFront status is Deployed; NLB target health; kubectl get pods -n coder |
| Workspace won't start | Fargate profile is ACTIVE; kubectl get sc shows efs-static; EFS mount targets healthy; kubectl get pvc -n coder-ws |
Workspace image pull error / ImagePullBackOff |
Step 1 image pipeline ran successfully; each <EKSClusterName>/coder-workspace-* ECR repo has a latest image; EKSClusterName and Region match between both stacks |
| Coder Agent model errors | Bedrock model access in us-east-1; AI providers/models applied by the ai-providers/ Terraform; Bedrock (OpenAI-compat) API key secret populated |
Use the teardown script — it removes everything in dependency order, including the
resources CloudFormation does not delete on its own: the eksctl-managed EKS
cluster, the Coder control-plane NLB, the Bedrock IAM service-specific credential,
SSM parameters, and the Retain-policy Aurora and EFS resources (which also
block stack deletion because their networking is stack-owned). The core stack is
deleted last.
# Dry run first to see exactly what will be deleted
infrastructure/scripts/teardown.sh --stack <core-stack-name> --region <aws-region> --dry-run
# Then run it for real (prompts for confirmation)
infrastructure/scripts/teardown.sh --stack <core-stack-name> --region <aws-region>
# Also delete the image-pipeline stack + its ECR images, and purge secrets immediately:
infrastructure/scripts/teardown.sh --stack <core-stack-name> --region <aws-region> \
--image-stack <image-stack-name> --purge-secrets --yesRequires aws, eksctl, kubectl, helm, and jq. The script discovers the cluster,
Aurora, EFS, Bedrock IAM user, and secret ARNs from the stack's parameters/outputs, so
you only supply the stack name and region. It is idempotent — safe to re-run if a step
fails. The core-stack delete is slow (CloudFront disable+delete, ~20–40 min).
If the core stack fails to reach
DELETE_COMPLETE, it is almost always a leftover ENI or security group left behind by the NLB or EKS. Delete it in the console, then re-runaws cloudformation delete-stack --stack-name <core-stack-name>(or re-run the script).
- AWS AI-DLC (AI-Driven Development Life Cycle) and awslabs/aidlc-workflows
- Firecracker microVM (powers AWS Fargate isolation)
- Coder Documentation
- Amazon EKS Fargate
- Amazon EFS CSI Driver
- AWS Responsible AI Policy
See LICENSE.
Designed for AWS AI Builder Lab events. Follow standard GitOps practices and test changes in a non-production environment first.