Juli 2022
Das berüchtigte Sommerloch ist dieses Jahr auch bei Amazon spürbar und so geht ein verhältnismäßig ruhiger Monat in der AWS-Welt zu Ende. Dieser Blogbeitrag stellt einen Ausschnitt aus den Neuerungen und Ankündigungen des Monats Juli dar, erhebt aber nicht den Anspruch auf Vollständigkeit. Das Hauptaugenmerk liegt hierbei auf Veränderungen, bei denen wir von einem direkten Einfluss auf unsere Kunden ausgehen. In diesem Beitrag werden insbesondere Änderungen und Ankündigungen der Services Route 53, AWS EBS und den Security Groups vorgestellt.
Retirements
Eine honorable Mention an das EC2-Classic Network
Bereits im Sommer des Jahres 2006 hat Amazon die ersten EC2-Instanzen veröffentlicht. Im Vergleich zu den Dimensionen, die dieser Service heutzutage angenommen hat, waren die Anfänge des Services noch sehr einfach gehalten: Es gab lediglich eine Größe, welche auch nur in einer einzigen Region verfügbar war. Die Instanz wurde dann mit einem flachen Netzwerk verbunden, welches öffentliche IP-Adressen mit dem Launch der jeweiligen Instanz vergeben hat. Dieses Modell wird heutzutage im AWS-Universum als das „EC2-Classic network-model“ bezeichnet und wird nun allmählich in seinen verdienten Ruhestand übergehen.
Am 30. Oktober dieses Jahrs wird der Vertrieb von Instanzen mit dem EC2-Classic Network eingestellt und bis zum darauffolgenden August empfiehlt Amazon alle noch bestehenden EC2-Classic-Instanzen auf modernere, VPC-basierte Systeme zu migrieren. Dies betrifft neben den EC2-Instanzen selbst natürlich auch alle Services, die eine EC2-Instanz verwenden, wie beispielsweise RDS, Data Pipelines oder ElastiCache.
Diese Änderung bezieht sich lediglich auf Kunden, die Ihren AWS Account vor dem 4. Dezember 2013 angelegt haben. Neuere AWS-Accounts sind bereits VPC-Basiert und dementsprechend nicht von dieser Änderung betroffen, sofern keine explizite Support-Anfrage für den Erhalt einer solchen Instanz gestellt wurde.
Internet Explorer 11
Als Randnotiz sei an dieser Stelle erwähnt, dass Amazon in diesem Monat auch bekannt gegeben hat, dass AWS zukünftig nicht mehr den Internet Explorer 11 unterstützen wird. Bereits seit dem 31. Juli 2021 garantiert Amazon nicht mehr, dass die Management Konsole von AWS, sowie web-basierte Services wie Amazon Chime oder Honeycode, vollständig funktionsfähig sind bei der Verwendung von IE11.
Nutzer des Internet Explorer 11 können dieses Ärgernis natürlich einfach umgehen, indem sie auf einen moderneren, sichereren und schnelleren Browser der neuesten Generation zurückgreifen.
Networking
Route 53
Der hochskalierbare Domain Name System (DNS) Web-Service Amazon Route 53 wurde im Monat Juli mit dem Application Recovery Controller um ein weiteres Feature ergänzt, welches die hohe Verfügbarkeit von in AWS gehosteten Ressourcen weiter erhöht. Der Service erlaubt es, die Recovery-Fähigkeiten von Applikationen und Systemen zu monitoren und zu kontrollieren. Die Funktionsweise des Services basiert auf zwei Säulen: Readiness-Checks und Routing-Control.
Readiness Checks entsprechen einer regelmäßigen Überprüfung der definierten Konfigurationen, Kapazitäten und Netzwerk-Policies. Diese Checks sollen garantieren, dass das Recovery-Environment korrekt konfiguriert ist, falls es denn eingesetzt werden muss. Die Checks betreffen die Auto Scaling Groups, die EC2-Instanzen, die EBS-Volumes sowie Amazon RDS, DynamoDB Tabellen und diverse weitere Services.
Die zweite Säule, die sogenannten Routing Controls, sollen dabei unterstützen, dass der Traffic zwischen den Plattformen während des Recovery-Vorgangs ausbalanciert wird, sodass Endnutzer weiter auf die Applikation zugreifen können. Dies entspricht auch den bisherigen Health-Check Failovers, die mit Route 53 automatisiert werden können, allerdings sind Routing Controls tatsächlich eine Verbesserung jener.
Routing Control bietet die Möglichkeit, die gesamte Applikation automatisch auf eine stand-by Replica umzuschalten, wenn eine bestimmte Metrik, wie beispielsweise eine erhöhte Latenz, erfüllt ist. Neben dem automatischen Umschalten bietet die neue Routing Control auch die Möglichkeit, manuell auf die stand-by Replica zu wechseln und so zum Beispiel Wartungsarbeiten an der Applikation durchzuführen. Ein dritter Vorteil gegenüber den bisherigen Health-Check Failovers ist die Sicherheit, dass nicht auf eine unvorbereitete oder nicht voll-funktionsfähige Replica umgeschaltet wird, da durch die neuen Readiness Checks diese ja regelmäßig auf Funktionstüchtigkeit überprüft werden.
Das neue Feature ist ein globaler Service und somit überall verfügbar. Die Kosten, die für die Nutzung entstehen, sind on-demand, d.h. es entstehen Kosten für jeden durchgeführten Readiness Check sowie eine stundenbasierte Abrechnung für die Cluster.
Storage
AWS EBS
Der Elastic Block Storage von Amazon hat im Juli einen neuen Speichertypen erhalten. Bereits während der re:invent 2020 wurden die io2 Block Express Volumes angekündigt, aber erst jetzt sind sie im Stauts „Generally Available“ angekommen und somit für alle Nutzer – Zumindest in Kombination mit einer R5b-Instanz – verfügbar.
Die io2 Block Express Volumes zeichnen sich durch sehr hohe Schreib– und Leseraten aus und eignen sich somit optimal, um als Speichermedium einer Datenbank zu fungieren. Außerdem ist eine Latenz von unter einer Millisekunde bei der Kommunikation mit AWS Nitro basierten Instanzen möglich. Einige Eigenheiten sind bei der Nutzung der Volumes allerdings trotzdem zu beachten:
- Die Größe und die vorgegebenen IOPS können nicht mehr verändert werden
- Es können keine R5b Instanzen mit einer unverschlüsselten oder nur teilweise verschlüsselten AMI mit einer verschlüsselten io2 Block Express erstellt werden, die größer ist als 16 TiB oder mehr als 64000 IOPS verfügt. Sollte man eine solche Größe benötigen, muss zunächst die AMI vollständig verschlüsselt werden
- Io2 Block Express Volumes unterstützen zumindest zum derzeitigen Stand keine Snapshots
Wie Eingangs angemerkt, sind die io2 Block Express Volumes nun für alle Nutzer von AWS mit Standort Frankfurt verfügbar, allerdings nur in Kombination mit einer R5b-Instanz. Hinsichtlich der Kosten gelten dieselben Preise, wie bei den bisher verfügbaren io2-Instanzen und auch in Nutzungsberichten werden diese nicht unterschieden. Aus diesem Grund empfiehlt es sich, Tags zu verwenden, um eine eindeutige Zuordnung zu gewährleisten. Unter diesem Absatz ist auch noch einmal eine Tabelle verlinkt, die die verfügbaren SSDs miteinander vergleicht.
| General Purpose SSDs | Provisioned IOPS SSDs | |||
| Bezeichnung | gp2 | gp3 | io2 | io2 Block Express |
| Beständigkeit | 99.8–99.9% | 99.8–99.9% | 99.999% | 99.999% |
| Use-Case | Allgemeine Applikationen | Allgemeine Applikationen | I/O intensive Applikationen und Datenbanken | I/O intensive Applikationen und Datenbanken |
| Größe | 1 GiB – 16 TiB | 1 GiB – 16 TiB | 4 GiB – 16 TiB | 4 GiB – 64 TiB |
| Max. IOPS | 16000 | 16000 | 64000 | 256000 |
| Max. Throughput | 250 MiB/s | 1000 MiB/s | 1000 MiB/s | 4000 MiB/s |
Security
AWS Firewall Manager
AWS Firewall Manager ist ein Service zur Sicherheitsverwaltung. Mit ihm können Kunden Firewallregeln für Konten und Ressourcen innerhalb ihrer Organisation zentral konfigurieren und verwalten, das heißt es können Regeln für Services wie AWS WAF, AWS Shield Advanced, VPC Security Groups und Amazon Route 53 definiert werden, welche dann automatisch innerhalb der Organisation angewandt werden. Seit Juli erhalten Kunden nun auch Warnungen über Routen, die nicht der Konfiguration entsprechen.
Wie oben beschrieben stellt Firewall Manager in jedem VPC eine Netzwerkfirewall bereit, welche den Datenverkehr reguliert. Mit der neuen Version von AWS Firewall Manager können Kunden nun auch VPC Routen überwachen und den über Internet Gateway ausgehenden Datenverkehr untersuchen. Die Warnungen, die hierbei ausgegeben werden, informieren Nutzer des Services über nicht konforme Routenkonfigurationen wie beispielsweise Routen, die die Untersuchung durch die Firewall umgehen oder zu einem ungleichmäßigen Datenverkehr führen.
Security Groups
Einer der Hauptgründe für eine Migration in die Cloud, ist das vereinfachte Management von Ressourcen wie Servern, Speicher und auch Nutzern. Viele der Neuerungen, die im Rahmen dieser Beiträge von uns vorgestellt werden, sind entweder große Neuankündigungen oder kleine, aber feine Änderungen bestehender Services, die die Nutzererfahrung erheblich verbessern. Ein Beispiel für eine solche Änderung sind die neuen VPC Security Group Rule IDs.
Eine Security Group in einem VPC funktioniert wie eine Firewall für einen Service wie beispielsweise Amazon EC2 oder Amazon RDS, d.h. eine Security Group ist dafür verantwortlich, dass nur von bestimmten Netzwerken aus auf die Datenbank oder Applikation eines Nutzers zugegriffen werden darf und auch nur an bestimmte Netzwerke Daten transferiert werden.
Verwendet man die CLI von AWS oder kommuniziert über eine der APIs, so mussten bisher eine Vielzahl von Elementen angegeben werden, um eine Security Rule zu identifizieren. Dies hatte zur Folge, dass CLI-Commands und einzelne Code-Passagen unübersichtlich und lang geworden sind. Dies gehört aber nun mit den neuen Security Group Rule IDs der Vergangenheit an.
Die Security Group Rule IDs sind eindeutige Bezeichnung, die einer Regel einer Security Group zugewiesen wird. In diesem Zusammenhang veröffentlicht Amazon zusätzlich zwei neue APIs: ModifySecurityGroupRules und DescribeSecurityGroupRules, mit welchen zukünftig programmatisch APIs abgefragt und verändert werden können.
Wie Eingangs erwähnt ist dies eine der vielen kleinen Änderungen von Amazon. Nichtsdestoweniger vereinfacht sie die Nutzung von AWS und insbesondere der CLI. Die neuen IDs sind ab sofort für alle VPC Security Gruppen in allen kommerziellen AWS Regionen verfügbar und erzeugen keine zusätzlichen Kosten.
August 2021
Nach einem verhaltenem Monat Juli folgen zum Ende des Sommers im August einige spannende Änderungen seitens AWS. Dieser Blogbeitrag stellt einen Ausschnitt aus den Neuerungen und Ankündigungen des Monats August dar, erhebt aber nicht den Anspruch auf Vollständigkeit. Das Hauptaugenmerk liegt hierbei auf Veränderungen, bei denen wir von einem direkten Einfluss auf unsere Kunden ausgehen. In diesem Beitrag werden insbesondere Änderungen und Ankündigungen der Services Amazon SageMaker, AWS Lambda und CloudGuru vorgestellt.
Machine Learning
Amazon SageMaker Pipelines
Amazon SageMaker Pipelines ist ein speziell entwickelter Service zur CI/CD für Machine Learning Workflows, in welchem es seit August auch möglich ist, sogenannte LambdaSteps zu integrieren, die eine Lambda-Funktion als Schritt in der ML-Pipeline ausführen. Dies erlaubt es, beliebe Aufgaben und Aufträge innerhalb des Machine-Learning Workflows zu integrieren und so beispielsweise Datensätze aufzuteilen oder benutzerdefinierte Benachrichtigungen zu versenden. Zur Bereitstellung einer Lambda-Funktion kann entweder über die Konsole eine Funktion in einer beliebigen Sprache geschrieben werden oder als .zip-Datei der Code inklusive der kompilierten Programme und Abhängigkeiten bereitgestellt werden und SageMaker Pipelines erstellt automatisch eine neu Lambda-Funktion, die als Teil des LambdaSteps ausgeführt wird.
Asynchrone Inferenz von Amazon SageMaker
Um Inferenzen mit großer Nutzlast oder langen Verarbeitungszeiten zukünftig besser verarbeiten zu können, hat Amazon im August eine dritte Inferenzoption, nämliche die asynchrone Inferenz, veröffentlicht. Mit dieser werden eingehende Anfragen in einer Warteschlange gestellt und dann nacheinander verarbeitet. Workloads, die von dieser neuen Option profitieren, sind beispielsweise Vorhersagen von hochauflösenden Grafiken und Bildern und Workloads, die Antworten innerhalb von Minuten nach Erhalt der Anfrage bereitstellen müssen.
Die Asynchrone Inferenz von Amazon SageMaker ist in allen kommerziellen AWS Regionen verfügbar, in denen auch SageMaker selbst verfügbar ist, außer in Mailand, Kapstadt und Osaka.
Amazon CodeGuru Profiler
Das auf Machine-Learning basierende Entwickler-Tool Amazon CodeGuru Profiler dient Entwicklern dazu, das Laufzeitverhalten von Anwendungen zu verstehen, ineffiziente Codepassagen zu erkennen und so die allgemeine Leistung zu verbessern und Kosten zu senken.
Ein wichtiger Bestandteil des Profilers sind die Visualisierungen mit welchen Ineffizienzen grafisch aufgezeigt und Vergleiche zwischen verschiedenen Applikationen verdeutlicht werden können. Genau diese Visualisierungen haben im August eine weitere Vergleichsoption hinzugewonnen, welche das Anzeigen der Unterschiede zwischen verschiedenen Zeitabschnitten derselben Profilgruppe ermöglicht und so die Diagnose von Problemen einer Anwendung innerhalb eines spezifischen Zeitbereichs vereinfacht.
Neben den neuen Visualisierungsmöglichkeiten ist auch die Unterstützung für Python neu hinzugekommen zum Funktionsumfang des Services. Bisher wurden nur Empfehlungen für Java-basierte Applikationen erstellt, aber seit neuestem werden auch Python Applikationen, die auf Version 3.6 bis 3.9 basieren und auf einer EC2, einem Container oder AWS Lambda laufen, unterstützt.
Apropos Lambda-Funktionen: Auch im Zusammenspiel zwischen dem CodeGuru Profiler und AWS Lambda gibt es eine Änderung, denn der Profiler kann nun automatisch über die Lambda Konsole eingerichtet werden. Bisher musste bei der Profilerstellung mit CodeGuru für AWS Lambda ein mehrstufiger manueller Prozess durchlaufen werden, welche von der Erstellung einer Profilinggruppe über die Vergabe von Berechtigungen bis hin zum Setzen von Umgebungsvariablen reichte. All diese Schritte führt der CodeGuru Profiler nun automatisch aus und erleichtert so die Bereitstellung des Services.
AWS Lambda
Neben den oben bereits angesprochenen Änderungen rund um AWS Lambda, wurde der beliebte serverless-compute Service selbst auch angepasst. Eine der Ankündigungen, die veröffentlicht wurden, ist, dass AWS Lambda nun auch die Python Version 3.9 sowohl als verwaltete Laufzeit als auch als Container-Basis-Image unterstützt. Dies erlaubt es Kunden Lambda-Funktionen in Python 3.9 zu verfassen und somit von den neuen String- und Dictionary-Funktionen, der Binärschnittstelle für CPython und den allgemeinen Performance-Updates der neuesten Python-Version zu profitieren. Damit auch ältere Lambda-Funktionen früherer Python-Versionen von den Aktualisierungen profitieren können, muss der Code mit Python 3.9 kompatibel sein. Sollte dies der Fall sein, so muss nur die Funktionslaufzeit in den Einstellungen der Lambda-Funktion auf Python 3.9 geändert werden.
Amazon MemoryDB for Redis
Interaktive Applikationen müssen Anfragen schnell bearbeiten und beantworten können. Dies wird insbesondere dann deutlich, wenn man eine Architektur betrachtet, die auf Microservices basiert, also auf verhältnismäßig kleinen, unabhängigen Services, die alle miteinander vernetzt sind.
Um eine schnelle Kommunikation zwischen den Systemen zu ermöglichen, ist eine performante Datenbank notwendig, welche im Optimalfall über einen in-memory Cache verfügt, um so die Latenz bei Lesezugriffen möglichst gering zu halten. Für diesen Cache greifen viele Entwickler auf den open-source in-memory Data-Structure-Store Redis zurück.
Auch Nutzer der AWS konnten bisher schon davon profitieren, indem sie beispielsweise ElastiCache for Redis verwendet haben, einem fully-managed in-memory Caching-Service, der als Fassade von Amazon Aurora oder Amazon DynamoDB eingesetzt werden kann. Um diese Architektur zu erzielen, mussten Entwickler aber selbst Code innerhalb einer Applikation schreiben, um den Cache des Systems in Synchronisation zur Datenbank zu halten.
Um dies zu umgehen, hat AWS nun Amazon MemoryDB for Redis vorgestellt. Dies ist eine mit Redis kompatible In-Memory Database, welche die oben beschriebene Architektur ablösen soll. Bei der Verwendung von MemoryDB werden alle Daten in-memory gespeichert und sind ohne praktisch ohne Latenz verfügbar.
Bisher ist Amazon MemoryDB in Europa lediglich in Irland verfügbar, allerdings sollen weitere Standorte in naher Zukunft hinzukommen.
Monitoring
Amazon CloudWatch
Auch für einen der wichtigsten Services in der AWS gab es einige Ankündigungen und Neuerungen im vergangenen Monat. Zum einen wurde angekündigt, dass CloudWatch Logs zukünftig CloudWatch-Nutzungsmetriken unterstützt, sodass die CloudWatch-Logs-API-Nutzung überwacht werden kann. Dies erlaubt es beispielsweise Alarme zu erstellen, die eine Benachrichtigung versenden, wenn ein Servicekontingent erreicht wird.
Eine zweite Ankündigung, die Amazon CloudWatch betrifft, ist, dass zukünftig kontoübergreifende Alarme erstellt werden können. Kontoübergreifende Alarme bieten die Möglichkeit, Warnmeldungen auf der Grundlage von Metriken aus verschiedenen AWS-Konten zu erstellen und diese in einem kontoübergreifenden Dashboard zu visualisieren, um so operative Transparenz in einem zentralen Überwachungskonto einzurichten.
Ein Anwendungsfall könnte ein zentrales AWS-Konto sein, welches dazu genutzt wird, mehrere AWS-Konten, auf denen Produktionsanwendungen installiert sind, zu überwachen. Über diese Konten hinweg könnte ein Alarm definiert werden, der beispielsweise die maximale CPU-Auslastung aller EC2-Instanzen überwacht und eine Benachrichtigung verschicken, wenn ein gewisser Schwellenwert überschritten wird. Durch die Zentralisierung des Monitorings können die Applikationen einfacher überwacht werden und Kausalitäten leichter erkannt werden.
Kontoübergreifende Alarme sind in allen AWS Regionen verfügbar und es fallen lediglich die Standardpreise für CloudWatch-Alarme an.
September 2021
Durch die Storage-Days zu Beginn des Monats steht der September nahezu gänzlich im Zeichen der verschiedenen Speicher-Services der AWS. Dieser Blogbeitrag stellt einen Ausschnitt aus den Neuerungen und Ankündigungen des Monats September dar, erhebt aber nicht den Anspruch auf Vollständigkeit. Das Hauptaugenmerk liegt hierbei auf Veränderungen, bei denen wir von einem direkten Einfluss auf unsere Kunden ausgehen. In diesem Beitrag werden insbesondere Änderungen und Ankündigungen der Services Amazon S3, AWS EFS und Amazon MSK vorgestellt.
Storage
Wie in der Einleitung bereits angemerkt, fand im September der inzwischen dritte jährliche AWS Storage Day statt. Der Storage Day ist – wie die re:invent auch – ein Event, an dem eine Vielzahl von Neuerungen und Ankündigungen bekannt gegeben werden. Im Gegensatz zu der re:invent liegt bei den Storage Days der Fokus allerdings ausschließlich auf den Speicher-Services der AWS Cloud.
Amazon S3
Für den Objektdatenspeicher S3 wurden zwei interessante Verbesserungen angekündigt. Die erste Verbesserung bezieht sich auf das Intelligent Tiering von AWS und den damit verbundenen Kosteneinsparungen. Die Zweite ist die Ankündigung von sogenannten Multi-Region Access Points, die die Performance von Anwendungen verbessern soll, die über mehrere Regionen hinweg verfügbar sind.
Das Amazon S3 Intelligent-Tiering ist im Jahre 2018 von Amazon eingeführt worden, um Daten basierend auf ihren Zugriffsschemata dynamisch zwischen verschiedenen Storage-Tiers zu bewegen. Zur Verwendung des Intelligent Tierings mussten die Daten nur zwei Voraussetzungen erfüllen: Zum einen müssen die Dateien größer als 128KB sein und zum anderen mindestens 30 Tage gespeichert werden. Für die zukünftige Verwendung des Services gestaltet sich dies nun etwas anders: Währen der Storage Days hat AWS verkündet, dass zukünftig keine Überwachungs- und Automatisierungsgebühren für Objekte anfallen, die kleiner als 128KB sind und auch die Mindestspeicherdauer von 30 Tagen entfällt. Dies erlaubt es nun auch Daten in das Intelligent Tiering einzuordnen, deren Zugriffsmuster und Größe (noch) nicht bekannt sind, was der Verwendung in einem auf S3 aufbauenden Data Lake entgegenkommt.
Die Änderungen betreffen nicht nur neu-erstellte, sondern auch bereits vorhandene Objekte und sind in allen AWS Regionen verfügbar.
Die zweite Bekanntgabe für AWS S3 während der Storage Days ist die Ankündigung sogenannter Multi-Region Access Points, die die Performance von Anwendungen verbessern soll, die über mehrere Regionen hinweg verfügbar sind. Bereits zuvor war es möglich, Endnutzern Applikationen mittels Funktionen wie den Global Tables von DynamoDB, dem Global DataStore von ElastiCache oder der Cross-Region-Replication von Amazon S3 zur Verfügung zu stellen. Bisweilen brachte dies allerdings den Nachteil mit sich, dass Code-Passagen an die einzelnen Regionen angepasst werden mussten und häufig genau beobachtet werden musste, welche Ressourcen wann zum Tragen kamen. Als Beispiel kann man eine Applikation betrachten, die auf drei S3-Buckets mit Cross-Region-Replication in drei verschiedene AWS Regionen basiert. Die Applikation muss nun zu jedem Zeitpunkt wissen, wie viele Kopien der Buckets existieren, wo diese liegen, welche davon der geografisch am nächsten Gelegene ist und was im Falle eines Fallbacks passiert. Im Falle von lediglich drei Regionen ist dies noch mehr oder weniger überschaubar. Steigt allerdings die Anzahl an Regionen, so steigt auch die Komplexität der Applikation und ihres Quellcodes ungemein.
Aus dieser Motivation heraus sind die neuen Multi-Region Access Points entstanden, welche auf den AWS Global Accelerator aufsetzen und Abfragen von S3 über das AWS Global Network leiten. Durch die Verwendung des Global Accelerators von AWS kann die Verfügbarkeit einer Region konstant überwacht werden und im Falle eines Ausfalls können Anfragen binnen Sekunden in eine andere Region ausgelagert werden.
Die neuen Multi-Region Access Points können in der Konsole, über die CLI oder die SDK eingerichtet werden und sind bisweilen in 17 Regionen verfügbar – Frankfurt, Irland, London, Paris und Stockholm eingeschlossen. Zusätzlich zu den normalen Kosten für die Nutzung von S3 entstehen Kosten für das Routing der Daten in Höhe von 0,0033$ pro GB sowie weitere Transferkosten, wenn die Daten das öffentliche Internet passieren.
Amazon EFS
Ähnlich wie AWS S3 bietet auch EFS verschiedene Storage Tiers an, um Daten kosteneffizient zu speichern und bietet, ebenfalls wie S3, die Möglichkeit, Daten mittels Lifecycle Management nach einer bestimmten Zeit der nicht-Nutzung in ein kälteres Tier zu verschieben. Dieses Vorgehen birgt allerdings eine Krux: Durch die Verschiebung der Daten in eine kältere Storage Tier entstehen geringere Kosten für das Speichern der Daten, allerdings höhere Kosten für die Abfrage eben jener. Sollte sich also das Abfrageverhalten der Nutzer ändern und die Daten werden nun häufiger abgefragt, so können unerwünscht Kosten entstehen. Aus dieser Überlegung heraus ist bereits das AWS S3 Intelligent Tiering entstanden und nun wurde während der Storage Days auch das EFS-Pendant vorgestellt. Wie oben beschrieben, können Daten automatisch in ein kälteres Storage-Tier verschoben werden. Sollte sich allerdings nun das Abfrageverhalten ändern, so können mittels EFS Intelligent Tiering die Daten wieder in ein wärmeres Tier zurückgeschoben werden und die Kosten bei der Nutzung von Amazon EFS optimiert werden.
EFS Intelligent Tiering ist ab September 2021 in allen Regionen verfügbar, in denen auch Amazon EFS verfügbar ist.
Compute
Amazon EKS Anywhere
Bereits währen der re:invent des vergangenen Jahres wurde sowohl ECS Anywhere als auch EKS anywhere angekündigt. Seit September 2021 ist nun EKS Anywhere frei verfügbar und bietet eine Option, wenn man Kubernetes gestützt von AWS EKS in seinem eigenen on-premises Data Center nutzen möchte. Am Ende des Absatzes befindet sich eine Tabelle, die eine Übersicht über die Unterschiede der verschiedenen Angebote beinhaltet.
| Feature | Amazon EKS | EKS on Outpost | EKS Anywhere | EKS Distro |
| Hardware | Managed by AWS | Managed by AWS | Managed by customer | Managed by customer |
| Deployment types | Amazon EC2, AWS Fargate (Serverless) | EC2 on Outposts | Customer Infrastructure | Customer Infrastructure |
| Control plane management | AWS-Managed | AWS-Managed | Self-Service | Self-Service |
| Control plane location | AWS Cloud | AWS Cloud | Im eigenen Data Center | Im eigenen Data Center |
| Cluster updates | Managed in-place update process for control plane and data plane | Managed in-place update process for control plane and data plane | CLI (Flux unterstützt rolling Updates für data plane, manuelle updates für control plane) | CLI (Flux unterstützt rolling Updates für data plane, manuelle updates für control plane) |
| Networking and Security | CNI + third-party CNI Plugins | CNI + third-party CNI Plugins | Cilium CNI | Third-party CNI plugins |
| Console support | Amazon EKS console | Amazon EKS console | EKS Console (EKS Connector | Self-service |
| Support | AWS Support | AWS Support | EKS Anywhere support subscription | Self-service |
Machine Learning
Amazon QuickSight Q
Geschäftsdaten auf nützliche Informationen zu untersuchen, kann eine komplexe und zugleich sehr wertvolle Aufgabe sein. Mit QuickSight stellt Amazon ein stark skalierbares BI-Tool zur Verfügung, welches über die Jahre konstant erweitert und verbessert wurde. Die aktuellste Verbesserung ist das sogenannte QuickSight Q, welches bereits im Dezember präsentiert wurde, nun aber frei verfügbar ist.
QuickSight Q ist ein Natural-Language-Query-Tool, welches für die Enterprise Edition von Amazon QuickSight verfügbar ist. Trainiert wurde das zugrundeliegende Modell mit dem Wortschatz und Fragestellungen verschiedener Domänen – wie beispielsweise Sales, Marketing oder Human Resources -, sodass QuickSight Q in der Lage ist, Fragen aus diesen Branchen basierend auf den Datenquellen, die von QuickSight unterstützt werden, zu beantworten.
QuickSight Q ist seit September für alle Kunden mit Standort Frankfurt, Irland, Ohio, Oregon, North Virginia und London verfügbar, allerdings wird zum Release zunächst nur die englische Sprache unterstützt.
Streaming
Amazon MSK
Kafka Connect ist eine Open-Source Komponente von Apache Kafka, die die Verbindung zu externen Systemen wie Datenbanken, Key-Value-Stores und Filesystemen erlaubt. Die benötigte Infrastruktur, um ein Kafka Connect Cluster zu betreiben, musste bisweilen selbst gemanaged und skaliert werden. Dies soll zukünftig mit Amazon MSK Connect umgangen werden können. Amazon MSK Connect stellt nicht nur die benötigten Ressourcen zur Verfügung und verwaltet diese, sondern betreibt auch ein kontinuierliches Monitoring des Systems und skaliert die Konnektoren automatisch, um auf Lastspitzen zu reagieren.
Weiterhin ist MSK Connect vollständig kompatibel mit Kafka Connect, sodass bereits bestehenden Konnektoren ohne Code-Änderungen migriert werden können. Neben Apache Kafka selbst unterstützt MSK Connect auch Amazon MSK, also das fully-managed Pendant zu Kafka von Amazon, sowie weitere 3rd-Party Clusters als Quell- und Zielort.
In Europa ist MSK Connect in Frankfurt, Irland, London, Paris und Stockholm verfügbar. Preislich orientiert sich der Service am pay-as-you-go Konzept. Genau Preiskonstellationen können den Pricing-Tabellen zu Amazon MSK entnommen werden.
Für weitere regelmäßige Updates zum Thema AWS Cloud, folgen Sie unserer Präsenz auf Xing und Instagram oder direkt unserem Blog.
