Day 3 - Fargate Cost Anatomy — Serverless Container's Real Price Tag

"Fargate is expensive" is half-true. Looking at the price list alone, it is roughly 2× more expensive per vCPU than EC2, but that omits node ops, idle resources, and bin-packing inefficiency. Compare an EC2 cluster averaging 30% node utilization to a Fargate Task running ~100% loaded—results flip. SAP exams drill this precise breakpoint with one to two questions per domain. "Variable traffic, 24/7 ops," "Peak 10× baseline," "GPU inference"—answers branch among EC2, Fargate, Lambda.

This article dissects Fargate's billing structure per second, showing why vCPU-memory combinations form peculiar matrices. Then we examine three discount levers—Fargate Spot, Compute Savings Plans, Graviton ARM—combined to halve per-unit cost. Finally, image pull cold-start, SOCI lazy loading, Lambda/EC2 breakpoints. Before the next service mesh topic, we aim to build intuition for "when Fargate doesn't fit."

Fargate Billing's Fine Structure — Per-Second + 1-Minute Floor

Fargate bills vCPU-hours and memory-hours separately. Roughly, us-east-1 rates are vCPU $0.04048/h, memory $0.004445/GB-h. Billing granulates per-second but with a 1-minute floor applied. Even 30-second Task completion gets billed as 1 minute.

First cost trap: image pull time is included in billing. Fargate lacks node cache, so every Task downloads images from ECR fresh. Large images take 30-60 seconds. Task time during traffic receipt blockage burns vCPU/memory costs. Short jobs (batch 30s) with large images (2GB) see pull cost exceed job cost.

[Task startup]
  │ (1) Micro-VM boot ~3s            ← Billing begins
  │ (2) ECR image pull 30-60s         ← Cost flows
  │ (3) Container runs + job processes ← Real work
  │ (4) Graceful shutdown            ← Billing ends
[Task termination]

💡 Related Theory: Cloud container service billing exemplifies fine-grained billing. EC2 hourly, Lambda millisecond, Fargate second-granular (1-minute floor). This difference is decisive per workload shape. Lambda's 1ms granularity dominates short, frequent calls (100ms per request); EC2 hourly favors long, steady load (24/7). Fargate optimizes "minute-to-hour scale, appearing then vanishing" workloads. Billing model evolution appears in AWS' "Serverless Architectures with AWS Lambda" whitepaper and NSDI 2020 Firecracker paper.

vCPU·Memory Combination's Strange Matrix

Fargate Task Definition's vCPU-memory assignment is confusing because arbitrary values fail; only preset matrices work.

This matrix exists because Fargate internally runs on EC2 instance families. AWS exposes the vCPU-memory ratios (1:2, 1:4, 1:8) directly. 8 vCPU / 64GB (1:8) memory-heavy combinations work, but 0.25 vCPU / 32GB unrealistic pairing is rejected.

Unaware users attempting "32GB memory + 0.5 vCPU" get registration failure. Need more memory? Must increase vCPU proportionally, raising costs. One reason Fargate costs more than EC2 for some workloads: forcing vCPU purchase alongside memory needs. Memory-intensive workloads (in-memory cache, JVM heap) pay for unwanted vCPU.

🔍 Deeper Dive: Matrix workaround pattern: multi-container Task. Single Task with main container (0.25 vCPU, 0.5GB) + sidecar (0.25 vCPU, 1.5GB) totals 0.5 vCPU·2GB overall, using memoryReservation in container specs to concentrate memory. Works only well on EC2 Launch Type; Fargate stricter isolation limits effectiveness. SAP exams don't ask this deeply, but real-world sees it often.

Fargate Spot — The ~70% Discount Cost

Fargate Spot discounts ~70% off standard Fargate. Tradeoff: AWS reserves reclamation rights, signaling with 2-minute SIGTERM before killing. Within 2 minutes, graceful shutdown (finish in-flight requests, requeue messages, flush cache) must complete.

[Spot Task runs normally]
   │
[AWS detects capacity shortage → reclamation decision]
   │
[Task receives SIGTERM]  ← 2-minute countdown starts
   │
[Application graceful shutdown:
  - Deregister from ALB Target Group
  - Complete in-flight responses
  - Reset SQS message visibility timeout]
   │
[2 minutes elapsed → SIGKILL]
[Task forcefully terminated]

Fargate Spot fits:

• Stateless back-office APIs: Short requests, instant replacement available
• Batch jobs: Restartable workers
• Dev/staging: Cost over availability priority

Poor fit:

• Long transactions (reclamation rollback costs)
• Stateful (in-memory sessions, WebSocket long connections)
• Real-time (no SIGTERM response time)

ECS Service Capacity Provider mixes with weight and base. Example: base=2, FARGATE weight=1, FARGATE_SPOT weight=4 → first 2 Tasks always On-Demand, then 20:80 ratio.

aws ecs put-cluster-capacity-providers \
  --cluster prod \
  --capacity-providers FARGATE FARGATE_SPOT \
  --default-capacity-provider-strategy \
    'capacityProvider=FARGATE,weight=1,base=2' \
    'capacityProvider=FARGATE_SPOT,weight=4'

💡 Related Theory: Spot instances' principle is price discovery via auction. AWS datacenters always have some idle capacity buffer; selling at list price finds insufficient demand. Instead, selling at market price (spot price) with reclamation rights when on-demand demand spikes. Reclamation notice duration (2-minute SIGTERM) is calibrated as minimum for graceful shutdown. EC2 Spot averages <5% reclamation, but Fargate Spot's smaller pool may see higher rates (official figures private).

📚 Case Study: 2023, Pinterest migrated some backend workloads to ECS Fargate + 80% Fargate Spot, cutting container infrastructure costs ~40%. They standardized 120-second STOPTIMEOUT, SIGTERM handlers for graceful HTTP request draining, and SQS message visibility timeout reset patterns. re:Invent 2023 CON401.

Compute Savings Plans — Commitments Discounted for Fargate Too

Savings Plans (SP) offer discounts when users commit "I'll buy N dollars worth of compute hourly for 1 or 3 years." Two types; Fargate uses Compute Savings Plans.

Compute SP's power is flexibility. Buy $10/h compute on 1-year commitment; apply it to ECS Fargate, EC2, Lambda interchangeably. During EC2-to-Fargate migration, commitment survives, preventing cost spikes.

[Compute SP $10/h commitment]
       │
       ├─ EC2 m5.xlarge × 2 $0.38/h → Auto-applies SP
       ├─ Fargate Task 5 × $4.20/h → Auto-applies SP
       └─ Lambda invocation $5.42/h → Auto-applies SP
                                      Total within commitment

Spot and Compute SP are distinct discount mechanisms, so Fargate Spot doesn't stack SP on top (Spot discount alone applies). On-Demand portions receive SP. So Capacity Provider mixing (base=2 On-Demand + Spot 80%) yields dual discount pattern: On-Demand gets SP discount, Spot gets Spot discount.

🔍 Deeper Dive: Reserved Instances (RI) predate SP, with separate programs per EC2/RDS/ElastiCache. RI fixes instance type and includes capacity reservation; SP skips capacity reservation, providing billing discounts only. AWS' 2019 SP announcement effectively signaled "RI no longer recommended," making SP standard for new workloads. SAP exams: "flexibility, multi-service" → Compute SP; "EC2 fixed, max discount" → EC2 Instance SP; "storage/DB capacity assurance required" → RI.

Graviton (ARM64) — Same Workload, 20% Cheaper

Fargate supports x86_64 and ARM64 (Graviton2-based). ARM64 costs ~20% less for identical performance. Change Task Definition's runtimePlatform.cpuArchitecture to ARM64—that's it.

{
  "family": "myapp",
  "runtimePlatform": {
    "cpuArchitecture": "ARM64",
    "operatingSystemFamily": "LINUX"
  },
  "cpu": "1024",
  "memory": "2048",
  ...
}

Prerequisite: container images must be multi-architecture built. Use docker buildx to push both amd64 and arm64; Fargate auto-selects the right image. Some native binaries (C/C++) or ML libraries lack ARM64 support yet, requiring pre-migration dependency checks.

docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t myrepo/myapp:1 --push .

📚 Case Study: 2022, Snap migrated some backend microservices to Graviton2 Fargate, achieving ~22% cost savings. Biggest work: securing ARM64 builds of dependent libraries (especially JNI-bound Java libraries, native node-gyp modules). AWS re:Invent 2022 CMP301 presentation. Core lesson: 80% of Graviton savings comes from infra change, 20% from dependency cleanup.

💡 Related Theory: ARM64's cheaper per-unit cost stems from two factors. First, AWS designs the chip, avoiding Intel/AMD royalties. Second, ARM (RISC) architecture packs more cores per transistor (Graviton3 = 64-core/socket). Same datacenter space and power yield more compute—the cost difference's essence. This trend parallels Apple Silicon (M1-M3), likely making ARM the cloud's default.

Three Discount Levers Combined

Fargate Spot (70%) + Compute SP (66%) + Graviton (20%) are orthogonal discounts; combining yields large cumulative effect, though multiplicatively coupled rather than purely additive.

Scenario: Back-office API, 1-year operation, average 5 Tasks × 1 vCPU × 2GB memory

Interesting: Spot and SP are mutually complementary. Spot carries reclamation risk; SP carries commitment burden. Mixed, stable portion (SP + On-Demand) and variable portion (Spot) naturally separate.

🎯 Scenario: "A SaaS runs back-office API on ECS Fargate. Average traffic: 5 Tasks; marketing campaigns spike to 30 Tasks. 1-year commitment possible; reclamation tolerable. Cost-optimal config?" — Compute SP 5-Task commitment + Capacity Provider (base=2 On-Demand + Spot 80%). Anchor baseline 5 Tasks with SP, handle excess traffic via Spot. base=2 ensures minimum availability on reclamation. Resources within SP limit get SP discount; beyond limit get Spot discount. Two levers naturally bifurcate.

Image Pull and Cold-Start — SOCI as New Option

Fargate cold-start's biggest culprit: image pull. No node cache means ECR downloads, decompresses entire images each Task. 2GB images take network + decompression time.

Three solutions:

1. Shrink images themselves. Distroless, Alpine, multi-stage build to <200MB. Most impactful.

2. ECR Pull Through Cache. Cache Docker Hub, quay.io images in ECR. Reduces external network cost, failure risk.

3. SOCI (Seekable OCI). Lazy-load images. Container reads only needed files from network; rest fetch backgrounded. Huge ML images (8GB+) see 50-80% startup reduction.

[Traditional pull]
ECR ────[entire 2GB]────► Task decompress 30s ► Execute

[SOCI lazy]
ECR ────[manifest + index]────► Task execute immediately
       │                          │
       └─[fetch needed files only]┘ Backgrounded
                              (typically 200-500MB actual use)

SOCI requires ECR pre-indexing; user-side changes minimal. Fargate Task Definition auto-applies.

🔍 Deeper Dive: SOCI's lazy-load concept derives from demand paging (OS virtual memory). OS doesn't load entire process memory upfront; pages only load on fault. Container filesystem similarly: only subset of files read in practice. Academia covered this in ATC 2016's "Slacker: Fast Distribution with Lazy Docker Containers"; SOCI implements it atop OCI standard.

⚠️ Trap: SOCI's benefit scales with image size; small images (<100MB) see index overhead exceed gains. "Enable SOCI on all images" is wrong. Small images are faster fetched directly.

Lambda vs. Fargate vs. EC2 Cost Breakpoints

Placing identical workload among three compute options is SAP's canonical scenario. Breakpoints hinge on workload lifetime, frequency, resource size axes.

Empirical breakpoints:

• Average 40%+ utilization + 24/7 steady = EC2 + Compute SP
• Variable + Spiky + 5min+ = Fargate
• 100ms-5min events = Lambda (max 10GB memory)

Lambda since 2020 supports 10GB memory, 6 vCPU, 15-minute execution, replacing some Fargate. Back-office APIs requiring connection pools still favor Fargate.

📚 Case Study: 2023, a log analysis company moved some batch jobs from Fargate to Lambda. Job duration: 3min average; frequency: 200/hour; memory: 4GB. Fargate: 2 Tasks always-on, idle costs high. Lambda: billed only for execution, slashing monthly cost ~60%. Tradeoff: Lambda cold-start (VPC connection 1-2s) acceptable.

Application Auto Scaling — Fargate's Standard Auto-Scaling

ECS Service Task count adjusts via Application Auto Scaling, a separate service powering ECS, DynamoDB, Aurora, SageMaker scalers.

Three policy types:

• Target Tracking: "Keep CPU average at 60%," most common.
• Step Scaling: "CPU >70% add 2, >85% add 5," discrete steps.
• Scheduled: "Weekday 9am min=10, 10pm min=2," time-based.

aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --resource-id service/prod/myapp \
  --scalable-dimension ecs:service:DesiredCount \
  --min-capacity 2 --max-capacity 50
 
aws application-autoscaling put-scaling-policy \
  --service-namespace ecs \
  --resource-id service/prod/myapp \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-name cpu-target \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 60.0,
    "PredefinedMetricSpecification":
      {"PredefinedMetricType":"ECSServiceAverageCPUUtilization"}
  }'

Target Tracking internally auto-creates CloudWatch alarms adjusting desired count. Mechanically close to PID control, but AWS's implementation is simple proportional. Default pattern: scale-up fast, scale-down slow—stable against traffic churn.

💡 Related Theory: Auto-Scaling applies control theory. Measures value (CPU%), target (60%), error difference, adjusts actuator (Task count). Proper PID uses integral/derivative terms; AWS Target Tracking resembles simple P-control. Simpler risks oscillation, so long scale-in cooldown is standard. Netflix built Scryer, a predictive autoscaler, ML-predicting traffic patterns past this limitation.

Summary

Fargate looks expensive on price sheets alone, but Fargate Spot (70%) + Compute SP (66%) + Graviton (20%) combined run workloads ~70% cheaper. Price comparison hinges most on average utilization and traffic variability. Steady 40%+ 24/7 → EC2 + SP wins; otherwise Fargate wins operationally.

Tomorrow we cover service mesh and service discovery. ECS Service Connect, AWS Cloud Map, App Mesh differences; how mTLS, canaries, circuit breakers implement. Ten microservices on Fargate—how inter-service communication becomes safe and observable.

📌 Today's Summary

1. Fargate billing = vCPU·hours + memory·hours, per-second minimum 1-minute, image pull time billed
2. vCPU-memory matrix: 0.5 vCPU = 1-4GB, 1 vCPU = 2-8GB etc., EC2 family ratios exposed
3. Fargate Spot 70% discount + 2-min SIGTERM, base=2 + Spot 80% Capacity Provider standard pattern
4. Compute Savings Plans only cover Fargate·EC2·Lambda; EC2 Instance SP EC2-only
5. Graviton ARM64 adds 20% savings, multi-arch build prerequisite
6. SOCI lazy-load cuts large-image cold-start 50-80%
7. 40%+ utilization + 24/7 = EC2 + SP, else variable/spiky = Fargate, short/frequent = Lambda