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 …)

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.

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.

SQLServer Optimierung auf AWS

im Dezember haben wir im Rahmen eines Consulting-Einsatzes verschiedene SQLServer EBS-Laufwerks-Kombinationen bei einem Kunden ausprobiert, um eine optimale Performance zu erreichen.

Zusammenfassung:

  • r4.4xlarge bringt fast doppelte Performance gegen über r4.2xlarge, obwohl CPU und RAM bei beiden Instanzen nicht viel Auslastung haben … Das war eine Überraschung!
  • Striping generell bringt fast doppelte Performance gegenüber kein Striping
  • EBS Typ io1 mit 5000 IOPS bringen gegenüber EBS Typ GP2 bei der einen Abfrage doppelte Performance, bei den anderen 4 Abfragen teilweise fast gleiche oder nur 30 % mehr Performance bei erheblich mehr Kosten
  • Die neuen R4 Instanzen haben übrigens DDR4 RAM, bis zu 10 Gbit Network und bis zu 12 Gbit EBS-Network Anbindung. Leider konnten wir keinen Vergleich zu R3 machen

 

Weitere Ideen:

(mehr …)

An- und Abschalten von Test- oder Evaluierungsserver über zeitgesteuerte Lambda-Events

Manchmal möchte man eine neue Software ausprobieren und hat aber keinen Server frei. Was liegt da näher, als einen virtuellen Server über EC2 zu starten. Hier kann man mit einer einfachen Methode über 50% der Kosten sparen: Wird der Server z.B. nur tagsüber benötigt, so kann man ihn mit AWS Lambda an- und ausschalten. Wenn die Server-Instanz EBS-Platten hat, so bleibt der letzte Stand der Daten erhalten und man zahlt im inaktiven Zustand nur die EBS-Volumen. Für jeden An- und Ausschaltvorgang einer Instanz zahlt man eine Stunde Servernutzung, daher sollte man nicht stündlich schalten.
(mehr …)

Amazon EFS in 60 Sekunden ausprobieren

Bereits auf der re:Invent 2014 hatte AWS den Service Amazon EFS, eine skalierbares Netwerkdateisystem, angekündigt. Jetzt ist EFS endlich für alle AWS-Kunden in den Regionen US East (N. Virginia), US West (Oregon) und EU (Ireland) verfügbar.

Brennen Sie schon darauf EFS selbst auszuprobieren? Dieser Artikel zeigt wie Sie in nur 60 Sekunden eine erste EFS-Umgebung aufsetzen können.

  1. Launch Stack
  2. Klick auf Next um zum nächsten Wizard-Schritt zu gelangen.
  3. Name für Stack und alle benötigten Parameter definieren.
  4. Klick auf Next um zum nächsten Wizard-Schritt zu gelangen.
  5. Klick auf Next um zum nächsten Wizard-Schritt zu überspringen.
  6. Klick auf Create um den Stack zu erstellen.
  7. Warten bis der Stack den Status CREATE_COMPLETE erreicht hat.

Jetzt können Sie sich mit SSH auf die EC2 Instanz einloggen, die vom CloudFormation Stack erzeugt wurde. EFS ist auf der Maschine unter /efs gemounted.

Viel Spaß beim Ausprobieren! Erfahrungsberichte bitte in die Kommentare.

EC2 x1.32xlarge Instanzen mit 128 vCores und 1952 GB RAM

AWS hat heute den neuen EC2 Instanztyp x1.32xlarge vorgestellt, der auch in Frankfurt und Irland verfügbar ist.

x1.32xlarge bietet 128 vCores und 1952 GB RAM … speziell für z.B. SAP HANA Workloads oder ähnliches. Der Preis pro Stunde beträgt in Frankfurt für SUSE-Linux 18,774 USD/h, für Windows 24,562 USD/h.

Es gibt selbstverständlich auch schon entsprechende Rabattpläne für 1- und 3-Jahre, so dass sich der Preis bei einem 1 Jahr schon um 42% reduzieren lässt, bei 3 Jahren sogar um 72%.

Weitere Details finden Sie hier im offiziellen AWS-Blog.

Auch ein spezieller SAP HANA Migration Guide to AWS ist schon vorhanden.

 

 

Encrypted EBS Boot Volumes

Encryption is an important part of any data protection strategy, and because of that today we are showing how encryption for EBS boot volumes works.

This will aid your security, compliance, and auditing efforts by allowing you to verify that all of the data that you store on EBS is encrypted. Further, because this feature makes use of KMS, you can track and audit all uses of the encryption keys.

 

Creating an Encrypted EBS Boot Volume

First of all you need to create the key you will use to encrypt the boot volume. This is done in IAM:

IAM Management Console

Note that the key must be created in the same region where you want to encrypt the boot volume.

(mehr …)