types and pricing

requirements:
        - key: "karpenter.k8s.aws/instance-category"
          operator: In
          values: ["c", "m", "r"]
          # minValues here enforces the scheduler to consider at least that number of unique instance-category to schedule the pods.
          # This field is ALPHA and can be dropped or replaced at any time
          minValues: 2
        - key: "karpenter.k8s.aws/instance-family"
          operator: In
          values: ["m5","m5d","c5","c5d","c4","r4"]
          minValues: 5
        - key: "karpenter.k8s.aws/instance-cpu"
          operator: In
          values: ["4", "8", "16", "32"]
        - key: "karpenter.k8s.aws/instance-hypervisor"
          operator: In
          values: ["nitro"]
        - key: "karpenter.k8s.aws/instance-generation"
          operator: Gt
          values: ["2"]
        - key: "topology.kubernetes.io/zone"
          operator: In
          values: ["us-west-2a", "us-west-2b"]
        - key: "kubernetes.io/arch"
          operator: In
          values: ["arm64", "amd64"]
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot", "on-demand", "reserved"]

Gotcha, Pavan. Here’s a crisp-but-detailed cheat sheet for those EC2 terms, with examples so you can map names to meaning fast.

EC2 naming anatomy (quick decode)

Example: c7g.4xlarge

• c → family (Compute optimized)

• 7 → generation

• g → CPU/special suffix (Graviton/Arm)

• .4xlarge → size (vCPU/RAM preset) Common extra suffixes: a (AMD EPYC), i (Intel Xeon), g (Graviton/Arm), d (NVMe instance store), n (higher networking), b (higher EBS BW), flex (lower-cost, flexible variant on some families).

---

1) Instance category

High-level “what it’s optimized for”.

• General purpose — balanced CPU/RAM/network. Families: t, m (e.g., t3, m7i, m7g).

• Compute optimized — more CPU per GB RAM. Family: c (e.g., c7g, c7i, c7gn).

• Memory optimized — high RAM:CPU. Families: r, x, u, z (e.g., r7g, r6i, x2idn).

• Storage optimized — high IOPS/throughput, local NVMe. Families: i, d, im/is (e.g., i4i, i4g, d3).

• Accelerated computing — GPUs/Inferentia/Trainium. Families: p, g, inf, trn (e.g., p5, g6, inf2, trn1).

• HPC — tightly-coupled compute with very fast interconnect. Family: hpc (e.g., hpc7g).

• Mac — dedicated Mac hosts. Family: mac (e.g., mac2-m2pro.metal).

👉 Pick category by workload: APIs/web → General purpose; batch/CI → Compute; DB/cache/analytics → Memory; data lakes/NoSQL with local SSD → Storage; AI/ML/video → Accelerated; CFD/FSI/HPC → HPC.

---

2) Instance family

Letter(s) that map to hardware emphasis inside a category.

• t (burstable), m (balanced), c (compute), r/x/u/z (memory),

• i/d/im/is (storage/NVMe),

• g/p/inf/trn (GPU/Inferentia/Trainium),

• hpc (HPC), mac (Apple).

Examples:

• m7i = General purpose, gen 7, Intel.

• m7g = General purpose, gen 7, Graviton.

• c7gn = Compute optimized, gen 7, Graviton, high networking.

• r6id = Memory optimized, gen 6, Intel, with NVMe instance store.

• i4i / i4g = Storage optimized (Intel vs Graviton).

---

3) Instance hypervisor

The virtualization platform beneath the instance.

• Nitro (modern, default for new families)

  • Hardware offload + KVM-based hypervisor.

  • Benefits: near bare-metal performance, consistent I/O, ENA networking, NVMe, better isolation, features like Nitro Enclaves and vEBS throughput improvements.

  • Most current families (m6/m7, c6/c7, r6/r7, i4, g6, p5, etc.) are Nitro.

• Xen (legacy)

  • Older generations (e.g., some 5 and earlier).

  • Less common now; new deployments should prefer Nitro families.

You’ll also see .metal variants (bare metal) that expose the physical host while still using the Nitro cards for I/O.

---

4) Instance generation

The number after the family (e.g., m7, c7, r6).

• Higher = newer silicon, better perf/$, newer Nitro features.

• Within a generation, the suffix usually signals CPU vendor or capability:

  • i = Intel (e.g., m7i, c7i)

  • a = AMD (e.g., m6a, r6a)

  • g = Graviton (Arm) (e.g., c7g, r7g)

  • d = NVMe instance store (e.g., c7gd, r6id)

  • n = enhanced networking (e.g., c7gn, m6in)

  • b = higher EBS bandwidth (e.g., r5b)

  • flex = lower-cost, flexible SKU (e.g., m7i-flex)

---

5) Architecture

CPU ISA your AMI/binaries must match.

• x86_64 — Intel/AMD. Broadest software ecosystem. Families: …i / …a, many GPU families.

• arm64 — AWS Graviton (g). Typically better price/perf and power efficiency; many modern workloads (Java, Go, Rust, Python, Node, NGINX, Redis, MySQL/Postgres) run great; check native libs. Families: …g (c7g, m7g, r7g, hpc7g), i4g (storage).

• Apple silicon on mac2 (M2/M2 Pro) — for macOS build/sign pipelines; special tenancy.

Rule: AMI architecture must match instance architecture (arm64 vs x86_64). Multi-arch containers make migrations easier.

---

6) Capacity type (how/where capacity is fulfilled)

Two common meanings in AWS tooling:

A) Purchase/fulfillment type

• On-Demand — pay per second, no commitment.

• Spot — up to ~90% cheaper, but can be interrupted; use in fault-tolerant/ stateless jobs with checkpointing.

• Reserved Instances / Savings Plans — billing commitments (1–3 yrs) for lower rates; not a capacity guarantee by themselves.

• Dedicated Hosts/Instances — physical isolation for compliance/licensing.

• Capacity Reservations / Zonal RI — hold capacity in a specific AZ (for strict SLAs/DR).

B) In EKS/Auto Scaling vocabulary

• capacityType: ON_DEMAND or SPOT for Managed Node Groups, Karpenter, EC2 Auto Scaling groups, and EC2/Fleet mix policies (set percentages or weights).

Allocation strategies (mixed fleets/ASG/Spot):

• price-capacity-optimized (recommended on Spot),

• capacity-optimized, lowest-price, plus weights per instance type and min/desired/on-demand base to blend OD/Spot.

---

Quick examples (name → meaning)

• c7g.large → Compute optimized, gen 7, Graviton (Arm), small size.

• m7i-flex.2xlarge → General purpose, gen 7, Intel “flex” (cheaper variant), mid size.

• r6id.8xlarge → Memory optimized, gen 6, Intel, d = local NVMe drives.

• c7gn.16xlarge → Compute optimized, gen 7, Graviton, n = very high networking.

• i4g.2xlarge → Storage optimized on Graviton (great price/IOPS for Arm-native stacks).

• p5.2xlarge / g6.8xlarge → GPU families (NVIDIA for training/inference/graphics).

• mac2-m2pro.metal → Apple silicon Mac host, bare metal.

---

Choosing quickly

• Default web/API/app: m7g (if Arm-ready) or m7i.

• High RPS microservices: c7g / c7i, consider c7gn for heavy networking.

• DBs/Redis/Elasticsearch: r7g / r7i (more RAM).

• Local NVMe for Kafka/ClickHouse/NoSQL: i4i / i4g / r6id / c7gd.

• GPU/ML: g6/g6e (inference/graphics), p5/p5e (training).

• HPC tightly coupled: hpc7g/hpc7a, enable EFA.

If you want, I can turn this into a one-pager PDF and a “name decoder” script (give it an instance type → it prints category, vendor, arch, storage/network hints).