AWS VPC S3-EndPoint vs. NAT-Instanz Performance

In einem VPC hat man die Möglichkeit private Subnetze einzurichten. EC2-Instanzen in den privaten Subnetzen können nur mit dem Internet kommunizieren (S3 ist aus Sicht des VPC Internet), wenn man eine sogenannte NAT-Instanz in einem Public-Subnet hat, die den Traffic entsprechend aus den privaten Subnetzen entgegen nimmt und in das Internet weiter routet.

Das Problem der NAT-Instanz ist allerdings, das man i.d.R. einen Single-Point of Failure hat und zum anderen die NAT-Instanz auch eine Perfomance-Bremse sein kann.

Seit kurzem bietet nun AWS im VPC neue Endpoints an, die es EC2-Instanzen in einem privaten Subnetz ermöglichen, direkt mit S3 in der Region zu sprechen.

Hier mal ein kurzer Performance-Test, bei dem wir eine Kommunikation mit S3 über NAT vs. des neuen Endpoints getestet haben:

Instanztyp für NAT und WebServer: t2.Micro (Network Low/moderate)

Über NAT Instance
Before | After fine Tuning
Über S3 Endpoint
Before | After fine Tuning
Upload Time (1) & CPU 41 sec (24MB/sec) | 20 sec (51MB/sec) 20 sec (51MB/sec) | 17 sec (60MB/sec)
Upload Time (2) & CPU 43 sec (23MB/sec) | 19 sec (53MB/sec) 19 sec (53MB/sec) | 17 sec (60MB/sec)
Upload Time (3) & CPU 40 sec (25MB/sec) | 20 sec (51MB/sec) 18 sec (56MB/sec) | 17 sec (60MB/sec)

 

Instanztyp für NAT und WebServer: m4.xlarge (Network high)

Über NAT Instance
Before | After fine Tuning
Über S3 Endpoint
Before | After fine Tuning
Upload Time (1) & CPU 17 sec (60MB/sec) | 17 sec (60MB/sec) 16 sec (64MB/sec) | 16 sec (64MB/sec)
Upload Time (2) & CPU 17 sec (60MB/sec) | 17 sec (60MB/sec) 16 sec (64MB/sec) | 16 sec (64MB/sec)
Upload Time (3) & CPU 17 sec (60MB/sec) | 17 sec (60MB/sec) 17 sec (60MB/sec) | 16 sec (64MB/sec)

Der Test wurde mit der AWS CLI durchgeführt. Für das Finetuning haben wir folgende Parameter bei der CLI eingestellt:

Folgenden Commands auf dem WebServer gelaufen und danach die Tests noch mal gemessen:

  • $ aws configure set default.s3.max_concurrent_requests 20 (Default is 10)
  • $ aws configure set default.s3.max_queue_size 10000 (Default is 1000)
  • $ aws configure set default.s3.multipart_threshold 64MB (Default is 8)
  • $ aws configure set default.s3.multipart_chunksize 16MB (Default is 8)

Amazon AWS RDS Datenbank im VPC aus dem Internet erreichbar machen …

Eigentlich will man das genau nicht. Eine Amazon RDS Datenbank im VPC soll eigentlich ja nur aus dem VPC heraus erreichbar sein … aber gerade beim Import von Daten möchte man gerne die Tools auf seinem Arbeitsplatz Rechner nutzen und am liebsten temporär direkt gegen die Datenbank konnektieren ….

Nun, das geht über einen kleinen Trick. Eine Amazon RDS Datenbank im VPC bekommt ein eigenes Network-Interface mit einer lokalen IP-Adresse aus einem entsprechenden Subnets. Kann man sich in der AWS Consule unter EC2 / Network Interfaces ansehen:

Nun kann man diesem RDSNetwork-Interface auch eine Public IP Adresse zuweisen. Man mmacht diese wie folgt:

  • EC2 / Elastic IPs –> Allocate New Address –> in der ComboBox VPC auswählen
  • EC2 / Elastic IPs –> neue IP anklicken –> Associate Address  –> in der Dialog Box dann unter Network Interface die ID des Network Interfaces der RDS Instanz auswählen.
  • Danach unter EC2 / Network Interfaces schauen, ob die Public IP korrekt unserem RDS Network Interface zugewiesen wurde.

Jetzt muss nur noch in der entsprechenden RDS-Security Group der Port für einen ZUgriff aus dem Internet geöffnet werden:

  • EC2 / Security Groups –> In der ComboBox „VPC Security Groups“ auswählen –> und dann in der entsprechenden RDS-Security Group den Datenbank-Port (z.B. 3306 oder 1433) für 0.0.0.0/0 öffnen.  Am besten das Ganze auf eine öffentliche IP beschränken und das Ganze sowieso nur TEMPORÄR für Admin-Zwecke machen!

 

Amazon VPC VPN-Verbindungen

Im Rahmen von einigen kürzlich durchgeführten Kunden Projekten haben wir zahlreiche VPN-Anbindungen an Amazon AWS VPCs durchgeführt. Hier ein paar Infos und Erfahrungswerte zu VPNs:

  • Amazon VPC kann zur Zeit nur VPN-Tunnels mit einer Verschlüsselung von 128-Bit durchführen (AES128), AES256 ist auf der Roadmap.
  • eine VPN-Verbindung besteht immer aus 2 Tunnel (Redundanz)
  • eine VPN-Verbindung kostet 0,05 USD pro VPN-Verbindungsstunde, dazu kommen dann noch die normalen Datentransfer-Gebühren
Es werden inzwischen zahlreiche VPN-Devices unterschiedlicher Hersteller unterstützt. Neu ist, dass auch direkt Windows 2008R2 oder normale IPSec-fähige Devices unterstützt werden. Um Details zur Konfiguration der IPSec-Devices herauszufinden, muss man für den Vendor „Generic“ einfach nur die Konfigurationsdaten herunterladen und dort dann die entsprechenden Informationen wie Pre-Shared Secret etc. entnehmen.
Amazon AWS hat kürzlich ein sehr gutes übersichtliches Whitepaper zum Thema VPN veröffentlicht:

AWS_Amazon_VPC_Connectivity_Options

Man kann natürlich auch anstelle der normalen Amazon VPC VPN-Möglichkeiten entsprechende Tools von Drittanbietern wie z.B. Checkpoint nutzen. Checkpoint bietet im Amazon AWS Marketplace eine fertige Software-Appliance an, die man in seinem Account als EC2 Instanz startet und dann konfiguriert. Der Preis für die Nutzung beträgt für die CheckPoint-Appliance  zwischen 0,08 bis 0,18 USD pro Stunde zzgl. der entsprechenden Amazon EC2 Instanzgebühr.

Dokumentation der CheckPoint Security Gateway Virtual Appliance R75 for Amazon Web Services VPC

Amazon AWS VPC mit mehreren Public-Subnets für ein Multi-AZ Szenario

Amazon AWS VPC bietet viele Vorteile und kostet nichts zusätzlich. Vorteile sind insbesondere:

  • Ec2-Instanzen können eine dauerhafte private IP-Adresse des Subnets bekommen (auch bei Stop der Instanz)
  • EC2-Instanzen können eine dauerhafte public (Elastic-IP) IP-Adresse bekommen (auch bei Stop der Instanz)
  • EC2 Security Gruppen innerhalb eines VPCs haben Inbound- und Outbound Regeln

Allein die dauerhaften privaten IP-Adressen sind schon bei bestimmten Szenarien Gold wert.

Will man mit VPCs ein Multi-AZ Szenario umsetzen, so dass ein Load-Balancer zwischen Instanzen in zwei unterschiedlichen AZs (Availability-Zonen) verteilt, stellt man zunächst fest, das ein Subnet einer VPC immer genau einem AZ zugeordnet werden muss. Die Standard Assistenten des VPCs erstellen aber immer nur ein Public Subnet … gehen denn auch mehrere Public Subnets?

Ja und zwar ganz einfach. Man erstellt einfach von Hand ein neues Subnet innerhalb eines bestehenden VPCs. Dann achtet man darauf, dass dieses neue Subnet dem gleichen Route-Table des bestehenden Public-Subnets zugewiesen wird. Dann nutzt auch diese neue Subnet das Internet-Gateway … fertig … und man hat 2 Public-Subnets.

 

 

Neu: Interne Load-Balancer in einem VPC-Szenario

Endlich … just hat Amazon AWS folgendes neue Feature released (auch in der Region EU) … im Rahmen eines VPC-Szenarios können nun auch interne Load-Balancer definiert werden.

Interne Load-Balancer braucht man, wenn man die Backend-Server auch über einen Load-Balancer optimal von den Frontend-Servern ansteuern möchte. Die Frontend-Server haben dann einen Load-Balancer, der aus dem Internet die Anfragen entsprechend auf die Frontend-Server verteilt und der interne Load-Balancer verteilt die Anfragen der Frontend-Server entsprechend an die Backend-Server. Super Sache … und vor allem sehr einfach im Rahmen einer VPC auf Amazon AWS zu implemetieren.

Mehr Details auch hier: http://aws.typepad.com/aws/2012/06/internal-elastic-load-balancers.html und hier: http://docs.amazonwebservices.com/ElasticLoadBalancing/latest/DeveloperGuide/UserScenariosForVPC.html

Amazon RDS VPC Support für SQLServer und Oracle … via Workaround

Amazon RDS bietet seit neuestem ja auch Microsoft SQLServer 2008 an. Oracle hatte ich mir bisher bei Amazon RDS noch nicht richtig angeschaut. Von MySQL und vor allem aus den Menüpunkten der AWS Console wusste ich, dass man Amazon RDS auch prinzipiell an ein VPC Subnet konnektieren kann.

Leider ist zur Zeit ausschliesslich für Amazon RDS  MySQL Instanzen eine Anbindung an ein VPC Subnet möglich. Somit können all die Enterprise Kunden, die alle eigentlich VPCs mit private und public  Subnets nutzen, eine Anbindung von z.B. einem Application-Server innerhalb des private Subnets an Amazon RDS SQLServer oder Oracle Instanzen nicht möglich. Alle Optionen für die Zuweisung von DBSecurityGroups, die einem VPC  zugeordnet sind, zu einer DB-Instanz fehlen in der AWS Console und sind nur bei MySQL-Instanzen verfügbar.

Nach etwas längerem Nachdenken und Ausprobieren habe ich einen Workaround gefunden, da unser Kunde unbedingt Amazon RDS SQLServer in Verbindung mit seinem VPC nutzen möchte …

Man gibt einfach der entsprechenden EC2-Instanz im Private-Subnet eine 2 Netzwerkkarte. Diese 2. Netzwerkkarte ist dann dem Public-Subnet zugeordnet und erhält eine Elastic-IP und eine entsprechende Security-Group, die Outbound 1433 zuläßt. Dann erlaubt man nur noch in der entsprechenden DBSecurity-Group in Amazon RDS den Zugriff von der entsprechenden Elastic-IP Adresse der 2. Netzwerkkarte. War doch ganz einfach.

Und das Gute ist vor allem, dann wenn dann der VPC-Support für Amazon RDS bei Oracle und SQLServer Instanzen kommt, dann kann man ganz einfach umstellen, da man nur die 2. Netzwerkkarte wieder entfernen muss und einiges in den DBSecurity-Groups umstellen muss …

Vorteile einer VPC für den Schutz von EC2-Instanzen

Viele Amazon AWS Kunden nutzen ihre EC2 Instanzen ohne ein VPC … und schützen Ihre EC2 Instanzen ausschließlich über EC2-Security Groups … das ist soweit ok, aber man kann es natürlich unter Einsatz einer Amazon AWS VPC besser machen … denn durch eine Amazon AWS VPC, die übrigens nichts groß extra kostet, kann man ein höheres Maß an Sicherheit erreichen.

Am besten für die meisten Anwendungsfälle ist eigentlich da Szenario bestehend aus einem Public- und einem Private-Subnet in einer VPC.

In diesem gängigen Szenario kommen die aus dem Internet erreichbaren Server (i.d.R. WebServer) in das Public-Subnet. Alle sonstigen Backend-Server kommen in das Privat-Subnet und sind somit aus dem Internet nicht erreichbar und somit zusätzlich geschützt. Damit die Server im Privat-Subnet aber auf z.B. Windows Updates zugreifen können, erfolgt ein Zugang über den Umweg über eine spezielle NAT-Instanz.

(mehr …)