Container Cost Optimization: ECS, Fargate and Kubernetes

Container cost optimization is reducing the cost of running containerized workloads by matching what you pay for to what the containers actually use. The first step is knowing which of three billing models a workload runs under, because the effective levers differ in each.

Model 1: you pay for nodes

On ECS with EC2 capacity, or on Kubernetes node pools, you pay for virtual machines and the containers share them. Cost falls only when there are fewer or smaller instances. That makes packing the lever: task or pod sizes set how many fit per instance, and a cluster or node autoscaler removes capacity that is no longer needed. Kubernetes’ node consolidation reasons about pod requests rather than measured usage, so inflated requests keep nodes alive. The Kubernetes cost optimization guide covers this model in depth.

Model 2: you pay for the requested size

On AWS Fargate, for both ECS tasks and EKS pods, pricing is based on the requested vCPU, memory, operating system, CPU architecture, and storage, from the time the image download starts until the task or pod terminates. Billing is per second with a one-minute minimum for Linux, and a five-minute minimum for Windows containers. GKE Autopilot’s general-purpose workloads follow the same idea: they are billed on pod resource requests.

Here there is no packing to optimise. Every unit of requested memory is paid for directly, so right-sizing the task definition or pod spec is the whole game, and a task that runs all night costs the same whether it is busy or idle.

Model 3: you pay while it serves traffic

Some container platforms bill closer to request activity:

• Google Cloud Run defaults to request-based billing, where instances are charged only while processing requests, with billable time rounded up to the nearest 100 milliseconds. Instances kept warm with minimum instances are billed at a lower idle rate. Instance-based billing instead charges for the entire lifecycle of each instance, even when no requests arrive.
• AWS App Runner charges for the memory of provisioned container instances while the application is idle, and for compute and memory while it processes requests, billed per second. Pausing a service reduces its compute capacity to zero; the application loses ephemeral state and redeploys on resume.

In this model the costly settings are the ones that keep capacity warm: minimum instances, provisioned instances, and instance-based billing.

Levers that apply everywhere

• Size from measurement. Set CPU and memory from observed peaks plus headroom, not from defaults copied between services.
• Scale non-production to zero. An ECS service with a desired count of zero runs no tasks. Application Auto Scaling for ECS supports scheduled actions, so a service’s capacity can follow a timetable.
• Keep warm capacity deliberate. Minimum instances and provisioned capacity buy latency; review them per environment.

Where ZopNight helps

ZopNight discovers ECS clusters and services, including whether a service runs on Fargate or EC2 capacity providers, and can start and stop ECS services by scaling them and pause or resume App Runner services on a schedule. For services that should stay on, its autoscaler policies can manage ECS service scaling through Application Auto Scaling, with an option to adopt an existing cloud policy rather than overwrite it. Scheduling and scaling actions need a read and write connection.

See the ECS service schedule page, serverless cost management, and autoscaling fundamentals.