DEV Community: Evgeny Anikiev

Bedrock vs Self-Hosted LLMs on EKS: The Break-Even Math

Evgeny Anikiev — Fri, 23 Oct 2026 09:51:49 +0000

When do your own GPUs beat Amazon Bedrock for the same open-weight model? Official AWS prices, the tokens per second you need to break even, and the Karpenter and vLLM config to test it.

By Evgeny Anikiev, AWS-certified DevOps engineer with 10+ years running build automation, CI/CD, and Kubernetes in production. Prices pulled from the AWS Price List API on October 23, 2026 (US East, N. Virginia, on-demand list prices).

TL;DR: The same open-weight model costs per token on Bedrock and per hour on your own GPUs. One H100 on a p5.4xlarge running gpt-oss-120b costs $5,022 a month. To beat Bedrock's price for that model, it has to process about 7,300 tokens per second, around the clock, every day of the month. Unless your traffic is that high and that steady, Bedrock costs less. Self-hosting also makes sense when you need a model Bedrock doesn't offer.

The numbers in this post:

Bedrock prices for gpt-oss-120b, gpt-oss-20b, and Llama 3.3 70B.
EC2 GPU instance prices for the instances that fit each model.
The break-even volume in tokens per month and tokens per second.
The costs a per-token price hides and a per-hour price doesn't.
A Karpenter NodePool and vLLM Deployment to run your own benchmark.

Which costs less: Amazon Bedrock or self-hosting on EKS?

Unless a GPU stays busy around the clock, Bedrock costs less. Bedrock bills per token and costs nothing when idle. A self-hosted model on EKS bills per GPU-hour whether it serves traffic or not. Self-hosting only wins when a GPU stays busy enough that its hourly cost divided by its tokens drops below Bedrock's per-token price. For gpt-oss-120b on one H100, that point is about 19 billion tokens a month.

Bedrock and self-hosting on EKS, side by side:

Billing: Bedrock charges per million tokens. EKS charges per GPU-hour, plus $73 a month for the cluster control plane.
Idle cost: zero on Bedrock. Full hourly price on EKS until the node is removed.
Scaling: Bedrock scales within your tokens-per-minute quota. On EKS, you scale GPU nodes yourself, with cold starts of several minutes.
Models: Bedrock offers its catalog plus Custom Model Import. EKS runs any open-weight model that fits your GPUs.
Operations: AWS runs Bedrock. On EKS, your team owns drivers, the serving engine, autoscaling, and on-call.

What does each option cost?

Bedrock: per token

These are on-demand (Standard tier) prices per million tokens in US East, from the AWS Price List API:

gpt-oss-120b: $0.15 input, $0.60 output.
gpt-oss-20b: $0.07 input, $0.30 output.
Llama 3.3 70B Instruct: $0.72 input, $0.72 output.

Batch inference and the Flex tier halve these prices for work that can wait, for example $0.075 input and $0.30 output for gpt-oss-120b.

Agents send far more input than they get back, because every call resends the conversation and tool results. With 3 input tokens for every output token, the blended price per million tokens is:

gpt-oss-120b: $0.2625
gpt-oss-20b: $0.1275
Llama 3.3 70B: $0.72

Self-hosted: per GPU-hour

On-demand Linux prices in US East:

g6e.xlarge (1× NVIDIA L40S, 48 GB): $1.861 per hour, about $1,359 a month.
p5.4xlarge (1× NVIDIA H100, 80 GB): $6.88 per hour, about $5,022 a month.
g6e.12xlarge (4× L40S, 192 GB total): $10.49 per hour, about $7,660 a month.

Which instance fits which model:

gpt-oss-20b fits on one L40S (g6e.xlarge). OpenAI says it runs within 16 GB of memory.
gpt-oss-120b fits on one 80 GB GPU, per OpenAI, so one H100 (p5.4xlarge) works. Four L40S GPUs (g6e.12xlarge) also fit it, at a higher hourly price.
Llama 3.3 70B needs about 140 GB for its weights at 16-bit precision, so it needs g6e.12xlarge or larger.

Where is the break-even point?

Divide the monthly instance cost by Bedrock's blended price. The result is how many tokens the instance has to process each month to cost the same as Bedrock. Divide by the seconds in a month to get the tokens per second it has to sustain.

HOURS = 730  # hours in an average month

def break_even(instance_per_hour, bedrock_in, bedrock_out, ratio=3):
    """Prices: instance in USD/hour, Bedrock in USD per million tokens.
    ratio = input tokens per output token."""
    blended = (ratio * bedrock_in + bedrock_out) / (ratio + 1)
    monthly = instance_per_hour * HOURS
    tokens = monthly / blended * 1_000_000
    per_second = tokens / (HOURS * 3600)
    return round(monthly), round(tokens / 1e9, 1), round(per_second)

print(break_even(6.88, 0.15, 0.60))      # gpt-oss-120b on p5.4xlarge:   (5022, 19.1, 7280)
print(break_even(1.861, 0.07, 0.30))     # gpt-oss-20b on g6e.xlarge:    (1359, 10.7, 4054)
print(break_even(10.49264, 0.72, 0.72))  # Llama 3.3 70B on g6e.12xlarge: (7660, 10.6, 4048)

Each instance has to sustain this load 24 hours a day to match Bedrock:

gpt-oss-120b on one H100: 19.1 billion tokens a month, about 7,300 tokens per second.
gpt-oss-20b on one L40S: 10.7 billion tokens a month, about 4,100 tokens per second.
Llama 3.3 70B on four L40S: 10.6 billion tokens a month, about 4,000 tokens per second.

Two adjustments make the bar higher:

Real traffic isn't flat. If your GPU is busy 40% of the time on average, it needs to handle 2.5 times the break-even rate at peak. For gpt-oss-120b, that is about 18,000 tokens per second.
If your workload can wait, compare against Batch or Flex. Both are half price, which doubles every break-even number above.

Whether one GPU can hit these rates depends on your prompts, context length, batch size, and serving engine. Measure it. The config at the end of this post sets up that test.

Worked example: the support agent from the readiness checklist

This example is hypothetical. The support agent from my AI agents readiness checklist handles 10,000 tasks a month, with 6 model calls per task, 8,000 input tokens and 1,000 output tokens per call:

Input: 480 million tokens a month.
Output: 60 million tokens a month.

On Bedrock:

gpt-oss-120b: 480 × $0.15 + 60 × $0.60 = $108 a month.
gpt-oss-20b: 480 × $0.07 + 60 × $0.30 = $51.60 a month.

Self-hosting the same agent on one p5.4xlarge costs $5,022 a month, about 46 times more. Its 540 million tokens are under 3% of the 19.1 billion the H100 needs to break even, so the agent would need about 35 times its current volume before that GPU paid for itself.

What costs does the per-hour price leave out?

Add these to the GPU-hour:

The EKS control plane: $0.10 per hour, $73 a month per cluster, if you don't already run one.
Model downloads. gpt-oss-120b weights are tens of gigabytes. Every new node pulls them. If that goes through a NAT gateway from S3 or the internet, you pay NAT processing on every pull. An S3 gateway endpoint makes the S3 part free; see Cut AWS NAT Gateway Costs.
Cold starts. Scaling GPU nodes to zero saves money but means minutes of waiting for a node, an image, and the weights before the first answer. Keeping one node warm puts you back on the 24-hour cost.
Quotas. EC2 limits GPU instances through vCPU quotas for G and P instances. Check them before you plan on p5 instances, since an increase request can take days.
People. Someone owns the serving engine upgrades, GPU drivers, autoscaling, and on-call. Bedrock includes that in the token price.

Savings Plans and EC2 Capacity Blocks lower the hourly price for steady GPU use, which moves the break-even point down. Price them for your term and Region before deciding.

When does self-hosting on EKS make sense?

Self-host when at least one of these is true:

Steady, high volume. Your measured traffic stays above the break-even rate for most of the day.
A model Bedrock doesn't have. A fine-tuned or niche open-weight model that isn't on Bedrock and can't be imported.
Control over the serving stack. You need a specific engine, quantization, or batching setup that a managed API doesn't expose.

Stay on Bedrock when:

Traffic is spiky or still growing. Paying per token means idle hours cost nothing.
You switch models often. Bedrock lets you change the model ID instead of resizing GPU node pools.
Nobody on the team wants GPU on-call.

A practical path is to prototype on Bedrock, measure real token volume for a month, then run the break-even function above with real numbers.

How do I test self-hosting on EKS?

Two pieces: a Karpenter NodePool that launches GPU nodes only when a GPU pod is waiting, and a vLLM Deployment that serves the model with an OpenAI-compatible API.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu-inference
spec:
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      requirements:
        - key: karpenter.k8s.aws/instance-family
          operator: In
          values: ["g6e"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand"]
      taints:
        - key: nvidia.com/gpu
          effect: NoSchedule
  limits:
    nvidia.com/gpu: 4
  disruption:
    consolidationPolicy: WhenEmpty
    consolidateAfter: 10m

The taint keeps other pods off GPU nodes. WhenEmpty removes a GPU node 10 minutes after its last pod leaves, so a test cluster doesn't bill GPU hours overnight. The limits block caps the pool at four GPUs, which stops a runaway Deployment from launching more.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: gpt-oss-20b
spec:
  replicas: 1
  selector:
    matchLabels:
      app: gpt-oss-20b
  template:
    metadata:
      labels:
        app: gpt-oss-20b
    spec:
      tolerations:
        - key: nvidia.com/gpu
          operator: Exists
          effect: NoSchedule
      containers:
        - name: vllm
          image: vllm/vllm-openai:latest
          args: ["--model", "openai/gpt-oss-20b"]
          ports:
            - containerPort: 8000
          resources:
            limits:
              nvidia.com/gpu: 1

Pin the vLLM image to a specific version once your test works. Then replay a day of real prompts against both endpoints, measure sustained tokens per second at your latency target, and put that number next to the break-even rate.

FAQ

Is Amazon Bedrock cheaper than running an LLM on EC2?

Unless the GPU stays busy around the clock, yes. Bedrock charges only for tokens processed, while an EC2 GPU instance charges every hour it runs. A single H100 serving gpt-oss-120b has to sustain about 7,300 tokens per second, 24 hours a day, to match Bedrock's on-demand price for that model.

How much does it cost to run gpt-oss-120b on AWS?

On Bedrock, $0.15 per million input tokens and $0.60 per million output tokens on demand in US East, or half that with Batch or Flex. Self-hosted on one p5.4xlarge (one H100), $6.88 per hour, about $5,022 a month on demand.

What EC2 instance do I need for gpt-oss-20b?

One GPU with at least 16 GB of memory. A g6e.xlarge with one NVIDIA L40S (48 GB) costs $1.861 per hour on demand in US East and leaves room for long contexts and batching.

Can I scale GPU nodes to zero on EKS?

Yes. Karpenter removes empty nodes based on the NodePool's disruption policy and launches new ones when a GPU pod is pending. The trade-off is cold start time, since a new node has to boot, pull the container image, and load the model weights before serving.

Is SageMaker cheaper than EKS for self-hosting an LLM?

The break-even logic is the same. A SageMaker real-time endpoint also bills per instance-hour while it runs, so it has to stay as busy as an EKS GPU node to beat Bedrock's per-token price. Compare the instance-hour prices for your Region, then run the same calculation.

Does Bedrock have a cheaper option for steady high volume?

Yes. Bedrock's Reserved service tier commits to a fixed tokens-per-minute capacity, with a minimum of 100,000 input and 10,000 output tokens per minute, arranged through your AWS account team. If your volume is close to the self-hosting break-even point, get a Reserved quote before buying GPUs.

Does Bedrock offer the same open-weight models I can self-host?

Some of them. gpt-oss-120b, gpt-oss-20b, and Llama 3.3 70B are available on Bedrock as serverless models. For a model Bedrock doesn't list, check Bedrock Custom Model Import before deciding to self-host.

Sources

Deciding between Bedrock and your own GPUs? I run cost reviews and build EKS platforms for AI teams at DevOps Cloud Consult. Bring a month of token counts and I'll run the break-even for your workload.

Get one AWS cost fix every two weeks: subscribe on Substack.

EKS 1.37 Upgrade Checklist: What Breaks and How to Test It

Evgeny Anikiev — Thu, 22 Oct 2026 14:11:39 +0000

Seven changes that break Amazon EKS clusters going from 1.36 to 1.37, with a test command for each.

By Evgeny Anikiev, AWS-certified DevOps engineer with 10+ years running build automation, CI/CD, and Kubernetes in production. Last verified: October 22, 2026, against the Amazon EKS 1.37 documentation.

TL;DR: Amazon EKS has supported Kubernetes 1.37 since October 2, 2026. Most of the release is additive, but seven changes can break running workloads. Test each one with the command in its section, rehearse on a staging cluster, then upgrade the control plane, add-ons, and nodes in that order.

The seven changes:

SELinux mount labeling is on by default.
Static pods can no longer reference Secrets or ConfigMaps.
The kubelet refuses to start with deprecated cAdvisor flags.
eventRecordQPS: 0 now means "no limit".
EKS Auto Mode defaults new NodePools to Balanced consolidation.
HPA scale-to-zero is enabled by default.
kube-proxy IPVS mode is deprecated.

What is new in Kubernetes 1.37 on EKS?

Kubernetes v1.37 ("Garhwal") shipped upstream on August 26, 2026, with 67 enhancements: 16 graduated to Stable, 23 to Beta, 27 new Alpha features, and 1 deprecation/removal. Amazon EKS and EKS Distro followed on October 2, 2026, in all commercial and GovCloud (US) regions.

Headline items for EKS users:

Metrics API GA: metrics.k8s.io/v1.
DRA device taints and tolerations GA. EKS does not install a DRA driver for you.
HPA configurable tolerance GA: per-HPA tolerance for scale-up and scale-down.
HPA scale-to-zero Beta, enabled by default (HPAScaleToZero).
Pod Certificates and ClusterTrustBundles GA.
StatefulSet maxUnavailable re-enabled by default after a bug held it back in 1.36.

None of those break you on their own. The list below is where upgrades actually fail.

The EKS 1.37 breaking-change checklist

1. SELinux mount labeling is on by default (`SELinuxMount`)

What changed: When a Pod sets seLinuxOptions and its CSI driver advertises seLinuxMount: true, the kubelet now mounts the volume with -o context=<label> instead of recursively relabeling every file. It is faster, but if two Pods share a volume with different SELinux labels, change policies, or privilege levels, one of them can sit in ContainerCreating indefinitely.

Who is affected: Mostly Bottlerocket nodes (SELinux enforcing) and anyone setting seLinuxOptions explicitly.

How to test:

# Which CSI drivers opt into SELinux mount labeling?
kubectl get csidriver -o custom-columns=NAME:.metadata.name,SELINUXMOUNT:.spec.seLinuxMount

# Which Pods set SELinux options?
kubectl get pods -A -o json | jq -r '
  .items[] | select(.spec.securityContext.seLinuxOptions != null
    or any(.spec.containers[]; .securityContext.seLinuxOptions != null))
  | "\(.metadata.namespace)/\(.metadata.name)"'

Fix: For workloads that share volumes across differently labeled Pods, opt out per Pod:

spec:
  securityContext:
    seLinuxChangePolicy: Recursive

2. Static pods can no longer reference Secrets or ConfigMaps

What changed: Static pods referencing API objects (secretRef, configMapRef, and similar) are now strictly prohibited, and the PreventStaticPodAPIReferences feature gate that let you opt out has been removed.

Who is affected: Self-managed node groups with custom static pod manifests in /etc/kubernetes/manifests (log shippers, security agents, node-local proxies). Managed node groups and Auto Mode rarely use static pods.

How to test:

# On a node (SSM session), look for API references in static pod manifests
sudo grep -rnE 'secretRef|configMapRef|secretKeyRef|configMapKeyRef|projected' \
  /etc/kubernetes/manifests/ 2>/dev/null

Fix: Convert those static pods to DaemonSets, or render the values into files on the host at bootstrap time.

3. Kubelet refuses to start with deprecated cAdvisor flags

What changed: The kubelet no longer starts if a deprecated cAdvisor flag is set (except --housekeeping-interval). It also drops three metrics: container_cpu_load_average_10s, container_cpu_load_d_average_10s, and container_tasks_state.

Who is affected: Custom AMIs, custom launch templates with --kubelet-extra-args, or Karpenter kubelet blocks that inherited old flags. EKS-optimized AMIs do not set them.

How to test:

# Inspect the live kubelet command line and config on a node
ps -o args= -C kubelet | tr ' ' '\n' | grep -E '^--'

# Grep dashboards/alerts for the removed metrics
grep -rnE 'container_cpu_load_average_10s|container_cpu_load_d_average_10s|container_tasks_state' \
  ./dashboards ./alerts ./prometheus-rules

Fix: Remove deprecated flags from user data and launch templates. Rewrite dashboards and alerts that use the dropped metrics.

4. `eventRecordQPS: 0` now means "no limit"

What changed: Before 1.37, eventRecordQPS: 0 meant the default of 5 events/second. Now it means unlimited, so a noisy CrashLoopBackOff node can flood the API server with events.

How to test:

kubectl get --raw "/api/v1/nodes/<node-name>/proxy/configz" | jq '.kubeletconfig.eventRecordQPS'

Fix: If you set 0 explicitly, change it to 5 to keep the old behavior. EKS-optimized AMIs do not set this field.

5. EKS Auto Mode: default consolidation policy is now `Balanced`

What changed: New Auto Mode NodePools that don't set consolidationPolicy default to Balanced instead of WhenEmptyOrUnderutilized. The built-in general-purpose and system NodePools also use Balanced, and you cannot change that on them.

Why it matters: Bin-packing behavior and node churn change. Cost dashboards may move; PodDisruptionBudget pressure patterns change.

How to test:

kubectl get nodepools -o custom-columns=NAME:.metadata.name,POLICY:.spec.disruption.consolidationPolicy

Any row showing <none> will pick up the new default.

Fix: Pin the old behavior explicitly on your own NodePools and target them from workloads that need it:

spec:
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized

6. HPA scale-to-zero is enabled by default

What changed: HPAScaleToZero is Beta and on by default. An HPA with minReplicas: 0 on Object or External metrics can now drive a Deployment to zero replicas.

Who is affected: Teams that templated minReplicas: 0 by accident (Helm defaults, copy-paste) where it was previously rejected or ignored. EKS does not install a metrics adapter, so this only applies if you run one (KEDA, Prometheus Adapter, CloudWatch adapter).

How to test:

kubectl get hpa -A -o json | jq -r '
  .items[] | select(.spec.minReplicas == 0)
  | "\(.metadata.namespace)/\(.metadata.name)"'

Fix: Set minReplicas: 1 anywhere zero is not intentional.

7. kube-proxy IPVS mode is deprecated

What changed: kube-proxy in ipvs mode now logs a deprecation warning on startup. Upstream plans to disable it by default around v1.40 and remove it around v1.43. Nothing breaks in 1.37, but this is the release to plan your move to nftables (or iptables), which now talks to the kernel through netlink instead of the nft CLI.

How to test:

kubectl -n kube-system get cm kube-proxy-config -o yaml | grep -i mode

Also on the radar

cgroup v1: failCgroupV1 has defaulted to true since 1.35. The temporary override still works in 1.37, but removal is coming. Move any remaining cgroup v1 nodes (old AL2 custom AMIs) to AL2023 or Bottlerocket.
kube-dns: No new packages expected after v1.40. EKS uses CoreDNS by default, so check that you are not running a legacy kube-dns.
kubectl run -f: The --filename/-f flag is deprecated. Fix scripts that use it.
Kubelet logs its full effective config at startup. Useful for verifying the items above, but check that your log pipeline does not alert on it.

How to test an EKS 1.37 upgrade safely

Step 1: Run EKS Upgrade Insights

aws eks list-insights --cluster-name my-cluster \
  --filter '{"categories":["UPGRADE_READINESS"]}'

aws eks describe-insight --cluster-name my-cluster --id <insight-id>

Insights flag deprecated API usage seen in audit logs and add-on/version-skew problems. Treat any ERROR as a blocker.

Step 2: Scan manifests for deprecated APIs

# Live cluster
kubent

# Helm charts and GitOps repos
pluto detect-files -d ./k8s --target-versions k8s=v1.37.0
pluto detect-helm -o wide --target-versions k8s=v1.37.0

Step 3: Check add-on compatibility

aws eks describe-addon-versions --kubernetes-version 1.37 \
  --query 'addons[].{name:addonName,default:addonVersions[?compatibilities[?defaultVersion==`true`]]|[0].addonVersion}' \
  --output table

Also check self-managed controllers: AWS Load Balancer Controller, Karpenter, cert-manager, external-dns, Istio/Cilium, the EBS/EFS CSI drivers, and your service mesh. Each publishes a supported-Kubernetes matrix; confirm 1.37 is on it.

Step 4: Rehearse on a staging clone

Create a staging cluster from the same IaC at 1.36, deploy production manifests, then upgrade it:

eksctl upgrade cluster --name staging --version 1.37 --approve
# or Terraform: bump cluster_version = "1.37" and apply

Then run the seven checks above, your smoke tests, and a synthetic load test. Watch for Pods stuck in ContainerCreating (SELinux), nodes failing to join (kubelet flags), and event volume spikes (eventRecordQPS).

Step 5: Upgrade production in the right order

Control plane: one minor version at a time (1.36 → 1.37 only).
EKS add-ons: VPC CNI, CoreDNS, kube-proxy, EBS CSI, Pod Identity Agent.
Data plane: managed node groups (rolling), Karpenter (drift), or Auto Mode (automatic).
Self-managed controllers.

Step 6: Post-upgrade verification

kubectl get nodes -o wide                        # all nodes Ready on v1.37
kubectl get pods -A | grep -vE 'Running|Completed'
kubectl get events -A --sort-by=.lastTimestamp | tail -50
kubectl get apiservices | grep -v True          # unhealthy aggregated APIs

EKS 1.37 upgrade checklist (copy-paste)

[ ] EKS Upgrade Insights: zero ERROR findings
[ ] kubent / pluto clean against v1.37
[ ] All EKS add-ons on a 1.37-compatible version
[ ] Third-party controllers confirm 1.37 support
[ ] SELinux: CSI drivers and seLinuxOptions Pods audited; seLinuxChangePolicy: Recursive where needed
[ ] Static pods: no Secret/ConfigMap references
[ ] Kubelet: no deprecated cAdvisor flags; dashboards don't use dropped metrics
[ ] eventRecordQPS: 0 replaced with 5 where set
[ ] Auto Mode NodePools: consolidationPolicy set explicitly
[ ] HPAs: no accidental minReplicas: 0
[ ] kube-proxy: IPVS migration plan logged
[ ] No cgroup v1 nodes left
[ ] Staging upgrade rehearsed, smoke + load tests passed
[ ] Rollback plan: blue/green node groups ready (control plane cannot be downgraded)

FAQ

When did Amazon EKS release Kubernetes 1.37?

EKS and EKS Distro added Kubernetes 1.37 on October 2, 2026, about five weeks after the upstream release on August 26, 2026.

Can I downgrade an EKS cluster from 1.37 to 1.36?

No. EKS control plane upgrades are one-way. Your rollback options are at the node level (keep a 1.36 node group until 1.37 nodes are proven) or a blue/green cluster migration.

Can I skip from EKS 1.35 straight to 1.37?

No. The control plane upgrades one minor version at a time: 1.35 → 1.36 → 1.37. Nodes may lag the control plane within the supported skew, but plan for both hops.

What is the biggest risk when upgrading to EKS 1.37?

For most clusters it is SELinux mount labeling on Bottlerocket nodes, followed by custom kubelet configuration (deprecated cAdvisor flags and eventRecordQPS: 0). Auto Mode users should check the Balanced consolidation default.

Does EKS 1.37 remove any APIs?

The upstream release lists one deprecation/removal. The practical removals are behavioral: the PreventStaticPodAPIReferences gate is gone and deprecated kubelet cAdvisor flags now stop the kubelet from starting. Still run kubent or pluto to catch older deprecated APIs you never migrated.

How long is EKS 1.37 supported?

EKS gives each version 14 months of standard support followed by 12 months of extended support. Check the official EKS Kubernetes version lifecycle page for exact dates.

Sources

Planning an EKS upgrade and want a second pair of eyes? I help teams run zero-downtime Kubernetes upgrades on AWS at DevOps Cloud Consult.

Cut AWS NAT Gateway Costs: 7 Fixes for Platform Teams

Evgeny Anikiev — Thu, 22 Oct 2026 14:10:21 +0000

Find what flows through your NAT gateways, then move it to free or cheaper paths. Prices, break-even math, and a command for each fix.

By Evgeny Anikiev, AWS-certified DevOps engineer with 10+ years running build automation, CI/CD, and Kubernetes in production. Prices verified October 22, 2026, against AWS public pricing pages (US East list prices; check your Region).

TL;DR: A NAT gateway charges $0.045 per hour per AZ plus $0.045 for every GB it processes, including traffic to S3, ECR, and other AWS services. Most of that traffic doesn't need a NAT at all. Measure what flows through it first, then move AWS-bound traffic to VPC endpoints and keep the rest in the same AZ.

The seven fixes, roughly in order of savings:

Add free S3 and DynamoDB gateway endpoints.
Add interface endpoints for high-volume AWS APIs (ECR, CloudWatch Logs, STS).
Stop sending traffic across AZs to reach a NAT gateway.
Keep Kubernetes service traffic in-zone.
Send IPv6 egress through an egress-only internet gateway.
Release idle public IPv4 addresses.
Show each team its own NAT and data transfer bill.

What is an AWS NAT gateway?

An AWS NAT gateway is a managed service that lets resources in private subnets open connections to the internet and to public AWS service endpoints, while blocking connections coming in from outside. AWS bills it by the hour and by every GB it processes, which is why it shows up on so many networking bills.

How much does an AWS NAT gateway cost?

An AWS NAT gateway costs $0.045 per NAT gateway-hour and $0.045 per GB of data processed, at the US East list price AWS uses in its own pricing example. Partial hours bill as full hours, and the per-GB charge applies "regardless of the traffic's source or destination." Internet egress is billed on top.

The rates that matter for this playbook (US East, list price):

NAT gateway (zonal): $0.045 per hour, about $32.85 per month per gateway.
NAT gateway (regional mode): $0.045 per hour per AZ it runs in. Three AZs means three NAT gateway-hours every hour.
NAT data processing: $0.045 per GB, both directions, any destination.
Internet data transfer out: $0.09 per GB in the first tier, after 100 GB free per month across your account.
Gateway VPC endpoint (S3, DynamoDB): no hourly or data processing charge.
Interface VPC endpoint (PrivateLink): $0.01 per hour per AZ, plus $0.01 per GB processed.
Public IPv4 address: $0.005 per hour, in use or idle (about $3.65 per month).
Cross-AZ traffic inside a Region: $0.01 per GB, charged on each side of the transfer.

The processing fee is where the money goes. A node pulling a 1 GB container image from ECR through a NAT gateway pays $0.045 for that pull. Multiply that by hundreds of nodes scaling up and down every day. That traffic never needed to leave AWS.

How do I find what is using my NAT gateway?

Start with two numbers: how much each NAT gateway processes, and where those bytes go.

Cost Explorer. Filter Service = EC2-Other and group by Usage Type. Look for NatGateway-Bytes, NatGateway-Hours, and DataTransfer-Regional-Bytes (cross-AZ).

Cost and Usage Report (CUR) in Athena. Rank NAT gateways by cost:

SELECT line_item_resource_id,
       line_item_usage_type,
       ROUND(SUM(line_item_unblended_cost), 2) AS cost
FROM cur
WHERE line_item_usage_type LIKE '%NatGateway%'
  AND line_item_usage_start_date >= date_add('day', -30, current_date)
GROUP BY 1, 2
ORDER BY cost DESC
LIMIT 20;

VPC Flow Logs on the NAT gateway ENI. This tells you where the bytes go. Enable flow logs on the NAT's network interface, query them in Athena, and rank destinations:

SELECT dstaddr,
       ROUND(SUM(bytes) / 1e9, 1) AS gb
FROM vpc_flow_logs
WHERE interface_id = 'eni-0123456789abcdef0'
  AND day >= '2026/10/01'
GROUP BY dstaddr
ORDER BY gb DESC
LIMIT 25;

Match the top destination IPs against AWS's published ranges to see which ones are AWS services:

curl -s https://ip-ranges.amazonaws.com/ip-ranges.json \
  | jq -r '.prefixes[] | select(.region=="us-east-1") | "\(.ip_prefix) \(.service)"' \
  > aws-ranges.txt

On container platforms, expect S3 (container image layers, artifacts, logs), ECR, CloudWatch Logs, and STS near the top. All of those can bypass the NAT.

How to reduce NAT gateway costs: seven fixes

1. Add S3 and DynamoDB gateway endpoints (free)

What it does: A gateway endpoint adds a route so traffic to S3 or DynamoDB stays on the AWS network and skips the NAT. AWS charges nothing for it, hourly or per GB.

Why it matters for containers: ECR stores image layers in S3. Without an S3 gateway endpoint, every layer download pays the NAT processing fee.

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0123456789abcdef0 \
  --service-name com.amazonaws.us-east-1.s3 \
  --vpc-endpoint-type Gateway \
  --route-table-ids rtb-0aaa rtb-0bbb rtb-0ccc

Attach it to every private route table, then repeat with com.amazonaws.us-east-1.dynamodb if you use DynamoDB. It costs nothing and needs no application changes, so ship it first.

2. Add interface endpoints for high-volume AWS APIs

What it does: An interface endpoint (PrivateLink) puts a private IP for an AWS service inside your subnets. Traffic costs $0.01 per GB at the endpoint instead of $0.045 per GB at the NAT.

Break-even: Each endpoint costs about $7.30 per AZ per month. You save $0.035 per GB moved off the NAT, so an endpoint pays for itself at roughly 210 GB per month per AZ. For a three-AZ VPC, that is about 630 GB per month per service.

Good candidates for container platforms:

ecr.api and ecr.dkr (image manifests and auth; layers go through S3)
logs (CloudWatch Logs, often the noisiest)
sts (IRSA and EKS Pod Identity token calls)
sqs, kinesis-streams, secretsmanager, depending on your workload

Use your flow log ranking from the queries above to decide. Don't create endpoints for services that move a few GB a month; they will cost more than they save.

3. Stop sending traffic across AZs to reach a NAT gateway

What it does: If private subnets in AZ b and AZ c route to a single NAT gateway in AZ a, every byte pays cross-AZ transfer on top of NAT processing.

The math: Two extra zonal NAT gateways cost about $65.70 per month. Cross-AZ traffic costs $0.02 per GB counting both sides. Above roughly 3.3 TB per month of cross-AZ NAT traffic, one NAT per AZ is cheaper, and it removes a single point of failure too.

Check your route tables:

aws ec2 describe-route-tables \
  --filters Name=vpc-id,Values=vpc-0123456789abcdef0 \
  --query 'RouteTables[].{rt:RouteTableId,subnets:Associations[].SubnetId,nat:Routes[?NatGatewayId].NatGatewayId}' \
  --output json

Each private subnet's route table should point at the NAT gateway in the same AZ.

Or use a regional NAT gateway. Since November 2025, a NAT gateway can run in regional availability mode: one gateway that expands into each AZ where you have workloads, with no public subnet per AZ and no per-AZ route table edits. It bills per AZ-hour, so it costs the same as one zonal NAT per AZ. AWS's launch post lists two caveats. Expansion into a new AZ takes 15 to 20 minutes on average, and up to 60. Until it finishes, traffic from that AZ goes to another AZ's NAT and pays cross-AZ charges.

4. Keep Kubernetes service traffic in-zone

Cross-AZ charges don't only come from NAT routing. Service-to-service traffic in EKS crosses AZs all the time because kube-proxy spreads connections across all endpoints by default.

On Kubernetes 1.33 and later, ask for zone-local routing per Service:

apiVersion: v1
kind: Service
metadata:
  name: orders
spec:
  trafficDistribution: PreferClose
  selector:
    app: orders
  ports:
    - port: 80
      targetPort: 8080

PreferClose sends traffic to endpoints in the client's zone when they exist and falls back to others when they don't. Pair it with topology spread constraints so each zone has replicas to receive the traffic. This traffic never touches the NAT, so it won't show up in your NAT numbers. Size it with the DataTransfer-Regional-Bytes usage type in Cost Explorer. If you're also planning an upgrade, see my EKS 1.37 upgrade checklist.

5. Send IPv6 egress through an egress-only internet gateway

An egress-only internet gateway lets IPv6 workloads reach the internet without a NAT gateway, so there is no NAT hourly or processing charge on that traffic. Standard data transfer out still applies. If your EKS cluster runs in IPv6 mode, or your dependencies (package registries, SaaS APIs) support IPv6, route ::/0 to an egress-only internet gateway and keep the NAT for IPv4-only destinations.

6. Release idle public IPv4 addresses

Every public IPv4 address costs $0.005 per hour whether it is in use or not. Find Elastic IPs that aren't attached to anything:

aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==null].[PublicIp,AllocationId,Tags]' \
  --output table

VPC IPAM's Public IP Insights view shows every public IPv4 in the account, including ones attached to load balancers and instances you may have forgotten.

7. Show each team its own network bill

Platform teams own the VPC, so NAT and data transfer costs usually land in one shared bucket that nobody feels responsible for. Split it:

Tag NAT gateways and endpoints with the owning team or environment and activate those tags as cost allocation tags.
Group flow logs by source subnet (or by pod CIDR in EKS) to attribute NAT bytes to the team that generated them.
Publish a monthly showback: GB through NAT per team, top destinations, and which fix from this list would remove it.

A monthly report line such as "your service pulled 4 TB of images through the NAT; an S3 gateway endpoint makes that free" gives a team a specific action to take.

Worked example: an EKS cluster across three AZs

This is an illustrative model using the list prices above, not a client bill. Assume three zonal NAT gateways process 20 TB (20,480 GB) per month:

15 TB to S3 (image layers, artifacts)
2 TB to CloudWatch Logs
3 TB to the internet

Before:

NAT hours: 3 × $0.045 × 730 = $98.55
NAT processing: 20,480 GB × $0.045 = $921.60
Total NAT cost: about $1,020 per month

After fixes 1 and 2:

S3 moves to a gateway endpoint: $0
CloudWatch Logs moves to an interface endpoint: 2,048 GB × $0.01 + 3 AZs × $7.30 = $42.38
NAT keeps only internet traffic: 3,072 GB × $0.045 + $98.55 = $236.79
Total: about $279 per month, a 73% cut

Internet data transfer out (about $276 at $0.09 per GB) is the same in both cases; endpoints don't change egress pricing. Your traffic mix will differ, so run the flow log queries above to get your own split before estimating savings.

NAT gateway cost checklist (copy-paste)

[ ] Cost Explorer: NatGateway-Bytes and DataTransfer-Regional-Bytes baselined
[ ] Flow logs enabled on every NAT ENI; top 25 destinations identified
[ ] S3 gateway endpoint attached to every private route table
[ ] DynamoDB gateway endpoint attached (if used)
[ ] Interface endpoints for AWS services above ~210 GB per AZ per month
[ ] Each private subnet routes to a NAT in its own AZ (or regional NAT in automatic mode)
[ ] Kubernetes Services with heavy east-west traffic use trafficDistribution: PreferClose
[ ] IPv6 egress goes through an egress-only internet gateway
[ ] No unattached Elastic IPs
[ ] NAT gateways and endpoints tagged; monthly showback per team

FAQ

Why is my AWS NAT gateway bill so high?

Usually because AWS-bound traffic (S3, ECR image layers, CloudWatch Logs) goes through the NAT and pays $0.045 per GB in processing. Container platforms with frequent node scaling pull large images many times a day. Enable flow logs on the NAT ENI to confirm where the bytes go.

Does a NAT gateway charge for traffic to S3?

Yes, if there is no S3 gateway endpoint. The NAT processing fee applies to all traffic it handles, regardless of destination. An S3 gateway endpoint is free and removes that traffic from the NAT completely.

Is a regional NAT gateway cheaper than zonal NAT gateways?

Not on price. Regional mode bills $0.045 per hour for each AZ it runs in, the same as one zonal NAT per AZ, and the same per-GB fee. It saves operational work (no public subnet per AZ, no route table edits) and helps avoid cross-AZ routing once it has expanded into every AZ you use.

Should I replace NAT gateways with NAT instances?

For small or non-production environments, a NAT instance on a small Graviton instance (for example with the open-source fck-nat AMI) avoids the per-GB processing fee. You take on patching, scaling, and failover yourself. For production, fix the traffic first with endpoints; the remaining NAT bill is often small enough that the managed gateway is worth it.

VPC endpoint vs NAT gateway: which is cheaper for AWS service traffic?

A gateway endpoint (S3, DynamoDB) is always cheaper because it is free. An interface endpoint costs $0.01 per GB plus about $7.30 per AZ per month, against $0.045 per GB through a NAT. It pays for itself above roughly 210 GB per month per AZ for that service.

How much does cross-AZ data transfer cost on AWS?

Traffic between Availability Zones in the same Region is billed at $0.01 per GB on each side, so $0.02 per GB in total. It appears as DataTransfer-Regional-Bytes in Cost Explorer. Same-AZ NAT routing and zone-aware Kubernetes Services reduce it.

How much does a NAT gateway cost per month?

About $32.85 per month per zonal gateway in hourly charges at US East list price, before data. Add $0.045 for every GB processed. A three-AZ setup starts at about $98.55 per month before any traffic.

Sources

Want a second pair of eyes on your AWS network bill? I run NAT and data transfer cost reviews for platform teams at DevOps Cloud Consult.

Migrating AI Agents to AWS: 15 Bedrock and AgentCore Checks

Evgeny Anikiev — Thu, 22 Oct 2026 14:04:14 +0000

A readiness assessment for AI teams moving agents from a prototype or another provider to Amazon Bedrock and AgentCore. Score yourself out of 30, with the evidence, AWS service, and command for each check.

By Evgeny Anikiev, AWS-certified DevOps engineer with 10+ years running build automation, CI/CD, and Kubernetes in production. AWS service details verified October 22, 2026.

TL;DR: Score 15 checks from 0 to 2. They cover cost per task, evaluations, model access, quotas, AgentCore Runtime, tools, identity, data, observability, and rollback. A total of 24 or more means you can move production traffic. From 15 to 23, fix the zeros and run a shadow or canary pilot. Below 15, keep the agent where it is and build the foundations first.

Three changes from the past year that older checklists miss:

Amazon Bedrock retired its Model Access page in October 2025. Serverless foundation models are now enabled by default in commercial Regions, so restricting models is your job, done with IAM and service control policies.
AgentCore Policy became generally available on March 3, 2026. It checks every tool call that passes through AgentCore Gateway against Cedar rules.
AgentCore Evaluations became generally available on March 31, 2026, with 13 built-in evaluators and online scoring of live traces.

What is an AI migration readiness assessment?

An AI migration readiness assessment is a review, done before production traffic moves, of whether an AI team can run its agents on a new platform safely and within budget. For AWS, that means checking cost per task, evaluation baselines, model governance, Bedrock quotas, AgentCore hosting, tool access, identity, data handling, monitoring, and rollback on Amazon Bedrock and Amazon Bedrock AgentCore.

It follows the six perspectives of the AWS Cloud Adoption Framework (Business, People, Governance, Platform, Security, Operations), applied to agents instead of servers. Typical starting points are an agent calling the OpenAI or Anthropic API directly, a LangGraph or CrewAI service in a container, or a notebook prototype that leadership now wants in front of customers.

How do you score it?

Give each check a score:

0: missing, or exists only in someone's head.
1: exists, but is incomplete, untested, or out of date.
2: written down, owned by a named person, and tested.

Add the scores. The maximum is 30.

24 to 30, ready: move production traffic in stages.
15 to 23, pilot: fix every 0, then run the agent in shadow mode or on a small share of traffic.
0 to 14, not ready: keep the current setup and build the foundations.

One rule overrides the total: a 0 on check 2 (evaluation baseline), check 11 (identity and tool policy), or check 15 (rollback) blocks production at any score. Without a baseline you can't tell whether the move made answers worse. Without tool policy an agent can call anything its credentials allow. Without rollback a bad model or prompt change stays live until someone fixes it by hand.

A copy-paste scoring sheet:

check,perspective,score,evidence,owner
01 cost per task,business,,,
02 evaluation baseline,business,,,
03 owners and on-call,people,,,
04 framework and AgentCore skills,people,,,
05 model access controls,governance,,,
06 cost attribution,governance,,,
07 quotas and inference routing,platform,,,
08 runtime hosting,platform,,,
09 tools behind Gateway,platform,,,
10 memory and RAG data,platform,,,
11 identity and tool policy,security,,,
12 data protection and network,security,,,
13 observability and logging,operations,,,
14 online evaluations,operations,,,
15 rollout and rollback,operations,,,

Business

1. Do you know the cost per task?

Agents bill per token, and one user request often makes several model calls. Measure input and output tokens per task on your current setup, then price them on Bedrock. Score 2 if finance has seen a cost per task and a monthly estimate at expected volume.

def cost_per_task(calls, in_tokens, out_tokens, in_price, out_price, cached=0, cache_discount=0.9):
    """Prices are USD per million tokens. cached = input tokens per call served from the prompt cache."""
    uncached = in_tokens - cached
    per_call = (uncached * in_price
                + cached * in_price * (1 - cache_discount)
                + out_tokens * out_price) / 1_000_000
    return calls * per_call

# Example prices, not a quote: $3 input and $15 output per million tokens.
print(round(cost_per_task(6, 8000, 1000, 3, 15), 3))               # 0.234
print(round(cost_per_task(6, 8000, 1000, 3, 15, cached=6000), 3))  # 0.137

The numbers that move this figure:

Prompt caching: AWS says it can cut costs by up to 90% on supported models. Cache-read discounts differ by model, and some models charge extra for cache writes, so test with your real prompts. It works only on on-demand inference.
Batch inference: 50% lower than on-demand for select models, for work that can wait.
Service tiers: Flex costs 50% less than Standard for non-urgent requests. Priority costs 75% more for the fastest responses.

2. Do you have an evaluation baseline from the current setup?

Build a golden set of real requests with expected answers or grading rules, and score your current agent on it before you change anything. Run the same set on Bedrock after the move. Score 2 if the set has at least a few hundred cases, covers your main task types, and has a pass threshold the product owner agreed to. A 0 here blocks production.

People

3. Are owners and on-call named?

Someone owns the prompts, someone owns the tools and their APIs, and someone gets paged when the agent fails at 2 a.m. Score 2 if all three are named and the on-call runbook covers model errors, throttling, and tool failures.

4. Can the team build and run on AgentCore?

AgentCore Runtime is framework-agnostic. AWS documents agents built with Strands Agents, LangGraph, and CrewAI running on it, so most teams keep their code. Score 2 if at least two engineers have deployed a test agent to AgentCore Runtime and called it with real credentials.

Governance

5. Who controls which models can be called?

Since October 2025, serverless Bedrock models are enabled by default. Anthropic models still need a one-time use-case form, which covers member accounts when submitted from the management account. Restrict models with a service control policy. Score 2 if an allow-list exists and is enforced at the organization level.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnapprovedBedrockModels",
      "Effect": "Deny",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "NotResource": [
        "arn:aws:bedrock:*::foundation-model/anthropic.*",
        "arn:aws:bedrock:*::foundation-model/amazon.nova-*",
        "arn:aws:bedrock:*:*:inference-profile/us.anthropic.*",
        "arn:aws:bedrock:*:*:inference-profile/us.amazon.nova-*"
      ]
    }
  ]
}

Replace the model families with your approved list. The Converse API uses the same bedrock:InvokeModel permission, so this policy covers it too.

6. Can you split the Bedrock bill by team and agent?

Create an application inference profile per agent or team, tag it, and activate the tags as cost allocation tags. Calls made through the profile then show up per tag in Cost Explorer. Score 2 if every production agent calls models through a tagged profile.

Platform

7. Are quotas and inference routing sized?

Bedrock quotas are tokens per minute and requests per minute, set per model and per Region. Cross-Region inference spreads load across Regions in one geography (geo) or worldwide (global), and not every model supports global. Score 2 if you have compared peak tokens per minute against your quotas in Service Quotas, requested increases in advance, and chosen geo or global routing to match your data residency rules. AWS gives priority on increases to accounts that already use their current quota, so build up real traffic before asking.

8. Is the hosting model chosen?

AgentCore Runtime runs each session in its own microVM with separate compute, memory, and filesystem, and wipes it when the session ends. A session ends after 15 minutes of inactivity by default and lives up to 8 hours. For longer jobs, AgentCore Runtime instances run up to 14 days. Score 2 if your longest task fits these limits and you have load-tested cold starts at expected concurrency.

9. Are tools exposed through AgentCore Gateway?

Gateway turns existing APIs and Lambda functions into MCP tools that agents can discover and call. It is also where AgentCore Policy checks each call. Score 2 if every tool the agent can call goes through Gateway, and none are hard-coded HTTP calls inside the agent.

10. Are memory and RAG data planned?

Decide what goes into AgentCore Memory (conversation history and long-term facts per user) and what goes into a Bedrock Knowledge Base (documents for retrieval). For each, write down the data source, refresh schedule, retention period, and who may read it. Score 2 if the retrieval quality on your golden set matches or beats the current setup.

Security

11. Are identity and tool policy in place?

Use AgentCore Identity for inbound authentication (who may call the agent) and for outbound credentials to tools, so no API keys live in agent code or environment variables. Add AgentCore Policy rules on the Gateway, for example limiting a refund tool to amounts below a threshold. Score 0 if the agent holds long-lived keys or can call tools without a policy check. A 0 here blocks production.

12. Are data protection and network paths decided?

AWS states that Bedrock does not use your prompts and completions to train AWS models or share them with model providers. Your security team will still ask about three more things:

private connectivity through AWS PrivateLink endpoints for Bedrock and AgentCore
Amazon Bedrock Guardrails for content filters and PII redaction
whether cross-Region inference fits your data residency rules

Score 2 if security has signed off on all three in writing.

Operations

13. Can you see what the agent did?

AgentCore Observability records traces of each step: model calls, tool calls, and latency. Bedrock model invocation logging is disabled by default. Turn it on for the audit trail, and treat the logs as sensitive, because they contain full prompts and responses.

aws bedrock put-model-invocation-logging-configuration \
  --logging-config '{
    "cloudWatchConfig": {
      "logGroupName": "/bedrock/model-invocations",
      "roleArn": "arn:aws:iam::111122223333:role/BedrockInvocationLogging"
    },
    "textDataDeliveryEnabled": true
  }'

Score 2 if traces, invocation logs, and alarms on errors, throttling, and latency exist in the production account.

14. Are evaluations running on live traffic?

AgentCore Evaluations samples live traces and scores them with built-in evaluators for response quality, safety, task completion, and tool use, or with your own. Score 2 if online evaluation runs on production traffic with an alarm when scores drop below the threshold from check 2.

15. Can you roll back a model, prompt, or agent change?

Pin model versions instead of relying on whatever is newest. Deploy agent changes as new AgentCore Runtime versions behind an endpoint, so you can move traffic back. Track Bedrock model end-of-life dates. Score 2 only if you rehearsed a rollback in a non-production account. A 0 here blocks production.

Worked example: a support agent leaving a direct API setup

This example is hypothetical, built to show the scoring. A team runs a LangGraph customer support agent in a container, calling a model provider's API directly with a key in an environment variable. It handles about 10,000 tasks a month. Its first scoring pass:

Business (checks 1–2): 1, 0. Token counts exist, but there is no golden set.
People (3–4): 1, 0. One engineer owns everything, and no one has used AgentCore.
Governance (5–6): 0, 0. No model allow-list, no cost tags.
Platform (7–10): 1, 1, 0, 1. Quotas not checked against peak, tools called directly from code.
Security (11–12): 0, 1. API keys in environment variables, no PrivateLink yet.
Operations (13–15): 1, 0, 0. Application logs only, no evaluations, no rollback path.

Total: 7 out of 30, with blockers on checks 2, 11, and 15. A sensible next four to six weeks:

Build a golden set from past tickets and score the current agent.
Deploy the same LangGraph code to AgentCore Runtime in a non-production account.
Move the agent's tools behind Gateway with Identity and a first Policy rule.
Add the model allow-list and a tagged application inference profile.
Run the golden set on both setups, then score all 15 checks again.

With the example prices from check 1, caching 6,000 of 8,000 input tokens per call would take the cost per task from about $0.23 to about $0.14, or from about $2,340 to about $1,370 a month at 10,000 tasks. Confirm with your model's real cache pricing.

FAQ

Do I need AgentCore to use Amazon Bedrock?

No. You can call Bedrock models from any application with the Converse or InvokeModel APIs. AgentCore adds hosting, memory, tool gateway, identity, policy, observability, and evaluations for agents, and works with models from Bedrock or other providers.

Can I run LangGraph or CrewAI agents on AgentCore?

Yes. AgentCore Runtime is framework-agnostic, and AWS documents agents built with Strands Agents, LangGraph, and CrewAI running on it.

Does Amazon Bedrock train on my prompts?

AWS states that Bedrock does not use your prompts and completions to train AWS models and does not share them with third-party model providers.

Do I still need to request model access in Bedrock?

Not for most models. Since October 2025, serverless models are enabled by default in commercial Regions. Anthropic models need a one-time use-case form. Some AWS Marketplace models need a subscription, which Bedrock tries to create on first use.

How long can an AgentCore Runtime session run?

Up to 8 hours per session on microVMs, with a default idle timeout of 15 minutes. AgentCore Runtime instances support work up to 14 days.

How do I get higher Bedrock quotas?

Request increases in Service Quotas per model and Region, and use cross-Region inference profiles to spread load. AWS gives priority to accounts that already use their existing quota.

What is the difference between AgentCore Policy and Bedrock Guardrails?

Policy controls which tool calls an agent may make, with Cedar rules checked at AgentCore Gateway. Guardrails filter model inputs and outputs, for example blocking topics or redacting PII.

Sources

Moving an agent to Bedrock and AgentCore? I run readiness assessments and build the AWS foundations for AI teams at DevOps Cloud Consult: landing zone, model access controls, observability, and cost tracking. If you scored under 24, that is the work I can help with.

DEV Community: Evgeny Anikiev

Bedrock vs Self-Hosted LLMs on EKS: The Break-Even Math

Which costs less: Amazon Bedrock or self-hosting on EKS?

What does each option cost?

Bedrock: per token

Self-hosted: per GPU-hour

Where is the break-even point?

Worked example: the support agent from the readiness checklist

What costs does the per-hour price leave out?

When does self-hosting on EKS make sense?

How do I test self-hosting on EKS?

FAQ

Related reading

Sources

EKS 1.37 Upgrade Checklist: What Breaks and How to Test It

What is new in Kubernetes 1.37 on EKS?

The EKS 1.37 breaking-change checklist

1. SELinux mount labeling is on by default (SELinuxMount)

2. Static pods can no longer reference Secrets or ConfigMaps

3. Kubelet refuses to start with deprecated cAdvisor flags

4. eventRecordQPS: 0 now means "no limit"

5. EKS Auto Mode: default consolidation policy is now Balanced

6. HPA scale-to-zero is enabled by default

7. kube-proxy IPVS mode is deprecated

Also on the radar

How to test an EKS 1.37 upgrade safely

Step 1: Run EKS Upgrade Insights

Step 2: Scan manifests for deprecated APIs

Step 3: Check add-on compatibility

Step 4: Rehearse on a staging clone

Step 5: Upgrade production in the right order

Step 6: Post-upgrade verification

EKS 1.37 upgrade checklist (copy-paste)

FAQ

Related reading

Sources

Cut AWS NAT Gateway Costs: 7 Fixes for Platform Teams

What is an AWS NAT gateway?

How much does an AWS NAT gateway cost?

How do I find what is using my NAT gateway?

How to reduce NAT gateway costs: seven fixes

1. Add S3 and DynamoDB gateway endpoints (free)

2. Add interface endpoints for high-volume AWS APIs

3. Stop sending traffic across AZs to reach a NAT gateway

4. Keep Kubernetes service traffic in-zone

5. Send IPv6 egress through an egress-only internet gateway

6. Release idle public IPv4 addresses

7. Show each team its own network bill

Worked example: an EKS cluster across three AZs

NAT gateway cost checklist (copy-paste)

FAQ

Related reading

Sources

Migrating AI Agents to AWS: 15 Bedrock and AgentCore Checks

What is an AI migration readiness assessment?

How do you score it?

Business

People

Governance

Platform

Security

Operations

Worked example: a support agent leaving a direct API setup

FAQ

Related reading

Sources

1. SELinux mount labeling is on by default (`SELinuxMount`)

4. `eventRecordQPS: 0` now means "no limit"

5. EKS Auto Mode: default consolidation policy is now `Balanced`