Understanding BYOC AWS infrastructure cost: HA topology and sizing
Last updated: September 25, 2026
Overview
Customers running BYOC (bring-your-own-cloud) sometimes see AWS infrastructure spend that looks high, and ask why there are so many Redis/ElastiCache nodes, or whether EBS throughput and EC2/EKS node counts can be reduced. In most cases this comes from the default high-availability (HA) topology that each BYOC data plane provisions, not from misconfiguration.
Why the footprint looks large
Each BYOC data plane is provisioned for HA by default. It spans multiple availability zones, and both RDS and ElastiCache run in Multi-AZ mode with automatic failover.
For Redis specifically, BYOC uses Redis Cluster. The keyspace is sharded across 3 primary nodes, and each primary has its own standby read replica. That means 6 Redis nodes per data plane is the expected HA footprint (3 shards x primary+replica), not 6 independent caches that can be removed individually.
Running more than one data plane (for example, a staging/test data plane alongside production) duplicates this entire baseline: EKS, EC2/node groups, RDS, ElastiCache, EBS, NAT gateways, load balancers, and PrivateLink endpoints. That duplication is usually the biggest driver of total AWS spend, not any single oversized resource.
Stateless LangSmith services and Kubernetes node capacity scale automatically with demand, using horizontal pod autoscaling and cluster autoscaling (Karpenter). Managed database HA topology and instance sizes are fixed BYOC defaults and are not customer-tunable directly; changing them requires a change from the LangChain team.
Reducing cost
HA and instance sizing for BYOC data planes are LangChain-managed defaults. If you want to run a data plane without HA, or on smaller instance sizes, this requires LangChain to review and apply the change per data plane. A few options, roughly in order of impact:
Remove Redis HA for a data plane. The Redis Cluster sharding stays in place, but the standby replicas are removed. This causes a brief disruption (typically a few minutes) during the changeover, and some requests may fail during that window. Instance size for Redis and Postgres/RDS can also be lowered once HA is removed.
Remove ClickHouse HA replicas. This is also possible, but re-adding replicas later takes longer, because data has to be replicated into the newly stood-up nodes. Note that ClickHouse instance size may already be at the minimum available, so sizing isn't always a further lever there.
Target non-production data planes first. Reducing HA and instance size on staging/test data planes removes a duplicated cost baseline without affecting production availability, and is the lowest-risk place to start.
Delete an unused data plane. If a staging/test data plane doesn't need continuous availability, deleting it entirely is the most direct way to remove its duplicated baseline cost.
AWS Savings Plans can reduce eligible EC2 costs, but don't cover ElastiCache, RDS, EBS, NAT gateway, load balancer, or PrivateLink charges. Consider right-sizing and HA changes before or alongside a savings plan, since those address the charges a savings plan can't.