AWS Monatsrückblick – März 2016

AWS ist eine innovative und schnell wachsende Plattform. Dies ist eine Zusammenfassung des vergangenen Monats.

Ankündigungen und Neuigkeiten

Fehlt eine wichtige Meldung? Ich freue mich über Feedback! Direkt an @andreaswittig oder als Kommentar zu diesem Beitrag.

Rolling Update mit AWS CloudFormation

Wie spielt man am besten ein Update auf alle EC2 Instanzen in einer Auto Scaling Gruppe ein?

Wenn man dem “Immutable Infrastructure” Ansatz folgt  wird ein Update als eine neue Version ausgerollt in dem neue EC2 Instanzen gestartet. Es werden nie Instanzen von einer Version auf die nächste gehoben. Alte Instanzen werden abgeschaltet und durch neue Instanzen ersetzt.

CloudFormation bietet eine einfache Möglichkeit via Update Policy eine Auto Scalling Gruppe in Batches zu aktualisieren.

Ein Beispiel: Eine Auto Scaling Gruppe besteht aus vier Instanzen (grau) die alle auf Version A laufen. Das Rolling Update von Version B (schwarz) wir mit einer Batch Size von 2 durchgeführt. Instanzen die gerade starten sind in blau gehalten.  Die folgende Animation verdeutlicht was passiert:rolling_update

 

 

Qualitätssicherung von AWS-Architekturen

Ist eine Infrastruktur zu AWS migriert oder dort neu entwickelt, stellt sich häufig die Frage nach der Qualitätssicherung. Entspricht das Setup den Best Practices für AWS-Infrastrukturen?

Einen Ordnungsrahmen zur strukturierten Untersuchung der Umgebung kann hierbei das AWS Well-Architected Framework bilden.

AWS_Well-Architected

Betrachtet werden darin die Bereiche Ausfallsicherheit (Skalierungsfähigkeit, Zero-Downtime Deployments, Backup und Desaster Recovery, etc.), Security (Konformität mit AWS Security Best Practices, Compliance in Design und Betrieb, IDS/IPS und WAF-Architekturen, etc.), Performance  (Optimierung von EC2, Netzwerk und EBS, Storage- und DB-Optimierung, Performance-Monitoring, etc.) und Kostenoptimierung (Einsatz und Kombination von Reserved-, On Demand- und Spot-Instances, Nutzung von AWS-Services, Schaffung von Kostentransparenz nach dem Verursachungsprinzip, etc.).

AWS RDS und Oracle Lizenzen

Beim Launch von RDS-Instanzen gibt es für Microsoft SQL Server und Oracle die Option “Bring your own license”. Bei Microsofts SQL Server kann man in der Enterprise und Standard Edition seine eigene Lizenz mitbringen, bei Oracle  muss man bei allen Editionen außer SE One seine eigene Lizenz mitbringen.

Wieviele Lizenzen muss man dann aber konkret besitzen?

In einer OnPremise-Virtualisierungsumgebung (bspw. auf ESX-Hosts) verlangt Oracle, dass alle physikalischen CPU Kerne der zugrundeliegenden Host-Maschine lizenziert werden, weil es theoretisch möglich ist, dass die Oracle-Instanz alle diese Kerne verwendet. Praktisch muss man also u.U. viel mehr CPU-Kerne lizenzieren, als man tatsächlich benutzt.

In AWS RDS verhält es sich anders. Hier werden die virtuellen CPU-Kerne, die über den Instanztypen provisioniert werden, von Oracle lizenztechnisch wie physikalische CPU-Kerne betrachtet.

Wähle ich also z.B. für meine RDS-Oracle Instanz in einem Single-AZ Deployment den Instanztyp db.m4.xlarge aus, so werden mir 4 vCPU zur Verfügung gestellt und genau so viele Oracle CPU-Lizenzen benötige ich dann auch.

Beim Multi-AZ-Deployment verdoppelt sich die Anzahl der benötigten Lizenzen, auch wenn die zweite Instanz nur als Standby im anderen AZ betrieben wird.

Für Microsoft SQL Server stellt sich die Problematik der physikalischen CPU-Kerne nicht, weil hier von vornherein die Maschine (Standard-Edition) bzw. die vCPU-Kerne (Enterprise-Edition) lizenziert werden. Allerdings gelten für die Verwendung der eigenen Microsoft-Lizenzen in der Cloud die Bestimmungen des License-Mobility-Programms von Microsoft.

Sicherheit bei AWS: CIS Benchmarks

Wer sich mit AWS-Sicherheit beschäftigt, kennt die Differenzierung zwischen “Security of the Cloud” (Amazonseitig) und “Security in the Cloud” (Betreiberseite). Auf die Zuständigkeiten beim Accountsetup, Firewalls und Monitoring wird immer wieder hingewiesen – oft fehlt im Praxisbetrieb aber eine ausführliche Richtschnur, welche Punkte für ein gutes Setup sinnvoll und wichtig sind.

Ende Februar ist nun der “CIS Amazon Web Services Foundations”-Benchmark erschienen, der eine strukturierte Übersicht über die grundlegendsten Tätigkeiten beinhaltet und eine Checkliste hierfür direkt mitliefert.

Das CIS (Center for Internet Security) ist eine herstellerunabhängige Organisation, die unter anderem solche Sicherheitsleitlinien und Checklisten herausgibt. Die bereitgestellten Dokumenten decken dabei einen großen Umfang ab, von Webbrowsern über Serverprozesse bis Betriebssystem-Hardening ist fast alles vertreten. Der nun herausgegebene Benchmark ergänzt die schon länger existierenden Benchmarks für Betriebssysteme (u.a. Amazon Linux, Ubuntu, Windows, SLES12) und oft genutzten Daemons (z.B. Apache, SQL Server, Tomcat, MySQL), die sich auch in den meisten AWS-Projekten wiederfinden.

Wem das Durcharbeiten der für Betriebssysteme sehr langen Dokumente zuviel Arbeit ist, der kann mittlerweile auch im Amazon Marketplace vorgehärtete AMIs des CIS erwerben.

Kontrollierter Zugriff ins Internet von privaten Instanzen. Wie geht das?

Sollen EC2 Instanzen ohne öffentliche IP Adresse (im privaten Sub-Netz) den Zugang zum Internet erhalten, ist eine entpsrechende “network address translation” (NAT) Einheit notwendig. Entweder als entsprechende EC2 NAT-Instanz oder seit kurzem mittels dem lang ersehnten NAT-Gateway.

Damit ist der Weg frei für IP-Verbindungen wenn sie von der Instanz im privaten Sub-Netz aufgebaut werden ( initiate outbound connection). Der umgekehrte Weg, Datenverkehr von IP-Verbindungen die aus dem Internet aufgebaut (connection initiated from the internet) werden ist nicht möglich.

Welche Möglichkeiten gibt es nun, den Zugriff ins Internet von den privaten Instanzen weiter einzuschränken (z.B. bestimmte Internet-Domänen) um Risiken des Missbrauchs zu minimieren?

In der Praxis haben sich Proxy basierte Lösungen mittels Squid bewährt. Eine Beschreibung wie eine solche Lösung aussehen kann, wird in diesem Blog-Post “How to Add DNS Filtering to Your NAT Instance with Squid” vom AWS Security Blog gegeben.

Eine weitere Möglichkeit ist der Einsatz einer Sophos UTM Lösung.

Weitere Informationen und Einsatzbeispiele von Squid Proxy Instanzen in Amazon VPC’s sind in diesen Foren-Beiträgen nachzulesen.

 

AWS Jahresrückblick 2015

year-end

In 2015 hat AWS über 450 Ankündigungen zu neuen Features veröffentlicht. Als AWS Consultant muss man immer am Ball bleiben. Meine Erfahrungen mit den neuen Features und Services aus 2015 möchte ich im Folgenden zusammenfassen.

Ich habe die Ankündigungen in insgesamt neun Kategorien unterteilt (interessantesten Änderungen zuerst):

  • Rechenleistung
  • Speicher & Content Delivery
  • Analytics
  • Application Services
  • Datenbanken
  • Networking
  • Internet der Dinge
  • Entwickler & Management Tools
  • Sicherheit & Identität

Ich wünsche allen ein frohes neues Jahr 2016!

(mehr …)