DEV Community: Matt

Why Do AWS Staging Environments Cost So Much?

Matt — Sun, 21 Jun 2026 15:01:58 +0000

Why AWS Staging Environments Cost So Much (2026 Guide)

Originally published at https://fortem.dev/blog/aws-staging-environment-cost
AWS staging environments run 168 hours a week. Your team works 40. Here's where the money goes on ECS Fargate — and how to cut it without touching production.

Guide

aws-staging-environment-costfargate-idle-costecs-environment-scheduling

You have 10 ECS environments. Most of them are staging, QA, or dev. No one is using them at 2am on Saturday. But Fargate bills by the second, and by the time the monthly invoice arrives the number is larger than expected. This isn't an infrastructure design problem — it's an idle compute problem. Here's where the money goes, and what moves the needle.

TL;DR

01Non-prod ECS environments run 168 hours a week. Your team works 40. That's 128 hrs/week of idle compute per environment.
02Fargate compute is ~68% of your ECS bill. The rest (CloudWatch Logs, ALB baseline) doesn't stop when the environment sits idle.
03NAT Gateway, VPC, and often ALB are shared across environments — that overhead doesn't multiply. Compute does.
04Fargate Spot cuts non-prod compute by up to 70% for fault-tolerant tasks. Not suitable for demo environments or shared QA sessions.
05Business-hours scheduling (Mon–Fri 09:00–19:00) cuts active compute time to ~30% of the 24/7 baseline with zero architecture changes.

Ready to use — drop this into your Terraform today

ECS Application Auto Scaling scheduled actions — stops all tasks at 19:00 and restarts at 09:00, Mon–Fri. No Lambda required. Replace your-cluster and your-service with your values. Repeat the aws_appautoscaling_* blocks for each service.

# Register the ECS service as a scalable target
resource "aws_appautoscaling_target" "staging_svc" {
  max_capacity       = 4
  min_capacity       = 0
  resource_id        = "service/your-cluster/your-service"
  scalable_dimension = "ecs:service:DesiredCount"
  service_namespace  = "ecs"
}

# Stop at 19:00 UTC Mon–Fri
resource "aws_appautoscaling_scheduled_action" "stop_evening" {
  name               = "stop-staging-evening"
  service_namespace  = aws_appautoscaling_target.staging_svc.service_namespace
  resource_id        = aws_appautoscaling_target.staging_svc.resource_id
  scalable_dimension = aws_appautoscaling_target.staging_svc.scalable_dimension
  schedule           = "cron(0 19 ? * MON-FRI *)"

  scalable_target_action {
    min_capacity = 0
    max_capacity = 0
  }
}

# Restart at 09:00 UTC Mon–Fri
resource "aws_appautoscaling_scheduled_action" "start_morning" {
  name               = "start-staging-morning"
  service_namespace  = aws_appautoscaling_target.staging_svc.service_namespace
  resource_id        = aws_appautoscaling_target.staging_svc.resource_id
  scalable_dimension = aws_appautoscaling_target.staging_svc.scalable_dimension
  schedule           = "cron(0 9 ? * MON-FRI *)"

  scalable_target_action {
    min_capacity = 1
    max_capacity = 4
  }
}

# Optional: Fargate Spot capacity provider for non-prod
resource "aws_ecs_service" "staging_svc" {
  # ... your existing service config ...

  capacity_provider_strategy {
    capacity_provider = "FARGATE_SPOT"
    weight            = 1
  }

  capacity_provider_strategy {
    capacity_provider = "FARGATE"
    weight            = 0
    base              = 0
  }
}

Monthly compute cost — 10 non-prod environments (80 services, 0.5 vCPU each)

us-east-1, Linux x86, on-demand rates June 2026

24/7 on-demand

$1,442/mo

Business hours on-demand

-70%$428/mo

Business hours + Fargate Spot

-91%$128/mo

Business hours = Mon–Fri 09:00–19:00 (50 hrs/wk, ~217 hrs/mo). Fargate Spot at 70% discount. Shared infrastructure (NAT Gateway, VPC, ALB) not included — shared cost does not multiply per environment.

Why non-prod spend stays invisible

Non-prod costs get lumped into a single “infrastructure” line item with no per-environment breakdown. No one owns the number, so it doesn't get fixed.

Production gets optimized after a big bill. Staging gets the same config it had when the second engineer joined and no one has touched it since. The reason isn't negligence — it's visibility. AWS Cost Explorer shows you ECS as a service total. Without per-environment cost allocation tags, there's no way to see that your staging environment costs more than your QA environment, or that three dev environments have been running since February with no active work behind them.

The result: non-prod spend is invisible in reviews, gets absorbed into the overall AWS bill, and deferred indefinitely with “it's just staging, we'll fix it later.”

KEY INSIGHT: Key insight “Nobody noticed because staging bills get lumped into ‘infrastructure costs’ and nobody questions them.” — practitioner, dev.to

Where the money goes on Fargate

Fargate compute is ~68% of a typical ECS bill at $0.04048/vCPU-hr and $0.004445/GB-hr. The remaining 32% — CloudWatch Logs at $0.50/GB ingested, ALB baseline at $0.0225/hr — doesn't scale to zero when tasks are idle.

The big number is compute, and compute is the lever. But a few non-obvious charges compound the problem for non-prod environments specifically:

01

CloudWatch Logs — verbose by default

Non-prod environments often run at DEBUG log level. A service generating 1 GB/day of logs costs $15/month in ingestion alone. Multiply by 8 services and 10 environments and you have a meaningful line item that has nothing to do with compute.
02

Container Insights — charged per observation

Container Insights is on by default on many clusters. For non-prod, it adds cost without adding value. Turn it off on dev and staging clusters.
03

ALB dedicated to one environment

If each environment has its own ALB, the $0.0225/hr base charge ($16.43/mo) runs regardless of traffic. Teams running 10 environments with dedicated ALBs pay $164/mo in ALB base charges before a single request is processed.

The 168-hour problem

A non-prod environment running 24/7 runs 168 hours a week. Your team works 40. That gap — 128 hours per week of idle compute per environment — is the real cost driver on Fargate.

Let's do the math on a realistic fleet. Ten non-prod environments, each running 8 services at 0.5 vCPU and 1 GB memory:

Scenario	Hrs/mo active	Compute/mo	vs 24/7
24/7 on-demand	730	$1,442	—
Business hours on-demand	~217	$428	−70%
Business hours + Spot	~217	~$128	−91%

80 services × 0.5 vCPU × $0.04048/hr + 80 × 1 GB × $0.004445/hr. Business hours = Mon–Fri 09:00–19:00 UTC (~217 hrs/mo).

KEY INSIGHT: Key insight The compute in a non-prod environment doesn't know it's 2am on Sunday. It charges the same rate as a Tuesday afternoon.

Fargate bills by the second with no minimum charge. A task stopped at 19:00 pays nothing until it restarts at 09:00. That's not an approximation — it's how the billing model works. The savings from scheduling are immediate and exact.

What shared infrastructure changes (and doesn't change)

NAT Gateway, VPC, and often ALB are shared across environments. That overhead doesn't multiply per environment. What multiplies is compute — one set of running tasks per environment, billed independently.

A well-structured ECS fleet shares:

—NAT Gateway — one per VPC, ~$32.85/mo base. Shared across all environments. $3.29/env at 10 environments.
—ALB with host-based routing — one ALB routes to all environments via hostname rules. $16.43/mo base total, not per environment.
—VPC, subnets, security groups — no per-environment charge.

What doesn't share: Fargate task hours, CloudWatch Logs ingestion per environment, and ECR image pull data. These are the numbers that multiply at fleet scale — and they're all driven by idle compute.

This is why the fix is scheduling tasks, not redesigning network architecture. Once you understand that shared infra is already cheap per environment, the question becomes: how do you stop paying for 128 idle compute hours per week?

You can set up per-environment cost allocation tags with AWS Cost Anomaly Detection to get alerted when any single environment deviates from its historical spend baseline — useful once you have scheduling in place and want to catch drift.

Fargate Spot for non-prod: when it works, when it doesn't

Fargate Spot runs non-prod tasks on spare AWS capacity at up to 70% off on-demand rates. It works well for dev and QA. Avoid it for environments used for customer demos or with stateful in-memory work that can't tolerate a restart.

The mechanics: AWS gives 2 minutes' warning via SIGTERM before reclaiming Spot capacity. ECS marks the task as SPOT_INTERRUPTIONand, if desired count is still > 0, launches a replacement.

Environment type	Fargate Spot?	Reason
Dev environments	✓ Yes	Stateless, restartable, no active users
Feature branch preview	✓ Yes	Ephemeral, restartable on interrupt
CI / integration tests	✓ Yes	Short-lived tasks, retry on failure
QA (automated)	✓ Yes	Tests restart automatically on failure
QA (live session)	✗ Risky	Interrupt kills active QA session
Demo environment	✗ No	Customer impact if interrupted
Staging (production-like)	✗ Usually not	Used for final validation, needs stability

The capacity provider strategy in the Terraform block above sets FARGATE_SPOT weight=1, FARGATE weight=0 — pure Spot. For environments that need occasional stability, set Spot weight to 3 and on-demand weight to 1 to prefer Spot but fall back automatically.

Business-hours scheduling: the fastest ROI

Scheduling ECS tasks to stop at 19:00 and restart at 09:00 Mon–Fri cuts active compute time from 730 hours/month to ~217 hours — a 70% reduction with no architecture changes required.

The AWS-native approach uses ECS Application Auto Scaling scheduled actions. No Lambda function, no custom scheduler, no third-party tool — this is a first-class ECS feature. The Terraform block at the top of this article implements it exactly.

A few operational details worth knowing before you deploy:

—Deregistration delay. ALB target groups have a default 300-second deregistration delay. Reduce this to 30 seconds on non-prod target groups so environments stop promptly at 19:00 instead of draining for 5 minutes.
—Stateful services. RDS and ElastiCache run independently — they're not stopped by this config. Data persists across task restarts. EFS mounts reattach on task start.
—Timezone offset. EventBridge cron uses UTC. Mon–Fri 09:00–19:00 ET is 13:00–23:00 UTC. Adjust the cron expressions for your team's timezone.
—Override capability. The scheduled action sets desired count — any engineer can manually set it back to 1 for an after-hours session. The schedule resumes as normal the next morning.

At 10+ environments, this math becomes unavoidable

One staging environment running 24/7 is an annoyance. Ten of them is a line item that starts appearing in board decks. The fix doesn't scale manually.

Manual scheduling via the AWS console or one-off Terraform blocks works at 1–2 environments. At 10+, the operational overhead compounds:

—Schedule drift — different engineers set different start/stop times, no one audits
—Environment-specific hours — the ML team needs their env at 6am, QA needs theirs until 9pm
—On-demand overrides — “can you keep staging up tonight, we have a client demo” — sent in Slack, forgotten in Terraform
—New environments inherit no schedule by default — the next dev environment someone spins up runs 24/7 until someone notices

This is where fleet-level tooling pays for itself. Fortem manages scheduling across all non-prod environments from one interface — with override capability per environment, audit log of who changed what, and defaults that apply to new environments automatically.

See which environments in your fleet are burning budget right now.

Talk to us about your fleet

Questions this article doesn't answer

How do I actually see which environment is costing what in AWS?+

Enable cost allocation tags for your environment key in the AWS Billing console, then use Cost Explorer with a Group by filter on that tag. You'll see per-environment spend broken out as individual rows. Our article on per-environment cost visibility walks through the exact steps.

Can I automatically stop ECS environments when there's no active deployment or open PR?+

Not with native ECS scheduling alone — you'd need to wire EventBridge to your CI/CD events. A GitHub Actions workflow can call the ECS UpdateService API to set desired count to 0 when a PR is closed and back to 1 when a new deployment completes. Some teams add this to their deploy pipeline directly.

What's the difference between desired count = 0 and deleting the ECS service entirely?+

Setting desired count to 0 stops all running tasks but preserves the service definition, IAM roles, capacity provider strategies, and auto-scaling rules. The service restarts exactly as configured. Deleting the service removes all of this and you'd need to recreate it from Terraform. For scheduling, use desired count = 0 — not service deletion.

Does stopping and restarting ECS tasks affect RDS or other stateful services?+

RDS, ElastiCache, and other stateful services run independently of ECS task count. Stopping tasks at 19:00 has no effect on your database — it continues running (and billing) until you separately stop it. Data persists across task restarts. EFS volumes reattach automatically when tasks start again.

Common questions

Is Fargate Spot available for ECS services or only tasks?

Fargate Spot is available for ECS services through capacity provider strategies. You set FARGATE_SPOT as a capacity provider with a weight in your ECS service definition. Tasks get scheduled on Spot capacity when available. If AWS needs the capacity back, tasks receive a SIGTERM with a 2-minute warning before SIGKILL.

Does setting ECS desired count to 0 stop billing immediately?

Yes. When desired count reaches 0 and running tasks drain and stop, Fargate billing stops within seconds — Fargate charges by the second with no minimum. However, other resources associated with the environment (ALB if dedicated, CloudWatch Log Groups, RDS) continue to incur charges independently.

How do I set up a schedule to stop ECS services on nights and weekends?

Use ECS Application Auto Scaling scheduled actions — no Lambda required. Create a scalable target for each ECS service, then add two scheduled actions: one to set desired count to 0 at your stop time and one to restore it in the morning. EventBridge cron expressions handle the schedule. Terraform example is included in this article.

Will reducing non-prod ECS task size break anything?

It depends on what the task does. For services that only handle QA traffic or automated tests, dropping from 1 vCPU to 0.5 vCPU rarely causes issues. The risk is for tasks that run build pipelines, data migrations, or integration tests under time constraints — those may fail or time out. Right-size based on actual observed CPU and memory utilization, not on what production uses.

How does Fargate Spot handle interruptions in ECS?

AWS sends a SIGTERM to the task 2 minutes before reclaiming capacity, then sends SIGKILL. ECS marks the task as stopped with reason SPOT_INTERRUPTION. If the ECS service has a desired count greater than 0, it will launch a replacement task — on Spot if available, falling back to on-demand if not (depending on your capacity provider strategy weights).

See your real per-env cost: fortem.dev/ecs-cost-calculator

Humanitec or Fortem: Which ECS Platform Fits Your Team?

Matt — Fri, 19 Jun 2026 23:51:03 +0000

Fortem vs Humanitec: ECS Ops vs General IDP

Originally published at https://fortem.dev/blog/fortem-vs-humanitec
Humanitec's Container Driver explicitly excludes ECS. If your problem is operating an ECS Fargate fleet, you're comparing the wrong category of tool. Here's the breakdown.

Versus

fortem-vs-humanitechumanitec-alternative-ecsecs-idp-comparison

Humanitec is the most-marketed IDP of 2025. If you run AWS ECS Fargate and searched “humanitec alternative,” you've likely seen it at the top of every comparison listicle. But the ECS team evaluating Humanitec is usually solving a different problem than the one Humanitec is built for. This article explains both tools precisely so you can figure out which problem you actually have.

TL;DR

Humanitec is a platform orchestrator built for Kubernetes — the Container Driver (Jan 2025) explicitly states it "can only be used with managed clusters (EKS, AKS or GKE)" — ECS is not a supported workload target
Humanitec Teams is $2,199/mo for 5 users, 2 projects, 5 environments per project — structurally incompatible with a fleet of 20+ ECS environments before you even reach Pro at $5,499/mo
Fortem is purpose-built for ECS Fargate fleet operations: scheduling, cloning, fleet visibility, developer self-service — reads your existing AWS resources, no Terraform rewrite
If your problem is 'operate my ECS fleet at scale' → Fortem. If your problem is 'build a company-wide IDP across AWS, GCP, and Azure' → Humanitec
Humanitec requires substantial custom work to build the developer interface — right for a 5+ person platform team, not for a 1–2 person ops team on ECS

Ready to use — run this evaluation today

Before booking a demo with either vendor, answer these 5 questions. The answers tell you which category of tool fits — before any sales call.

1.

What runtimes does your production infrastructure actually run on?

If the answer is 'ECS Fargate only' → operational layer. If 'ECS + EKS + Lambda + GCP' → platform orchestrator.
2.

How many ECS environments do you have, and are any of them running 24/7 without a workload?

Count: aws ecs list-clusters | jq '.clusterArns | length'. If >10 environments with idle time → scheduling ROI is immediate.
3.

How many full-time engineers are dedicated to the internal platform (not to product features)?

1–2 engineers → operational layer. 5+ dedicated platform engineers → full IDP may make sense.
4.

Are developers filing tickets to the platform team for environment restarts, clones, or access?

If yes, that's an ops bottleneck — a self-service operations layer solves this faster than building an IDP.
5.

What is your current monthly Fargate compute spend on non-production environments?

Run: aws ce get-cost-and-usage --time-period Start=2026-05-01,End=2026-06-01 --granularity MONTHLY --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Elastic Container Service"]}}' --metrics BlendedCost. If >$1,000/mo → scheduling saves more than Fortem Starter costs.

What Humanitec actually is

Humanitec is a graph-based platform orchestrator that enforces security, cost, and compliance policies on every deployment. It is Kubernetes-architected and cloud-agnostic.

The current homepage headline is “Let AI build. On your terms.” — Humanitec has repositioned from “developer self-service platform” to “AI agent governance layer.” The product lets platform teams define resource templates (databases, caches, queues) that AI agents and human developers can provision in a standardized, policy-compliant way across multiple cloud providers.

Compute targets claimed on the marketing site: EKS, GKE, AKS, VMs, Serverless. The reality for ECS teams is more nuanced. Humanitec's Container Driver — the mechanism that actually routes workloads to a compute target — was announced in January 2025 with an explicit restriction:

“As of today, the Container Driver can only be used with managed clusters (EKS, AKS or GKE.)”

— Humanitec blog: Introducing the Container Driver (Jan 2025)

AWS ECS and Fargate are not listed. The “serverless-ecs” runner type that appears in Humanitec docs refers to running Humanitec's own build agents on ECS compute — not routing your application workloads to ECS clusters. As of June 2026, humanitec.com/blog has zero posts about deploying to ECS.

Humanitec's workload descriptor is called Score — a YAML format that abstracts a service away from any specific runtime. To deploy through Humanitec, teams rewrite their Terraform task definitions or Kubernetes manifests in Score. This is the right tradeoff for organizations standardizing across heterogeneous platforms. For ECS-only teams, it adds an abstraction layer on top of resources that already exist and work.

Gartner Peer Insights reviewers describe the implementation honestly: Humanitec “requires you to build the developer interface and integrate existing tools. This means platform teams need to do substantial custom work to create the complete developer experience.” Humanitec is transparent about this — their MVP Program is a structured onboarding that guides a platform team through building that experience.

Known customers: Western Union, BambooHR, Cimpress — large, multi-cloud organizations with dedicated platform teams. The product is enterprise-sold; it does not have a self-serve signup.

KEY INSIGHT: Humanitec is genuinely good at what it does — the absence of ECS support is not a flaw, it's a design decision. The question is whether the ECS team evaluating it is solving the same problem Humanitec was built to solve.

What Fortem actually is

Fortem is a control plane for ECS Fargate fleet operations. It reads your existing AWS resources via tags and naming — Terraform stays your source of truth, nothing gets rewritten.

Fortem connects to your AWS account via a read-heavy IAM role, discovers every ECS cluster, service, and task definition through tags and naming conventions, and adds an operations layer on top. It does not replace Terraform, does not manage deployments, and does not require you to learn a new workload descriptor format.

What it adds: fleet-wide scheduling (stop all non-production environments at 7pm, restart at 9am, per-timezone), environment cloning (copy a staging environment with one API call), per-environment cost tracking, developer self-service with ECS-scoped RBAC so engineers can restart their own service without filing a ticket, and AI-assisted diagnostics that pull CloudWatch logs and task events when something is unhealthy.

The typical customer is a platform engineering team of 1–3 people running 10–80 ECS Fargate environments across 1–3 AWS accounts. Their IaC is Terraform. They did not set out to build an internal developer platform — they wanted to stop being the bottleneck for every environment restart, clone, and schedule change. See how ECS Fargate cost optimization compounds when scheduling, right-sizing, and Spot work together.

What Fortem does not do: Fortem does not manage Kubernetes, does not provide a service catalog, does not handle multi-cloud deployments, and does not give you a Backstage-style developer portal. If those are your requirements, Fortem is not the right tool.

Pricing — what you actually pay

Humanitec Teams at $2,199/mo limits you to 5 users and 5 environments per project. For a fleet of 20+ ECS environments, you're on Pro at $5,499/mo before you've saved anything.

Humanitec's pricing was verified June 2026 at humanitec.com/pricing. Both cloud-hosted tiers offer a free trial. An annual discount of 10% applies to both plans. Humanitec also lists a separate AWS Marketplace SKU at $999/mo for up to 15 users — the terms differ from the main site plans.

Humanitec Teams $2,199/mo - 5 users · 2 projects · 5 envs/project - Email su

Fortem Starter $790/mo - Up to 20 environments · 1 AWS account - Unlimited u

The ROI math for Fortem is straightforward. Scheduling 10 dev and staging environments (8 services each, 0.5 vCPU / 1 GB per task) to business hours saves $1,013/month in Fargate compute — using published AWS pricing at $0.04048/vCPU-hr. The Starter plan pays for itself before any other feature. For the full calculation, see the Fargate real cost breakdown — including the fixed overhead (ALB, NAT Gateway, CloudWatch) that scheduling doesn't eliminate.

Humanitec ROI comes from platform team leverage — fewer tickets, faster developer onboarding, consistent environments across teams. That is real value, but it requires a platform team large enough to build and maintain the developer experience layer Humanitec expects you to create. The Gartner review notes this plainly: “platform teams need to do substantial custom work to create the complete developer experience.”

ECS Fargate specifically

Humanitec has no ECS-specific features. Fortem was built exclusively for ECS Fargate — every feature maps to a real ECS operational problem.

Humanitec on ECS

✗No ECS workload deployment — Container Driver supports EKS, AKS, GKE only
✗No environment scheduling for ECS clusters or services
✗No ECS fleet visibility — no per-environment cost or status dashboard
✗No environment cloning for ECS task definitions
✗No ECS-specific diagnostics — no CloudWatch log integration
✗Zero ECS-specific blog posts or documentation as of June 2026

Fortem on ECS

✓Reads ECS services, task definitions, and CloudWatch metrics natively via AWS API
✓Fleet-wide scheduling: stop/start all environments by timezone on a cron schedule
✓Per-environment cost tracking using ECS service CPU/memory allocations
✓Environment cloning: copy a full ECS environment with one API call
✓Developer self-service: scoped IAM lets engineers restart their own services
✓AI diagnostics: surfaces unhealthy tasks with CloudWatch context automatically

KEY INSIGHT: The Humanitec “serverless-ecs” runner type that appears in their docs is not what it sounds like. It refers to running Humanitec's own CI build agents on ECS compute — not routing your application services to ECS clusters. If you found that in a Google search, it is not ECS workload support.

When Humanitec is the right choice

Humanitec is right when you need a company-wide platform across multiple clouds and platforms — not when your problem is operating an ECS fleet.

The strongest signal that Humanitec fits: your engineering org runs workloads on at least two of EKS, GKE, AKS, Lambda, or VMs, and you want a single interface for developers to provision infrastructure regardless of which runtime it lands on. Score (Humanitec's workload descriptor) earns its abstraction cost when the same service needs to deploy to different runtimes depending on environment or team.

Humanitec fits when

—You need a formal IDP for 50+ engineers across AWS, GCP, and Azure
—You're building a dedicated platform team with a charter to standardize all of engineering
—You already use Backstage or Port and want an orchestration layer on top
—You're willing to invest 2–6 months in implementation and have 5+ dedicated platform engineers
—You need AI agent governance — controlled AI provisioning across heterogeneous platforms
—Your compliance requirements need multi-cloud deployment standardization

Humanitec's MVP Program offers structured onboarding with a platform architect. Their documentation targets a first working example environment in the initial session — not a production IDP. The actual implementation timeline for a working internal developer platform, with real services, resource drivers, and a developer-facing interface, is measured in months.

When Fortem is the right choice

Fortem is right when your infrastructure is primarily AWS ECS Fargate and your problem is operational — managing environments, controlling costs, and enabling self-service without a full IDP build.

Fortem fits when

—Your stack is primarily or entirely AWS ECS Fargate — no multi-cloud requirement
—You have 10–80 environments and growing compute spend on idle dev and staging
—Your platform team is 1–3 people — not 5+ engineers dedicated to IDP work
—You use Terraform and don't want to learn Score or rewrite task definitions
—You need results in days, not months — no multi-month implementation project
—Developers are filing tickets for environment restarts, clones, or schedule changes

Fortem onboarding runs 7 business days: a Fortem engineer audits your AWS setup, tags environments, configures per-timezone schedules, and hands you the dashboard. No Score migration, no new abstraction layer. You keep your Terraform as the source of truth.

Side-by-side at a glance

The table below shows the practical differences. If a row is missing from one column, that tool doesn't have that capability.

| | Humanitec | Fortem |
| --- | --- |
| Pricing | $2,199/mo (Teams) · $5,499/mo (Pro) | $790/mo (Starter) · $2,490/mo (Scale) |
| Users included | 5 (Teams) · 50 (Pro) | Unlimited on all plans |
| Environments | 5/project (Teams) · Unlimited (Pro) | 20 (Starter) · 80 (Scale) |
| ECS Fargate support | Not a workload target | Purpose-built |
| Kubernetes support | EKS, AKS, GKE via Container Driver | Not supported |
| Terraform required | Score replaces task definitions | Reads existing state, no rewrite |
| Self-service for devs | Build it (custom developer portal) | Included — ECS-scoped RBAC |
| Environment scheduling | Not available | Fleet-wide, per-timezone |
| Environment cloning | Not available | Single API call |
| Onboarding time | Months (IDP build required) | 7 business days |
| Right for | Multi-cloud, 50+ engineers, Kubernetes | ECS Fargate, 1–3 platform engineers |

Humanitec pricing: humanitec.com/pricing, verified June 2026. Fortem pricing: fortem.dev/pricing, verified June 2026.

If you read this, you might also want to know

What does an actual platform engineering stack look like for an ECS team?+

Most ECS teams run Terraform for IaC, GitHub Actions or CircleCI for CI/CD, Datadog or CloudWatch for observability, and a Slack-connected ops runbook for manual operations. Fortem slots in as the fleet operations layer — the piece that handles scheduling, self-service, and cost tracking that none of those tools cover.

Can I start with Fortem and add a developer portal like Backstage later?+

Yes. Fortem operates at the ECS fleet operations layer — it doesn't own your service catalog, developer portal, or deployment pipeline. Backstage (or Port, or Cortex) can sit alongside Fortem, each covering different surfaces. Many teams start with Fortem for immediate cost and ops wins, then add a portal when the team grows large enough to need a service catalog.

What does Humanitec's Score language actually require me to rewrite?+

Score replaces the deployment configuration for each service — your ECS task definitions, environment variables, resource dependencies (databases, caches, queues). You'd define each service in a score.yaml and map its resources to Humanitec resource types. For a team with 40 ECS services, this is a significant migration. The payoff is portability across Kubernetes clusters and other runtimes.

Frequently asked questions

Does Fortem replace Humanitec?

No — they solve different problems. Humanitec is a general-purpose platform orchestrator for standardizing deployments across multiple clouds and Kubernetes clusters. Fortem is a control plane specifically for AWS ECS Fargate fleet operations. If your stack is ECS Fargate, Fortem addresses the actual operational problems (scheduling, fleet visibility, self-service) without requiring you to build an IDP.

Does Humanitec support ECS Fargate workload deployment natively?

Not through its primary deployment mechanism. Humanitec's Container Driver — the tool used to route workloads to compute targets — explicitly states: 'the Container Driver can only be used with managed clusters (EKS, AKS or GKE).' ECS and Fargate are not supported workload targets. The 'serverless-ecs' runner type in Humanitec docs refers to running Humanitec's own build agents on ECS infrastructure, not deploying user applications to ECS.

Can I use Fortem and Humanitec together?

In theory, yes — they operate at different layers. If you're running both ECS Fargate and Kubernetes workloads in a hybrid architecture, Humanitec could handle Kubernetes orchestration while Fortem handles ECS fleet operations. In practice, most ECS-first teams don't need both — Humanitec's value proposition (standardized developer experience across multi-cloud, multi-platform infrastructure) is a different problem than what ECS teams typically face.

What is Humanitec's Score language and do I have to learn it?

Score is Humanitec's workload descriptor — a YAML format that abstracts your service definition away from any specific infrastructure target. To use Humanitec fully, you describe your services in Score rather than in Terraform task definitions or Kubernetes manifests. For teams that need to deploy the same service across EKS, GKE, and Lambda, Score makes sense. For ECS-only teams who already have Terraform task definitions, Score is an additional abstraction layer with no payoff.

How long does Fortem onboarding take compared to Humanitec?

Fortem onboarding runs 7 business days: a Fortem engineer audits your AWS setup, imports your environments, configures schedules per timezone, and hands you the keys. Humanitec's MVP Program (their structured onboarding) targets a working MVP after the first session but typically involves multiple months of platform team work to build the developer interface, configure resource drivers, and integrate existing tooling.

Running 10+ ECS environments?

We'll show you what fleet operations looks like without building an IDP — scheduling, cloning, cost tracking, and dev self-service, live in your AWS account in 7 days.

Run Fleet Audit →Book a 20-min call →

Response within 4 hours, weekdays.

Worth reading

ComparisonECS vs EKS: Which AWS Container Service?Humanitec's Container Driver explicitly excludes ECS. If you're on Fargate, the comparison starts here.Guide · How to Cut AWS ECS Fargate Costs by 65%Scheduling, right-sizing, Spot, and orphaned environments — the four methods that take a 12-environment fleet from $1,730 to $380/month.

All ECS platform comparisons: fortem.dev/versus

Who Restarted Prod? How to Find It in CloudTrail

Matt — Fri, 19 Jun 2026 23:50:07 +0000

Who Restarted Prod? ECS Audit in CloudTrail

Originally published at https://fortem.dev/blog/ecs-audit-log-compliance
Every ECS change — UpdateService, StopTask, RunTask — lands in CloudTrail with who, when, and from where. Three CLI commands find the culprit in under 2 minutes.

Use Case · June 16, 2026 · 8 min read

ecs-audit-logecs-compliance-loggingaws-ecs-cloudtrail

How to Find It in CloudTrail

Your ECS service restarted. Or a task was manually stopped. Or desiredCount dropped to zero and nobody admits it. The ECS console shows WHAT happened — not WHO. CloudTrail has the answer, and three CLI commands get you there in under two minutes.

TL;DR

01CloudTrail captures every ECS API call — UpdateService, StopTask, RunTask, RegisterTaskDefinition — with who, when, and from where.
02Event History is free for the last 90 days. Three CLI commands find the culprit in under 2 minutes.
03The userIdentity field tells you human vs CI/CD vs AWS service. Root account activity in ECS is always suspicious.
04Download the skill file — an AI agent runs the full fleet audit and produces a structured report automatically.

Why the ECS events tab doesn't tell you who did it

ECS events show WHAT happened — "service updated", "task stopped" — but not WHO. The userIdentity lives in CloudTrail, not in the ECS console. That's the gap most teams waste an hour trying to bridge.

You open the ECS service page. Under Events: "service my-api has started 1 tasks" at 14:23, "service my-api has stopped 1 running tasks" at 14:21. Something stopped your service and triggered a redeploy. The ECS console stops there — it doesn't record the API caller, the IAM identity, or whether it was a human clicking the console or Terraform applying a change.

ECS Events tabCloudTrail

Shows WHAT happenedShows WHO did it, WHEN, and FROM WHERE

Service-level messages onlyAll API calls including StopTask, UpdateService, RunTask

No API caller infouserIdentity: human, CI/CD role, or AWS service

Kept for a few hours90-day Event History, free

Not queryableSearchable by event name, username, resource, IP

KEY INSIGHT: Key insight CloudTrail records every ECS API call automatically — no setup required. The 90-day Event History is free. You're not paying for it already; it's just there. The only thing missing is knowing where to look.

Three commands to find the culprit in under 2 minutes

aws cloudtrail lookup-events with AttributeKey=EventName filters to specific actions. Pipe through jq to extract userIdentity.userName, eventTime, and sourceIPAddress. Covers the last 90 days at no charge.

Find who stopped a task

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=StopTask \
  --query 'Events[*].CloudTrailEvent' \
  --output text | \
jq -r '. | {
  time: .eventTime,
  who: (
    if .userIdentity.type == "IAMUser" then .userIdentity.userName
    elif .userIdentity.type == "AssumedRole" then .userIdentity.sessionContext.sessionIssuer.userName
    else .userIdentity.type
    end
  ),
  from: .sourceIPAddress,
  via: .userAgent,
  task: .requestParameters.task
}'

Find who updated a service (deployments, scale changes)

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=UpdateService \
  --query 'Events[*].CloudTrailEvent' \
  --output text | \
jq -r '. | {
  time: .eventTime,
  who: (
    if .userIdentity.type == "IAMUser" then .userIdentity.userName
    elif .userIdentity.type == "AssumedRole" then .userIdentity.sessionContext.sessionIssuer.userName
    else .userIdentity.type
    end
  ),
  via: .userAgent,
  service: .requestParameters.service,
  desiredCount: .requestParameters.desiredCount
}'

Narrow by specific user or role

# Find everything a specific IAM user did in the last 24h
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=john.smith \
  --start-time $(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%SZ 2>/dev/null || date -u -v-24H +%Y-%m-%dT%H:%M:%SZ) \
  --query 'Events[*].{Time:EventTime,Event:EventName}' \
  --output table

Rate limit: lookup-events is capped at 2 requests/second per account per region. If you're scripting across many event types, add a 0.5s sleep between calls or use --next-token for pagination. Max 50 events per request; paginate if you need more.

Which ECS events map to which actions

UpdateService = scale change or deployment. StopTask = manual kill. RegisterTaskDefinition = new image or config. RunTask = standalone task launch. Each has a different userIdentity pattern worth knowing.

ScenarioCloudTrail eventNameWho typically calls it

Service scaled up/downUpdateServiceHuman, CI/CD, autoscaler

Deployment triggeredUpdateService + RunTaskCI/CD pipeline

Task manually stoppedStopTaskHuman, script, ECS agent

New task definitionRegisterTaskDefinitionCI/CD pipeline, human

Service created/deletedCreateService / DeleteServiceHuman, Terraform

Cluster deletedDeleteClusterHuman, Terraform

The most ambiguous one is StopTask. It appears in CloudTrail when a human manually stops a task, when a script does it, and when ECS itself stops a task during a rolling deployment. Check userIdentity.invokedBy — if it says ecs.amazonaws.com, ECS triggered the stop internally during service orchestration, not a human.

Decoding userIdentity: human, CI/CD, or AWS service

userIdentity.type tells you who called the API: IAMUser = human, AssumedRole = CI/CD or Lambda, AWSService = autoscaler or ECS itself. Root type should never appear in ECS — alert immediately if it does.

userIdentity.typeMeaningHow to extract the name

IAMUserHuman with IAM credentials.userIdentity.userName

AssumedRoleCI/CD, Lambda, or human via role.userIdentity.sessionContext.sessionIssuer.userName

RootAWS root account — alert immediatelytype = Root is the signal

AWSServiceAWS-owned service (autoscaling, ECS agent).userIdentity.invokedBy

AWSAccountCross-account call from another AWS account.userIdentity.accountId

FederatedUserSSO / identity provider user.userIdentity.principalId

The tricky one is AssumedRole. When a GitHub Actions pipeline runs aws ecs update-service, the CloudTrail event shows type: AssumedRole and the ARN of the role. The human-readable role name is in sessionContext.sessionIssuer.userName. That's the field to surface in your audit report — not the full ARN.

To distinguish console vs CLI vs Terraform, use the userAgent field:

userAgent valueWhat called the API

console.amazonaws.comAWS console (someone clicked)

aws-cli/2.*AWS CLI (manual or script)

Terraform/1.* terraform-provider-aws/*Terraform apply

github-actions/*GitHub Actions CI/CD

ECS ConsoleECS service console actions

KEY INSIGHT: Key insight If userIdentity.type is Root, stop everything else and investigate. Root credentials should never be used for routine ECS operations. A Root call in CloudTrail means either someone is using the root account directly (a security failure) or credentials were compromised.

Alerting in real time: EventBridge rule for critical ECS changes

EventBridge can trigger a notification within seconds of a StopTask or UpdateService call — before you notice the incident. One Terraform resource sets up the rule with no additional infrastructure.

Searching CloudTrail after an incident is reactive. EventBridge makes it proactive: you define a rule that matches specific CloudTrail events, and EventBridge triggers an SNS notification, Lambda, or Slack webhook immediately when the event occurs. For teams running 10+ ECS environments, catching a DeleteService before the on-call rotation starts saves significant incident response time.

Terraform: EventBridge rule for critical ECS events

resource "aws_cloudwatch_event_rule" "ecs_critical" {
  name        = "ecs-critical-changes"
  description = "Alert on destructive or suspicious ECS API calls"

  event_pattern = jsonencode({
    source      = ["aws.ecs"]
    detail-type = ["AWS API Call via CloudTrail"]
    detail = {
      eventSource = ["ecs.amazonaws.com"]
      eventName   = [
        "StopTask",
        "DeleteService",
        "DeleteCluster",
        "UpdateService"
      ]
    }
  })
}

resource "aws_cloudwatch_event_target" "ecs_critical_sns" {
  rule      = aws_cloudwatch_event_rule.ecs_critical.name
  target_id = "SendToSNS"
  arn       = aws_sns_topic.alerts.arn

  input_transformer {
    input_paths = {
      event   = "$.detail.eventName"
      who     = "$.detail.userIdentity.sessionContext.sessionIssuer.userName"
      time    = "$.time"
      service = "$.detail.requestParameters.service"
    }
    input_template = ""ECS alert: <event> on <service> by <who> at <time>""
  }
}

For UpdateService, add a second rule specifically for scale-to-zero: filter where requestParameters.desiredCount = 0. That's the most common accidental incident — someone running a cleanup script that hits the wrong environment.

The Oct 2025 addition: ECS CloudTrail data events

Since October 2025, ECS supports CloudTrail data events for ContainerInstance agent API activity (ecs:Poll, ecs:StartTelemetrySession). These aren't in Event History — they require a CloudTrail trail or CloudTrail Lake.

AWS management events (UpdateService, StopTask, etc.) are what most teams need for incident response. The October 2025 addition is different: ECS now supports CloudTrail data events for ContainerInstance agent API calls — the low-level polling activity between the ECS agent and the control plane.

Management eventsData events (Oct 2025)

What they captureUpdateService, StopTask, RunTask, etc.ecs:Poll, ecs:StartTelemetrySession, ecs:PutSystemLogEvents

CostFree (Event History)Additional CloudTrail charges

In Event History?Yes — 90 daysNo — trail or Lake required

Who needs themEveryone — incident responseEC2 launch type, compliance auditing

Resource type—AWS::ECS::ContainerInstance

For most ECS Fargate teams, data events aren't needed for incident response — management events cover UpdateService and StopTask which is where incidents come from. Data events matter if you run EC2 launch type and need to audit ContainerInstance registration activity, or if compliance requires a full record of agent-to-control-plane communication. Enable them only if you have a specific requirement — at scale, ContainerInstance polling events generate significant volume and cost. Details in the ECS CloudTrail logging docs.

Download the skill file — let the AI agent do the audit

The skill file instructs an AI agent to pull all critical ECS CloudTrail events from the last 24 hours across every cluster in your account and produce a structured "who did what" report. Read-only — no changes applied.

ECS CloudTrail Audit Agent scans all clusters, pulls critical ECS events (Update

The agent lists all clusters, runs lookup-eventsfor each critical event type, decodes the userIdentity, and produces a structured output: "Service X was updated at HH:MM by role deploy-prod via GitHub Actions from IP 140.82.114.3." It also flags Root account activity, unexpected source IPs, and scale-to-zero incidents. For teams where "who did this?" is a recurring post-incident question, this is the 2-minute version of the 20-minute manual process.

"To identify the user who initiates a StopTask API call, view StopTask in AWS CloudTrail for userIdentity information."

— AWS Knowledge Center: Troubleshoot running task count changes in ECS

Book a 20-min fleet walkthrough: fortem.dev/book

What Is ECS Service Connect and Should You Use It?

Matt — Fri, 19 Jun 2026 23:50:05 +0000

ECS Service Connect: Is It Worth the Envoy Tax?

Originally published at https://fortem.dev/blog/ecs-service-connect-guide
ECS Service Connect adds an Envoy sidecar to every Fargate task — free feature, real cost. When it beats Cloud Map, when it doesn't, and the July 2025 blue/green fix.

Guide

ecs-service-connectaws-ecs-service-connectecs-service-mesh

TL;DR

ECS Service Connect injects an Envoy proxy into every task automatically. No task definition changes — ECS manages the sidecar.
The feature is free. The cost is the Envoy tax: AWS recommends budgeting +0.25 vCPU and +64 MiB per task on Fargate.
Native blue/green (launched July 2025) works with Service Connect. The older CodeDeploy-based blue/green controller still does not.
Under 5 services or stuck on CodeDeploy: use Cloud Map. 10+ services on native deploys: Service Connect. External traffic: ALB.

Service Connect launched in 2022. It spent two years blocked by a CodeDeploy incompatibility that sent most teams back to plain Cloud Map. That blocker was fixed on July 17, 2025. Here's what Service Connect actually does, what it costs on Fargate, and the three situations where you should still skip it.

Ready to use — Terraform Service Connect configuration

resource "aws_ecs_service" "api" {
  name            = "api"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.api.arn
  desired_count   = 3
  launch_type     = "FARGATE"

  service_connect_configuration {
    enabled   = true
    namespace = "arn:aws:servicediscovery:us-east-1:123456789:namespace/ns-xxx"

    service {
      port_name = "http"  # must match portMappings[].name in task definition

      client_alias {
        port     = 8080
        dns_name = "api"  # other services call: http://api:8080
      }
    }
  }

  network_configuration { ... }
}

# In task definition portMappings, name the port:
# { "name": "http", "containerPort": 8080, "appProtocol": "http2" }

# Account for the Envoy sidecar in your task CPU/memory:
# If your app needs 512 CPU / 1024 MiB, set task to 768 CPU / 1088 MiB

What ECS Service Connect actually does

ECS injects an Envoy proxy sidecar into every task automatically. Apps call other services by short name (http://checkout:8080); the proxy routes, load-balances, and health-checks in seconds — not minutes.

The AWS docs are explicit about how the sidecar works: "This container isn't present in the task definition and you can't configure it. Amazon ECS manages the container configuration in the service." You don't add anything to your task definition (except naming the port mapping). ECS handles the rest at deploy time.

Short-name routing. Services call each other by a name you define in the client_alias.dns_name field — http://checkout:8080, not an ALB DNS string or VPC Route 53 entry. The proxy resolves the endpoint from the Cloud Map namespace and load-balances across all healthy task IPs in round-robin.

Passive health checks. The proxy marks individual tasks unhealthy and stops routing to them within seconds of detecting failures — no health check endpoint required on the calling service. This is the primary reliability advantage over plain Cloud Map DNS, where stale records can persist for the full DNS TTL (typically 15–60 seconds) after a task stops.

Automatic CloudWatch metrics. Request count, HTTP 4xx/5xx rates, and latency (p50, p99) are emitted per service pair without any instrumentation in your app. If your appProtocol is tcp, you get proxy activity but no per-call telemetry — only HTTP/1.1, HTTP/2, and gRPC get the full metric set.

Namespace scope. Service Connect manages its own namespace — it does not write to VPC DNS or Route 53. Short names are only resolvable from inside tasks enrolled in the same namespace. A Lambda function, an EC2 instance, or an ECS service not enrolled in that namespace cannot resolve those names.

Service Connect vs Cloud Map vs internal ALB — which is which

Cloud Map is DNS-based discovery — cheap, simple, slow to fail over. Service Connect adds a proxy for sub-10s failover and per-call metrics. Internal ALBs are for external ingress or non-ECS callers. Most fleets need all three.

The full picture of ECS service-to-service options — including when Cloud Map still wins — is in the ECS service discovery decision guide. This article focuses specifically on Service Connect: what it costs, what it can't do, and when to use it.

Dimension	Service Connect	Cloud Map	Internal ALB
Failover speed	Seconds (proxy detects)	DNS TTL — 15–60s stale	Seconds (connection drain)
Feature cost	$0	$0.10/resource/month	$0.0225/ALB-hour (~$16/mo)
Automatic retries	2 retries on failure	None — app-level only	None — app-level only
Per-call metrics	Built-in (HTTP/gRPC)	None	ALB access logs
Non-ECS callers	No	Yes	Yes
Protocol telemetry	HTTP/1.1, HTTP/2, gRPC	n/a	HTTP only (L7 log)

When to use an internal ALB alongside Service Connect. Lambda functions, EC2 instances, on-prem services via Direct Connect — anything not enrolled in the Service Connect namespace needs a stable HTTPS endpoint. That's the ALB's job. You can run Service Connect for ECS-to-ECS traffic and an internal ALB for inbound calls from outside ECS simultaneously on the same service.

When Cloud Map still wins over Service Connect. If your services have more than 1,000 tasks (Cloud Map hits a Route 53 quota at that scale; Service Connect does not), or if you need cross-account service discovery without AWS RAM, Cloud Map is the cleaner path. And if you have non-ECS callers anywhere in your stack, Cloud Map DNS is the only registry they can reach without a separate ALB.

What Service Connect costs — the feature is free, the sidecar isn't

Service Connect has no feature charge. The cost is the Envoy sidecar: AWS recommends +0.25 vCPU and +64 MiB per task. On a 0.25 vCPU task, that doubles the CPU line item.

AWS's official recommendation is to reserve 256 CPU units (0.25 vCPU) and 64 MiB for the sidecar per task. Bump that to 512 CPU units if your service handles more than 500 requests per second at peak, and to 128 MiB if your cluster runs more than 100 Service Connect services or more than 2,000 tasks total. These are minimums, not guarantees — monitor actual sidecar container metrics in CloudWatch after enabling.

Fleet math for a typical 10-service setup, 3 tasks per service, running 24/7 in us-east-1:

Resource	Calculation	$/month
Sidecar CPU	30 tasks × 0.25 vCPU × $0.04048/hr × 730 hrs	~$221
Sidecar memory	30 tasks × 0.064 GB × $0.004445/GB-hr × 730 hrs	~$6
Service Connect feature	—	$0
Total Envoy tax (10 services × 3 tasks)	~$227/mo

The ratio matters more than the absolute number. On a 2 vCPU task, the sidecar adds ~12% to the CPU line — negligible. On a 0.25 vCPU task, the sidecar doubles it. If your services are right-sized to small task sizes, run the math before enabling fleet-wide. The full breakdown of Fargate task pricing is in the AWS Fargate pricing breakdown.

KEY INSIGHT: The Envoy sidecar is the cost. Run the math on your actual task sizes before rolling Service Connect out fleet-wide. A 0.25 vCPU task doubles its CPU cost. A 1 vCPU task adds 25%. The break-even depends on how much your team values built-in retries and per-call CloudWatch metrics versus paying for those resources.

Cloud Map fees when using Service Connect. ECS creates the Cloud Map namespace and registers service instances automatically when you enable Service Connect. Standard Cloud Map fees still apply — $0.10/registered resource/month for each service instance ECS registers. On a 10-service fleet with 3 tasks each, that is 30 registered resources × $0.10 = $3/month on top of the Envoy sidecar compute. It is a small line item but not zero.

mTLS adds cost. Service Connect supports mutual TLS via AWS Private CA. Certificates rotate every 5 days — roughly 6 rotations per service per month. Factor in Private CA per-certificate pricing if you plan to enable mTLS. Without it, traffic between tasks is unencrypted at the proxy level (VPC provides network isolation, but not encryption in transit).

The July 2025 blue/green unblock — and the CodeDeploy trap that remains

ECS native blue/green (July 17, 2025) supports Service Connect. The old CODE_DEPLOY deployment controller still does not — and throws a hard error at deploy time if you combine them.

"DeploymentController#type CODE_DEPLOY is not supported by ECS Service Connect. I ended up going with Cloud Map-based Service Discovery — which initially felt like the 'old way' of doing things."

— Dev.to, AWS Builders, 2024 (CodeDeploy limitation — still accurate; blue/green via native controller now unblocked)

The dev.to article above drove a lot of teams away from Service Connect. Its conclusion — "use Cloud Map instead" — was correct at the time. The author hit a real, hard error. But the central reason for that conclusion changed on July 17, 2025, when AWS launched built-in blue/green deployments for ECS without a CodeDeploy dependency. Service Connect is explicitly supported in the new native blue/green controller.

What changed. ECS now has three deployment controllers: ROLLING (default), ECS (native blue/green, launched July 2025), and CODE_DEPLOY (legacy). Service Connect works with ROLLING and ECS. It still fails with CODE_DEPLOY.

How to check your controller. In Terraform, look for deployment_controller { type = "CODE_DEPLOY" } in your aws_ecs_service resources. In the AWS console: ECS → Clusters → your cluster → Services → select a service → Configuration tab → Deployment type. If it says "Blue/green deployment (powered by AWS CodeDeploy)", you're on the legacy controller.

The migration path. Switch from CODE_DEPLOY to ECS native blue/green before enabling Service Connect. The blue/green deployment guide covers that migration in detail — including the differences in traffic routing, test header behavior, and rollback mechanics.

KEY INSIGHT: If you're on CodeDeploy and want Service Connect, you have two options: migrate to the ECS native blue/green controller (recommended), or stay on Cloud Map for service discovery until the migration is done. Enabling Service Connect on a CodeDeploy service fails at deploy time with a hard error — not a warning. Budget the controller migration as a prerequisite.

Gotchas nobody warns you about

Envoy sidecar memory can grow unbounded with gRPC traffic. appProtocol is immutable after service creation. HTTP/1.0 is not supported. Windows containers and standalone tasks don't work with Service Connect.

gRPC memory growth. There's a documented re:Post thread from August 2024 where teams noticed the Service Connect proxy container's memory growing without bound after redeploys with gRPC workloads. The app container's memory released normally — only the sidecar kept climbing until gRPC traffic eventually stalled. AWS's workaround: add a task-level memory limit (not just container-level) and over-provision sidecar memory. Also, pin a recent ecs-service-connect-agent version — CVE-2024-34364 (Envoy mirror-response unbounded buffer allocation) can manifest as a memory leak in older agent releases. Monitor sidecar container memory in CloudWatch if you're serving gRPC.

Immutable appProtocol. You set appProtocol in your port mapping configuration — http, http2, grpc, or tcp. You cannot change it after the service is created. If you start with http and later migrate to gRPC, you must delete and recreate the ECS service. Plan the protocol decision before your first deploy — this is the single most operationally painful gotcha in Service Connect.

HTTP/1.0 not supported. The Envoy proxy drops HTTP/1.0 traffic. Most modern clients speak HTTP/1.1 or higher, but legacy internal tools occasionally use 1.0. Verify your client HTTP version before enabling Service Connect on any service that receives internal API calls from older tooling.

Namespace cleanup is manual. ECS does not delete the Cloud Map namespace when you delete a cluster. The namespace (and its resource registrations) stays behind, and you pay $0.10/resource/month for every orphaned registration. Add Cloud Map namespace cleanup to your cluster teardown runbook.

What Service Connect doesn't support at all: Windows containers, standalone task invocations (only ECS services — not RunTask), and cross-Region routing. Services in different AWS Regions cannot communicate via Service Connect. Use an ALB or API Gateway with a custom domain for cross-Region traffic.

Mixed enrollment. You can run some services on Service Connect and some on Cloud Map in the same cluster. The constraint is that non-enrolled services cannot resolve Service Connect short names. Migrate callers and callees together in the same deployment window, or keep a Cloud Map registration running in parallel during the cutover.

What you actually get — retries, passive health checks, metrics

Service Connect configures the proxy for 2 retries, passive outlier detection (eject after 5 failures in 30s), a 15s default timeout, and per-call CloudWatch metrics — and these settings are fixed, not configurable per service.

Retries. The proxy automatically retries failed requests twice, routing each retry to a different task (not re-sending to the failing host). This is transparent to the calling app — it sends one request, the proxy handles the retry if the first task fails to respond. Retry count is 2; you cannot configure it higher or lower.

Passive outlier detection. The proxy tracks failure rates per task. After 5 consecutive failures in a 30-second window, the task is ejected from the load-balancing pool for 30–300 seconds depending on how many consecutive ejections have occurred. This is "passive" — no active health check probes — and it fires within seconds of detecting a problem.

Timeout. The default per-request timeout is 15 seconds. This value is fixed — AWS manages it. If your service has requests that legitimately run longer (batch processing, report generation), Service Connect's fixed timeout will cause failures. Those services should either use Cloud Map or route through an ALB with a custom timeout.

CloudWatch metrics. Without any instrumentation, you get per-service-pair: RequestCount, HTTPCode_Target_4XX, HTTPCode_Target_5XX, and TargetResponseTime (p50, p99). With appProtocol = tcp, the proxy is active but emits only byte-level metrics — no per-call telemetry.

Not a full service mesh. Retry count, timeout, and outlier detection parameters are AWS-managed fixed values. Unlike raw Envoy or the now-deprecated App Mesh, you cannot configure per-route retry policies or custom circuit-breaker thresholds. App Mesh (the configurable option) reaches end-of-life on September 30, 2026. If you need per-route circuit breaker configuration, the current path is a self-managed Envoy deployment — there's no AWS-native equivalent for ECS once App Mesh retires.

Should you use it? A decision framework by fleet size

Under 5 microservices or on the CodeDeploy controller: use Cloud Map. 10+ services on rolling or native blue/green: Service Connect. Need external routing or L7 features: ALB, often alongside Service Connect.

Walk through these questions in order:

If your situation is…	Use this
On CODE_DEPLOY deployment controller	Cloud Map — migrate controller first if you want SC
Non-ECS callers (Lambda, EC2) need to reach the service	Internal ALB (SC can't help here)
Fewer than 5 ECS services calling each other	Cloud Map — simpler, cheaper
10+ ECS services, rolling or native blue/green	Service Connect — right default
Need mTLS between services	Service Connect + AWS Private CA
Heavy gRPC, Fargate	Service Connect with +128 MiB sidecar memory, pinned agent version
Tasks need >15s per request	Cloud Map or ALB — SC has a fixed 15s timeout
Windows containers	Cloud Map — SC doesn't support Windows

"In cases where you don't need traffic insights and the service is a minor supporting service, Cloud Map Service Discovery can be a simpler solution."

— AWS re:Post community, verified June 2026

Service Connect is the right default for new ECS-to-ECS traffic on rolling or native blue/green. But "right default" doesn't mean "apply to everything without checking." The three concrete situations where you should stay on Cloud Map: you're on the CodeDeploy controller and don't have time to migrate it, you have non-ECS callers that can't enroll in the namespace, or your tasks are sized at 0.25 vCPU and the doubled CPU cost isn't justified by the built-in retries.

For teams already using Cloud Map — the bar for migration is not "Service Connect is available." The bar is "we have a concrete reason to switch": you want per-call CloudWatch metrics without adding instrumentation, you need built-in retries without client-side retry logic, or you're enabling mTLS and want the native Private CA integration. If none of those apply, an existing Cloud Map setup that works is not worth disrupting.

If you read this, you might also want to know

Can I mix Service Connect and Cloud Map service discovery in the same cluster?

Yes — services in the same cluster can use different discovery mechanisms. The constraint is that a service not enrolled in the Service Connect namespace cannot resolve SC short names. Services on Cloud Map use Route 53 DNS and are reachable by any VPC resource regardless of namespace enrollment. Migrate callers and callees together to avoid resolution failures during cutover.

How do I migrate existing services from Cloud Map to Service Connect?

Add the service_connect_configuration block to your ECS service Terraform resource and redeploy. ECS creates a new namespace or enrolls in an existing one. Remove the service_registries block after the service is healthy on Service Connect. One caveat: Cloud Map and Service Connect cannot be active on the same ECS service simultaneously — the cutover is per-service, so migrate callee first, then callers in the same deploy window.

Does Service Connect work with ECS tasks on EC2 launch type?

Yes. Service Connect works with both Fargate and EC2 launch types. The Envoy sidecar overhead (0.25 vCPU, 64 MiB) applies either way, but on EC2 you're paying for the instance regardless — the marginal sidecar cost is lower than on Fargate where every CPU unit and MiB is billed directly.

What happens to Service Connect if the Cloud Map namespace is deleted?

Service Connect stops working. The Envoy proxy cannot resolve service names without the Cloud Map namespace. Services lose the ability to route to each other via short names. ECS does not auto-recreate the namespace. Treat the Cloud Map namespace as a dependency of your ECS cluster — include it in disaster recovery runbooks and don't delete it without disabling Service Connect first.

Common questions

Does ECS Service Connect replace Cloud Map?

No — Service Connect uses Cloud Map as its backend registry. When you enable Service Connect, ECS creates the Cloud Map services automatically. If you're already using Cloud Map directly, Service Connect sits on top of it. You pay for Cloud Map resources whether or not you add the proxy layer.

How much memory does Service Connect use?

AWS recommends reserving +64 MiB per task for the Envoy sidecar. Observed idle usage is typically under 60 MB, but production workloads with many concurrent connections can push higher. There's a documented issue with gRPC traffic causing unbounded sidecar memory growth on Fargate — add a task-level memory limit and monitor sidecar container memory in CloudWatch.

Does Service Connect work with CodeDeploy blue/green?

No. The ECS native blue/green controller (launched July 2025) works with Service Connect. The older CodeDeploy-based blue/green controller does not — you'll get the error 'DeploymentController#type CODE_DEPLOY is not supported by ECS Service Connect' at deployment time. If you're on CodeDeploy, use Cloud Map for service discovery until you migrate to the native controller.

Can Service Connect route traffic between ECS clusters?

Yes — within the same AWS Region and the same Cloud Map namespace. Cross-Region routing is not supported. Services in different clusters can communicate as long as they're registered in the same namespace and the networking (VPC, security groups) allows it.

What protocols does ECS Service Connect support?

HTTP/1.1, HTTP/2, gRPC, and TCP. Set appProtocol in your service configuration. HTTP/2 and gRPC get full per-call telemetry (request count, error rate, latency). TCP mode works but gives no protocol-level metrics — just bytes transferred. HTTP/1.0 is not supported. Note: appProtocol cannot be changed after the service is created.

Worth reading

GuideAWS ECS Fargate: What It Is, How It Works, What It CostsService Connect in context — where it fits in the full Fargate architecture alongside task definitions, clusters, and cost.GuideECS Service Discovery: Cloud Map, Service Connect, or Internal Load Balancer?The decision table for when to use Service Connect vs Cloud Map vs an internal ALB.

Book a 20-min fleet walkthrough: fortem.dev/book

How to Optimize AWS ECS Costs Beyond Reserved Instances

Matt — Fri, 19 Jun 2026 23:49:23 +0000

AWS ECS Cost Optimization Beyond Spot and Savings Plans

Originally published at https://fortem.dev/blog/aws-cost-optimization-ecs
Spot and Savings Plans cover the first 30%. Five more levers most ECS teams miss: Graviton, VPC endpoints, Container Insights scoping, shared ALBs, Compute Optimizer.

Guide

aws-ecs-cost-optimizationecs-fargate-cost-reductionaws-cost-savings-ecs

TL;DR

Fargate compute is only half your ECS bill. ALBs, NAT Gateway, and Container Insights account for 30–52% of total spend in verified fleet benchmarks.
The S3 gateway endpoint is free — add it today. Every container image pull currently routes through NAT at $0.045/GB unless you have one.
ARM64/Graviton Fargate is $0.03238 vs $0.04048/vCPU-hr — a flat 20% reduction on all compute, no architectural change required.
AWS Compute Optimizer covers Fargate (free since Dec 2022). One CLI command returns right-sizing recommendations for every service in your fleet.

Ready to use — copy this today

Three commands you can run right now — before changing a single task definition.

1. Add the free S3 gateway endpoint (eliminates NAT charges on ECR image pulls)

aws ec2 create-vpc-endpoint \
  --vpc-id $VPC_ID \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids $RTB_ID \
  --type Gateway

2. Pull Compute Optimizer recommendations fleet-wide

aws compute-optimizer get-ecs-service-recommendations \
  --query 'ecsServiceRecommendations[*].{
    Service:serviceArn,
    Finding:finding,
    vCPU:recommendationOptions[0].containerRecommendations[0].containerName
  }' \
  --output table

3. Check Container Insights status per cluster

aws ecs list-clusters | jq -r '.clusterArns[]' | \
  xargs -I{} aws ecs describe-clusters \
    --clusters {} \
    --include SETTINGS \
    --query 'clusters[0].{
      Name:clusterName,
      Insights:settings[?name==`containerInsights`].value|[0]
    }' \
  --output table

You've done Spot and scheduling. Here's where the next 30% hides.

Fargate compute is only half the ECS bill. Teams that stop at Spot and scheduling still pay $0.045/GB in NAT data processing, $0.07/metric/month for Container Insights they forgot was on, and 20% more per vCPU than Graviton would cost. Verified average: compute-only estimates undercount total spend by 30–52%.

CloudBurn ran the numbers on a real Fargate fleet and found compute-only estimates of $181.77 against an actual bill of $276.27 — a 52% gap driven entirely by ALB base charges, NAT data processing, and CloudWatch metrics. The gap compounds across environments: 10 environments that look like a $1,800/month Fargate bill are actually closer to $2,700.

This article picks up where Spot and scheduling leave off. If you haven't covered those yet, start with how to cut Fargate compute costs with Spot and scheduling — those two moves alone cut 60–70% before touching anything else. Come back here for the second layer.

The five levers below — NAT/VPC endpoints, Graviton, Container Insights, ALB consolidation, and Compute Optimizer — are independent. You can apply any one of them this week without touching the others. Each section includes the dollar math for a 10-service fleet so you can rank them by impact before you start.

NAT Gateway is quietly billing $0.045/GB on every image pull

Every container image pull and AWS API call from a private subnet runs through NAT at $0.045/GB data processing. A 403MB image pulled 32k times (crash-looping health check) costs ~$566 via NAT — $0.35 with an S3 gateway endpoint. The gateway endpoint is free. Add it before anything else.

The crash-loop story is instructive. One team deployed a container with a health check misconfiguration — the task started, failed, restarted, and repeated 32,000 times over several days. The 403MB image pulled each time at $0.045/GB NAT data processing: 403 MB × 32,000 pulls ÷ 1,024 = 12,594 GB × $0.045 = ~$567. With the free S3 gateway endpoint routing ECR layer pulls through AWS backbone instead of NAT, the same traffic costs $0.35. The endpoint takes 90 seconds to add.

Option	Hourly	Data processing
NAT Gateway	$0.045/hr	$0.045/GB
Interface endpoint (ECR, CW, etc.)	$0.01/hr/AZ	$0.01/GB
Gateway endpoint (S3, DynamoDB)	Free	Free

The nuance that trips teams up: interface endpoints are not always cheaper than NAT. One interface endpoint costs $0.01/hr/AZ = ~$7.20/month per AZ. Add the five endpoints typically required for private ECS tasks (ECR API, ECR DKR, CloudWatch Logs, Secrets Manager, STS) across 3 AZs: that's 5 × 3 × $7.20 = $108/month in endpoint hourly charges alone — before counting data processing. The fourtheorem team documented exactly this: a setup that looked cheaper with endpoints ($43.84) flipped to $197/month once all required endpoints were counted, versus $100/month with NAT.

“Each service that is not deployable to a VPC requires a new VPC Endpoint… the bills stack up quickly!”

— fourtheorem, Amazon ECS Hidden Costs

KEY INSIGHT: The S3 gateway endpoint is always free and takes 90 seconds to add — do it unconditionally. Interface endpoints require explicit break-even math: calculate monthly NAT data charges vs. (number of endpoints × AZs × $7.20). At low data volumes, NAT is cheaper.

Check whether you already have the S3 gateway endpoint in place:

aws ec2 describe-vpc-endpoints \
  --filters \
    "Name=service-name,Values=com.amazonaws.us-east-1.s3" \
    "Name=vpc-endpoint-type,Values=Gateway" \
  --query 'VpcEndpoints[*].{State:State,VPC:VpcId}'

Empty output means you don't have one. The create command is in the Ready-to-use block above.

Switch to Graviton and take 20% off every Fargate task

ARM64 Fargate costs $0.03238/vCPU-hr vs $0.04048 for x86 — exactly 20% less, same memory pricing. For 10 services × 3 tasks × 2 vCPU running 730 hours, that's $142/month saved with no infrastructure change — just rebuild images for linux/arm64.

The math is clean. For a 10-service fleet where each service runs 3 tasks at 2 vCPU:

Graviton savings — 10-service fleet

x86: 10 × 3 × 2 vCPU × $0.04048 × 730 hr = $1,773/mo

ARM64: 10 × 3 × 2 vCPU × $0.03238 × 730 hr = $1,418/mo

Savings: $355/mo · $4,257/yr

That's at 2 vCPU per task. At 0.5 vCPU (smaller tasks), the same formula yields ~$89/month — still worth it for zero architectural work. Memory pricing is identical between x86 and ARM64, so all savings come from compute.

KEY INSIGHT: Graviton + Spot is the highest-impact combination on Fargate. The 20% Graviton discount stacks with the ~70% Spot discount for a combined ~76% reduction versus x86 on-demand. For dev environments that already run on Spot, switching to ARM64 pulls another 20% out of the remaining compute spend.

What needs to change: rebuild Docker images with docker buildx build --platform linux/arm64, then update the ECS task definition's runtimePlatform.cpuArchitecture to ARM64. Most Python, Node.js, Go, Java, and Ruby stacks rebuild without any code changes. Test before flipping production — native code compiled for x86, some C-extension Python packages, and kernel-module-dependent workloads need verification.

For the full Spot setup and capacity provider strategy, see how to cut ECS Fargate costs by 65%. Graviton and Spot configure independently — you can add Graviton to an existing Spot setup today.

Container Insights Enhanced: $0.07/metric/month, and it multiplies with fleet size

Enhanced Container Insights for ECS charges $0.07 per metric per month. AWS's own example: 1 cluster, 5 services, 20 tasks, 50 containers = 2,264 metrics = $158.48/month. At 10 environments that's over $1,500/month for observability you may not be actively using.

The metric count compounds with fleet size because each container generates multiple metrics: CPU utilization, memory utilization, network bytes in/out, storage read/write, task count. AWS's CloudWatch pricing page gives the worked example directly: 1 cluster with 5 services, 20 tasks, 50 containers generates 2,264 metrics. At $0.07 each: $158.48/month per cluster.

Container Insights fleet math

1 cluster (50 containers): 2,264 metrics × $0.07 = $158.48/mo

5 clusters (dev + staging + prod × regions): ~$792/mo

10 clusters (multi-environment fleet): ~$1,585/mo

Fix: enable Enhanced on prod clusters only → $158/mo vs $1,585/mo

Enhanced Container Insights is opt-in per cluster — it is not on by default for all clusters. The problem is that teams often enable it when debugging a production issue and never disable it on the dev/staging clusters where they also turned it on. Standard CloudWatch metrics (CPU, memory at task level) still work without Enhanced — they're the base tier and are billed differently. Enhanced adds per-container-level metrics, ECS-specific dimensions, and storage metrics.

Check which clusters have Enhanced enabled, then disable it on non-production clusters:

# Check current status per cluster
aws ecs describe-clusters \
  --clusters YOUR_CLUSTER_NAME \
  --include SETTINGS \
  --query 'clusters[0].settings'

# Disable Enhanced on a cluster
aws ecs update-cluster-settings \
  --cluster YOUR_CLUSTER_NAME \
  --settings name=containerInsights,value=disabled

For controlling CloudWatch log costs across ECS at fleet scale, see controlling CloudWatch log costs for ECS— that covers log group retention, FireLens vs awslogs, and the log-volume math by service type.

One ALB per environment, not one per service

Each ALB costs $16–20/month in base hourly charges before LCUs. Teams that provision one ALB per microservice per environment run 50–100+ ALBs. One team reduced from 270 ALBs to 9 by switching to host-based routing — one ALB per environment, listener rules route to services.

The Signiant engineering team documented their ALB consolidation in detail: they had 270 ALBs across their infrastructure, running at roughly $16–20 each per month. Switching to a shared ALB model with host-based routing ( *.service.env.internal → listener rules → target groups) reduced that to 9 ALBs — 261 base charges eliminated. At $18/month average: $4,698/month removed from the bill.

The anti-pattern is common: a Terraform module creates one ECS service and one ALB together, so teams end up with an ALB per service per environment by default. Shared ALBs require slightly more routing configuration but the cost argument is clear past 3–4 services per environment.

ALB consolidation also reduces IPv4 address charges. Since February 2024, AWS charges $0.005/hr per public IPv4 address — each ALB typically holds one. At 270 ALBs: 270 × $0.005 × 730 hr = $985/month in IPv4 charges alone.

A shared ALB setup in Terraform:

# Shared ALB — one per environment
resource "aws_lb" "env" {
  name               = "${var.env_name}-alb"
  internal           = false
  load_balancer_type = "application"
  subnets            = var.public_subnet_ids
  security_groups    = [aws_security_group.alb.id]
}

resource "aws_lb_listener" "https" {
  load_balancer_arn = aws_lb.env.arn
  port              = 443
  protocol          = "HTTPS"
  ssl_policy        = "ELBSecurityPolicy-TLS13-1-2-2021-06"
  certificate_arn   = var.acm_cert_arn

  default_action {
    type = "fixed-response"
    fixed_response {
      content_type = "text/plain"
      message_body = "no route"
      status_code  = "404"
    }
  }
}

# Per-service listener rule — host-based routing
resource "aws_lb_listener_rule" "api" {
  listener_arn = aws_lb_listener.https.arn
  priority     = 100

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.api.arn
  }

  condition {
    host_header {
      values = ["api.${var.env_name}.example.com"]
    }
  }
}

resource "aws_lb_listener_rule" "worker" {
  listener_arn = aws_lb_listener.https.arn
  priority     = 110

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.worker.arn
  }

  condition {
    host_header {
      values = ["worker.${var.env_name}.example.com"]
    }
  }
}

Caveat: WebSocket services and services that require conflicting port bindings may need their own ALB. Otherwise, one ALB per environment handles up to 100 listener rules (the default soft limit, extendable via quota request).

Compute Optimizer runs a free fleet right-sizing pass — and it's scriptable

AWS Compute Optimizer has supported Fargate since December 2022 at no charge. get-ecs-service-recommendations returns CPU and memory recommendations at both task and container level. Script it across all services and diff against current task definitions to find over-provisioned tasks fleet-wide.

Compute Optimizer launched ECS Fargate support on December 23, 2022 — it's free, and most teams haven't used it. The tool analyzes CloudWatch utilization metrics from the trailing 14 days and returns recommendations at two levels: the task definition (overall CPU/memory) and the individual container (container-level CPU/memory shares within the task). For over-provisioned long-running services, the claimed savings are 30–70% of compute spend.

The gotcha that wastes time:Compute Optimizer won't generate recommendations for a service if a target-tracking Auto Scaling policy is attached to CPU or memory for that service. If you check a service and get no recommendations, verify whether it has an ASG policy. Recommendations require at least 24 hours of CloudWatch and ECS utilization data in the trailing 14-day window.

Fleet script — loop over all clusters and return recommendations for every service:

#!/bin/bash
# Get Compute Optimizer recommendations for all ECS services
# Requires: AWS CLI v2, jq

REGION="${AWS_DEFAULT_REGION:-us-east-1}"

echo "Fetching all clusters..."
CLUSTERS=$(aws ecs list-clusters --region "$REGION" --query 'clusterArns[]' --output text)

for CLUSTER in $CLUSTERS; do
  CLUSTER_NAME=$(basename "$CLUSTER")
  echo ""
  echo "=== $CLUSTER_NAME ==="

  SERVICES=$(aws ecs list-services     --cluster "$CLUSTER"     --region "$REGION"     --query 'serviceArns[]'     --output text)

  for SERVICE_ARN in $SERVICES; do
    RESULT=$(aws compute-optimizer get-ecs-service-recommendations       --service-arns "$SERVICE_ARN"       --region "$REGION"       --query 'ecsServiceRecommendations[0].{
        Finding: finding,
        CurrentCPU: currentServiceConfiguration.cpu,
        CurrentMem: currentServiceConfiguration.memory,
        RecommendedCPU: recommendationOptions[0].containerRecommendations[0].memorySizeConfiguration.cpu,
        RecommendedMem: recommendationOptions[0].containerRecommendations[0].memorySizeConfiguration.memory
      }'       --output json 2>/dev/null)

    if [ -n "$RESULT" ] && [ "$RESULT" != "null" ]; then
      SERVICE_NAME=$(basename "$SERVICE_ARN")
      echo "$SERVICE_NAME: $RESULT" | jq -c .
    fi
  done
done

To use this in CI: run the script, parse the JSON output, and compare recommended vs current CPU/memory in each task definition. Flag as a PR comment or Slack alert when drift exceeds 20%. Teams that do this catch over-provisioning at deploy time before it accumulates.

“If you've estimated your ECS costs based only on Fargate compute pricing, you're probably underestimating by 30–50%.”

— CloudBurn, AWS Fargate Pricing: Real Costs

If you read this, you might also want to know

How do I know if my ECS tasks are right-sized without Compute Optimizer?

Check CloudWatch Container Insights → CPU and Memory Utilization per service. Look at p95 over a 2-week window. If p95 CPU stays below 30% of the task allocation, drop to the next Fargate size (e.g. 1 vCPU → 0.5 vCPU). If p95 memory stays below 40%, halve the memory allocation. Standard Container Insights (not Enhanced) gives you this at the task level for free.

Can I mix x86 and ARM64 tasks in the same ECS cluster?

Yes — ECS clusters are architecture-agnostic. Each task definition specifies its own runtimePlatform.cpuArchitecture. You can migrate services one at a time: flip a dev task definition to ARM64, test for a week, then move staging and production. No cluster changes required.

How do I set up AZ-aware task placement to avoid cross-AZ charges?

Use the spread placement strategy with field=attribute:ecs.availability-zone to distribute tasks across AZs, and ensure your target groups use the same AZ as the tasks routing through them. Cross-AZ traffic in the same region costs $0.01/GB each direction. For high-throughput services, co-locating the ALB target group and the task in the same AZ eliminates this charge.

What happens to in-flight requests when a Fargate Spot task is interrupted?

ECS sends SIGTERM to the container and fires an EventBridge event with stopCode SPOT_INTERRUPTION. You have up to 2 minutes before the task is forcibly stopped. Set stopTimeout to 120 seconds in your task definition to use the full window. Configure your ALB to deregister the target before SIGTERM (the connection draining period handles this). In-flight requests that complete within the draining window are served normally.

Common questions

Are VPC endpoints always cheaper than NAT Gateway for ECS?

Not always. The free S3 gateway endpoint is always worth adding — it cuts NAT costs on ECR image pulls at zero cost. Interface endpoints for ECR API, CloudWatch Logs, and Secrets Manager each cost ~$7.20/month per AZ. If you need all five common endpoints in 3 AZs, that's ~$108/month — which can exceed your NAT costs at low data volumes. Run the math: monthly NAT data charges vs. (number of endpoints × AZs × $7.20). The break-even is roughly 1,200 GB/month of relevant traffic per interface endpoint.

Does AWS Compute Optimizer work with ECS Fargate?

Yes — Compute Optimizer has covered Fargate since December 23, 2022 at no charge. It recommends CPU and memory at both task and container level. Requirements: at least 24 hours of CloudWatch and ECS utilization data in the trailing 14 days. One gotcha: it won't generate recommendations if a target-tracking Auto Scaling policy is attached to CPU or memory for the service.

How much does Container Insights cost for ECS?

Enhanced Container Insights charges $0.07 per metric per month, prorated hourly. AWS's own example for a single cluster with 5 services, 20 tasks, and 50 containers: 2,264 metrics = $158.48/month. Standard CloudWatch custom metrics are a separate charge. Enhanced is opt-in per cluster — check which clusters have it enabled with: aws ecs describe-clusters --clusters CLUSTER --include SETTINGS

How do I migrate ECS Fargate tasks to Graviton/ARM64?

Rebuild your container images for linux/arm64 using Docker Buildx: docker buildx build --platform linux/arm64 -t myimage:arm64 . Then update your ECS task definition to set runtimePlatform.cpuArchitecture to ARM64 and runtimePlatform.operatingSystemFamily to LINUX. Most interpreted stacks (Python, Node.js, Go, Java, Ruby) rebuild without code changes. Test binaries compiled for x86 — they won't run on ARM64 without recompilation.

What is the Fargate Spot interruption rate?

AWS does not publish a specific Fargate Spot interruption rate. In practice, Spot interruptions are infrequent for most workloads — typically single-digit percentage of tasks per month in stable capacity regions, though this varies by AZ and instance family demand. ECS gives a 2-minute SIGTERM warning via both the container signal and an EventBridge event (aws.ecs task-state-change with stopCode SPOT_INTERRUPTION). Set stopTimeout to 120 seconds or less in your task definition to handle the full window.

Worth reading

ToolAWS ECS Fargate Cost CalculatorCalculate your real Fargate bill before and after optimization. Enter fleet size, see the dollar impact of scheduling.Guide · How to Cut AWS ECS Fargate Costs by 65%Scheduling, right-sizing, Spot, and orphaned environments — the four methods that take a 12-environment fleet from $1,730 to $380/month.

See your real per-env cost: fortem.dev/ecs-cost-calculator

AWS Cost Anomaly Detection for ECS Teams: What It Catches, What It Misses, and How to Set It Up

Matt — Fri, 19 Jun 2026 23:49:18 +0000

AWS Cost Anomaly Detection for ECS: Setup Guide 2026

Originally published at https://fortem.dev/blog/aws-cost-anomaly-detection-ecs
Set up AWS Cost Anomaly Detection for ECS Fargate fleets with per-environment tag monitors. Includes Terraform config, threshold strategy, and what the 24h delay means for your team.

Guide

aws-cost-anomaly-detectionecs-cost-monitoringfargate-cost-alerts

AWS Cost Anomaly Detection is free, ships with ML-based pattern detection, and can catch ECS spend spikes automatically. The catch: it runs on billing data that's up to 24 hours old, and the default setup monitors all ECS spend as one pooled number — not per environment. A spike in staging looks identical to a spike in prod. This guide covers how CAD actually works, how to wire it to your environment tags for per-environment alerts, what Terraform to drop in, and where the tool has real blind spots.

TL;DR

01CAD is free and uses ML — no static thresholds to maintain, no per-service configuration by default.
02The default AWS service monitor pools all ECS spend together — set up a tag-based monitor to get per-environment alerts.
03Detection takes up to 24 hours after a spike appears in billing data. Sub-12-hour spikes often go undetected.
04IMMEDIATE alerts require an SNS topic, not an email address — email-only subscriptions get a ValidationException.
05CAD is your monthly fire detector. It won't catch a runaway task that was killed before the billing data arrived.

Ready to use — drop this into your Terraform today

Tag-based monitor on your environment key, SNS topic with correct IAM policy, and an IMMEDIATE subscription with combined $ + % threshold. Replace alerts@yourcompany.com with your on-call address.

# SNS topic for cost anomaly alerts
resource "aws_sns_topic" "cost_anomaly" {
  name = "ecs-cost-anomaly-alerts"
}

# Required: grant CAD permission to publish to SNS
data "aws_iam_policy_document" "cost_anomaly_sns" {
  statement {
    sid     = "AllowCostAnomalyDetection"
    effect  = "Allow"
    actions = ["SNS:Publish"]
    principals {
      type        = "Service"
      identifiers = ["costalerts.amazonaws.com"]
    }
    resources = [aws_sns_topic.cost_anomaly.arn]
    condition {
      test     = "StringEquals"
      variable = "aws:SourceAccount"
      values   = [data.aws_caller_identity.current.account_id]
    }
  }
}

resource "aws_sns_topic_policy" "cost_anomaly" {
  arn    = aws_sns_topic.cost_anomaly.arn
  policy = data.aws_iam_policy_document.cost_anomaly_sns.json
}

resource "aws_sns_topic_subscription" "oncall_email" {
  topic_arn = aws_sns_topic.cost_anomaly.arn
  protocol  = "email"
  endpoint  = "alerts@yourcompany.com"
}

# Tag-based monitor — one ML baseline per environment tag value
resource "aws_ce_anomaly_monitor" "env_monitor" {
  name         = "ecs-per-environment-monitor"
  monitor_type = "CUSTOM"

  monitor_specification = jsonencode({
    Tags = {
      Key          = "environment"      # must match your cost allocation tag key
      MatchOptions = ["EQUALS"]
    }
  })
}

# Subscription: IMMEDIATE via SNS (email-only = ValidationException)
resource "aws_ce_anomaly_subscription" "env_alerts" {
  name      = "ecs-environment-anomaly-alerts"
  frequency = "IMMEDIATE"

  monitor_arn_list = [aws_ce_anomaly_monitor.env_monitor.arn]

  subscriber {
    type    = "SNS"
    address = aws_sns_topic.cost_anomaly.arn
  }

  depends_on = [aws_sns_topic_policy.cost_anomaly]

  # AND logic: both conditions must be met to reduce alert noise
  threshold_expression {
    and {
      dimension {
        key           = "ANOMALY_TOTAL_IMPACT_ABSOLUTE"
        values        = ["30"]           # $30 minimum impact
        match_options = ["GREATER_THAN_OR_EQUAL"]
      }
    }
    and {
      dimension {
        key           = "ANOMALY_TOTAL_IMPACT_PERCENTAGE"
        values        = ["25"]           # 25% above expected
        match_options = ["GREATER_THAN_OR_EQUAL"]
      }
    }
  }
}

How AWS Cost Anomaly Detection works

CAD uses ML to model your normal spend per dimension, runs approximately 3× daily on billing data that's up to 24 hours old, and alerts when actual spend deviates from expected by more than your configured threshold.

The service launched in 2020 and has been updated significantly since. The November 2025 update switched from calendar-day batches to rolling 24-hour windows — meaning the model now compares your current spend against the same time of day in previous periods, rather than against a full-day total. For ECS workloads with business-hours patterns, this reduces false positives on Monday mornings when spend jumps from a quiet weekend.

Monitor dimension	What it tracks	ECS use
AWS services	All ECS spend pooled across all envs	Default — too coarse for fleets
Linked accounts	Per AWS account spend	Useful for account-per-env setups
Cost allocation tags	Per tag value (e.g. per environment)	Best for ECS fleets using env tags
Cost categories	Per business unit or product	Useful for multi-product orgs

The ML model adjusts for trends and seasonality automatically. You don't set a fixed budget cap — the model learns what "normal" looks like for your specific spend pattern and alerts only when that pattern breaks. The tradeoff: the model needs at least 10 days of history per dimension before it can fire. A brand-new ECS environment with zero history gets no anomaly alerts until day 11.

What ECS cost spikes CAD actually catches

CAD catches ECS spend anomalies at AWS service level by default — meaning all your environments pooled together. It reliably catches sustained scale-out events, forgotten running environments, and Fargate On-Demand vs Spot fall-through spikes that last longer than one billing cycle.

The "sustained" qualifier matters. per-environment cost visibility on ECS is already hard — CAD makes it harder when all environments share one anomaly baseline. A $200 spike in your dev environment looks like noise when your prod environment spends $2,000.

Scenario	Spike type	CAD (default)	Delay
Dev env running 24/7 after sprint ends	Sustained (3+ days)	Catches it	24–48 hours
Fargate Spot falls back to On-Demand for 8 hours	Sustained (8+ hours)	Usually catches it	24 hours
Runaway task scales to 50 replicas for 3 hours	Short spike (<6h)	Often misses	Task gone before detection
NAT Gateway burst from one env's batch job	Single-env spike	Misses (pools with others)	No per-env alert without tag monitor

KEY INSIGHT: Key insight The 24-hour delay is the biggest constraint for ECS teams. A Fargate task that scaled out at 9am and was killed by 3pm generates no anomaly alert — the spending happens in a single billing period, and CAD reads billing data with a 24-hour lag. By the time the data arrives, the task is gone.

Setting up a per-environment tag monitor

Create a Cost Allocation Tag monitor on your environmentkey. Each tag value — dev, staging, prod — gets its own ML baseline and can fire independently without one environment's spend pattern polluting another's alert.

Before creating a tag-based monitor, your cost allocation tags must be activated. Tags only appear in Cost Explorer — and therefore in CAD — after activation. This catches teams off guard: you've been tagging your ECS tasks for months, but none of that data flows into CAD until you flip the switch.

Prerequisite — activate cost allocation tags

1.Open AWS Billing and Cost Management console
2.Navigate to Cost allocation tags → "AWS-generated tags" and "User-defined tags" tabs
3.Find your environment tag key (e.g. "environment") → click Activate
4.Wait up to 24 hours for historical data to appear in Cost Explorer
5.Then create your CAD monitor — do not create it before activation

Choose an AWS managed monitor(not customer managed) for your environment tag. Managed monitors automatically discover new tag values as you add environments — if you spin up a new "staging-eu" environment next month, the monitor picks it up without any config change. The trade-off: all tag values share one alert threshold. If you need different thresholds for prod vs dev, use customer managed monitors — but they cap at 10 tag values per monitor.

New tag values need 10 days of billing history before CAD can model normal spend and fire alerts. Plan for this when spinning up a new environment — don't expect anomaly alerts in the first two weeks.

Terraform: the full config

Two core resources: aws_ce_anomaly_monitor (tag-based) and aws_ce_anomaly_subscription (SNS, IMMEDIATE). Email-only subscriptions cannot use IMMEDIATE frequency — you need an SNS topic with the correct IAM policy first.

The Terraform block at the top of this article is the complete production config. Two things to get right:

SNS topic policy

The SNS topic must explicitly grant costalerts.amazonaws.com permission to publish. Without this policy, CAD sends no error — alerts fail silently and you get nothing. The aws:SourceAccount condition limits the permission to your own account only.

CUSTOM vs DIMENSIONAL monitor type

Tag-based monitors use monitor_type = "CUSTOM" with a monitor_specification JSON block. Service-level monitors use monitor_type = "DIMENSIONAL" with monitor_dimension = "SERVICE". These are different resource shapes in the Terraform provider — using the wrong type will error at apply time.

For teams using consistent cost allocation tagging across environments, the tag-based monitor can also be created as an AWS managed monitor (not customer managed) — which auto-discovers new environments. The Terraform resource for a managed TAG monitor looks slightly different: omit the monitor_specification block and instead use monitor_type = "DIMENSIONAL" with monitor_dimension = "TAG". Check the AWS Cost Anomaly Detection docs for the current provider version syntax.

Threshold strategy for ECS fleets

For a 10-environment fleet, start with $30 absolute AND 25% relative (AND logic). Production alone warrants a lower absolute threshold — $20 with 20% catches real incidents without drowning in dev noise. The AWS default (40% + $100) is too blunt for ECS environments with variable baselines.

The problem with the $100 default: a dev environment spending $40/month on idle Fargate tasks can spike to $120 — a 200% increase — and never trigger an alert because the $100 absolute threshold isn't met. For small environments, percentage-based thresholds catch what dollar thresholds miss.

Environment	Absolute ($)	Percentage (%)	Logic
Production	$20	20%	AND
Staging	$30	25%	AND
Dev / ephemeral	$15	30%	AND
All environments (fallback)	$30	25%	AND

Use AND, not OR. OR logic on a percentage threshold fires every time a tiny environment has any activity after a quiet weekend — because 100% above $0 is infinite. AND requires both the dollar amount and the percentage to be exceeded simultaneously, which dramatically reduces noise from small environments with variable usage.

After the first few weeks, mark detected anomalies as "Accurate anomaly" or "Not an issue" in the console. CAD uses this feedback to tune the model. A model trained on your team's feedback converges on your actual noise floor faster than one running without it.

Where CAD falls short for ECS teams

CAD won't catch a Fargate task that scales to 50 replicas, runs for 6 hours, and is killed before billing data arrives. It also can't alert on per-service cost within an environment — only on per-environment total spend.

Three hard limits to plan around:

No real-time detection

Cost Explorer has up to a 24-hour data lag. CAD runs 3× per day on that data. A Fargate task that spends $300 between 8am and 5pm on a Tuesday won't appear in CAD until Wednesday at the earliest — and only if the spending pattern looks anomalous relative to your history. Real-time cost monitoring requires CloudWatch metrics and billing alarms, which operate on estimated charges with a different (faster) refresh cycle.

No service-level granularity within an environment

The tag-based monitor fires when total spend for the "dev" tag value deviates from normal. It cannot tell you which ECS service within "dev" caused the spike. Root cause analysis surfaces up to 10 contributing factors (service, region, account, usage type) — but these are dimensions in Cost Explorer, not ECS service names. You still need Cost Explorer or a per-service tagging strategy to narrow it down.

Scheduled environments create false anomalies

If you schedule non-prod environments to stop outside business hours, CAD sees a cost of $0 at night and a spike every morning when they restart. The ML model learns this pattern over time — but the first 2–4 weeks after introducing scheduling will generate false positive alerts. Disable alerts during the model warm-up period or set a higher absolute threshold temporarily.

KEY INSIGHT: Key insight CAD is your monthly fire detector. It catches sustained burns — a forgotten environment left running, a Spot fallback that held for three days. Fortem's per-environment cost tracking is your smoke alarm: it sees what's happening now, before it becomes a billing-cycle problem.

"AWS Cost Anomaly Detection runs approximately three times a day after your billing data is processed. Anomaly detection relies on the data from Cost Explorer which has a latency of up to 24 hours. Therefore, it can take up to 24 hours to detect an anomaly after the anomalous usage happens."

— AWS Cost Anomaly Detection FAQ, verified June 2026

If you read this, you might also want to know

Can I use CAD with a multi-account ECS setup?

Yes. In a management account, create a linked account monitor to track per-member-account spend. Combine it with a tag-based monitor per account if you want both dimensions. Member accounts can only create an AWS service monitor — linked account and tag monitors require the management account.

What if my ECS tasks don't have environment tags yet?

Tag-based monitoring only works on costs that are tagged. Untagged ECS tasks appear in the 'no tag value' bucket. The fastest path: add a default_tags block to your Terraform AWS provider — every resource gets the environment tag automatically without changing individual resource configs.

Does CAD replace AWS Budgets?

No — they answer different questions. Budgets: 'alert me when I cross $X.' CAD: 'alert me when I'm abnormally above my historical pattern, even if I haven't hit a fixed cap.' Use Budgets for hard financial limits and CAD for pattern deviation. A $50 spike in a normally-$10 environment is an anomaly even if it's well below your budget cap.

Common questions

Is AWS Cost Anomaly Detection free?

Yes. CAD itself is free — no charge for monitors, alert subscriptions, or email/SNS delivery. The underlying data comes from Cost Explorer, which charges $0.01 per API request for programmatic access. Console use is free. For most ECS teams, the total cost is $0.

How long does it take for Cost Anomaly Detection to start working?

CAD needs at least 10 days of historical billing data per monitored dimension before it can model 'normal' spend. After setup, alerts can take up to 24 hours to fire — Cost Explorer (which CAD reads) has a built-in delay of up to 24 hours. A Fargate task that scales out and is killed within 12 hours may never trigger an alert.

Can AWS Cost Anomaly Detection detect ECS Fargate cost spikes?

Yes, with caveats. The default AWS service monitor sees all ECS spend pooled together — a spike in one environment dilutes across others. For per-environment detection, create a tag-based monitor on your 'environment' cost allocation tag. Each tag value gets its own ML baseline and can fire independently.

What is the difference between AWS Cost Anomaly Detection and AWS Budgets?

Budgets use static thresholds: 'alert me when I spend more than $500.' CAD uses ML to detect deviation from your historical pattern — it catches a 200% spike even if you're only at $50 total. Use both: Budgets for hard caps, CAD for pattern deviation. They answer different questions.

How do I get immediate alerts from Cost Anomaly Detection?

Set alerting frequency to 'Individual alerts' — but this requires an SNS topic, not an email address. Attempting to use IMMEDIATE frequency with an email-only subscription triggers a ValidationException. Create an SNS topic, grant costalerts.amazonaws.com permission to publish, then subscribe your email to the SNS topic.

What triggers a cost anomaly alert?

By default: spend 40% above expected AND at least $100 above expected. Both conditions must be met. You can customize both thresholds — for ECS environments with variable usage, combine an absolute threshold ($20–$50) AND a percentage threshold (20–30%) using AND logic to avoid false positives on small environments.

### See what Fortem shows you that CAD doesn't CAD catches sustained billing ano

Worth reading

Use Case · Why Can't You See Per-Environment AWS Costs?Cost Explorer shows you by service, by account, by region. Not by environment. Here's why, and what to do about it.Use Case · How to Control CloudWatch Logs Costs on ECSECS creates log groups with no retention by default. 4 steps to cut CloudWatch costs by 60–80% without touching application code.

See your real per-env cost: fortem.dev/ecs-cost-calculator

Fortem vs Humanitec: ECS Fleet Operations vs General-Purpose IDP

Matt — Fri, 19 Jun 2026 09:53:35 +0000

Humanitec is the most-marketed IDP of 2025. If you run AWS ECS Fargate and searched "humanitec alternative," you've likely seen it at the top of every comparison listicle. But the ECS team evaluating Humanitec is usually solving a different problem than the one Humanitec is built for. This article explains both tools precisely so you can figure out which problem you actually have.

TL;DR

Humanitec is a platform orchestrator built for Kubernetes — the Container Driver (Jan 2025) explicitly states it "can only be used with managed clusters (EKS, AKS or GKE)" — ECS is not a supported workload target
Humanitec Teams is $2,199/mo for 5 users, 2 projects, 5 environments per project — structurally incompatible with a fleet of 20+ ECS environments before you even reach Pro at $5,499/mo
Fortem is purpose-built for ECS Fargate fleet operations: scheduling, cloning, fleet visibility, developer self-service — reads your existing AWS resources, no Terraform rewrite
If your problem is "operate my ECS fleet at scale" → Fortem. If your problem is "build a company-wide IDP across AWS, GCP, and Azure" → Humanitec
Humanitec requires substantial custom work to build the developer interface — right for a 5+ person platform team, not for a 1–2 person ops team on ECS

Run this evaluation before booking any demo

Before talking to either vendor, answer these 5 questions:

What runtimes does your production infrastructure actually run on?
If the answer is "ECS Fargate only" → operational layer. If "ECS + EKS + Lambda + GCP" → platform orchestrator.
How many ECS environments do you have, and are any running 24/7 without a workload?
Count: aws ecs list-clusters | jq '.clusterArns | length'. If >10 environments with idle time → scheduling ROI is immediate.
How many full-time engineers are dedicated to the internal platform (not product features)?
1–2 engineers → operational layer. 5+ dedicated platform engineers → full IDP may make sense.
Are developers filing tickets for environment restarts, clones, or access?
If yes, that's an ops bottleneck — a self-service operations layer solves this faster than building an IDP.
What is your current monthly Fargate compute spend on non-production environments?
Run: aws ce get-cost-and-usage --time-period Start=2026-05-01,End=2026-06-01 --granularity MONTHLY --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Elastic Container Service"]}}' --metrics BlendedCost
If >$1,000/mo → scheduling saves more than Fortem Starter costs.

What Humanitec actually is

Humanitec is a graph-based platform orchestrator that enforces security, cost, and compliance policies on every deployment. It is Kubernetes-architected and cloud-agnostic.

The current homepage headline is "Let AI build. On your terms." — Humanitec has repositioned from "developer self-service platform" to "AI agent governance layer." The product lets platform teams define resource templates (databases, caches, queues) that AI agents and human developers can provision in a standardized, policy-compliant way across multiple cloud providers.

"As of today, the Container Driver can only be used with managed clusters (EKS, AKS or GKE.)"
— Humanitec blog: Introducing the Container Driver (Jan 2025)

AWS ECS and Fargate are not listed. The "serverless-ecs" runner type that appears in Humanitec docs refers to running Humanitec's own build agents on ECS compute — not routing your application workloads to ECS clusters. As of June 2026, humanitec.com/blog has zero posts about deploying to ECS.

Gartner Peer Insights reviewers describe the implementation honestly: Humanitec "requires you to build the developer interface and integrate existing tools. This means platform teams need to do substantial custom work to create the complete developer experience."

Known customers: Western Union, BambooHR, Cimpress — large, multi-cloud organizations with dedicated platform teams. The product is enterprise-sold; it does not have a self-serve signup.

Key insight: Humanitec is genuinely good at what it does — the absence of ECS support is not a flaw, it's a design decision. The question is whether the ECS team evaluating it is solving the same problem Humanitec was built to solve.

What Fortem actually is

Fortem is a control plane for ECS Fargate fleet operations. It reads your existing AWS resources via tags and naming — Terraform stays your source of truth, nothing gets rewritten.

Pricing — what you actually pay

Humanitec Teams at $2,199/mo limits you to 5 users and 5 environments per project. For a fleet of 20+ ECS environments, you're on Pro at $5,499/mo before you've saved anything.

Humanitec pricing was verified June 2026 at humanitec.com/pricing. Both cloud-hosted tiers offer a free trial. An annual discount of 10% applies to both plans. Humanitec also lists a separate AWS Marketplace SKU at $999/mo for up to 15 users.

Humanitec pricing:

Teams: $2,199/mo — 5 users, 2 projects, 5 envs/project
Pro: $5,499/mo — 50 users, 10 projects, unlimited envs
AWS Marketplace: $999/mo (up to 15 users, different terms)

Fortem pricing:

Starter: $790/mo — up to 20 environments, 1 AWS account, unlimited users
Scale: $2,490/mo — up to 80 environments, 3 AWS accounts, SSO, priority support

The ROI math for Fortem is straightforward. Scheduling 10 dev and staging environments (8 services each, 0.5 vCPU / 1 GB per task) to business hours saves $1,013/month in Fargate compute — using published AWS pricing at $0.04048/vCPU-hr. The Starter plan pays for itself before any other feature.

ECS Fargate specifically

Humanitec has no ECS-specific features. Fortem was built exclusively for ECS Fargate — every feature maps to a real ECS operational problem.

Humanitec on ECS:

✗ No ECS workload deployment — Container Driver supports EKS, AKS, GKE only
✗ No environment scheduling for ECS clusters or services
✗ No ECS fleet visibility — no per-environment cost or status dashboard
✗ No environment cloning for ECS task definitions
✗ No ECS-specific diagnostics — no CloudWatch log integration
✗ Zero ECS-specific blog posts or documentation as of June 2026

Fortem on ECS:

✓ Reads ECS services, task definitions, and CloudWatch metrics natively via AWS API
✓ Fleet-wide scheduling: stop/start all environments by timezone on a cron schedule
✓ Per-environment cost tracking using ECS service CPU/memory allocations
✓ Environment cloning: copy a full ECS environment with one API call
✓ Developer self-service: scoped IAM lets engineers restart their own services
✓ AI diagnostics: surfaces unhealthy tasks with CloudWatch context automatically

Worth clarifying: The Humanitec "serverless-ecs" runner type that appears in their docs is not what it sounds like. It refers to running Humanitec's own CI build agents on ECS compute — not routing your application services to ECS clusters. If you found that in a Google search, it is not ECS workload support.

When Humanitec is the right choice

Humanitec is right when you need a company-wide platform across multiple clouds and platforms — not when your problem is operating an ECS fleet.

Humanitec fits when:

You need a formal IDP for 50+ engineers across AWS, GCP, and Azure
You're building a dedicated platform team with a charter to standardize all of engineering
You already use Backstage or Port and want an orchestration layer on top
You're willing to invest 2–6 months in implementation and have 5+ dedicated platform engineers
You need AI agent governance — controlled AI provisioning across heterogeneous platforms
Your compliance requirements need multi-cloud deployment standardization

Humanitec's MVP Program offers structured onboarding with a platform architect. The actual implementation timeline for a working internal developer platform, with real services, resource drivers, and a developer-facing interface, is measured in months.

When Fortem is the right choice

Fortem is right when your infrastructure is primarily AWS ECS Fargate and your problem is operational — managing environments, controlling costs, and enabling self-service without a full IDP build.

Fortem fits when:

Your stack is primarily or entirely AWS ECS Fargate — no multi-cloud requirement
You have 10–80 environments and growing compute spend on idle dev and staging
Your platform team is 1–3 people — not 5+ engineers dedicated to IDP work
You use Terraform and don't want to learn Score or rewrite task definitions
You need results in days, not months — no multi-month implementation project
Developers are filing tickets for environment restarts, clones, or schedule changes

Side-by-side at a glance

Feature	Humanitec	Fortem
Pricing	$2,199/mo (Teams) · $5,499/mo (Pro)	$790/mo (Starter) · $2,490/mo (Scale)
Users included	5 (Teams) · 50 (Pro)	Unlimited on all plans
Environments	5/project (Teams) · Unlimited (Pro)	20 (Starter) · 80 (Scale)
ECS Fargate support	Not a workload target	Purpose-built
Kubernetes support	EKS, AKS, GKE via Container Driver	Not supported
Terraform required	Score replaces task definitions	Reads existing state, no rewrite
Self-service for devs	Build it (custom developer portal)	Included — ECS-scoped RBAC
Environment scheduling	Not available	Fleet-wide, per-timezone
Environment cloning	Not available	Single API call
Onboarding time	Months (IDP build required)	7 business days
Right for	Multi-cloud, 50+ engineers, Kubernetes	ECS Fargate, 1–3 platform engineers

Humanitec pricing: humanitec.com/pricing, verified June 2026. Fortem pricing: fortem.dev/pricing, verified June 2026.

FAQ

Does Fortem replace Humanitec?
No — they solve different problems. Humanitec is a general-purpose platform orchestrator for standardizing deployments across multiple clouds and Kubernetes clusters. Fortem is a control plane specifically for AWS ECS Fargate fleet operations. If your stack is ECS Fargate, Fortem addresses the actual operational problems (scheduling, fleet visibility, self-service) without requiring you to build an IDP.

Does Humanitec support ECS Fargate workload deployment natively?
Not through its primary deployment mechanism. Humanitec's Container Driver explicitly states: "the Container Driver can only be used with managed clusters (EKS, AKS or GKE)." ECS and Fargate are not supported workload targets. The "serverless-ecs" runner type in Humanitec docs refers to running Humanitec's own build agents on ECS infrastructure — not deploying user applications to ECS.

Can I use Fortem and Humanitec together?
In theory, yes — they operate at different layers. If you're running both ECS Fargate and Kubernetes workloads in a hybrid architecture, Humanitec could handle Kubernetes orchestration while Fortem handles ECS fleet operations. In practice, most ECS-first teams don't need both.

What is Humanitec's Score language and do I have to learn it?
Score is Humanitec's workload descriptor — a YAML format that abstracts your service definition away from any specific infrastructure target. To use Humanitec fully, you describe your services in Score rather than in Terraform task definitions or Kubernetes manifests. For ECS-only teams who already have Terraform task definitions, Score is an additional abstraction layer with no payoff.

How long does Fortem onboarding take compared to Humanitec?
Fortem onboarding runs 7 business days: a Fortem engineer audits your AWS setup, imports your environments, configures schedules per timezone, and hands you the keys. Humanitec's MVP Program targets a working MVP after the first session but typically involves multiple months of platform team work to build the developer interface, configure resource drivers, and integrate existing tooling.

Running 10+ ECS environments? Run the free Fleet Audit — see your idle compute spend, scheduling potential, and per-environment costs in one report.

How to Debug AWS Fargate Containers with ECS Exec

Matt — Tue, 16 Jun 2026 08:34:03 +0000

How to Debug AWS Fargate Containers with ECS Exec?

Originally published at https://fortem.dev/blog/ecs-exec-guide
No more SSH into EC2 instances. ECS Exec gives you a shell into Fargate containers. The 5 IAM errors that catch everyone, copy-paste policy, and production audit setup.

Use Case · June 11, 2026 · 7 min read

You moved to Fargate. No more SSH. No more docker exec. Your container is failing and you can't get inside. ECS Exec — AWS's answer to docker exec for Fargate — has been here since 2021. This guide covers setup, the 5 IAM permissions that catch everyone, and the commands that work.

TL;DR

01ECS Exec uses SSM Session Manager — bind-mounts an agent into your container, no sidecar needed
02Requires 3 things: --enable-execute-command on the service, IAM task role with SSM permissions, and the SSM Session Manager plugin on your local CLI
03The #1 failure point is IAM — the task role needs ssmmessages permissions, not just ecs:ExecuteCommand
0420-minute idle timeout, 1 session per container, root user — know the limits before you rely on it in production
05CloudTrail logs every ExecuteCommand call. S3 and CloudWatch can capture command output for compliance

Why ECS Exec exists — the Fargate debugging gap

Fargate has no hosts to SSH into. ECS Exec bind-mounts the SSM agent at runtime, giving you an interactive shell without ports, keys, or changing your task definition. Available since Nov 2021 on both Linux and Windows containers.

ECS on EC2 (before)ECS on Fargate (with ECS Exec)

SSH into EC2 instanceaws ecs execute-command (no SSH needed)

docker exec -it container bash/bin/bash inside container via SSM

Open ports, manage SSH keysNo ports, no keys — IAM controls access

Locate instance in ASG firstDirect to task ID — always routable

Security: instance-level accessSecurity: per-task, per-container IAM

Before ECS Exec (launched March 2021), debugging a Fargate container meant you couldn't get a shell at all — there are no EC2 instances to SSH into. Fargate runs your tasks on AWS-managed infrastructure, which has real implications for operating Fargate at scale. ECS Exec was the #1 most requested feature on the AWS Containers Roadmap for good reason.

KEY INSIGHT: Key insight ECS Exec is not a sidecar container or a separate service. It bind-mounts the SSM agent binaries into your existing container at runtime. Your task definition doesn't change — the ECS agent handles the plumbing transparently.

Download the skill file — check readiness first

Before hitting one of the 5 errors below — a skill file your AI agent can run. It checks IAM permissions, the SSM plugin, networking, and the read-only-filesystem trap, all at once. Everything runs locally against your AWS account.

ECS Exec Readiness Checker Checks whether ECS Exec is enabled and the agent is r

The 5 errors that catch everyone

Every team hits these. The error messages are cryptic but the fixes are specific — missing enable flag, wrong IAM role, missing SSM plugin, no VPC route, or read-only root filesystem. Each has a one-line resolution.

01ExecuteCommandAgent not RUNNING

Cause: You forgot --enable-execute-command when creating or updating the service. ECS Exec must be explicitly turned on per service or per standalone task.

Fix

# Update the service to enable ECS Exec
aws ecs update-service \
    --cluster your-cluster \
    --service your-service \
    --enable-execute-command \
    --force-new-deployment

# Or for a standalone task:
aws ecs run-task \
    --cluster your-cluster \
    --task-definition your-task \
    --enable-execute-command

Verify: aws ecs describe-tasks --cluster your-cluster --tasks task-id — check that enableExecuteCommand is true and ExecuteCommandAgent status is RUNNING

02AccessDeniedException — User is not authorized

Cause: Your task IAM role doesn't have the SSM permissions needed for the agent to open a session.

Fix

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "ssmmessages:CreateControlChannel",
      "ssmmessages:CreateDataChannel",
      "ssmmessages:OpenControlChannel",
      "ssmmessages:OpenDataChannel"
    ],
    "Resource": "*"
  }]
}

Verify: Attach this policy to the task role (NOT the execution role). The SSM agent runs inside the container — it's the task that needs the permissions, not the service launching it.

03TargetNotConnected — Session Manager plugin not found

Cause: The SSM Session Manager plugin is not installed on your local machine.

Fix

# macOS
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac/sessionmanager-bundle.zip" -o "session.zip" && \
unzip session.zip && sudo ./sessionmanager-bundle/install -i /usr/local/sessionmanagerplugin -b /usr/local/bin/session-manager-plugin

# Linux
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm" -o "plugin.rpm" && \
sudo yum install -y plugin.rpm

Verify: session-manager-plugin --version

04Timeout — session never connects

Cause: Your Fargate task has no route to the SSM service endpoint. Either the task is in a private subnet with no NAT gateway, or VPC endpoints for SSM are missing.

Fix

# Option A: Add NAT Gateway to route traffic to internet
# Option B: Create VPC endpoints for SSM (recommended for private subnets)

aws ec2 create-vpc-endpoint \
    --vpc-id vpc-xxx \
    --service-name com.amazonaws.region.ssmmessages \
    --subnet-ids subnet-xxx

Verify: Check task networking: aws ecs describe-tasks — the task must be able to reach ssmmessages.region.amazonaws.com. If you're in a private subnet with no NAT, you MUST have the VPC endpoint.

05Session starts but commands fail — 'cannot create directory'

Cause: Your container's root filesystem is read-only (readonlyRootFilesystem: true). The SSM agent needs to create directories and files inside the container to function.

Fix

# In your task definition, set:
"linuxParameters": {
  "initProcessEnabled": true
}
# And remove or set to false:
"readonlyRootFilesystem": false

Verify: SSM agent writes to /var/lib/amazon/ssm/. If the root FS is read-only, ECS Exec won't work. There's no workaround — the agent needs writable storage.

The happy path — step by step

Step 1 — Install the Session Manager plugin

# macOS
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac/sessionmanager-bundle.zip" -o "session.zip"
unzip session.zip
sudo ./sessionmanager-bundle/install -i /usr/local/sessionmanagerplugin -b /usr/local/bin/session-manager-plugin

# Verify
session-manager-plugin --version

Step 2 — Create the task IAM role

This is the policy the container needs to call SSM. Attach it to your ECS task role (NOT the execution role — that's for pulling images and writing logs).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ssmmessages:CreateControlChannel",
        "ssmmessages:CreateDataChannel",
        "ssmmessages:OpenControlChannel",
        "ssmmessages:OpenDataChannel"
      ],
      "Resource": "*"
    }
  ]
}

Step 3 — Enable ECS Exec on your service

aws ecs update-service \
    --cluster my-cluster \
    --service my-service \
    --enable-execute-command \
    --force-new-deployment

Step 4 — Verify the agent is ready

aws ecs describe-tasks \
    --cluster my-cluster \
    --tasks $(aws ecs list-tasks --cluster my-cluster --service my-service --query 'taskArns[0]' --output text)

# Look for:
# "enableExecuteCommand": true
# "lastStatus": "RUNNING" under ExecuteCommandAgent

Step 5 — Execute

# Interactive shell
aws ecs execute-command \
    --cluster my-cluster \
    --task YOUR_TASK_ID \
    --container nginx \
    --command "/bin/bash" \
    --interactive

# Single command
aws ecs execute-command \
    --cluster my-cluster \
    --task YOUR_TASK_ID \
    --container nginx \
    --command "env | grep DATABASE" \
    --interactive

Production setup — logging, audit, security

Three layers control ECS Exec in production: S3/CloudWatch logging captures every command, CloudTrail audits who ran what, and IAM conditions restrict exec by container name, cluster, and tags — including denying production access entirely.

ECS Exec is powerful — and you need controls around it in production. Three layers: logging (what commands ran), auditing (who ran them), and access control (who CAN run them). If you enable CloudWatch logging, set a retention policy — unbounded CloudWatch log groups accumulate real cost on active clusters.

1.Layer 1 — Log command output to S3 and CloudWatch

Configure at the cluster level. Two destinations: S3 for durable retention, CloudWatch for real-time search. CloudTrail separately logs the ExecuteCommand API call (who and when). Together they give you full visibility: CloudTrail = who executed. S3/CloudWatch = what they ran.

aws ecs update-cluster \
    --cluster my-cluster \
    --configuration executeCommandConfiguration='{
      "logging": "OVERRIDE",
      "logConfiguration": {
        "cloudWatchLogGroupName": "/aws/ecs/my-cluster-exec",
        "s3BucketName": "my-exec-logs",
        "s3KeyPrefix": "exec-output"
      }
    }'

2.Layer 2 — Restrict who can exec

Use IAM condition keys on ecs:ExecuteCommand. This policy allows exec only on tasks tagged environment=development in a specific cluster. Production tasks are blocked — even if someone has the right IAM role.

{
  "Effect": "Allow",
  "Action": "ecs:ExecuteCommand",
  "Resource": [
    "arn:aws:ecs:us-east-1:123456789:cluster/my-cluster",
    "arn:aws:ecs:us-east-1:123456789:task/my-cluster/*"
  ],
  "Condition": {
    "StringEquals": {
      "ecs:ResourceTag/environment": "development"
    }
  }
}

3.Layer 3 — Block production by container name

Add a Deny policy that blocks exec on any container named production-app — regardless of IAM role. This is the safety net. Even if someone tags a task wrong, the container name catches it.

{
  "Effect": "Deny",
  "Action": "ecs:ExecuteCommand",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "ecs:container-name": "production-app"
    }
  }
}

What ECS Exec can't do

Seven hard limits: 20-minute idle timeout, one session per PID namespace, must be enabled at launch, read-only root FS blocks the agent, commands run as root, no AWS Console support, only tools in the image are available.

LimitationWhy

20-minute idle timeoutThe SSM session drops after 20 minutes of inactivity — not configurable. Active commands keep it alive, but a paused shell will disconnect. Plan for reconnection.

1 session per PID namespaceIf you share a PID namespace across containers in a task, you can only exec into one at a time. The second session will fail until the first exits.

Must be enabled at launchYou can't retroactively enable ECS Exec on an already-running task. If you forgot --enable-execute-command, you need to redeploy the task.

Read-only root FS breaks itThe SSM agent writes to /var/lib/amazon/ssm/ inside the container. readonlyRootFilesystem: true makes this impossible. No workaround.

Commands run as rootEven if your container runs as a non-root user, commands executed through ECS Exec run as root. The SSM agent and its children ignore the container's USER directive.

No AWS Console supportECS Exec is CLI/SDK only. You can't click a button in the Console to get a shell. AWS Copilot supports it (copilot svc exec), but the web Console doesn't.

Only tools in the imageIf curl, netstat, or jq aren't in your container image, you can't use them during an exec session. ECS Exec doesn't inject tools — it only gives you access to what's already there.

"ECS Exec sessions drop after 20 minutes of idle time — this timeout is not configurable. Only one session per container PID namespace is supported, and sessions always run as root regardless of the container USER directive."

— AWS ECS Exec documentation, verified June 2026

Map your fleet in 5 min: fortem.dev/audit

How to Control CloudWatch Logs Costs on ECS

Matt — Tue, 16 Jun 2026 08:34:01 +0000

How to Control CloudWatch Logs Costs on ECS?

Originally published at https://fortem.dev/blog/cloudwatch-costs-ecs
ECS sends all logs to CloudWatch with retention set to Never Expire by default. 4 steps to cut your CloudWatch bill by 60-80%: retention, log level filtering, Insights queries, and per-service monitoring.

Use Case

Your AWS bill shows CloudWatch at $400 this month. You have 15 ECS services logging INFO-level to CloudWatch — with retention set to Never Expire. You didn't configure this. ECS did it by default. The fix takes 4 steps.

TL;DR

01ECS default log driver sends everything to CloudWatch with retention = Never Expire — you didn't set this, ECS did
024-step fix: set retention (90% impact), filter by log level (5%), Insights instead of streaming (3%), monitor per-service (2%)
03One Terraform line: retention_in_days = 30 — cuts storage cost by 60-80% immediately
04Real example: 15 services, 3 GB/day → $135/mo (before) → $30/mo (after) — 78% savings
05Download the skill file — your AI agent can audit and fix this for you in 5 minutes

Why CloudWatch is silently eating your AWS bill

ECS creates CloudWatch log groups with no retention policy by default — logs accumulate forever at $0.50/GB ingestion plus $0.03/GB/month storage, with no upper bound. Every container's stdout goes to CloudWatch. Logs accumulate forever and your bill grows every month. You did not configure this.

The part that surprises most teams: ECS creates log groups with no retention policy. No retention = Never Expire = logs accumulate forever = your bill grows every month. We audited a 15-service fleet where CloudWatch was $135/month — more than the compute cost for two of the environments combined. Retention is one lever; right-sizing and scheduling are the rest of the picture.

Cost component15 services, INFO level, 3 GB/day

Ingestion ($0.50/GB)$45/mo

Storage ($0.03/GB/month)$54/mo (grows every month)

Insights queries ($0.50/GB)$36/mo (5 queries/day)

Total$135/mo

KEY INSIGHT: Key insight Three separate charges on the same data. Ingestion is pay-what-you-send. Storage is pay-what-you-keep. Insights is pay-what-you-scan. ECS defaults mean you pay all three — with no upper bound — on every log line your application prints.

Download the skill file — let AI fix it

The downloadable skill file lets your AI agent scan all CloudWatch log groups, identify which ones lack retention, estimate monthly cost per group, and apply fixes — without writing a line of code. Everything runs locally on your machine against your AWS account.

*CloudWatch Cost Optimizer Finds log groups without retention, estimates monthly *

Step 1 — Set retention on every log group

Adding retention_in_days = 30 to every aws_cloudwatch_log_group Terraform resource cuts CloudWatch storage cost by 60–80% immediately — it is the single highest-impact change in this guide. Find every log group without retention and set it to something sensible.

This single change has the biggest impact of any step in this guide. Every log group with Never Expire keeps accumulating data you will never query. The commands below find them and set a sensible ceiling.

Find groups without retention:

aws logs describe-log-groups \
    --query 'logGroups[?retentionInDays==`null`].[logGroupName,storedBytes]' \
    --output table

Set 30-day retention on one group:

aws logs put-retention-policy \
    --log-group-name "/aws/ecs/your-service" \
    --retention-in-days 30

Terraform — the one-liner that saves you $$$:

resource "aws_cloudwatch_log_group" "ecs_service" {
  name              = "/ecs/${var.env_prefix}-${var.service_name}"
  retention_in_days = 30  # ← was null (Never Expire). Now 30 days.
}

EnvironmentRetentionWhy

Production90 daysCompliance + incident investigation

Staging30 daysRecent deploy history

Dev / QA7 daysActive development only

CI/CD / Build1 dayDon't store ephemeral build logs

Step 2 — Filter by log level

Switching ECS production services from INFO to WARN log level reduces ingested log volume by one to two orders of magnitude, cutting both the $0.50/GB ingestion and $0.03/GB storage charges. Switch production to WARN, keep INFO for staging.

“CloudWatch Logs charges $0.50 per GB ingested, $0.03 per GB stored per month, and $0.50 per GB scanned by Logs Insights queries — beyond the 5 GB/month free tier.”

— aws.amazon.com/cloudwatch/pricing, verified June 2026

Spring Boot, Express, Django — they all default to INFO-level logging. That means every HTTP request, every database query, every cache hit generates a log line. Production doesn't need INFO. Switch to WARN.

# Find which log groups ingest the most data (last 7 days)
aws logs start-query \
    --log-group-name "/aws/ecs/prod-api" \
    --start-time $(date -v-7d +%s) \
    --end-time $(date +%s) \
    --query-string "stats count() by @logStream | sort count desc | limit 10"

# Check your framework's log level:
# Spring Boot: logging.level.root=WARN in application.properties
# Express: set LOG_LEVEL=warn
# Django: LOGGING['root']['level'] = 'WARNING'

KEY INSIGHT: Key insight An INFO-level web server can generate one to two orders of magnitude more log volume than the same server at WARN. If you're paying $0.50/GB for ingestion, every unnecessary log line costs you money — twice (once to ingest, once to store).

Step 3 — Use Insights instead of streaming everything

Use CloudWatch Logs Insights to query on demand at $0.50/GB scanned rather than streaming every log line to a third-party tool that charges separately for ingestion and indexing. For compliance, subscription filter to S3.

Datadog's log pricing is two-part: ingestion is billed separately from indexing (making logs searchable). Once you index everything for debugging — which is the point of streaming logs there — the combined cost per GB is several times CloudWatch's ingest ($0.50/GB) + storage ($0.03/GB) total. For debugging, use CloudWatch Logs Insights instead — query on demand, pay per GB scanned ($0.50/GB), not per GB ingested or indexed.

“Datadog charges separately for log ingestion and for indexing logs to make them searchable — to query logs during incident response, they need to be indexed.”

— datadoghq.com/pricing, verified June 2026

# Find errors in the last hour across all services
aws logs start-query \
    --log-group-name "/aws/ecs/prod-api" \
    --start-time $(date -v-1H +%s) \
    --end-time $(date +%s) \
    --query-string "fields @timestamp, @message | filter @message like /ERROR/ | sort @timestamp desc | limit 50"

# For compliance: subscription filter → S3 (cheap, durable)
aws logs put-subscription-filter \
    --log-group-name "/aws/ecs/prod-api" \
    --filter-name "AllToS3" \
    --filter-pattern "" \
    --destination-arn "arn:aws:firehose:..."

Step 4 — Find which service costs the most

One Insights query grouping by log stream and sorting by byte volume identifies which ECS service is responsible for the majority of your CloudWatch bill — run it in under 5 minutes. You don't know which service is responsible until you run it.

Total CloudWatch cost is $400 — but which of your 15 services is responsible for $300 of it? This Insights query tells you in 5 minutes.

# Top log producers by byte volume (last 7 days)
aws logs start-query \
    --log-group-name "/aws/ecs/prod-api" \
    --start-time $(date -v-7d +%s) \
    --end-time $(date +%s) \
    --query-string "stats sum(strlen(@message)) as totalBytes by @logStream | sort totalBytes desc | limit 10"

Once you know which service generates the most logs, go to that service and do three things: (1) check its log level, (2) check if it's logging stack traces on every request, (3) check if it's logging health check pings. Those three fix 90% of high-volume log problems. And when you're done with CloudWatch, the next invisible cost is per-environment attribution.

Find what your fleet is spending: fortem.dev/audit

How Should You Set Up ECS Logging? (awslogs, FireLens, or Neither)

Matt — Tue, 16 Jun 2026 08:33:06 +0000

How to Set Up ECS Logging the Right Way

Originally published at https://fortem.dev/blog/aws-ecs-logging-guide
awslogs, FireLens, and the three decisions every ECS Fargate team gets wrong: blocking mode, Never Expire retention, and log group naming at fleet scale.

Guide

TL;DR

ECS gives you three logging options: awslogs (CloudWatch only), FireLens (any destination, sidecar required), or none.
Default CloudWatch log retention is Never Expire — $0.03/GB/month accumulates silently. Set it to 30 days on every log group.
awslogs is synchronous by default. If CloudWatch is slow, your container blocks. Add mode: non-blocking to every task definition.
Name log groups /ecs/{environment}/{service} — not /ecs/{service}. It's impossible to fix at 30 environments.
Container Insights costs $0.07/metric/month — worth it in prod, skip it for dev environments.

Ready to use — fix Never Expire retention on existing log groups

# Find all log groups with no retention policy and set 30 days
aws logs describe-log-groups \
  --query 'logGroups[?retentionInDays==`null`].[logGroupName]' \
  --output text | \
  xargs -I {} aws logs put-retention-policy \
    --log-group-name {} \
    --retention-in-days 30

Run once, then enforce via Terraform going forward (see aws_cloudwatch_log_group below).

The three ECS logging options (and when each breaks)

ECS supports awslogs (CloudWatch only, 3 params), FireLens (any destination, sidecar required), or none. Most teams start with awslogs and hit its limits somewhere between 5 and 10 services.

The three options are not equally suited to every team. The right driver depends on where you want logs to go, whether you can tolerate blocking on delivery, and whether you run Windows containers. Here's the full comparison:

Driver	Setup	Destination	Backpressure risk	Windows	Extra cost
awslogs	3–4 params	CloudWatch only	Yes (blocking)	Yes	$0 extra
FireLens	Sidecar + config	CloudWatch + any	No (buffered)	No	~$0.005/task/mo
None	Zero	Nowhere	No	Yes	$0 (blind)

The key decisions are: (1) do you need to send logs to anything other than CloudWatch? (2) do you run Windows containers? (3) can you tolerate blocking? If you answered no, no, and no — awslogs with non-blocking mode is the right setup. If any of those answers change, FireLens is the path.

KEY INSIGHT: "None" is not zero-cost. A service with no logging driver is invisible during incidents. At 10+ environments, the time you spend reconstructing what happened from ALB access logs and CloudTrail is more expensive than the CloudWatch bill would have been.

Setting up awslogs: the 4 parameters you actually need

awslogs requires awslogs-group, awslogs-region, awslogs-stream-prefix. Add awslogs-create-group: true or the task silently fails to start if the log group doesn't exist. The task execution role needs logs:CreateLogStream and logs:PutLogEvents.

Missing IAM permissions causes silent log loss — the task starts, ECS shows it as healthy, but nothing appears in CloudWatch. No error in the task events. You find out during an incident. Below is the correct task definition snippet and the Terraform to create the log group with an enforced retention policy.

# Terraform — ECS task definition with correct awslogs config
resource "aws_cloudwatch_log_group" "service" {
  name              = "/ecs/${var.environment}/${var.service_name}"
  retention_in_days = 30

  tags = {
    Environment = var.environment
    Service     = var.service_name
  }
}

resource "aws_ecs_task_definition" "service" {
  # ... other fields ...

  container_definitions = jsonencode([
    {
      name  = var.service_name
      image = var.container_image

      logConfiguration = {
        logDriver = "awslogs"
        options = {
          "awslogs-group"         = aws_cloudwatch_log_group.service.name
          "awslogs-region"        = var.aws_region
          "awslogs-stream-prefix" = "ecs"
          # Non-blocking mode — prevents container blocking on CloudWatch hiccup
          "mode"                  = "non-blocking"
          "max-buffer-size"       = "25m"
        }
      }
    }
  ])
}

Note the log group naming: /ecs/{environment}/{service} — not /ecs/{service}. This matters at scale, covered in the naming section below.

"logs:CreateLogStream and logs:PutLogEvents permission on the IAM role that you launch your container instances with."

— AWS ECS documentation, verified June 2026

The "Never Expire" retention tax

Every log group created by ECS defaults to "Never Expire" retention. At $0.03/GB/month, a 10-service fleet accumulates $500+/month in pure storage costs by month 12 if you never set a policy.

This is the most common silent cost in ECS fleets. New log groups — created by awslogs-create-group: true, the console, or CloudFormation — all default to Never Expire. AWS sets this default because it's the safe option for them: you can never lose data you didn't intend to delete. For your bill, it means every GB ever ingested stays charged until you explicitly delete the group.

The math compounds fast. A fleet of 10 services producing 5 GB/day per service ingests 1,500 GB/month. After 12 months with no retention policy, you're storing ~18,000 GB. At $0.03/GB/month, that's $540/month just for storage — on top of the $750/month ingestion cost.

We covered the full CloudWatch cost breakdown in more detail in how to control CloudWatch costs on ECS — including log-level filtering and Logs Insights query optimization. For most teams, retention alone cuts the bill by 30–40%.

KEY INSIGHT: 30 days covers 95% of incident investigations. 90 days covers compliance requirements for most regulated environments. "Never Expire" covers your AWS bill growing in perpetuity.

The awslogs backpressure problem

awslogs is synchronous by default — if CloudWatch is slow or throttling, your container blocks waiting for the log write. Fix: set mode to non-blocking and max-buffer-size to 25m in logConfiguration.

This is the production gotcha nobody documents until they've seen it. Under normal conditions, CloudWatch responds fast enough that you never notice the synchronous behavior. But when CloudWatch is throttling your account, when a region has degraded performance, or when you're logging at high throughput — your application containers pause waiting for log writes to complete. Requests time out. Health checks fail. ECS replaces the task.

AWS confirmed this in their container logging backpressure blog post: "an application can become blocked using the default awslogs driver." The fix is two lines in your task definition — add mode: non-blocking and max-buffer-size: 25m:

{
  "logConfiguration": {
    "logDriver": "awslogs",
    "options": {
      "awslogs-group": "/ecs/prod/api",
      "awslogs-region": "us-east-1",
      "awslogs-stream-prefix": "ecs",
      "mode": "non-blocking",
      "max-buffer-size": "25m"
    }
  }
}

The trade-off with non-blocking mode: if the buffer fills (25 MB by default), newer logs are dropped rather than blocking the container. This is the correct trade-off for production — a container that drops some logs under extreme pressure is better than one that stops serving requests. If you need guaranteed delivery, FireLens with filesystem buffering is the right answer.

When to switch to FireLens

Switch to FireLens when you need multi-destination routing, log filtering at source, or guaranteed non-blocking delivery. Don't switch if CloudWatch is your only destination — awslogs is simpler and cheaper.

FireLens runs a Fluent Bit sidecar container alongside your application. Your application's stdout goes to the Fluent Bit container (via the awsfirelens log driver), and Fluent Bit routes it to one or more destinations using its configuration file. The sidecar approach adds ~10 MB of memory and a small amount of CPU, but it buys you filesystem buffering — Fluent Bit buffers logs to disk before delivery, so CloudWatch issues never block your application.

Three specific cases where FireLens is the right call:

—Multi-destination routing: you want CloudWatch for compliance + S3 for long-term storage + Datadog for real-time analysis. awslogs sends to CloudWatch only. FireLens sends to all three simultaneously.
—Filter before ingestion: you have DEBUG logs that are useful locally but cost money in CloudWatch. Fluent Bit can drop DEBUG-level records before they're ingested — cutting your CloudWatch bill without changing application code.
—Guaranteed delivery: you're in a regulated environment where dropped logs are a compliance issue. Fluent Bit's filesystem buffer survives CloudWatch throttling and delivery retries automatically.

Two important FireLens constraints: it does not support Windows containers on ECS, and it listens on port 24224 — block inbound traffic on that port in your task's security group or anyone on the same VPC can push logs to your sidecar.

Log group naming at fleet scale

Name log groups /ecs/{environment}/{service} — not /ecs/{service}. Flat naming makes Logs Insights queries unworkable at 10+ environments and makes per-environment retention policies impossible to set.

This is a convention decision that feels unimportant at 3 services and becomes a serious operational problem at 30. With flat naming (/ecs/api, /ecs/worker), you can't query "all prod logs" in a Logs Insights query without listing every group by name. You can't set a shorter retention on dev environments without affecting prod. You can't see cost by environment in the CloudWatch console.

With hierarchical naming (/ecs/prod/api, /ecs/staging/api), Logs Insights can query all prod groups with logGroupNamePrefix /ecs/prod. You can set 7-day retention on all dev groups using describe-log-groups --log-group-name-prefix /ecs/dev. Naming is part of the broader ECS Fargate best practices for fleet-scale operations — the same principle applies to CloudWatch metric namespaces, IAM role names, and ECS cluster names.

# Query all prod logs at once — only works with hierarchical naming
aws logs start-query \
  --log-group-name-prefix "/ecs/prod" \
  --start-time $(date -d '1 hour ago' +%s) \
  --end-time $(date +%s) \
  --query-string 'filter @message like /ERROR/ | stats count(*) by @logStream'

# Set 7-day retention on all dev log groups
aws logs describe-log-groups \
  --log-group-name-prefix "/ecs/dev" \
  --query 'logGroups[].logGroupName' \
  --output text | \
  xargs -I {} aws logs put-retention-policy \
    --log-group-name {} \
    --retention-in-days 7

What ECS logging actually costs

Ingestion costs $0.50/GB. Storage costs $0.03/GB/month. Logs Insights queries cost $0.12/GB scanned. A 10-service fleet producing 5 GB/day per service pays $750/month in ingestion before touching storage or queries.

The full CloudWatch pricing breakdown (verified June 2026):

Line item	Unit	Price	Note
Log ingestion	per GB	$0.50	First 5 GB free/month
Log storage	per GB/month	$0.03	Never Expire = runs forever
Logs Insights queries	per GB scanned	$0.12	Per GB, not per query
Container Insights Enhanced	per metric/month	$0.07	~30–50 metrics per 10 services

Source: AWS CloudWatch pricing, verified June 2026

Running the math on two real scenarios:

Scenario A — 10 services, 5 GB/day each

Monthly log volume1,500 GB

Ingestion cost$750/mo

Storage — no retention (month 12)$540/mo

Storage — 30-day retention$45/mo

Logs Insights (100 GB/day queries)$360/mo

Total without retention fix: $1,650/mo

Total with 30-day retention~$1,155/mo

Scenario B — 5 services, 1 GB/day each

Monthly log volume150 GB

Ingestion cost: $72/mo

Storage — no retention (month 12)~$54/mo

Storage — 30-day retention~$4.50/mo

Total without retention fix: $126/mo

Total with 30-day retention~$77/mo

The ingestion cost ($0.50/GB) is largely unavoidable if you're sending logs to CloudWatch. The storage cost is 100% avoidable with a retention policy. The Insights cost scales with how much data you scan per query — shorter retention windows mean cheaper queries.

"When a new CloudWatch Log Group is created, its data retention policy is automatically set to 'Never Expire.' While this ensures logs are always available, it also results in unnecessary storage costs over time."

— Towards AWS, verified June 2026

If you read this, you might also want to know

What happens to logs already in CloudWatch if I switch from awslogs to FireLens?

Nothing — existing logs stay in CloudWatch. FireLens only affects where new logs go. The switch requires updating the task definition and redeploying (new task revision). Old log streams stay queryable under the same log groups.

Can I send ECS logs to Datadog without FireLens?

Not directly. The awslogs driver sends to CloudWatch only. You can set up a Lambda function to forward CloudWatch logs to Datadog, but FireLens is the cleaner path — send directly from the container to Datadog without going through CloudWatch at all.

How do I query logs across multiple ECS environments in Logs Insights?

Use the log group name prefix filter in Logs Insights — logGroupNamePrefix /ecs/prod queries all groups under that prefix. This only works with hierarchical naming (/ecs/{environment}/{service}). Flat naming requires selecting each group individually.

Should I use structured (JSON) logging or plaintext in ECS?

JSON. CloudWatch Logs Insights can parse and filter JSON fields natively, which reduces the GB scanned per query. Plaintext requires grep-style filters that scan every byte. The switch to JSON in your application doesn't change ECS or CloudWatch config — it's an application-level change.

Common questions

Does ECS automatically create CloudWatch log groups?

Yes, if you set awslogs-create-group to true in the log configuration. Without it, the task fails to start if the log group doesn't exist. Log groups created this way default to Never Expire retention — set an explicit policy immediately.

What IAM permissions does ECS need for CloudWatch logging?

The task execution role needs logs:CreateLogStream and logs:PutLogEvents. Missing these causes silent log loss — the task starts normally but no logs appear in CloudWatch. No error is surfaced in the ECS console.

Can I use FireLens on Windows containers in ECS?

No. FireLens is not supported for Windows containers on ECS. Use the awslogs driver for CloudWatch, or configure a third-party logging agent compatible with Windows containers.

How much does CloudWatch Logs Insights cost?

$0.12 per GB scanned. Querying 100 GB of logs costs $12. Cost scales with data volume scanned, not query count — use time ranges and log group filters to reduce GB scanned per query.

What is the default CloudWatch log retention for ECS?

Never Expire. Every log group ECS creates defaults to Never Expire retention at $0.03/GB/month. A 10-service fleet accumulates over $500/month in storage alone by month 12. Set a 30-day retention policy on every log group.

### Blind spots in your ECS fleet cost money. Book 20 minutes — we'll show you w

Map your fleet in 5 min: fortem.dev/audit

ECS Service Discovery: Cloud Map, Service Connect, or an Internal Load Balancer?

Matt — Mon, 15 Jun 2026 11:40:38 +0000

ECS Service Discovery: Cloud Map vs Service Connect

Originally published at https://fortem.dev/blog/ecs-service-discovery-guide
Cloud Map, Service Connect, or an internal ALB? A practical decision framework for ECS Fargate teams — with the July 2025 blue/green unblock, real cost math, and Terraform snippet.

Guide

TL;DR

AWS docs say "We recommend Service Connect" for new ECS-to-ECS traffic — built-in retries, metrics, and mTLS without extra config.
Blue/green + Service Connect shipped July 17, 2025. The main reason teams stayed on Cloud Map is gone.
Cloud Map service discovery still wins for non-ECS callers (Lambda, EC2, on-prem) and services with 1,000+ tasks per service.
An internal ALB wins when you need L7 routing rules or a stable endpoint callable by anything outside ECS.
Services not enrolled in Service Connect cannot resolve its short names — namespace membership is required on both sides.

Your first ECS service called its dependency by ALB DNS name. That worked fine. Now you have 15 services, some team is asking about mTLS, someone noticed the console keeps surfacing "Service Connect," and a cross-account architecture is on the roadmap. Here's what the three options actually do, where each breaks, and the rule for choosing.

What service discovery actually solves

Service discovery maps a logical name to healthy task IPs as tasks start, stop, and reschedule — without you touching DNS entries or hardcoding addresses.

ECS tasks on Fargate get ephemeral private IPs. The IP changes every time a task restarts or a new version deploys. If service A hardcodes the IP of service B, you get connection failures on every B deployment. An ALB solves this — the ALB DNS name stays stable — but you're paying ~$16–22/month per ALB and adding a network hop for every service-to-service call.

Service discovery handles three things automatically: registration (ECS adds a new task to the registry on launch), discovery (your app resolves a name to the current set of healthy IPs), and deregistration (ECS removes a task on shutdown). Your app just calls http://payments or http://payments.internal.example.com and gets a healthy endpoint back.

What it is not: a load balancer, an API gateway, or a circuit breaker. It finds services. Retry logic, traffic shaping, and rate limiting are separate concerns — though Service Connect handles the first two.

Option 1 — ECS Service Connect

Service Connect is AWS's recommended approach for ECS-to-ECS traffic. ECS injects an Envoy sidecar per task that handles routing, retries, metrics, and optional mTLS — your app just calls a short name.

"We recommend Service Connect, which provides Amazon ECS configuration for service discovery, connectivity, and traffic monitoring."

— AWS ECS networking best practices, verified June 2026

How it works. When you enable Service Connect on an ECS service, ECS automatically runs an Envoy proxy container inside each task. Services call each other by short name — http://payments instead of payments.internal.example.com. The proxy handles load balancing, retries on transient failures, and outlier detection.

DNS mechanism. Service Connect does not write to VPC DNS or Route 53. It manages its own namespace. Short names are only resolvable from inside tasks enrolled in the same namespace. A Lambda function, EC2 instance, or ECS service not in the namespace cannot resolve those names — they get a connection timeout instead of a useful error.

Cost. Service Connect itself is free. The Cloud Map backend usage is free when used via Service Connect. You pay for the Envoy sidecar's compute: AWS recommends 0.1 vCPU and 128 MB per task, which runs ~$0.31/month per task at On-Demand Fargate rates. For a 20-service fleet with 3 tasks per service, that's ~$18/month of sidecar overhead.

Blue/green deployments. As of July 17, 2025, ECS Native Blue/Green supports Service Connect. Test traffic routes to the green revision via the x-amzn-ecs-blue-green-test header. The previous blocker — CodeDeploy blue/green was incompatible with Service Connect — no longer applies if you migrate to ECS Native Blue/Green.

mTLS. Native support via AWS Private CA. Service Connect rotates TLS certificates every 5 days — roughly 6 certificates per service per month. Factor in Private CA cost if you enable this.

Known limitation

If you create some services, wait more than 5 hours, then add more services to the same cluster, the original services may not resolve the new ones via DNS until you redeploy them. This is a known proxy registration timing issue — not a showstopper, but something to handle in your deployment runbook.

Option 2 — Cloud Map service discovery

Cloud Map service discovery registers ECS tasks as Route 53 DNS A-records. Any VPC resource — Lambda, EC2, on-prem via Direct Connect — can resolve those names. No proxy overhead, no namespace enrollment requirement.

How it works. ECS registers each task's private IP with a Cloud Map service on launch and deregisters it on shutdown. Route 53 returns the current set of healthy task IPs for a DNS query like payments.internal.example.com. Your app connects directly to the task IP — no proxy in the path. If the DNS TTL is set high, your app may hold a stale IP for a few seconds after a task stops.

Cost. Cloud Map charges $0.10 per registered resource per month, plus $1.00 per million HTTP API calls for non-DNS lookups. Route 53 adds $0.50/month per private hosted zone and $0.40/million DNS queries. For a fleet with 20 services × 3 tasks, that's ~$6/month in Cloud Map registry fees plus minimal Route 53 query costs. Compare to Service Connect's ~$18/month sidecar overhead for the same fleet — Cloud Map is cheaper at moderate scale.

1,000-task limit. AWS docs state: "Services configured to use service discovery have a limit of 1,000 tasks per service. This is due to a Route 53 service quota." If you run high-scale services — a job runner, a stateless API serving burst traffic — Cloud Map service discovery hits this ceiling. Service Connect does not have this limit.

Manual cleanup. AWS docs: "The AWS Cloud Map resources created when service discovery is used must be cleaned up manually." Delete an ECS service and its Cloud Map registration stays. Over time, stale records accumulate — you pay $0.10/month per orphaned registration. Add a cleanup step to your service teardown runbook.

DNS propagation. There is a window between when a task stops and when Route 53 TTL expires. If your DNS TTL is 30 seconds and you scale down rapidly, callers may get dropped connections. AWS's own migration blog documents dropped requests under load during fast scale-in. Set TTL to 10 seconds or less for services with frequent task churn, and implement retry logic in your clients.

When to choose Cloud Map: you have non-ECS callers; your services run more than 1,000 tasks; you need cross-account without setting up AWS RAM; or your existing Cloud Map setup already works and you don't need mTLS or built-in retries.

On ECS multi-environment strategy and mixed-compute architectures, Cloud Map is the only option that gives all layers of the stack a single naming layer.

Option 3 — Internal ALB

An internal Application Load Balancer gives any compute — Lambda, EC2, ECS, on-prem — a stable HTTP endpoint for an ECS service. It costs $16–22/month per ALB plus LCU charges, regardless of traffic.

The ALB handles health checks and connection draining automatically. When an ECS task stops, the ALB deregisters it before terminating — no dropped connections. You get L7 routing rules: path-based routing to send /api/users/* and /api/orders/* to different ECS services behind a single ALB.

When an internal ALB is the right answer: a Lambda function calls an ECS API and needs a stable HTTPS endpoint; you want path-based routing between services; or you need WebSocket support with sticky sessions across multiple ECS tasks.

The cost adds up fast. At ~$22/month per ALB, 10 internal ALBs (one per service) cost $220/month before any traffic. Sharing one ALB across services with path routing brings this to $22/month — but then you're managing routing rules as a shared resource.

Decision table

Use Service Connect for pure ECS-to-ECS traffic in a single Region. Use Cloud Map when non-ECS services are involved. Use an internal ALB when you need L7 routing or a stable endpoint callable by anything.

Scenario	Service Connect	Cloud Map	Internal ALB
ECS → ECS, same cluster	✓ Recommended	Works	Works (extra cost)
ECS → ECS, cross-cluster	✓ (shared namespace)	✓	Works
Lambda → ECS	✗ (can't resolve names)	✓	✓
EC2 → ECS	✗ (not enrolled)	✓	✓
Cross-account (with RAM)	✓	✓	Works
Service with 1,000+ tasks	✓ (no task limit)	✗ (Route 53 quota)	✓
mTLS required	✓ (native, via Private CA)	Manual	Manual
Blue/green deployments	✓ (as of July 2025)	✓	✓

KEY INSIGHT: If you're starting a new ECS service today and all its callers are also ECS services, choose Service Connect. If you have an existing Cloud Map setup that works and you don't need mTLS or built-in retries, leave it alone — the migration cost isn't worth it until you have a concrete reason to switch.

Migrating from Cloud Map to Service Connect

AWS publishes a migration guide. The short version: add service_connect_configuration to your ECS service, redeploy, then remove the service_registries block. One deploy cycle per service.

The catch: Service Connect and Cloud Map service discovery are not cross-compatible at the namespace level. A caller on Cloud Map cannot resolve Service Connect short names, and vice versa. Migrate the callee first, then migrate callers in the same deployment window — or keep the Cloud Map registration running in parallel during the cutover.

Here is the Terraform diff for a single service:

Ready to use — Terraform service_connect_configuration

resource "aws_ecs_service" "payments" {
  name            = "payments"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.payments.arn
  desired_count   = 2

  # Remove this block when migrating to Service Connect:
  # service_registries {
  #   registry_arn = aws_service_discovery_service.payments.arn
  # }

  service_connect_configuration {
    enabled   = true
    namespace = aws_service_discovery_private_dns_namespace.main.arn

    service {
      port_name      = "http"  # must match portName in task definition
      discovery_name = "payments"

      client_alias {
        dns_name = "payments"
        port     = 8080
      }
    }
  }
}

# Task definition: add portName to the port mapping
# "portMappings": [
#   {
#     "name": "http",
#     "containerPort": 8080,
#     "protocol": "tcp"
#   }
# ]

What changes after the deploy: each task gets an Envoy sidecar container. The service is reachable at http://payments:8080 from any other Service Connect service in the same namespace. Your VPC, subnets, security groups, and task definition don't change.

One thing to watch: App Mesh reaches end-of-life on September 30, 2026. If you're still on App Mesh for ECS workloads, Service Connect is the replacement. (For EKS, AWS recommends VPC Lattice instead.)

If you read this, you might also want to know

How does Service Connect compare to AWS App Mesh?

App Mesh was the predecessor service mesh for ECS and EKS — it reaches end-of-life September 30, 2026. Service Connect is the ECS replacement: simpler to configure (no separate mesh/virtual service objects), fully managed Envoy injection, and integrated with ECS deployments. If you're on App Mesh, migrate to Service Connect for ECS workloads or VPC Lattice for EKS.

Can I run Service Connect and Cloud Map service discovery on the same ECS service?

No. A single ECS service can use either service_registries (Cloud Map) or service_connect_configuration (Service Connect), not both. During migration, you can run parallel ECS services — one on Cloud Map, one on Service Connect — but a single service object chooses one path.

What happens to Service Connect traffic when a task crashes mid-request?

The Envoy proxy in the calling task detects the failed connection and retries on a different task instance using the configured retry policy. Outlier detection marks unhealthy tasks and stops routing to them until they recover. This is the main reliability advantage over Cloud Map, where retry logic lives entirely in your application code.

Common questions

Does Service Connect work with blue/green deployments?

Yes, as of July 17, 2025. AWS shipped built-in blue/green deployments for ECS — including Service Connect. Test traffic routing uses the x-amzn-ecs-blue-green-test header. The previous blocker (CodeDeploy blue/green was incompatible with Service Connect) no longer applies with ECS Native Blue/Green.

Can I use ECS Service Connect across AWS accounts?

Yes, with AWS Resource Access Manager (RAM). Share the Cloud Map namespace across accounts and configure Service Connect in each account's ECS cluster to use the shared namespace. Without RAM, Cloud Map service discovery is simpler for cross-account: it uses Route 53 / VPC DNS, which you extend with VPC peering or Transit Gateway.

How much does the Service Connect Envoy sidecar cost on Fargate?

Service Connect itself is free — no charge for the feature or the Cloud Map backend. You pay only for the Envoy proxy sidecar container's CPU and memory. AWS recommends 0.1 vCPU and 128 MB per task. At Fargate On-Demand rates ($0.04048/vCPU-hr, $0.004445/GB-hr), that's roughly $0.31/month per task running 24/7.

Why can't my service resolve Service Connect names?

Service Connect manages its own namespace — it does NOT update VPC DNS. A service not enrolled in the same Service Connect namespace cannot resolve those short names. Fix: enroll the calling service in the same namespace, or switch the caller to Cloud Map service discovery (which uses Route 53 / VPC DNS and is accessible to any VPC resource).

What's the difference between Cloud Map and ECS service discovery?

They're the same thing. 'ECS service discovery' is the ECS feature that registers tasks into AWS Cloud Map namespaces using Route 53 DNS. Cloud Map is the underlying registry. Service Connect is a newer, higher-level abstraction built on top of Cloud Map — it adds an Envoy proxy per task for retries, metrics, and mTLS, without requiring your app to change its DNS lookup code.

### Service discovery is solved. Operating 20 services across 10 environments is

Map your fleet in 5 min: fortem.dev/audit

ArgoCD Alternatives in 2026: 5 Real Options (and One Nobody Mentions)

Matt — Sun, 14 Jun 2026 09:11:11 +0000

ArgoCD Alternatives in 2026: 5 Real Options (and One Nobody Mentions)

Originally published at https://fortem.dev/blog/argocd-alternative
An honest comparison of ArgoCD alternatives: Flux, Fleet, Harness, Spinnaker, plain CI — and the option comparison posts skip: not needing GitOps at all.

Guide

Most “ArgoCD alternatives” posts are written by people who have never debugged a stuck sync wave at 2 a.m. This one isn't.

Teams leave ArgoCD for specific reasons: App-of-Apps complexity that grows faster than the fleet it manages, multi-cluster RBAC that fights you, drift detection that cries wolf, a UI that becomes the bottleneck instead of the helper. If one of those is your reason, the right alternative depends on which one. Here are the five real options — and a sixth that comparison posts never include, because it questions the premise.

TL;DR

Flux CD: best direct replacement — lighter, composable, CNCF-graduated, active post-Weaveworks.
Rancher Fleet: best for managing dozens or hundreds of clusters — overkill below that.
Harness CD / managed: best when operating ArgoCD costs more than buying the service.
Spinnaker: enterprise pipelines, multi-cloud, canary analysis — serious operational overhead.
Plain CI + helm upgrade: underrated for small fleets where GitOps reconciliation is unnecessary.
ECS Fargate: if the pain is Kubernetes itself, the problem category disappears on ECS.

Ready to use — decision checklist

Before picking an alternative, answer these five questions:

1.Is the pain in ArgoCD itself (sync, RBAC, UI) — or in Kubernetes operations (nodes, upgrades, cost)?
2.How many clusters do you manage — fewer than 5, or dozens+?
3.Does your team have time to assemble and maintain CD tooling, or do you need to buy that back?
4.Do you need multi-cloud, approval gates, or canary analysis as first-class features?
5.Are your workloads stateless services on AWS — or do they depend on K8s operators and CRDs?

Map your answers to the summary table at the bottom of this article.

1. Flux CD — GitOps primitives without the platform

Flux is the closest direct ArgoCD replacement — CNCF-graduated, lighter on cluster resources, and composable instead of opinionated.

Flux is the other CNCF-graduated GitOps project, and the closest thing to a direct ArgoCD replacement. Where ArgoCD ships an opinionated platform — UI, SSO, RBAC, ApplicationSets — Flux ships composable controllers (source, kustomize, helm, notification) that you assemble into the workflow you actually want. Reconciliation logic is comparable; the philosophy is not.

Pick it if

ArgoCD's resource weight and platform opinions are your problem. Flux controllers are lighter on cluster resources, the Kustomize/Helm integration feels native rather than bolted on, and there is no central UI server to scale, secure, and babysit.

Skip it if

Your developers live in the ArgoCD UI and you have no appetite to rebuild that experience.

KEY INSIGHT: The “Flux has no UI” objection is outdated. As of 2025–2026, the Flux Operator ships a Web UI with cluster dashboards and deep-dive views into Kustomizations and HelmReleases. The gap with ArgoCD's UI has narrowed substantially.

The “is Flux dead?” question is also settled. After Weaveworks shut down in 2024, core maintainers moved to ControlPlane, which employs them to work on the project. Flux is CNCF-graduated with a public roadmap and steady releases. If you ruled it out in 2024 over maintenance fears, re-evaluate. Flux 2.8 (GA February 2026) added native Helm v4 support with server-side apply — Helm-heavy shops should pay attention.

The trade-off you accept: more assembly required. Multi-tenancy, dashboards-as-default, and the app-centric mental model that ArgoCD gives you out of the box are things you compose yourself with Flux.

2. Rancher Fleet — when the problem is cluster count, not GitOps

Designed for managing configuration across very large cluster counts — dozens to hundreds. At 1–5 clusters, you're paying Fleet's complexity for a problem you don't have.

Fleet is SUSE/Rancher's GitOps engine, designed from the start for managing configuration across very large numbers of clusters — its docs talk about scaling to up to a million. It uses a hub-and-spoke model where a single management plane drives bundles of resources out to downstream clusters.

Pick it if

Your actual pain is ArgoCD's multi-cluster story — you're juggling dozens or hundreds of clusters (edge, retail, per-customer) and ApplicationSets plus cluster secrets are creaking. Fleet treats fleet-scale as the primary use case, not an extension.

Skip it if

You run one to five clusters. At that scale Fleet solves a problem you don't have, and you pay its complexity anyway.

The trade-off you accept: a smaller ecosystem and community than either ArgoCD or Flux, and noticeable gravity toward the Rancher stack. Outside Rancher-managed environments you lose part of the value, and hiring engineers with Fleet experience is harder.

3. Harness CD / managed pipelines — make it someone else's pager

Stop self-hosting CD entirely. Harness and similar platforms take upgrades, scaling, and RBAC wiring off your team — for a real cost, in both dollars and vendor coupling.

The third answer to “ArgoCD alternative” is: stop self-hosting CD entirely. Harness CD offers a GitOps-as-a-service mode that actually runs ArgoCD under the hood, managed for you. Similar commercial platforms take the operational burden — upgrades, scaling, RBAC and SSO wiring, audit — off your team. Codefresh, long the other big name in managed GitOps, was acquired by Octopus Deploy in 2024; factor vendor trajectory into any evaluation there.

Pick it if

The problem was never ArgoCD's design. The problem is that operating ArgoCD became a part-time job nobody wanted: certificate rotations, controller scaling, upgrade regressions, SSO breakage. If your platform team is two people and CD tooling eats one of them, buying it back is rational.

Skip it if

The reason you chose GitOps was control and auditability of every change through Git. Managed platforms blur that line by design.

The trade-off you accept: real money (these platforms price for enterprises), vendor coupling, and a less Git-purist workflow — pipelines and UI-driven configuration creep back in. Budget time for the procurement and security review cycle too.

4. Spinnaker — the heavyweight, for a narrow profile

A deployment orchestrator built around pipelines and canary analysis — not GitOps in the reconciliation sense. Correct for enterprise multi-cloud; easy to regret adopting casually.

Spinnaker predates the GitOps wave: it is a deployment orchestrator built around pipelines, multi-cloud targets, and sophisticated deployment strategies — automated canary analysis, staged rollouts, manual judgments. It is not GitOps in the reconciliation sense at all, which for some teams is exactly the point.

Pick it if

You're an enterprise with hard requirements for multi-cloud deployment pipelines, approval gates, and canary analysis as first-class citizens — and you have a platform team that can own a complex distributed system, because Spinnaker is one (a dozen-odd microservices to run and upgrade).

Skip it if

You're anything smaller than a platform organization. This is the easiest tool on this list to regret adopting casually.

The trade-off you accept: Spinnaker is famously heavy to operate, and community momentum has visibly shifted toward GitOps-native tools over the last several years. Choosing it in 2026 means choosing against the current, which is fine if your requirements genuinely demand it.

5. Plain CI + `helm upgrade` — the option listicles are embarrassed by

Delete the CD layer and let CI run helm upgrade --installdirectly. Underrated for small fleets where GitOps reconciliation solves a problem you don't have.

Here is the alternative most posts omit, because there is nothing to affiliate-link: delete the CD layer and let your CI pipeline run helm upgrade --install or kubectl apply directly. Push-based deploys, straight from the pipeline that built the artifact.

Pick it if

You run a small fleet — a handful of services, a few environments — and you adopted ArgoCD because a conference talk said you should. GitOps reconciliation earns its complexity when many actors mutate cluster state and drift is a real threat. If deploys are the only thing that changes your clusters, a reconciliation loop is machinery without a purpose.

Skip it if

Multiple teams or operators touch the clusters, or compliance requires a continuously enforced desired state.

The trade-off you accept: no drift detection, no self-healing, no declarative picture of “what should be running right now” outside your pipeline history. Cluster credentials live in CI, which widens your blast radius if the pipeline is compromised. You also give up the rollback ergonomics ArgoCD's history view provides.

Alternative #6: not needing GitOps at all

If you're on AWS and your workloads are mostly stateless services, there's a version of your stack where the problem category that ArgoCD solves disappears entirely.

ArgoCD exists to solve a Kubernetes-shaped problem: continuously reconciling a cluster's live state against Git. If you are on AWS and your workloads are mostly stateless services, there is a version of your stack where that entire problem category disappears.

On ECS Fargate, a deploy is your CI pipeline updating a task definition. There is no cluster state to reconcile, no sync waves, no drift — because there is no node-level state to drift. You do not replace ArgoCD; you stop needing the thing ArgoCD does.

This is not the right move if your team runs Kubernetes well, or if you depend on operators and CRDs. It is worth a hard look if the pain is not ArgoCD — it is operating Kubernetes itself, on a small platform team, on AWS. We wrote up the full comparison: ECS vs EKS — the cost and ops breakdown.

Disclosure: this is the part where we are biased. Fortem is a control plane for teams running 10+ ECS Fargate environments — scheduling, cloning, fleet-wide visibility. If you do land on ECS, that is the tooling gap you will eventually hit.

Which one, then?

Match the tool to the pain: Flux for platform weight, Fleet for cluster count, managed for ops burden, Spinnaker for enterprise pipelines, plain CI for small fleets, ECS if the pain is Kubernetes itself.

Your actual pain	Best option
ArgoCD's platform weight; you want primitives, not opinions	Flux CD
GitOps across dozens or hundreds of clusters	Rancher Fleet
Operating CD tooling eats your platform team	Harness CD / managed GitOps
Enterprise pipelines, canary analysis, approval gates, multi-cloud	Spinnaker
Small fleet; GitOps reconciliation is solving a problem you don't have	Plain CI + helm upgrade
The pain is Kubernetes itself, and you're on AWS	ECS Fargate

One closing heuristic: before replacing ArgoCD, write down the three incidents or frustrations that triggered the search. If all three mention ArgoCD specifically — sync behavior, UI, RBAC — pick from rows one through five. If they mention nodes, upgrades, or “why is our EKS bill like this,” your problem is one layer down, and no GitOps tool will fix it.