SW BBANG D

Du schreibst ein Deployment-Skript, das auf dem EC2-Server selbst läuft, und brauchst die Instance-ID — ohne sie hardzukodieren oder aus externen Quellen zu ziehen. Der Instance Metadata Service (IMDS) liefert genau das. Aber wer IMDSv1 noch verwendet, hat eine stille Sicherheitslücke im System, die in realen SSRF-Angriffen bereits ausgenutzt wurde. TL;DR: IMDSv2 vs. IMDSv1 beim Abruf der EC2 Instance-ID Merkmal IMDSv1 IMDSv2 Authentifizierung Keine — direkter GET-Request Session-Token erforderlich (PUT → GET) SSRF-Schutz Nicht vorhanden Token-Pflicht blockiert einfache SSRF-Angriffe TTL-Kontrolle Nicht anwendbar Token-Lebensdauer konfigurierbar (1–21600 Sek.) AWS-Empfehlung Veraltet, nicht empfohlen Empfohlen, erzwingbar per Instance-Konfiguration Abwärtskompatibilität — IMDSv2 funktioniert auch wenn IMDSv1 deaktiviert ist Wie der Instance Metadata Service funktioniert Der IMDS ist ein link-l...

Eine Nachricht landet bei zwei verschiedenen Consumern gleichzeitig — das ist kein Bug im Anwendungscode, sondern meistens ein falsch kalibriertes Visibility Timeout in Amazon SQS. Wer diesen Mechanismus nicht genau versteht, baut sich eine Race Condition direkt in die Verarbeitungspipeline ein. TL;DR: SQS Visibility Timeout auf einen Blick Aspekt Detail Was es ist Zeitfenster, in dem eine abgerufene Nachricht für andere Consumer unsichtbar ist Standardwert 30 Sekunden Konfigurierbarer Bereich 0 Sekunden bis 12 Stunden Typische Ursache für Doppelverarbeitung Verarbeitungszeit überschreitet das Visibility Timeout Lösung Timeout an reale Verarbeitungsdauer anpassen oder ChangeMessageVisibility nutzen Löschen der Nachricht Muss explizit per DeleteMessage erfolgen — passiert nicht automatisch Wie SQS Visibility Timeout funktioniert SQS ist kein klassischer Message Broker mit exklusivem Loc...

Du startest ein neues Projekt, hast aber noch keine belastbaren Traffic-Daten – und fragst dich, ob du mit Provisioned Capacity zu wenig reservierst und Throttling riskierst, oder mit On-Demand zu viel zahlst. DynamoDB Capacity Modes sind der erste Hebel, den du richtig stellen musst, bevor du überhaupt anfängst, Tabellen zu designen. TL;DR – DynamoDB Capacity Modes auf einen Blick Kriterium On-Demand Provisioned Traffic-Muster bekannt? Nein / unvorhersehbar Ja / stabil Throttling-Risiko Sehr gering Bei Fehlkonfiguration hoch Kosten bei stabilem Traffic Höher Günstiger Auto Scaling erforderlich Nein Empfohlen Moduswechsel Einmal alle 24 Stunden Einmal alle 24 Stunden Typischer Einsatz Neue Apps, Spikes, Dev/Test Produktion mit bekanntem Muster Wie DynamoDB Capacity Modes funktionieren Bevor du den richtigen Modus wählst, musst du verstehen, wie DynamoDB intern Kapazität verwaltet – sonst ...

Du richtest eine neue Domain ein, zeigst auf einen Application Load Balancer – und stehst vor der Frage: CNAME oder Alias? Auf den ersten Blick scheinen beide dasselbe zu tun. In der Praxis ist der Unterschied jedoch entscheidend, besonders wenn du den Zone Apex ( example.com ohne Subdomain) konfigurieren willst. TL;DR – Route 53 Alias vs. CNAME auf einen Blick Kriterium CNAME Route 53 Alias Zone Apex ( example.com ) ❌ Nicht erlaubt (RFC 1912) ✅ Unterstützt Ziel Beliebiger Hostname AWS-Ressourcen (ALB, CloudFront, S3, etc.) DNS-Abfragekosten Kostenpflichtig pro Query Kostenlos für unterstützte AWS-Ziele TTL steuerbar ✅ Ja ❌ Nein (von AWS verwaltet) Health Check Integration Eingeschränkt Direkt integrierbar Gibt A/AAAA zurück Nein (gibt CNAME-Chain zurück) Ja (löst direkt auf) Wie Route 53 Alias Records funktionieren Ein CNAME-Record ist ein DNS-Standard: Er verweist einen Hostnamen auf e...

Du hast einen Datenbankendpunkt, der sich je nach Umgebung ändert — Entwicklung, Staging, Produktion — und willst ihn nicht direkt in den Funktionscode schreiben. Lambda Environment Variables lösen genau dieses Problem, aber der Teufel steckt im Detail: Wann reichen die Standard-Verschlüsselung aus, wann brauchst du einen eigenen KMS-Schlüssel, und wie liest du die Werte zur Laufzeit korrekt aus? TL;DR: Lambda Environment Variables auf einen Blick Aspekt Detail Speicherort Funktionskonfiguration, nicht im Deployment-Paket Standard-Verschlüsselung AWS-verwalteter Schlüssel (aws/lambda) — automatisch, kein Setup nötig Eigener KMS-Schlüssel Kundenverwalteter CMK — explizite IAM-Berechtigung erforderlich Laufzeitzugriff Über Betriebssystem-Umgebungsvariablen (z. B. process.env , os.environ ) Maximale Grö...

Wer ein neues AWS-Konto anlegt und erste Experimente startet, bemerkt oft erst Wochen später, dass ein vergessener EC2-Instance oder ein NAT Gateway still und leise Kosten verursacht hat — der Free Tier schützt nicht vor allem. Ein CloudWatch Billing Alarm ist die einfachste Absicherung, die du einrichten kannst, bevor du überhaupt die erste Ressource deployest. TL;DR: Kostenalarm für AWS Free Tier Schritt Aktion Wichtiger Hinweis 1 Billing Alerts im Root-Account aktivieren Muss einmalig in den Billing Preferences gesetzt werden 2 SNS Topic erstellen und E-Mail bestätigen Ohne Bestätigung der E-Mail werden keine Alarme zugestellt 3 CloudWatch Alarm auf EstimatedCharges setzen Metrik ist nur in us-east-1 verfügbar 4 Alarm testen Schwellenwert temporär auf $0.01 setzen zum Verifizieren Wie AWS Billing Metriken funktionieren Bevor du den ersten CLI-Befehl ausführst, musst du verstehen, warum dieser ...