Druckfrisch: Amazon Web Services in Action (Second Edition)

Die erste Version von Amazon Web Services in Action haben Michael und ich 2015 geschrieben und publiziert. Unser Buch wurde schnell zum Bestseller. Wir sind immer noch vom positiven Feedback unserer Leser begeistert. Vielen Dank dafür!

Allerdings entwickelt sich AWS schnell weiter. Jede Woche werden neue Features angekündigt. Daher haben wir uns wieder an die Tastatur gesetzt um unser Buch zu überarbeiten und zu erweitern.

Heute ist es endlich soweit! Die zweite Version unseres Buches Amazon Web Services in Action ist sowohl als „echtes“ Buch sowie als eBook (PDF) verfügbar. Andere eBook-Formate folgen demnächst. Übrigens, wer das gedruckte Buch kauft bekommt automatisch auch das eBook mit dazu.

Mit dem Gutschein-Code nlaws2e gibt es beim Kauf von Amazon Web Services in Action Second Edition 20% Rabatt.

Was erwartet mich im Buch?
Mit unserem Buch lernst du die grundlegenden Teile und Konzepte von AWS kennen: Virtuelle Maschinen (EC2), Speichersysteme (EBS, EFS, S3), Datenbanken (RDS, DynamoDB) sowie Netzwerk (VPC). Außerdem lernst du, wie du deine Applikationen mit Hilfe von Elastic Beanstalk, OpsWorks oder CloudFormation ausrollen kannst.

Ein wichtiger Vorteil von AWS ist die Möglichkeit zur Automatisierung des kompletten Rechenzentrums- und Anwendungsbetriebs. In unserem Buch fokussieren wir uns daher auf Infrastructure as Code mit AWS CloudFormation. CloudFormation erlaubt es dir alle notwendigen Ressourcen automatisiert zu provisionieren und zu warten.

Mit unserem Buch lernst du außerdem wie man auf AWS skalierbare und hochverfügbare Architekturen (ELB, SQS, Auto Scaling) entwirft und umsetzt. Und selbstverständlich lernst du auch, wie du deine Cloud-Infrastruktur absichern kannst (IAM, Security Groups).

Was finde ich nicht im Buch?
Das Produktportfolio von AWS ist riesig. Wir lieben es basierend auf all diesen Bausteinen die bestmögliche Lösung zu entwickeln. Allerdings sind die Anzahl der Seiten in einem Buch begrenzt. Daher mussten wir einige spannende Themengebiete komplett ausklammern. In unserem Buch findest du daher u.a. nichts zu folgenden Themen: Container, Big Data, Machine Learning und Mobile Anwendung. Das wäre dann vielleicht etwas für unser nächstes Buch.

Was hat sich in der zweiten Version geändert?
Wir haben alle Kapitel komplett aktualisiert und überarbeitet. AWS bewegt sich schnell und daher hat sich seit 2015 viel geändert. Ein paar Beispiele:

  • Es ist mittlerweile deutlich einfacher mit Hilfe von Reserved und Spot Instances relevant Kosten einzusparen.
  • Zwei neue Load Balancer Typen wurden eingeführt: Application Load Balancer und Network Load Balancer.
  • Für Auto Scaling wurden zusätzliche Optionen eingeführt.

Wir haben außerdem alle CloudFormation Templates in YAML überführt. Im Vergleich zum bisherigen JSON-Format ist das YAML-Format unserer Meinung deutlich lesbarer.

Was ist neu in der zweiten Version?
Wir haben nicht nur alle Kapitel überarbeitet sondern auch drei neue Kapitel hinzugefügt. In den neuen Kapiteln lernst du folgende Dienste kennen:

  • Amazon Elastic File System (EFS): ein skalierbares und ausfallsicheres Network File System (NFS)
  • Amazon ElastiCache: In-Memory-Datenbanken u.a. um Abfragen an SQL-Datenbanken zu cachen
  • AWS Lambda: eine Ausführungsumgebung für deinen Code

Danke!
Vielen Dank an alle Leser, die die Vorabversion (MEAP) unseres Buches gekauft haben. Wer die gedruckte Variante gekauft hat, wird schon bald ein Paket mit dem Buch erhalten. Außerdem ein großes Dankeschön an alle Rezensenten, die uns dabei geholfen haben die zweite Version zu verbessern.

Angebot
Für alle, die noch nicht stolze/r Besitzer/in unseres Buches sind: mit dem Gutschein-Code nlaws2e gibt es unter Amazon Web Services in Action Second Edition 20% Rabatt auf unser Buch.

Das alte Terminal kann weg!

 

Diese Probleme tauchen manchmal bei der Arbeit mit AWS Instanzen auf:

  • Du arbeitest mit AWS Instanzen und die Firewall lässt keine ausgehenden SSH Verbindungen zu?
  • Die Suche nach dem richtigen Konzept für die Verwaltung von SSH Keys gestaltet sich schwierig?
  • Es ist erforderlich, dass jeder Terminal Zugriff auf die Instanzen protokolliert wird.
  • Der SSH Key ist so sicher verlegt, dass keiner mehr auf die Instanzen kommt.

Wäre es da nicht schön, einfach über die AWS Console eine Terminal Session auf eine Instanz zu starten?

Genau das geht jetzt.

(mehr …)

Einleitung zu tRick

Wer träumt nicht davon das Infrastructure as Code Framwork zu benutzen, das die eigenen Anforderungen bestens erfüllt? Aber wie findet man nun dieses eine richtige Framework für seinen Anwendungsfall, den „Alleskönner“ oder den „Spezialisten“?

Magic Tree in a Forest

Auch wir bei tecRacer haben immer wieder mit unterschiedlichsten Infrastructure as Code Frameworks zu tun. Bei unseren Projekten im AWS Umfeld steht uns eine große Zahl an möglichen Tools zur Verfügung.

Aber worin genau besteht der Vorteil von Infrastructure as Code Frameworks gegenüber einer manuellen Bereitstellung von Infrastruktur-Resourcen?

(mehr …)

CloudWatch Alarme über Slack empfangen

Ob CPU-Auslastung einer EC2-Instanzen, Fehler beim Ausführen einer Lambda-Funktion oder verfügbarer Speicherplatz einer RDS-Instanz mit Amazon CloudWatch lassen sich Ressourcen bei AWS überwachen. Dafür werden zwei Komponenten benötigt:

  • Metriken: Eine Metrik ist ein Sammeltopf für Messwerte, die von den AWS Services automatisch befüllt werden.
  • Alarme: Ein Alarm überprüft in regelmäßigen Abständen ob sich die Messwerte einer Metrik noch innerhalb von definierten Grenzen bewegt.

Eine Übersicht über alle verfügbaren Metriken findet sich unter Metriken und Dimensionen-Referenz von Amazon CloudWatch.

Wann immer ein CloudWatch Alarm feststellt, dass sich eine Metrik außerhalb der definierten Grenzen bewegt, können automatisch folgende Aktionen ausgeführt werden:

Beispielsweise lässt sich ein CloudWatch Alarm so konfigurieren, dass bei einer CPU-Auslastung von über 80% über SNS eine E-Mail an den Verteiler des eigenen DevOps-Teams gesendet wird. Allerdings führen Benachrichtigungen von CloudWatch Alarmen per E-Mail schnell zu einem überquellenden Postfach. Außerdem entsteht mit jeder E-Mail an den Verteiler des eigenen DevOps-Teams auch Abstimmungsbedarf: „Wer kümmert sich um das Problem?“.

Bei tecRacer Consulting verwenden wir Slack um über Standorte (Hannover, Duisburg, Frankfurt und München) hinweg die Kommunikation zwischen allen Cloud Consultants sicherzustellen. Was liegt da näher als auch CloudWatch Alarme über Slack zu empfangen?

Im Jahr 2016 haben Michael und ich an der Serverless Chatbot Competition teilgenommen und in diesem Rahmen einen Chatbot entwickelt. Mit marbot lassen sich CloudWatch Alarme über Slack empfangen. Dabei versucht der Chatbot das DevOps-Team möglichst wenig zu stören. Eingehende Alarme werden über eine Eskalationsstrategie erst einem einzelnen Teammitglied, bei Bedarf einem weiteren Teammitglied und schließlich erst dem ganzen Team zugestellt.

Neben CloudWatch Alarmen integriert sich marbot mit einer Vielzahl von anderen Quellen, über die AWS-Ressourcen überwacht werden können.

Zusätzlich können per HTTP/HTTPS oder E-Mail beliebige Alarme an marbot gesendet werden.

Unser Chatbot kann damit als unkompliziertes und agiles Incident Management Tool verwendet werden. Fügen Sie marbot zu Ihrem Slack Workspace hinzu um die 14-tägige und kostenlose Probezeit zu starten.

Amazon SageMaker ist mehr als Machine Learning in python – er kann auch Teaching in go

Haben Sie nicht auch schon mal beim Durchlesen von Code Anleitungen gedacht, wie schön dass wäre, wenn die Anleitung und der Code zusammen ausführbar wären? Nun, genau das kann Amazon SageMaker!

Amazon SageMaker unterstützt nicht nur bei der Erstellung von Code und Modellen für Machine Learning. Das „literal Programming“, also dokumentenzentrierte Programmierung kann auch mit anderen Sprachen, z.B. go/golang verwendet werden, um Code und Dokumentation als Paket zu verwenden.

Hier ein Beispiel, wie man die jupyter Notebooks mit go verwendet:

(mehr …)

Link Local-Addressen bei AWS

Im sogenannten APIPA/Link Local-Bereich (siehe RFC 3927) sind auf AWS EC2-Instanzen mehrere Dienste erreichbar, von denen der Metadata Service mit Abstand der Bekannteste und Wichtigste ist. Allerdings gibt es dort auch andere Services (siehe Post „Default DNS-Server in AWS VPCs“), die in der Dokumentation teils recht versteckt sind:

169.254.169.123              AWS eigener NTP-Server seit 2017
169.254.169.250/251      Microsoft KMS-Server zum Check von Windowslizenzen
169.254.169.253              DNS Endpunkt, falls DNS Support im VPC aktiv ist
169.254.169.254              Metadataservice auf Port 80

Die IPs mit 169er Prefix sind übrigens von Security Groups völlig unabhängig, da sie auf Hypervisorebene direkt verarbeitet werden. Deswegen findet sich auch kein „Metadata-Agent“ auf den Instanzen und die Route für den 169.254er Bereich zeigt auf das normale Netzwerkinterface. Der Zugriff kann aufgrund dieser Implementation nur auf der OS-Ebene eingeschränkt werden – was aber nicht ratsam ist, da damit auch EC2 Rollen nicht mehr funktionieren.

Durch die Verwendung des RFC 3927 Addressbereichs umgeht AWS elegant Routingprobleme, die bei der Nutzung von RFC1918-Addressen in Hybridumgebungen sonst entstehen könnten. Dasselbe Prinzip wird übrigens auch bei den Default-Transfernetzen bei VPN-Verbindungen angewandt, die aus dem 169.254er Bereich ausgewählt werden.

Default DNS-Server in AWS VPCs

AWS reserviert in jedem Subnetz die dritte IP (bei einer 24er Maske also die x.x.x.2) für Ihren DNS-Server. Sobald man mit Network ACLs arbeitet, geht man daher davon aus, dass die DNS-Queries innerhalb des Subnetzes der Instanz stattfinden. Allerdings findet sich versteckt in den Dokumentationen der Hinweis, dass es sich bei „Subnetz+2“ nur um eine Reservierung handelt, der DNS aber eigentlich auf „VPC+2“ liegt – selbst wenn dort überhaupt kein Subnetz konfiguriert ist.

Dieses Problem kann man elegant umgehen, indem der DNS Endpunkt auf dem lokalen Interface genutzt wird. Während die Existenz des Metadata-Services auf der 169.254.169.254 weithin bekannt ist, ist nämlich der DNS auf 169.254.169.253 eher unbekannt.

Bei Security Groups findet sich eine weitere Besonderheit im Zusammenhang mit DNS: Sofern man ausgehende Regeln explizit konfiguriert hat, ist der default DNS-Server implizit auch freigegeben – selbst wenn udp/53 nicht in den erlaubten Regeln vorhanden ist. Ein externer DNS Server, der z.B. im on-Premise Netzwerk steht, braucht allerdings eine explizite Freigabe.