Inhaltsverzeichnis14 Abschnitte
- TL;DR
- Die Familien-Logik
- Preise im Vergleich (eu-central-1, On-Demand, Mai 2026)
- Graviton — die wichtigste Optimierung 2026
- Burstable T-Familie — der Indie-Sweet-Spot
- Storage-Optionen: was passt zur Instance
- Networking-Performance — die unsichtbare Variable
- Bestellempfehlungen nach Workload
- Saving-Plans und Spot — wann was
- GPU-Instances kurz angerissen
- Real-World: 30-VM-Setup Kostenoptimierung
- Naechste Generation: Was 2026 kommt
- Faustregeln zum Mitnehmen
- Quellen
Wer sich bei AWS zum ersten Mal die EC2-Instance-Familien-Tabelle anschaut, bekommt eine ehrliche Reaktion: zu viele Buchstaben. C7i, C7g, C7a, M7i, M7g, R7iz, X2idn, I4g, T4g — und das sind nur die aktuellen Generationen. Spoiler: die meisten Workloads brauchen drei davon, der Rest ist Optimierung.
Dieser Guide raeumt auf: welche Familie loest welches Problem, was kostet sie in eu-central-1 und wo lohnt sich Graviton wirklich. Stand der Preise: 14. Mai 2026.
TL;DR
- C7i / C7g / C7a: Compute-optimiert. Web-Server, API-Backends, CI-Runner. Graviton (C7g) ist ~20 % guenstiger und in den meisten Faellen gleich schnell.
- M7i / M7g: General Purpose. Wenn du nicht weisst was du brauchst, ist M die Default-Wahl.
- R7i / R7iz / X2: Memory-optimiert. Caches, In-Memory-DBs, Java-Heaps jenseits 64 GB.
- T4g: Burstable. Cron-Jobs, Dev-Instanzen, Side-Projects unter 20 % Average-Load.
- Faustregel: Wenn Workload ARM-tauglich ist (>95 % heute), nimm Graviton. Spart ~20 % bei gleicher Performance.
Die Familien-Logik
EC2-Instances folgen einem Schema: <Familie><Generation><Suffix>.<Groesse>.
| Buchstabe | Bedeutung | Wofuer |
|---|---|---|
| C | Compute-optimiert | CPU-bound, hoher Takt |
| M | Memory:CPU 4:1 (Mittel) | General Purpose |
| R | Memory:CPU 8:1 (Hoch) | In-Memory, Caches |
| X | Memory-extrem (>= 16:1) | SAP HANA, Riesen-Caches |
| I | Storage-optimiert | NVMe lokal, IOPS-Bedarf |
| G | GPU | Inferenz, kleine Trainings |
| P | GPU schwer | Training, HPC |
| T | Burstable | Idle-Workloads mit Spitzen |
Suffix-Buchstaben sagen dir die CPU-Architektur:
- i = Intel Xeon (z. B. c7i)
- g = AWS Graviton (ARM, eigene Silicon-Linie)
- a = AMD EPYC
- z = High-Frequency-Variante (z. B. r7iz mit 3,9 GHz)
- n = Network-optimiert (>= 100 Gbit/s)
- d = mit lokalem NVMe-Storage
Praxis: 80 % aller AWS-Kunden brauchen nur C, M, R. Der Rest sind Sonderfaelle.
Preise im Vergleich (eu-central-1, On-Demand, Mai 2026)
Hier die haeufigsten 2xlarge-Groessen (8 vCPU). Preise gerundet, Stundenpreis und Monat (730 h):
| Instance | vCPU | RAM | Stunde | Monat | Notiz |
|---|---|---|---|---|---|
| t4g.2xlarge | 8 | 32 GB | $0,1075 | ~$78 | Burstable, Graviton |
| c7i.2xlarge | 8 | 16 GB | $0,3604 | ~$263 | Intel, compute-opt |
| c7g.2xlarge | 8 | 16 GB | $0,2890 | ~$211 | Graviton, ~20 % off |
| c7a.2xlarge | 8 | 16 GB | $0,3245 | ~$237 | AMD EPYC |
| m7i.2xlarge | 8 | 32 GB | $0,4032 | ~$294 | Intel, GP |
| m7g.2xlarge | 8 | 32 GB | $0,3270 | ~$239 | Graviton, GP |
| r7i.2xlarge | 8 | 64 GB | $0,5292 | ~$386 | Intel, memory |
| r7g.2xlarge | 8 | 64 GB | $0,4291 | ~$313 | Graviton, memory |
| r7iz.2xlarge | 8 | 64 GB | $0,7440 | ~$543 | 3,9 GHz, fuer Latenz |
Rechnung: Ein typisches API-Backend laeuft auf c7g.2xlarge fuer ~$211/Monat. Dasselbe auf c7i.2xlarge: ~$263. Differenz 24 %. Bei 10 Instanzen sind das ~$520 weniger pro Monat, nur durch Architektur-Wechsel.
Graviton — die wichtigste Optimierung 2026
Graviton (AWS-eigene ARM-Prozessoren) ist 2026 die Default-Empfehlung fuer fast alles. Hier die Realitaet:
| Workload | Graviton-tauglich? | Performance vs Intel |
|---|---|---|
| Node.js / Python / Ruby / Go | Ja | +10 bis +20 % |
| Java (OpenJDK 17+) | Ja | +5 bis +15 % |
| .NET 8+ | Ja | gleich bis +10 % |
| PHP | Ja | gleich |
| Postgres / MySQL / Redis | Ja | gleich bis +15 % |
| Kafka / Elasticsearch | Ja | gleich |
| Legacy x86-Binaries (kein ARM) | Nein | n/a |
| Tensorflow / PyTorch Inference | Ja (CPU) | gleich |
Der einzige echte Blocker: wenn du Closed-Source-Software hast, die nur als x86-Binary kommt. Im Indie-/Startup-Kontext ist das heute selten.
Burstable T-Familie — der Indie-Sweet-Spot
T4g-Instances laufen mit einer Baseline-CPU-Quote und sammeln „CPU-Credits“, wenn sie unter dieser Quote bleiben. Bei Lastspitzen werden Credits verbraucht und der vCPU auf 100 % freigegeben.
| Instance | Baseline | Vollast / h | Credits / h | Sinnvoll fuer |
|---|---|---|---|---|
| t4g.nano | 5 % | 0,3 vCPU/h | 6 | DNS, kleine Worker |
| t4g.micro | 10 % | 0,3 vCPU/h | 12 | Cron, kleine APIs |
| t4g.small | 20 % | 0,5 vCPU/h | 24 | Dev-VMs |
| t4g.medium | 20 % | 0,5 vCPU/h | 24 | Side-Project-API |
| t4g.xlarge | 40 % | 1,5 vCPU/h | 96 | Mittlere Web-Apps |
Achtung: T-Instances haben einen Unlimited-Mode, in dem extra-CPU einfach extra-billed wird. Wenn du nicht aufpasst, wird die billige t4g.medium bei 80 % Auslastung teurer als eine m7g.medium. Im Monitoring „CPU Credit Balance“ immer mit alerten.
Storage-Optionen: was passt zur Instance
Die Instance ist eine Sache, das Storage daneben die andere:
| Storage | Latenz | IOPS-Range | Preis (eu-central-1) | Wofuer |
|---|---|---|---|---|
| EBS gp3 | ~1 ms | 3.000-16.000 | $0,096/GB-Monat | Default-Volume |
| EBS io2 | <1 ms | bis 64.000 | $0,138/GB + IOPS-Preis | DB-Volumes |
| EBS st1 | ~5-10 ms | 500 | $0,053/GB-Monat | Throughput, Cold-DB |
| Instance-NVMe (i7g) | <0,2 ms | >>100k | inkl. Instance-Preis | Hot-Cache, ephemer |
| EFS Standard | ~2-5 ms | n/a | $0,33/GB-Monat | Shared-Filesystem |
| EFS One-Zone | ~2-5 ms | n/a | $0,176/GB-Monat | Single-AZ-Workloads |
Faustregel: gp3 ist 2026 fast immer richtig. io2 nur, wenn du
16.000 IOPS und Sub-Millisekunden-Latenz brauchst — und dann auch wirklich messen, ob die Datenbank das nutzt.
Networking-Performance — die unsichtbare Variable
| Instance-Groesse | Network-Bandbreite (Burst) | EBS-Bandbreite |
|---|---|---|
| .large | bis 12,5 Gbit/s | bis 4,7 Gbit/s |
| .xlarge | bis 12,5 Gbit/s | bis 4,7 Gbit/s |
| .2xlarge | bis 15 Gbit/s | bis 10 Gbit/s |
| .4xlarge | 15 Gbit/s sustained | 10 Gbit/s |
| .8xlarge | 30 Gbit/s sustained | 20 Gbit/s |
| .16xlarge | 75 Gbit/s sustained | 40 Gbit/s |
| .metal | 100-200 Gbit/s | 80 Gbit/s |
Was nicht in den Marketing-Charts steht: die kleinen Groessen bursten auf hohe Bandbreite, halten sie aber nicht. Wenn du einen Replication-Lag-Streamer auf m7g.large laufen laesst, bekommst du 12 Gbit/s als Hochkommas. Sustained sind es nach ~5 Minuten weniger. Fuer Streaming-Workloads .8xlarge+ planen.
Bestellempfehlungen nach Workload
Stateless Web/API-Backend, normale Last: c7g.large bis c7g.2xlarge. Ein paar davon hinter ALB. Auto-Scaling- Group mit Spot-Mix (50 % Spot, 50 % On-Demand).
Postgres / MySQL Primary: r7g.2xlarge oder r7g.4xlarge mit io2-Volume. RDS-Instanz oder selbst gehostet — bei beidem Graviton (db.r7g) waehlen.
Redis / Memcached: r7g.large bis r7g.2xlarge. Oder ElastiCache mit selber Familie.
Hot-Cache mit lokalem NVMe: i4g.large / i4g.xlarge. NVMe-SSD ist ephemer, also nur fuer „rebuild-bares“ Cache geeignet.
CI-Runner / Build-Server: c7g.4xlarge im Spot-Mode. Selbst mit Unterbrechungen ~70 % Rabatt gegenueber On-Demand.
Side-Project / Dev-Box: t4g.medium oder t4g.large. ~30-50 €/Monat.
Saving-Plans und Spot — wann was
| Strategie | Rabatt vs On-Demand | Commitment |
|---|---|---|
| Compute Savings Plan 1y | ~30 % | 1 Jahr |
| Compute Savings Plan 3y | ~50-55 % | 3 Jahre |
| Reserved Instance Standard 3y AURI | ~60 % | 3 Jahre + Family lock |
| Spot Instances | bis 90 % | Kein, aber Unterbrechungen |
Praxis: Compute Savings Plan 1y fuer Baseline-Kapazitaet, Spot fuer Spitzen. RIs sind 2026 nur noch in absoluten Ausnahmefaellen wirtschaftlich besser als Savings Plans.
GPU-Instances kurz angerissen
Wenn du GPUs auf AWS willst, gibt es 2026 zwei relevante Familien:
| Instance | GPU | vRAM | vCPU | RAM | $ / h eu-central-1 |
|---|---|---|---|---|---|
| g6.xlarge | 1× L4 (24 GB) | 24 GB | 4 | 16 GB | $0,932 |
| g6.2xlarge | 1× L4 (24 GB) | 24 GB | 8 | 32 GB | $1,128 |
| g6e.xlarge | 1× L40S (48 GB) | 48 GB | 4 | 32 GB | $1,931 |
| p4d.24xlarge | 8× A100 (40 GB) | 320 GB | 96 | 1.152 GB | $32,77 |
| p5.48xlarge | 8× H100 (80 GB) | 640 GB | 192 | 2.048 GB | $98,32 |
| p5e.48xlarge | 8× H200 (141 GB) | 1.128 GB | 192 | 2.048 GB | $107,80 |
Praxis: Fuer Inferenz ist g6 oder g6e die richtige Wahl — ~$700-1.400 / Monat. Fuer Training sind p5/p5e die einzigen sinnvollen Optionen, aber spuerbar teurer als Specialist-Provider wie RunPod oder Lambda Labs. Spot-Pricing schlaegt zu (bis ~70 % off bei g6).
Real-World: 30-VM-Setup Kostenoptimierung
Ein konkretes Beispiel aus eigener Beratung: 30 EC2-Instances, Mischbetrieb. Vorher: alle c7i.2xlarge mit On-Demand-Pricing.
| Massnahme | Saving |
|---|---|
| 20× c7i → 20× c7g (Graviton) | ~$520 / Mo |
| 5× t4g.medium statt c7g.large (Dev/Cron) | ~$80 / Mo |
| Compute SP 1y NU auf 60 % Baseline | ~$1.200 / Mo |
| Spot fuer 5× CI-Runner | ~$280 / Mo |
| gp2 → gp3 auf allen Volumes | ~$45 / Mo |
Total Saving: ~$2.125 / Monat bei initial ~$8.500 / Monat Compute-Bill. ~25 % Reduktion ohne Performance-Verlust.
Wichtig: die Aenderungen sind additiv. Du kannst sie ueber 3-4 Wochen einfuehren ohne grosse Migrations-Aktion.
Naechste Generation: Was 2026 kommt
AWS hat fuer Q3 2026 angekuendigt:
- c8g / m8g / r8g: Graviton 4 mit ~25 % mehr Performance bei gleichem Preis wie c7g
- i8g: Storage-Instances mit Graviton + neuer NVMe-Generation
- p6 / p6e: Trainium 3 + Inferentia 3, AWS-eigene AI-Chips als Alternative zu NVIDIA
Wenn dein Workload nicht akut ist: warte mit 3y-Reservations, bis c8g/m8g/r8g GA sind (vermutlich Juli-September 2026).
Faustregeln zum Mitnehmen
- Default: Graviton (g-Suffix). Ausnahme nur, wenn x86-Binary zwingt.
- C fuer CPU, M fuer Generalist, R fuer RAM. Mehr Buchstaben brauchst du selten.
- T-Familie nur bei < 20 % Average-Load. Sonst zahlst du drauf.
- Spot fuer alles, was Restart vertraegt. CI, Batch, ML-Inferenz.
- gp3 statt gp2. Immer. gp2 ist seit 2024 nur noch Legacy.
Quellen
- AWS EC2 Instance Types
- AWS EC2 On-Demand Pricing
- AWS Graviton Performance Reports
- AWS Savings Plans
- AWS Spot Instance Advisor
Pricing-Stand: 14. Mai 2026. AWS aendert Preise und fuegt Instance-Typen quartalsweise dazu — vor Reservierungen die aktuelle Pricing-Page pruefen.
Geschrieben von
Harbinger Team
Cloud-, Data- und AI-Engineer in DACH. Schreibt seit 2018 über infrastrukturkritische Tech-Entscheidungen — keine Marketing- Folien, sondern echte Trade-offs aus Production-Workloads.
Hat dir das geholfen?
Jede Woche ein neuer Artikel über DACH-Cloud, Data und AI — direkt in dein Postfach. Kein Spam, kein Marketing-Sprech.
Kein Spam. 1-Klick-Abmeldung. Datenschutz bei Loops.so.