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.

 

 

CloudWatch Custom Metrics

Old but good…

Da es leider noch keine eingebauten Metriken für CloudWatch gibt zu den Standards wie, z.B. Memory Utilization oder EBS Volume-Belegung, möchte ich an dieser Stelle an folgenden Artikel erinnern (natürlich aus aktuellen Anlass, ich habe es gerade erst selber benötigt …).

http://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/mon-scripts.html

  • Einfach einzurichten
  • Einfach zu nutzen
  • viele Einstellungsmöglichkeiten

Viel Spaß dabei!

tecRacer ist jetzt Trend Micro Deep Security Cloud Service Provider

TM_Partner_Portal_Logo_150319

Seit Anfang Mai ist tecRacer offizieller Trend Micro Deep Security Cloud Service Provider und verfügt über eine eigene mandantenfähige Deep Security Plattform, die wir unseren Kunden im Rahmen unseres AWS Managed Hosting oder anderen Kunden als SaaS Plattform zur Verfügung stellen.

Der Vorteil für unsere Kunden ist hierbei insbesondere:

  • das pro Server individuell gewählt werden kann, welches der Deep Security Module aktiviert werden soll und nur diese Module müssen dann entsprechend bezahlt werden
  • das die Deep Security Module pro 100-Stunden-Block pro Monat bezahlt werden, so dass auch bei Cloud AutoScaling- oder z.B. Test-Szenarien, bei denen Server nicht immer laufen, der Einsatz von DeepSecurity in diesem Preismodell wesentlich günstiger ist.

Deep Security bietet automatisierte und hoch skalierbare Cloud-Sicherheit:

  • Malware-Schutz mit Web Reputation zum Schutz vor häufig verwendeten Infektionsquellen
  • Überwachung von Datei- und Systemintegrität zu Compliance-Zwecken
  • Erkennung und Abwehr von Eindringlingen zur Abschirmung von ungepatchten Schwachstellen
  • Stateful-Firewall zur Bereitstellung einer anpassbaren Firewall für jeden einzelnen Server
  • Logüberprüfung zur Erkennung wichtiger Sicherheitsereignisse und Erstellung entsprechender Berichte

cloud-service-providers-address-requirements-en

Encrypt files in S3

Last time I wrote about encrypting EBS boot volumes, this week I will continue with the encryption as the main topic by writing about S3 encryption and since it could not have turned out any other way, we will use again KMS for that.

Files in S3 also can be encrypted by using KMS, providing an extra layer of security.
In the example I will use to explain it, I will use:

  • An EC2 instance
  • An IAM role (I will call it “sync”) attached to the EC2 instance
  • S3 Bucket  (I will call it „encrypted-sync“)
  • Key in KMS

Remember that to use roles for applications that run on Amazon EC2 instances instead of AWS credentials is an AWS best practice.

 

Use Case

Files in the server will synchronise with S3 every 5 minutes. The files will be encrypted in S3.

 

Graphical overview

 

Solution

As simple as our scenario: Just a command.

/usr/local/bin/aws s3 --region eu-central-1 sync --sse aws:kms --sse-kms-key-id 611g215z-a7j3-3c6f-g59e-f1e6f53b2et3 /data/ s3://encrypted-sync

 
Here a small explanation for some parts of the command:

--sse (string) Specifies server-side encryption of the object in S3.

--sse-kms-key-id (string) The AWS KMS key ID that should be used to server-side encrypt the object in S3.

 
In order that the synchronisation takes place every 5 minutes, you just need to create a cronjob.

 

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

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.