kprompt on AWS: EKS day-2 with BYOK, without a new control plane

Teams on AWS often ask: “How do we run kprompt on Amazon?” Same honest answer as for Google Cloud: not a Marketplace listing, not a managed fleet SaaS. kprompt is a laptop CLI (and an optional in-cluster Observe agent) that speaks Kubernetes. On AWS that means EKS in your kubeconfig, your bring-your-own-key model — and the same plan → safety → approve contract you get on kind or GKE.

If you already operate EKS with aws CLI and kubectl, you already have the hard parts. This post is the AWS-shaped path: credentials, aliases, LLM choices (including Bedrock honesty), useful day-2 prompts, and when (not) to install the Observe agent.

What “on AWS” actually means

That last row matters. “Create me an EKS cluster in us-east-1” is still aws / eksctl / your IaC. kprompt’s lane is day-2: investigate CrashLoop, scale a Deployment, open a reviewable plan — after the cluster exists.

1. Point kubeconfig at EKS

Same muscle memory as kubectl. Authenticate the AWS CLI (SSO or IAM), then write the cluster into kubeconfig. Prefer a non-production cluster for the first session. Private API endpoints still need your VPN / bastion / SSM path — kprompt will not invent a tunnel.

aws sso login --profile my-sso
# or: export AWS_PROFILE=… / AWS_REGION=…

aws eks update-kubeconfig \
  --name CLUSTER_NAME \
  --region REGION \
  --profile my-sso

kubectl config current-context
# → arn:aws:eks:REGION:ACCOUNT:cluster/CLUSTER_NAME (typical shape)

kprompt doctor

doctor checks kube reachability and LLM readiness. If the API server is unreachable, fix aws auth, security groups, or private-endpoint access first.

2. Alias the long EKS ARN context

EKS context names are ARNs on purpose. Aliases keep blast radius mental: prod means one string, staging means another. require_alias_match refuses a mutate when kubectl’s current-context does not match the alias you asked for — fat-finger insurance when three EKS contexts sit in one file.

kprompt contexts
kprompt contexts --check

kprompt config alias set prod arn:aws:eks:us-east-1:123456789012:cluster/prod
kprompt config alias set staging arn:aws:eks:us-east-1:123456789012:cluster/staging
kprompt config set require_alias_match true

kprompt --context staging "list deployments"
kprompt --contexts staging,prod "list pods"

Read fan-out across staging and prod is explicit. Mutate fan-out never rides on a lone --approve — you need --approve-each-context if you truly meant every listed context. Credentials still never leave the laptop.

3. Wire an LLM — Ollama, BYOK, or Bedrock via gateway

Natural-language plans need a model. On an AWS-heavy stack you usually pick one of three paths. Prefer Ollama when you want $0 inference and no cloud quota. Use Anthropic / OpenAI / Gemini BYOK when you already pay those APIs. For Bedrock: there is no named bedrock preset yet (P-008 deferred — SigV4 / IAM auth does not fit the simple Bearer BYOK model). If you already terminate Bedrock behind an OpenAI-compatible gateway, point openai-compatible + base_url at it.

# A) Local Ollama — $0
#    ollama serve && ollama pull llama3.2
kprompt init --ollama

# B) Anthropic BYOK (common when Claude is already org-standard)
export KPROMPT_ANTHROPIC_API_KEY=...
kprompt init --provider anthropic

# C) Bedrock (or other) behind an OpenAI-compatible gateway
export KPROMPT_OPENAI_API_KEY=...          # gateway token
export KPROMPT_OPENAI_BASE_URL=https://YOUR_GATEWAY/v1
kprompt config set provider openai-compatible
kprompt config set model YOUR_MODEL_ID

kprompt --context staging "list pods"

Honesty: native aws-sdk Bedrock Converse is out of scope until a stable Chat Completions path fits env-key BYOK. Do not expect kprompt to pick up ~/.aws/credentials for LLM calls today — only for whatever aws CLI / kubeconfig exec plugin you already use to reach the API server.

4. Day-2 on EKS — read first, then plan

Brownfield rule still applies: first value is a read. Managed node groups vs Fargate do not change the contract — PlanResult before apply, wipe-class intents hard-denied. IRSA, NetworkPolicy, and AWS Load Balancer Controller CRDs still obey your RBAC.

# Read / investigate (risk = 0)
kprompt --context staging "explain why checkout is failing" -n payments
kprompt --context staging "investigate CrashLoopBackoff" -n payments
kprompt --context staging "optimize my cluster"

# Mutate — plan only by default; TTY y/N or --approve
kprompt --context staging "scale api to 3" -n payments
kprompt --context staging "scale api to 3" -n payments --approve

# Optional: bind existing Prometheus / Grafana / AMP URLs — do not install a second stack
kprompt tools
kprompt config set tools.prometheus.url http://prometheus.monitoring:9090

If the IAM identity behind your kubeconfig cannot list Pods in payments, neither can kprompt. That is a feature. Pod Identity / IRSA for the Observe agent ServiceAccount is your cluster’s job — put LLM and Slack secrets in Kubernetes Secrets, not in ConfigMaps.

5. Optional: Observe agent inside EKS

The CLI is reactive. The Observe agent is always-on watch in one namespace: correlate Pods/Events into an Incident, optionally analyze, then gate Discord/Slack/webhook. Default mode never patches or deletes. Same Helm chart as on GKE or kind.

helm upgrade --install kprompt-agent ./charts/kprompt-agent -n payments \
  --create-namespace \
  # LLM / Slack / Discord via Secret + values — see chart README

# Laptop smoke before you Helm:
kprompt agent run -n payments --emit-initial --analyze --fetch-logs --heuristic

Start heuristic for demos ($0). Turn on LLM analysis when you accept token spend and have tightened --min-severity / --min-confidence. Autopilot apply stays gated — propose is not silent heal.

AWS checklist

What we are not claiming

• Not an AWS Marketplace app or managed “kprompt on AWS” control plane
• Not an EKS / ECS / Fargate provisioner
• Not uploading kubeconfigs to api.kprompt.ai
• Not a native Bedrock SDK preset (openai-compatible gateway only, until P-008)
• Not reading AWS Secrets Manager for LLM keys by default — env / K8s Secret
• Not silent remediations from the in-cluster agent

Experimental software. Prefer staging. Read every plan. On AWS the win is the same as everywhere else: intentional day-2 ops on the EKS you already run — with your keys, your IAM/RBAC, and approval still on the human side of the boundary.