EKS Fargate vs. EC2 Pricing Compared

FinOps AI’s safe-remediation workflow helps teams turn supported AWS cost findings into proposed, guarded changes, check each one after it runs, and roll back reversible changes that fail that check. Evaluating EKS Fargate vs EC2 pricing often forces engineering teams to choose between resizing an EC2 node group or moving specific workloads to Fargate. When Kubernetes resource metrics show oversized instances or unattached storage, you need to know if shifting your compute model will measurably lower the AWS bill. FinOps AI provides multi-cloud cost visibility, AI spend monitoring, and Kubernetes cost visibility necessary to spot these gaps, though you must evaluate the underlying AWS mechanics to understand which option makes sense. Currently, GCP provides cost and usage visibility within our platform, but GCP remediation is not supported; on AWS, supported findings follow an approval-gated remediation and rollback loop. When a platform engineer reviews a finding and proposes an AWS change, an owner or admin approves it under the account's safety rules. The platform then executes the change, runs a post-action check, rolls back a reversible action that fails it, and, for stops and EBS deletions, books the estimated saving for a re-check about seven days later.

EKS Fargate vs. EC2: The Cost Model

Neither option is universally cheaper, because they measure compute differently. Fargate bills each pod’s rounded, provisioned capacity for its lifetime, while EC2 bills whole worker nodes from launch to termination. Fargate is highly competitive when workloads are brief or sparse and would otherwise leave worker nodes sitting idle. EC2 frequently becomes the more cost-effective choice when steady workloads pack well onto shared instances, or when your organization applies purchase options like compute savings plans.

To build an accurate comparison, you need to normalize the inputs. The following examples use US East (N. Virginia), Linux/x86 architecture, and public On-Demand rates before taxes or discounts. A 730-hour month serves as the baseline to compare continuous usage, rather than representing a fixed AWS billing period. These models exclude optional EKS Auto Mode and Provisioned Control Plane charges, focusing entirely on the data-plane compute.

How EKS Fargate Calculates Compute Costs

Fargate pricing follows provisioned pod capacity rather than the application's observed CPU and memory usage. AWS determines a pod’s compute reservation strictly from its container requests, and for EKS specifically, adds a flat 256 MB to the total requested memory to account for Kubernetes system components. The platform then rounds that total up to a supported compute size.

The rates on the AWS Fargate Pricing page for US East (N. Virginia) Linux/x86 set the baseline compute cost. The page lists $0.000011244 per vCPU-second and $0.000001235 per GB-second. Those rates convert to approximately $0.0404784 per vCPU-hour and $0.004446 per GB-hour.

For Amazon EKS Fargate, CPU and memory requests must equal their limits for every container because Pods run with guaranteed priority. The running pod's CapacityProvisioned annotation reports its enforced capacity. For example, when a pod requests 1 vCPU and 8 GB of memory, Fargate adds 256 MB to the reservation. That pushes the reservation above the 8-GB maximum for a 1-vCPU configuration, so Fargate rounds up to the next available configuration. As the EKS Fargate pod configuration documentation explains, Fargate provisions this pod with 2 vCPU and 9 GB, and the annotation determines its cost.

Billing duration begins the moment the container image starts downloading and ends when the pod terminates. AWS rounds the duration up to the nearest second, applying a one-minute minimum charge. The first 20 GB of ephemeral storage is included in the base compute price, while any additional configured storage incurs separate charges. Because completed or failed Kubernetes Job pods can remain on the cluster until explicitly deleted, they can continue to accrue Fargate charges long after the work finishes.

How Amazon EC2 Nodes Calculate Compute Costs

EC2 instances follow an entirely different pricing model based on whole-node uptime, meaning you pay for the worker node regardless of how many pods run on it or how much memory those pods leave unused. Linux On-Demand instances carry a 60-second minimum charge, followed by per-second billing until you stop or terminate the instance. EKS managed node groups handle the provisioning and lifecycle of these instances without adding a separate management fee on top of the standard compute charges.

To estimate an EC2 node cost, multiply the applicable On-Demand rate by the planned runtime. The official AWS EC2 pricing page describes per-instance-hour billing, so regularly refresh your internal models against its published rates.

Calculating node fit requires looking beyond advertised hardware specs to estimate allocatable capacity. AWS reserves a portion of the node's CPU and memory for the operating system and the kubelet, while DaemonSets for networking, logging, and security agents consume further resources on every node. If you launch an 8 GB node, your application pods might only have 6 GB of allocatable memory available. To model costs accurately, calculate the total monthly price of the instance and divide it across the workloads that share the node, factoring in your organization's specific purchase commitments.

Compare Three Workload Patterns

Comparing compute subtotals across different workload behaviors highlights the distinct financial trade-offs between the two architectures. The following examples apply the stated regional On-Demand rates and a 730-hour normalization to isolate compute costs. For this initial comparison, shared cluster fees and networking charges are excluded to focus strictly on the cost of running pods.

Steady Small Pods

Consider an application running 20 continuous pods, where each pod requests 0.25 vCPU and 0.5 GB of memory.

On Fargate, the platform adds the 256 MB Kubernetes overhead and rounds each pod up to the minimum supported configuration of 0.25 vCPU and 1 GB. At the calculated rate of $0.0145656 per pod-hour, a single pod costs roughly $10.63 per month, bringing the Fargate compute subtotal for 20 continuous pods to $212.66 per month.

Placing these same pods on EC2 requires calculating node fit. An m7i.large instance costs $73.58 per month. If you can fit seven of these pods onto a single node after accounting for system reservations and DaemonSets, three nodes will host the workload for $220.75 per month. If node overhead restricts you to six pods per node, you need four instances, raising the monthly compute cost to $294.34. Assuming seven pods per node is an aggressive packing strategy, so verifying actual allocatable capacity is mandatory before concluding that EC2 is cheaper for highly fragmented workloads.

Bursty Pods

Next, consider a batch processing job using six of those same small pods, active for exactly two hours a day over a 30-day period.

Fargate bills only for the time the pods exist. Assuming 60 billable hours per pod across the month, including the time required to pull the container image, the Fargate compute subtotal drops to $5.24 per month.

Running one m7i.large node on EC2 for 60 hours costs $6.05. However, if you keep that EC2 node running for the full 730-hour month to accommodate unpredictable job schedules, the node costs $73.58. Fargate excels when it prevents nodes from sitting idle. If those bursty pods can schedule onto an EC2 node already paid for by other continuous workloads, the marginal compute cost on EC2 drops to zero, which shifts the financial advantage back to the node groups.

A Large Request That Triggers a Fargate Size Step

Finally, evaluate a single, continuous backend service pod requesting 1 vCPU and 8 GB of memory.

Because Fargate adds 256 MB for the kubelet, the pod requires 8.25 GB. Fargate cannot provision 8.25 GB on a 1-vCPU instance, so it rounds up to 2 vCPU and 9 GB. At standard hourly rates, that provisioned capacity costs $88.31 per month.

Creating a direct per-pod equivalent for EC2 is impossible in this scenario. You must select a node type large enough to host the pod, pay the hourly rate for the entire instance, and divide the cost among any other workloads scheduled there. Inefficient requests trigger higher bills in both architectures, but Fargate enforces rigid step functions that can unexpectedly double CPU charges for a marginal memory increase.

Build the Fully Loaded Cost Comparison

Looking at compute subtotals alone ignores the surrounding infrastructure. A complete cost model includes shared cluster charges and architecture-specific AWS costs, evaluating operational time alongside the monthly invoice.

Add Shared EKS and Architecture-Specific Charges

Every EKS cluster has a per-cluster fee based on its Kubernetes version, whether you run workloads on Fargate or EC2. The Amazon EKS pricing documentation lists standard Kubernetes version support at $0.10 per cluster-hour, or $73 for a 730-hour month; for a cluster running a version in extended support, the fee is $0.60 per cluster-hour, or $438 for the same period. So adding the standard support fee raises the earlier steady-pod compute estimate by $73 per 730-hour month for either Fargate or EC2.

Fargate architectures also accumulate specific secondary charges. You must account for configured ephemeral storage beyond the included 20 GB, logging and metrics ingestion, load balancers, and data transfer. If pods need internet access from their private subnets, the network path may add NAT Gateway hourly charges and processing fees; VPC endpoints can also add costs.

EC2 architectures carry their own accompanying charges. You pay for the EC2 node-hours at your selected purchase-option rate, alongside the attached EBS root volumes required to boot the instances. You also need to model data transfer, cross-AZ traffic, load balancers, and any applicable public IPv4 charges, since AWS bills worker-node resources separately from the EKS cluster fee.

Separate the AWS Bill From Operational TCO

Calculating the total cost of ownership requires looking at account guardrails and your team's capacity to manage infrastructure. Fargate entirely removes EC2 instance provisioning, OS patching, and AMI upgrades, though teams remain responsible for pod sizing, configuring Fargate profiles, and managing Kubernetes behavior. Managed node groups automate the provisioning and lifecycle tasks of EC2 instances without adding a separate group fee, which narrows the operational gap between the two options.

To build a reliable comparison, allocate your EC2 whole-node costs using realistic node fit and rely on actual provisioned pod sizes for Fargate rather than measured CPU use alone. Reprice the models using your organization’s effective rates. Since EKS Fargate Spot is unsupported, On-Demand and Compute Savings Plans serve as the primary financial levers. By contrast, EC2 node groups can utilize Spot capacity, which reduces compute costs below Fargate pricing for fault-tolerant workloads.

When platform teams identify idle capacity, they need a safe path to remediate it. For findings FinOps AI can act on, such as an idle EC2 instance or an unattached EBS volume, it connects the finding to an execution plan and proposes the AWS change. Kubernetes findings such as over-requested pods get no proposed change, so node-group resizing and pod-request changes stay in your own process. An owner or admin reviews a proposed change against the configured guardrails, and upon approval, the system applies it. A post-action check then confirms the result (for a stop, the state AWS reports back); it does not check application health. If a reversible action fails that check, the platform rolls it back, and the estimated saving from a stop or EBS deletion goes to a savings ledger, where it counts only if the change still holds about seven days later. This workflow brings cost visibility and guarded AWS remediation together, while GCP remediation is not currently supported.

Which EKS Compute Option Fits?

Choosing the right compute option means comparing actual provisioned pod-hours against whole-node hours and realistic packing metrics for your specific environment. Both platforms offer distinct advantages depending on the stability and density of the workloads you deploy.

EC2 stands out as the most cost-effective choice for steady workloads that pack efficiently. When you maintain high base utilization and apply Spot instances or Savings Plans, the per-vCPU cost on EC2 drops well below the Fargate baseline. EC2 also supports specialized requirements that Fargate cannot handle, including GPUs, Arm processors, attached EBS volumes, and privileged containers.

Fargate delivers value when isolation and hands-off operations justify a premium, or when it prevents you from paying for idle nodes. For cron jobs, sparse environments, or unpredictable batch processing, Fargate avoids paying for idle nodes, though billing covers each pod's lifetime from image download through termination. Adopting Fargate requires redesigning daemon functions as sidecars, because the platform does not support DaemonSets.

Before migrating workloads, run practical checks on your existing clusters to quantify the potential impact. Inspect pod requests and limits to ensure they match, and read the CapacityProvisioned annotation to identify what AWS bills. Measure your current node allocatable capacity to verify how aggressively you are packing instances. Finally, refresh the regional prices, apply your effective discount rates, and calculate the total cost across compute, networking, and storage. FinOps AI can support the next step by connecting supported AWS cost findings to approval-gated changes, with post-action checks and rollback for reversible changes that fail them.

---

FinOps AI turns supported AWS cost findings into approval-gated changes that are checked after they run, with reversible changes rolled back if they fail that check. Bring AWS and GCP spend, Kubernetes allocation, and AI costs into a single platform, while keeping in mind that GCP remediation is not currently supported. Explore the platform at getfinops.cloud.