AWS vs Azure

From UVOO Tech Wiki
Revision as of 15:46, 1 August 2026 by Busk (talk | contribs) (Created page with "**for most greenfield projects, standard microservices, and general container workloads, Fargate is the default best choice.** The reduced configuration, lack of node managem...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

for most greenfield projects, standard microservices, and general container workloads, Fargate is the default best choice.

The reduced configuration, lack of node management (no OS patching, no AMI rotations, no cluster autoscaling setup), and per-task scaling make it the lower-overhead option for developer velocity.

However, saying it’s only when resources are "mostly pegged" misses a few critical non-cost boundaries where Fargate simply cannot be used or becomes significantly more expensive.


Non-Cost Constraints (When Fargate Is Not an Option)

Sometimes you must use EC2 regardless of price or utilization:

  1. GPU / Specialized Hardware Workloads: Machine learning inference/training (NVIDIA GPUs), high-performance media encoding, or AWS Inferentia/Trainium hardware require EC2 instance types. Fargate doesn't support GPU pass-through.
  2. Custom Daemon / Host-Level Monitoring: If you rely on daemonsets/agents that must run at the host OS level (e.g., specific kernel-level eBPF tracing, custom security agents, or system-wide log forwarders), Fargate’s serverless boundary prevents host access. Sidecar containers are required on Fargate instead.
  3. Privileged Mode & Kernel Tweaks: Tasks requiring Linux --privileged access, custom kernel module loading, raw network sockets, or sysctl modifications are blocked by Fargate’s isolation boundary.
  4. Extreme Local Disk I/O: Fargate task storage tops out at 200 GB of ephemeral storage. If your app requires terabytes of high-speed local NVMe scratch disk (like i3en or z1d instances), you need EC2.

Cost Decision Matrix

                    Is the workload continuous & predictable?
                                  /          \
                                 /            \
                                YES            NO (Bursty / Batch / Variable)
                               /                \
      Are you running high-volume baseline?      -->  Use FARGATE
                 /          \                         (Zero idle capacity waste)
                /            \
              YES             NO
              /                \
    Are you using 3-yr Savings  -->  Use FARGATE 
    Plans + tight bin-packing?       (Engineering time > ~20% savings)
            /
          YES
          /
     Use EC2
(Save up to 50%+)


Summary Checklist

Dimension Default Choice Shift to EC2 when...
Operational Effort Fargate (Zero node maintenance) You already have robust node automation (e.g., Karpenter/Cluster Autoscaler) and dedicated DevOps resource.
Scale Mechanism Fargate (Fast task provisioning) Scaling is predictable and you can handle warm node pools.
Hardware Fargate (Standard CPU/ARM + RAM) You require GPUs, host storage, or kernel/privileged access.
Cost at Scale Fargate (No waste from idle nodes) Your monthly compute bill is large enough ($5k–$10k+/mo) that saving 30–50% pays for the engineering time to manage nodes.