Most teams that adopt AWS Fargate do so for one reason: they want to stop managing servers. Fargate is the serverless compute engine for containers that lets you run Amazon ECS or EKS workloads without provisioning a single EC2 instance. You define CPU and memory, hand over a container image, and AWS handles the rest.
That promise is real, but it comes with a catch. Fargate bills on the resources you request, not the resources you actually use. According to AWS’s own Fargate documentation, you pay for the vCPU and memory allocated to your task for the entire time it runs, rounded up to the nearest second. That single billing detail explains why so many Fargate deployments quietly cost more than the EC2 clusters they replaced.
Below are the mistakes that show up again and again, plus what actually works in practice.
Mistake 1: Picking CPU and Memory Combinations That Don’t Exist
This trips up nearly everyone on their first task definition. Fargate does not let you choose arbitrary amounts of CPU and memory. It accepts a fixed menu of valid pairs. If you ask for 0.5 vCPU and 3 GB of memory, the task definition registration fails outright.
The practical fix is simple: check the valid combinations table in the Amazon ECS task definition documentation before you write your IaC. Teams that hardcode values from a tutorial often inherit a pairing that no longer matches what their application needs, then spend an afternoon debugging a validation error that has nothing to do with their code.
A common real-world pattern: a small API service gets 1 vCPU and 2 GB because “that’s what the example had.” It runs fine. It also costs roughly double what a 0.5 vCPU / 1 GB task would cost for the same throughput.
Mistake 2: Treating Requested Resources as a Performance Setting
Here is the mental model that causes the most waste. On EC2, giving an instance more CPU is often a safe way to improve performance. On Fargate, requested resources are a price tag first and a performance setting second.
If your container is single-threaded and handles 40 requests per second comfortably on 0.5 vCPU, moving to 2 vCPU does not quadruple throughput. It quadruples the bill. Fargate allocates CPU shares proportionally, so a task with more vCPU gets more compute time, but only if the workload can actually use it.
What works in practice:
- Deploy with the smallest valid combination that passes your load test.
- Watch CPU and memory utilization in CloudWatch for at least a week of real traffic.
- Right-size based on the p95 utilization, not the peak.
- Re-test after every significant application change.
The teams that get this right treat task sizing as a recurring tuning exercise, not a one-time decision. It is closer to database index maintenance than to server provisioning.
Mistake 3: Forgetting That Local Storage Is Ephemeral and Capped
Fargate tasks get ephemeral local storage, and by default that amount is modest. Workloads that write large temporary files, generate PDFs, process video, or unpack archives will hit a disk-full error that looks like an application bug but is really a platform limit.
AWS lets you configure ephemeral storage per task up to a documented maximum, and you pay extra for anything above the default. The mistake is not knowing the default exists until production fails at 2 a.m.
Two habits prevent this. First, audit what your container writes to `/tmp` and to the working directory. Second, if the data needs to survive a task restart, it should never live on local disk at all. Fargate tasks are disposable by design. State belongs in S3, EFS, or a managed database.
Mistake 4: Assuming You Can SSH In
There is no host to SSH into. Fargate abstracts the underlying infrastructure completely, which is the whole point, but it removes a debugging reflex that many engineers have relied on for a decade.
The replacement toolkit is genuinely good once you build the habit:
- ECS Exec for an interactive shell inside a running container
- Structured logs shipped to CloudWatch Logs
- Container health checks that surface failures as task state changes
- Distributed tracing through AWS X-Ray or a third-party APM
The failure mode here is subtle. Teams that never invest in observability find Fargate “hard to debug” and blame the platform. In reality, they are missing the tooling that replaces SSH. If you are also running API gateways in front of these services, the comparison in this Kong vs AWS API Gateway vs Apigee breakdown is worth reading before you lock in a front-door architecture, because gateway choice affects how much tracing and logging you get for free.
Mistake 5: Skipping Graceful Shutdown Handling
Fargate stops tasks regularly. Deployments roll, autoscaling scales in, Spot capacity gets reclaimed. Each of those events sends SIGTERM to your container, followed by a hard kill after a timeout window.
If your application ignores SIGTERM, in-flight requests get dropped. Users see errors during deploys, which is exactly when you least want them.
The fix is a few lines of code in most frameworks: catch SIGTERM, stop accepting new connections, finish in-flight work, exit cleanly. Then set the `stopTimeout` parameter to match how long your slowest request actually takes. Teams that skip this step often see a small but persistent error rate that they attribute to “network blips” for months.
Mistake 6: Mismatched Health Checks and Slow Starts
Fargate offers container health checks and load balancer health checks, and they serve different purposes. Confusing them causes two opposite problems.
Set the health check too aggressive and a Java service that takes 45 seconds to warm up gets killed and restarted in a loop. Set it too lax and traffic reaches a container that is not ready, producing 502s during every deployment.
What actually works: separate liveness from readiness. A liveness check should confirm the process is alive. A readiness check should confirm the app can serve traffic. Give the load balancer a generous health check grace period, and let the container health check handle restarts.
Mistake 7: Ignoring the Networking Model
Fargate tasks in `awsvpc` mode each get their own elastic network interface and their own private IP address. This is mandatory, not optional, and it has downstream consequences that surprise people.
Every running task consumes an IP from your subnet. If you run 200 tasks in a subnet with a /24 CIDR, you are close to exhausting the 251 usable addresses, and new tasks fail to launch with an obscure error. Security groups attach to the task’s ENI, which is convenient for least-privilege design but means you need a security group strategy before you scale, not after.
The practical rule: size subnets for peak task count times two, and keep security groups narrow and named clearly.
Mistake 8: Leaving Platform Version and Architecture Unpinned
Fargate platform versions control the underlying OS, kernel, and runtime behavior. If you do not pin one, or if you pin one and never revisit it, you get surprises. A new default can change networking behavior or storage behavior between deployments.
Architecture is the newer version of the same trap. ARM64 (Graviton) tasks cost less per vCPU-hour than x86 tasks for many workloads, and the savings are meaningful at scale. But your container image has to be built for the right architecture. Teams that switch the runtime platform without rebuilding multi-arch images get instant `exec format error` failures.
Pin the platform version explicitly. Build multi-architecture images. Test the ARM64 variant in staging before you flip production.
Mistake 9: Paying On-Demand Prices Out of Habit
Fargate has two pricing levers that many teams never pull.
Fargate Spot offers a substantial discount in exchange for the possibility of interruption with a two-minute warning. It is a great fit for batch jobs, CI runners, and stateless workers that can tolerate restarts. It is a poor fit for anything holding a long-lived connection.
Compute Savings Plans apply across Fargate and EC2 and deliver a discount in exchange for a one- or three-year commitment. If you have a stable baseline of Fargate usage, this is close to free money.
The pattern is depressingly common: a team runs everything on Fargate on-demand, pays full price for a year, and only discovers Spot and Savings Plans during a cost review. Run the numbers before your next billing cycle.
Mistake 10: Assuming Portability Without Testing It
Fargate is managed, but it is not generic Kubernetes. Task definitions, IAM task roles, secrets injection, and networking all have Fargate-specific behavior. Teams that assume a workload will “just move” between EKS on Fargate, ECS on Fargate, and self-managed Kubernetes often discover differences in IAM, log routing, and sidecar support at the worst possible moment.
Cloud platform choice compounds this. If your broader strategy is still in flux, the trade-offs in this AWS vs Azure vs Google Cloud comparison are a useful sanity check before you commit deeply to any one provider’s container runtime. Similarly, if you are putting a WAF in front of Fargate services, the differences covered in this Cloudflare WAF vs AWS WAF vs Imperva analysis matter more than most teams expect, because WAF integration with ALB and API Gateway is not uniform. (AWS Fargate)
A Quick Reference Table
| Mistake | Symptom | Practical Fix |
|---|---|---|
| Invalid CPU/memory pair | Task definition fails to register | Use the documented valid combinations |
| Over-provisioning | Bill higher than expected | Right-size from p95 utilization |
| Ephemeral storage limits | Disk-full errors in production | Raise storage or move state off-disk |
| No SSH access | “Hard to debug” complaints | ECS Exec, structured logs, tracing |
| Ignoring SIGTERM | Errors during deploys | Handle SIGTERM, tune stopTimeout |
| Health check mismatch | Restart loops or 502s | Separate liveness and readiness |
| IP exhaustion | Tasks fail to launch | Size subnets for peak times two |
| Unpinned platform | Behavior changes between deploys | Pin version, build multi-arch images |
| On-demand by default | Avoidable spend | Fargate Spot plus Savings Plans |
| Untested portability | Surprise breakage on migration | Test IAM, logging, sidecars early |
Conclusion
Fargate rewards teams that treat it as a billing model with a compute engine attached, not as a smaller EC2. The mistakes above are not exotic. They are the default behavior of engineers applying EC2 instincts to a serverless container platform.
The good news is that every one of them is fixable with configuration and a small amount of discipline. Right-size from real data. Handle shutdown signals. Pin your platform version. Pull the Spot and Savings Plan levers. Build observability before you need it. Do those five things and Fargate becomes what it was sold as: containers without the operational tax.
Frequently Asked Questions
What is the most common AWS Fargate mistake?
Over-provisioning CPU and memory is the most common and most expensive mistake. Because Fargate bills on requested resources rather than actual utilization, an oversized task silently wastes money every second it runs. Teams that right-size from p95 utilization data typically cut Fargate spend significantly without any performance loss.
Can you SSH into an AWS Fargate task?
No. Fargate has no underlying host that you can access, so traditional SSH is not possible. The supported alternative is ECS Exec, which opens an interactive shell inside a running container. Combined with structured logging and distributed tracing, ECS Exec covers most of the debugging needs that SSH used to serve.
Does Fargate support persistent local storage?
No. Local storage on Fargate tasks is ephemeral and disappears when the task stops. You can configure the amount of ephemeral storage per task, but it is still temporary and billed above the default. Any data that must survive a restart should go to Amazon S3, Amazon EFS, or a managed database.
Why do my Fargate tasks keep restarting?
The usual causes are an overly aggressive container health check, an application that takes longer to start than the health check grace period allows, or a memory limit that is too low for the workload. Check the task’s stopped reason in the ECS console first, then compare your health check timings against actual application startup time.
Is Fargate Spot safe for production?
It is safe for the right workloads. Fargate Spot tasks can be interrupted with a two-minute warning, so they suit batch processing, CI runners, queue workers, and other stateless jobs that can tolerate restarts. They are a poor fit for long-lived connections or anything that cannot checkpoint its work. Many teams run a stable on-demand baseline alongside a Spot pool for burst capacity.
How do I reduce AWS Fargate costs?
Four levers do most of the work: right-size CPU and memory from real utilization data, move interruptible workloads to Fargate Spot, commit to a Compute Savings Plan for your stable baseline, and set up autoscaling so you are not paying for idle tasks overnight. Reviewing task sizing quarterly keeps the savings from eroding as applications change.
