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