Default DNS-Server in AWS VPCs

AWS reserviert in jedem Subnetz die dritte IP (bei einer 24er Maske also die x.x.x.2) für Ihren DNS-Server. Sobald man mit Network ACLs arbeitet, geht man daher davon aus, dass die DNS-Queries innerhalb des Subnetzes der Instanz stattfinden. Allerdings findet sich versteckt in den Dokumentationen der Hinweis, dass es sich bei „Subnetz+2“ nur um eine Reservierung handelt, der DNS aber eigentlich auf „VPC+2“ liegt – selbst wenn dort überhaupt kein Subnetz konfiguriert ist.

Dieses Problem kann man elegant umgehen, indem der DNS Endpunkt auf dem lokalen Interface genutzt wird. Während die Existenz des Metadata-Services auf der 169.254.169.254 weithin bekannt ist, ist nämlich der DNS auf 169.254.169.253 eher unbekannt.

Bei Security Groups findet sich eine weitere Besonderheit im Zusammenhang mit DNS: Sofern man ausgehende Regeln explizit konfiguriert hat, ist der default DNS-Server implizit auch freigegeben – selbst wenn udp/53 nicht in den erlaubten Regeln vorhanden ist. Ein externer DNS Server, der z.B. im on-Premise Netzwerk steht, braucht allerdings eine explizite Freigabe.

 

Anpassen von Konfigurationsdateien mit Ausgabewerten von CloudFormation Stacks

Bei der Migration von Anwendungen auf AWS müssen auch die Konfigurationsdateien der Anwendungen angepasst werden.  Auch dabei gilt der Grundsatz „Automatisiere alles“. Doch wie kommen die Daten aus der neu auf AWS provisionierten Infrastruktur auf die Server? Hierzu ein paar Tipps zu CloudFormation und Anpassung von Konfigurationsdateien mit Shell Skripten. (mehr …)

Clouds – einfaches Management von CloudFormation Templates

Infrastruktur als Code ist eine (Heraus)Forderung von DevOps. Die Infrastrukturbeschreibungssprache von AWS heißt CloudFormation. Hat man sich erstmal eingearbeitet, greift man immer häufiger zum Texteditor statt zur Console, um AWS Ressourcen zu erstellen. Und eh man es sich versieht, hat man eine unüberschaubare Anzahl von Cloudformation Templates. Und dann steht man vor der Aufgabe, diese zu verwalten. Hier wollen wir ein paar Möglichkeiten dafür vorstellen.

(mehr …)

Call Center Service „Amazon Connect“ mit Lambda Integration – Alles möglich?

Call Center Service „Amazon Connect“ mit Lambda Integration

Connect ist der neue Service von AWS, in dem man einfach in der Cloud ein Call Center mit eigener Rufnummer erstellen kann. Mit einer grafischen Oberfläche kann man dann mit wenig Programmierkenntnissen eigene telefonische Abläufe erstellen, Anrufe auf S3 aufzeichnen, Statistik über Cloudwatch machen usw..

Alle telefonischen Agenten können vollständig mit einem Browser und Rechner ohne Telefonanschluss arbeiten. Hier stellen wir im Beispiel, vor wie Connect mit eigenen Lambda Funktionen zusammenarbeitet.

Dabei kann komplett dynamische Abläufe in der Anrufbehandlung erstellen. In Kürze wird dies mit Amazon lex auch mit tatsächlicher natürlicher Sprachsteuerung, also gesprochene Wörter möglich sein. Im Moment muss man immer noch auf Tastendrücke zurückgreifen.

In kurzer Zeit kann man Call Funktionen wie folgende in der Cloud realisieren:

Ein Anrufer mit Basis Support im Beispiel:

 

(mehr …)