Über unsMediaKontaktImpressum
Dennis Kieselhorst & Wladislaw Mitzel 30. März 2021

AWS Cloud-Umgebungen einfach und sicher verwalten

Um wettbewerbsfähig zu bleiben, müssen Unternehmen schneller und effizienter als je zuvor arbeiten und gleichzeitig die Kontrolle über Kosten, Compliance und Sicherheit behalten. Die IT steht unter dem Druck, Infrastruktur, Prozesse sowie Architekturen zu vereinfachen und Entwicklern die Möglichkeit zu geben, agiler zu sein. Mit herkömmlichen Ansätzen und Tools ist das nicht zu erreichen und IT-Experten müssen daher immer zwischen geschäftlicher Agilität und Governance-Kontrolle abwägen. In diesem Artikel wird beschrieben, wie mithilfe von AWS Management- und Governance-Services beides erfüllt werden kann. Weiterhin gibt der Artikel Anregungen, um eine "Well-Architected"-Umgebung basierend auf etablierten Best Practices zu erstellen. In dieser können Sicherheits-, Betriebs- und Compliance-Regeln zur Steuerung von Workloads auf der Amazon Web Services (AWS) Plattform verwaltet werden.

Ein Workload in der Cloud ist schnell erstellt: Nach der Accountregistrierung kann beispielsweise ein existierendes Image (eines Servers oder Containers) genutzt werden und so ist innerhalb von Minuten die erste Anwendung verfügbar. Entwicklungsteams freuen sich über diese Möglichkeit, da sie so schnell und agil testen und experimentieren können. Die Kollegen mit Betriebs- und Sicherheitsfokus wünschen sich allerdings einen definierten Rahmen und Kontrollmöglichkeiten und sehen durch die Cloud mögliche Probleme auf sie zukommen.

Häufig wächst eine auf diese Weise erstellte Umgebung schnell an und immer mehr Personen arbeiten mit dem entsprechenden AWS-Account. Prinzipiell können natürlich viele verschiedene Workloads in einem AWS-Account genutzt werden. Üblicherweise sind aber mehrere Teams an Entwicklung und Betrieb beteiligt und arbeiten jeweils an unterschiedlichen Systemen oder Projekten. Je nach Workload können auch unterschiedliche Isolationsgrade erforderlich sein (bspw. bei der Handhabung von Kreditkartendaten oder sensiblen Gesundheitsdaten). In diesem Zusammenhang wird auch vom "Blast Radius" gesprochen: welche Systeme könnten bei einem Ausfall oder der Fehlkonfiguration eines Workloads in Mitleidenschaft gezogen werden? In größeren Unternehmen haben einzelne Organisationseinheiten teilweise angepasste Prozesse. Zuletzt ist auch noch relevant, welche Kosten für einzelne Produkte und/oder Lösungen anfallen, um eine interne Verrechnung vornehmen zu können.

Erfahrene AWS-Nutzer werden nun denken, dass eine solche Isolation auch sehr einfach in einem AWS-Account mit Hilfe der Dienste AWS Identity- und Access Management (IAM) und mehreren separierten Amazon Virtual Private Clouds (VPCs) erledigt werden kann. Das ist möglich, schafft allerdings keine klare, eindeutige Abgrenzung. So ist der anfallende Datenverkehr nicht problemlos einer Anwendung zuzuordnen, eine etwaige Weiterberechnung beispielsweise auf Kostenstellenbasis wird erschwert. Mitarbeiter aus unterschiedlichen Teams können sich unter Umständen "gegenseitig auf den Füßen" stehen. Über die Zeit wird die aufgesetzte Umgebung komplizierter und unaufgeräumter, weil keine klare Zuständigkeit vorhanden ist.

Dementsprechend empfiehlt es sich, eine Aufteilung auf mehrere AWS-Accounts vorzunehmen: Kosten können so pro Account einfacher zugeordnet werden, die Seiteneffekte zwischen verschiedenen Workloads werden minimiert und die Sicherheit erhöht, da sich die notwendigen Berechtigungen auf kleinere Teile des Gesamtsystems beschränken. Wenn diese grundsätzliche Richtung festgelegt wurde, müssen alle AWS-Accounts entsprechend konfiguriert werden und sollten eine gemeinsame Sicherheits-Baseline als Basis haben.

Doch eine Aufteilung der Infrastruktur in mehrere AWS-Accounts schafft auch neue Herausforderungen, die vorher nicht oder in geringerer Ausprägung vorhanden waren: Wie schafft man es, den Überblick über die Aktivitäten in mehreren AWS-Accounts zu behalten? Wie sorgt man dafür, dass Sicherheitsrichtlinien in allen AWS-Accounts umgesetzt werden? Und natürlich muss dabei eine Kostenkontrolle über alle AWS-Accounts hinweg umgesetzt werden. Bei diesen Herausforderungen unterstützen die AWS Management und Governance Services.

AWS Management und Governance Services

AWS stellt eine Vielzahl von Services bereit, um Management und Governance zu unterstützen. Abb. 1 zeigt einige Beispiele, aufgeteilt in die Phasen Enable (initiale Aktivierung), Provision (Provisionierung/ Bereitstellung) und Operate (Betrieb). Ziel ist dabei immer schnelle Innovation und Agilität parallel mit der nötigen Kontrolle über Kosten, Compliance und Sicherheit zu ermöglichen, damit sich AWS-Nutzer nicht für eine Seite entscheiden müssen.

Der maßgebliche Service, der im weiteren Verlauf dieses Artikels betrachtet wird, ist AWS Control Tower. Dieser Service kapselt und orchestriert zahlreiche weitere Services, wie beispielsweise AWS Organizations, AWS Single-Sign On und AWS Service Catalog.

Landing Zone

AWS Control Tower unterstützt beim Aufsetzen einer sogenannten Landing Zone. Dabei handelt es sich um ein generelles, nicht AWS-spezifisches Konzept welches als Ausgangspunkt für den Start in die Cloud genutzt wird. Eine Landing Zone ist eine vorkonfigurierte, skalierbare und flexible Umgebung, welche im übersetzten Sinne den Start- und Landeplatz für eine Cloudmigration oder -anwendungsentwicklung bietet und damit Grundlage für Agilität und Innovation ist.

Bereits bevor AWS Control Tower 2019 ins Leben gerufen wurde, gab es mit der AWS Landing Zone Solution die Möglichkeit, eine Landing Zone zu automatisieren und so eine Multi-Account-Strategie umzusetzen. Bei der Solution handelt es sich allerdings um eine codebasierte Lösung, die von jemandem (dem Kunden selbst oder einem Dritten) verwaltet und gewartet werden muss. AWS Control Tower ist im Vergleich dazu ein Managed Service für eine Landing Zone, der die Konzepte aus der Solution verwendet, aber mit wenigen Klicks aufgesetzt und später ebenso aktualisiert werden kann. Abb. 2 zeigt den Einrichtungsbildschirm, der zum Start nur eine Regionsauswahl und zwei weitere E-Mail-Adressen benötigt, um die Landing Zone einzurichten. Regionen sind bei AWS derzeit 25 geographische Standorte, an denen Rechenzentrumscluster betrieben werden. Zehn dieser Regionen stehen aktuell für AWS Control Tower als mögliche Heimatregion zur Verfügung, darunter auch Frankfurt (eu-central-1). Als Primär- oder Heimatregion wird dabei die Region bezeichnet, die bei der Einrichtung einer Landing Zone ausgewählt wird. Dies hat unter anderem Einfluss darauf, wo Protokolldateien (Logs) aus den verschiedenen AWS-Accounts gespeichert werden.

AWS Control Tower als zentraler Ausgangspunkt

Die Bestandteile dieser initialen AWS Control Tower Landing Zone werden in Abb. 3 dargestellt. Der AWS-Account, in dem AWS Control Tower initialisiert wird, wird als Verwaltungskonto (Management Account) bezeichnet. Im Rahmen der Einrichtung wird dann ein zusätzliches Protokollarchivkonto (Log Archive Account) und ein Prüfungskonto (Audit Account) erzeugt. AWS-Accounts für eigene Workloads sind in der Abbildung in dem Bereich Provisioned Accounts angedeutet.

Der Log Archive Account bündelt die Protokolle (Logs) der API-Aktivitäten (AWS CloudTrail) und Ressourcenkonfigurationen (AWS Config) aller Accounts in der Landing Zone und ermöglicht so die spätere Nachvollziehbarkeit. Der Audit Account dient dazu, Security- und Compliance-Teams programmatischen Lese-/ Schreibzugriff zu AWS-Accounts zu ermöglichen, damit diese eventuelle Vorfälle analysieren können.

Weitere AWS-Accounts können automatisiert mit der Account Factory eingerichtet werden. Im Gegensatz zu der normalen Registrierungsseite sind in diesem Prozess weniger Angaben erforderlich, da durch eine Verknüpfung mit dem bestehenden Account die gemeinsame Abrechnung sichergestellt wird. Weiterhin folgen die auf diese Weise erstellten Accounts den festgelegten Best Practices und Standards (z. B. bzgl. des IP-Adressbereiches im Netzwerk).

Wie zuvor erwähnt bedient sich AWS Control Tower weiterer AWS Services. Einer dieser Services ist AWS Organizations, der einen zentralen Blick auf AWS-Accounts schafft und im Hintergrund die Integration verschiedener weiterer Management-Services ermöglicht. AWS Control Tower bedient sich der Mechanismen von AWS Organizations, um Best Practices umzusetzen. Organizations Policies sind Richtlinien, die bestimmte Berechtigungen oder Konfigurationen innerhalb einer Organization festschreiben. So können Tag-Richtlinien verwendet werden, um technisch zu erzwingen, dass Ressourcen mit Tags – also benutzerdefinierten Metadaten – versehen werden müssen. Ein Beispiel hierfür sind Tags für Projektbezeichnungen oder Kostenstellen, sodass eine eindeutige Zuordnung ermöglicht wird. Ein anderer Typ von Richtlinien sind Service Control Policies (SCP): Diese erlauben die Einschränkung von Zugriffen auf Services, selbst wenn Berechtigungen dafür gewährt wurden. Wann ist dies sinnvoll? Nehmen wir an, wir stellen einen AWS-Account für Entwickler zur Verfügung, und möchten den Entwicklern größtmögliche Freiheiten geben. Gleichzeitig müssen wir aber sicherstellen, dass die Protokollierung der API-Aktivitäten in CloudTrail nicht deaktiviert werden kann. In diesem Fall könnten Entwickler eine IAM Policy mit weitgehenden Rechten erhalten (z. B. AdministratorAccess für den kompletten Zugriff auf alle Ressourcen), würden durch die SCP aber an Änderungen an der CloudTrail-Konfiguration gehindert.

AWS-Accounts lassen sich in Organisationseinheiten (OUs) einteilen. Diese sollten nicht genau den organisatorischen Gruppierungen innerhalb von Unternehmen entsprechen. Vielmehr ist zu überlegen, welche AWS-Accounts ähnliche Anforderungen hinsichtlich Berechtigungen, Compliance und Sicherheitsanforderungen haben. Anschließend kann man Policies auf OUs anwenden. Best Practices zu diesem Themengebiet werden in einem Blogbeitrag [1] vertieft.

Die vorgestellte Struktur nutzt AWS Control Tower um Guardrails umzusetzen und damit sprichwörtlich Leitplanken, also einen vorgegebenen Rahmen für die jeweiligen AWS-Accounts zu setzen. Guardrails sind eine automatisierte Implementierung von Richtlinienkontrollen mit einem Schwerpunkt auf Sicherheit, Compliance und Kostenmanagement. Sie können präventiv (blockierende Maßnahmen bei Aktionen, die als riskant eingestuft werden) oder reaktiv (Warnung bei nicht konformen Aktionen) sein. Präventive Guardrails werden mit den zuvor erläuterten SCPs realisiert, einige Dinge lassen sich aber nicht vorab feststellen und können aufgrund der Verkettung erst im Nachgang anhand eines Regelwerkes festgestellt werden. Dies wird im Service AWS Config festgelegt.

Tabelle 1: Beispiele für Guardrails

Guardrail-BeschreibungVerhaltenTyp
MFA für den Root-Benutzer aktivierenpräventivdringend empfohlen
Öffentlichen Lesezugriff auf S3-Buckets verweigernreaktivdringend empfohlen
AWS Config in allen verfügbaren Regionen aktivierenpräventivobligatorisch
Richtlinienänderungen für das Protokollarchiv nicht zulassenpräventivobligatorisch
CloudTrail-Ereignisse in CloudWatch Logs integrierenpräventivobligatorisch
Verweigern von S3-Buckets, für die kein Versioning aktiviert istreaktivoptional
Löschaktionen für S3-Buckets ohne MFA nicht zulassenreaktivoptional

Zu unterscheiden ist weiterhin, ob Guardrails standardmäßig aktiviert (und nicht deaktivierbar sind) oder explizit ausgewählt werden müssen. Die obligatorischen Guardrails sind dabei essentiell, um AWS Control Tower funktionsfähig zu halten.

Einen Überblick über den aktuellen Stand, insbesondere die Einhaltung von Guardrails, gibt das Dashboard, welches in Abb. 5 dargestellt ist. Natürlich kann das Monitoring der Compliance nicht nur über die Oberfläche erfolgen, sondern es gibt auch andere Benachrichtigungsmöglichkeiten (per E-Mail, Messenger oder Integration in bereits existierende Tools).

Ein wichtiger Aspekt bei einer Struktur mit mehreren AWS-Accounts ist Single Sign-On, um einen zentralen Zugriff mit einmaliger Anmeldung zu ermöglichen. AWS Control Tower integriert dazu AWS Single Sign-On (SSO), bei dem Benutzer in einem integrierten Verzeichnis verwaltet werden können. In der Regel existiert in Unternehmen allerdings bereits ein Verzeichnis und so ist es üblicher, einen Drittanbieter wie Okta Universal Directory[2] oder Microsoft Active Directory (AWS SSO ist als App in Azure AD app gallery verfügbar [3]) einzusetzen. Ein zentrales Benutzerverzeichnis hat viele Vorteile: Berechtigungen und Gruppenzugehörigkeiten können an einer Stelle administriert werden. Ebenso ist es beim Ausscheiden von Mitarbeitern möglich, diese zentral zu sperren. Die Tatsache, dass Benutzer sich nicht mehrere Zugangsdaten pro System merken müssen, ist dabei nicht nur komfortabel, sondern führt auch zu höherer Sicherheit.

Der AWS Control Tower Service erhält regelmäßige Updates, welche zusätzliche Guardrails implementieren, oder weitere administrative Aufgaben vereinfachen und zentralisieren. Da damit auch Änderungen am Verhalten (z. B. durch zusätzliche Prüfungen) der Landing Zone einhergehen können, werden Updates auf neue Versionen nicht automatisch durch den Service durchgeführt. Diese Updates müssen durch AWS-Control-Tower-Administratoren auf Nutzerseite angestoßen werden. Ob ein Update zur Verfügung steht, kann in den Landing-Zone-Einstellungen in der AWS Console ermittelt werden. Diese zeigen die aktuelle Landing-Zone-Version und eventuell verfügbare Updates an. Ein einfacher Klick auf den Update-Knopf stößt die Aktualisierung an. Eine Historie bisheriger Versionen findet sich in den Release Notes [4].

Mit zunehmender Nutzung, Konfiguration verschiedener Organisationseinheiten und voranschreitender Zeit ist die Wahrscheinlichkeit, dass Accounts nicht den Vorgaben entsprechen, relativ hoch. Dieser Zustand wird als Drift oder auch Abweichung bezeichnet. Drift kann versehentlich entstehen, falls Ressourcen falsch konfiguriert werden oder wenn Landing-Zone-Konfigurationen außerhalb von AWS Control Tower händisch angepasst werden. In diesem Fall bietet AWS Control Tower die Möglichkeit einer automatischen Reparatur, um den Wunschzustand wiederherzustellen. Resultiert der Drift aus geänderten Geschäftsanforderungen, müssen Guardrails angepasst werden, um die neuen Anforderungen abzubilden.

Bei der Umsetzung einer Multi-Account-Strategie mit AWS Control Tower spielt das Thema Netzwerk eine wichtige Rolle: wie werden die verschiedenen Computernetze in den AWS-Accounts untereinander und mit Büros oder den eigenen Rechenzentren verbunden? Das Whitepaper "Building a Scalable and Secure Multi-VPC AWS Network Infrastructure" [5] gibt einen umfassenden Überblick über dieses Themengebiet.

Unterstützung für existierende Umgebungen

Während die Einrichtung neuer Umgebungen gemäß den bisher erläuterten Schritten einfach durchgeführt werden kann, so mag die Überführung einer bestehenden Umgebung in diese Struktur als vergleichsweise aufwändig empfunden werden. Hierzu stellt der AWS-Control-Tower-Service jedoch einige Hilfestellungen bereit.

Aus Sicherheitsgründen wird empfohlen, den Management Account einer AWS-Control-Tower-Installation nur für die Verwaltung der Landing Zone und der AWS Organization zu verwenden. Die eigentlichen Workloads sollten in eigenen AWS-Accounts betrieben werden. Dies hängt damit zusammen, dass Organizations-Administratoren Zugriff auf die verwalteten AWS-Accounts haben.

Hat man bisher nur einen AWS-Account im Einsatz, stellt sich die Frage, ob AWS Control Tower überhaupt sinnvoll ist. Dies hängt im wesentlichen davon ob, ob man in Zukunft eine Multi-Account Strategie verfolgen möchte, um Kostenzuordnung, erhöhte Sicherheit und Risikominimierung durch eine Aufteilung der AWS Ressourcen zu erreichen. Falls ja, ist die Einrichtung eines neuen AWS-Accounts, der als Management Account der Landing Zone dient, empfehlenswert. Anschließend kann man den bestehenden AWS-Account, welcher die Workloads enthält, zunächst in die neue AWS Organization und anschließend in die Landing Zone integrieren. Dieser Aufbau schafft gute Voraussetzungen, um in einem zweiten Schritt über Aufteilung der Workloads in eigene AWS-Accounts nachzudenken, bzw. neue Workloads direkt in eigenen AWS-Accounts zu realisieren.

Häufiger liegen AWS-Accounts bereits in einer Organisationsstruktur in AWS Organizations vor, die weiterverwendet werden kann. Im ersten Schritt muss die Landing Zone eingerichtet werden. Dies erfolgt genau wie im vorangegangenen Abschnitt beschrieben, nur dass dies in dem bestehenden Management-Account der AWS Organization ausgeführt wird. Eine Vorabprüfung stellt dabei sicher, dass alle Grundvoraussetzungen für die Einrichtung erfüllt sind.

In einem zweiten Schritt sind die AWS-Accounts auszuwählen, die zukünftig von AWS Control Tower verwaltet werden sollen. Es ist sowohl möglich, komplette Organisationseinheiten (OUs), als auch nur einzelne AWS-Accounts der AWS Control Tower Governance zu unterwerfen. In einer umgekehrten Variante ist es auch möglich, diese davon auszunehmen und diese unregistriert zu belassen. Weitere Details werden in einem Video in der Dokumentation veranschaulicht [6].

Erweiterung

Wie zu Beginn des Artikels erläutert, können neue AWS-Accounts mit der AWS Control Tower Account Factory erzeugt werden. Eine häufige Anforderung ist es, bei Abschluss des Prozesses weitere Aktionen auszuführen. Hierzu kann mit so genannten Lifecycle Events [7] auf den Lebenszyklus reagiert werden. Im Beispiel der Accountanlage sendet AWS Control Tower nach Fertigstellung das Ereignis CreateManagedAccount. Für dieses Ereignis kann eine Amazon EventBridge-Regel erstellt werden, welche die nächsten Schritte im Automatisierungsworkflow basierend auf dem Status des Lebenszyklus-Ereignisses auslösen kann.

Die Customization for AWS Control Tower Solution [8] bietet darüber hinaus die Möglichkeit, dies in Form von Infrastructure as Code abzubilden (in einem Git Repository oder einem S3 Bucket). Bei den entsprechenden Lifecycle Events wird dann eine CI/CD-Pipeline ausgelöst, welche Anpassungen in Form von AWS CloudFormation StackSets oder Service Control Policies in AWS Organizations ausrollt.

Einbindung von weiteren AWS Services

Ergänzend zum Standardfunktionsumfang kann die aufgesetzte Umgebung mit weiteren AWS Services ergänzt werden. Im folgenden Abschnitt werden einige Beispiele aufgeführt. Um AWS Control Tower inklusive der genannten weiteren Services automatisiert aufzusetzen, kann die von zwei deutschen AWS-Partnern entwickelte Lösung Superwerker eingesetzt werden [9].

AWS Identity and Access Management (IAM) Access Analyzer

Der AWS IAM Access Analyzer hilft, die Ressourcen in einer AWS-Organisation und in den zugehörigen Konten zu identifizieren, z. B. Amazon S3-Buckets oder IAM-Rollen, die extern freigegeben werden. Auf diese Weise können der unbeabsichtigte Zugriff auf Ressourcen und Daten identifiziert und daraus resultierende, mögliche Sicherheitsrisiken aufgedeckt werden. Der Access Analyzer identifiziert Ressourcen, die mit externen Principals (außerhalb des eigenen Accounts) gemeinsam genutzt werden, indem die ressourcenbasierten Richtlinien in einer AWS-Umgebung analysiert werden. In den Ergebnissen sind außerdem Ressourcen enthalten, die außerhalb des Accounts gemeinsam genutzt werden. Sie umfassen Informationen über den Zugriff und den externen Prinzipal, dem der Zugriff gewährt wird. Anhand der Resultate kann klassifiziert werden, ob der Zugriff beabsichtigt und damit sicher ist oder ob er unbeabsichtigt ist und ein Sicherheitsrisiko darstellt [10].

Amazon GuardDuty

Amazon GuardDuty ist ein Service für die intelligente Bedrohungserkennung und zur kontinuierlichen Sicherheitsüberwachung von Protokolldateien und Dateien im Objektspeicher Amazon S3. Der Service unterstützt die folgenden Datenquellen: VPC Flow Logs, AWS CloudTrail-Verwaltungsereignisprotokolle, Cloudtrail S3-Datenereignisprotokolle und DNS-Protokolle. Er verwendet Bedrohungsdaten, z. B. Listen bösartiger IP-Adressen und Domänen, ebenso wie maschinelles Lernen, um unerwartete und potenziell nicht autorisierte, bösartige Aktivitäten in einer AWS-Umgebung zu identifizieren. Dies kann Probleme wie Privilege Escalation (Ausnutzung von Programmfehlern um mehr Berechtigungen zu erhalten), die Verwendung kompromittierter Anmeldeinformationen oder die Kommunikation mit schädlichen IP-Adressen oder Domänen umfassen. Beispielsweise kann GuardDuty manipulierte EC2-Instanzen erkennen, die für Malware oder ein Bitcoin-Mining verwendet werden. Darüber hinaus überwacht er das Zugriffsverhalten des AWS-Accounts auf Anzeichen einer Sicherheitsverletzung, z. B. unbefugte Infrastruktur-Bereitstellungen, wie etwa die Bereitstellung von Instanzen in einer Region, die noch nie verwendet wurde, oder ungewöhnliche API-Aufrufe, wie beispielsweise für eine Änderung der Kennwortrichtlinie, um die Stärke des Kennworts zu reduzieren [11].

AWS Security Hub

AWS Security Hub bietet einen umfassenden Überblick über Sicherheitsmeldungen und den Sicherheitsstatus aller AWS-Accounts. Dafür steht eine Reihe leistungsstarker Sicherheitstools zur Verfügung, die von Firewalls und Endpunktschutz bis hin zu Schwachstellen- und Compliance-Scannern reichen. Aber oft muss zwischen diesen Tools hin und her gewechselt werden, um Sicherheitswarnungen zu bearbeiten. Mit Security Hub werden diese an einem einzigen Ort gebündelt, d. h. es können Sicherheitswarnungen oder -ergebnisse von mehreren AWS-Services wie Amazon GuardDuty, Amazon Inspector, Amazon Macie und AWS Identity and Access Management (IAM) Access Analyzer, AWS Systems Manager und AWS Firewall Manager sowie von AWS Partner Network (APN)-Lösungen zusammengefasst, organisiert und priorisiert werden. AWS Security Hub überwacht die Umgebung kontinuierlich, indem automatisierte Sicherheitsüberprüfungen der Infrastruktur und Konfigurationen auf der Grundlage bewährter Methoden von AWS und der jeweils zutreffenden Branchenstandards durchgeführt werden. Die Ergebnisse dieser Sicherheitsüberprüfungen können in Amazon Detective untersucht oder mithilfe von Amazon CloudWatch-Ereignisregeln an Ticket- oder Chat-Systeme, die Sicherheitsinformations- und Ereignisverwaltung (SIEM), Security Orchestration Automation and Response (SOAR), an Tools für das Vorfallsmanagement oder an benutzerdefinierte Playbooks mit Abhilfemaßnahmen gesendet werden, um weiterführende Maßnahmen zu ergreifen [12].

AWS Backup

Mit AWS Backup kann die Datensicherung über AWS-Services hinweg zentralisiert und automatisiert werden. AWS Backup bietet einen vollständig verwalteten, richtlinienbasierten Service, der die Datensicherung im großen Maßstab weiter vereinfacht. AWS Backup hilft auch, die Einhaltung von gesetzlichen Vorschriften zu unterstützen und Betriebskontinuitätsziele zu erfüllen. Zusammen mit AWS Organizations ermöglicht AWS Backup die zentrale Bereitstellung von Datensicherungsrichtlinien, um die Sicherungsaktivitäten für die AWS-Accounts und -Ressourcen eines Unternehmens zu konfigurieren, zu verwalten und zu steuern [13].

Weitere Lösungen im AWS Marketplace

Neben den genannten Beispielen finden sich im AWS Marketplace noch eine Vielzahl weiterer Lösungen [14]. Der AWS Marketplace ist ein digitaler Katalog mit tausenden von Softwareeinträgen von unabhängigen Softwareanbietern. Es ist dadurch sehr einfach für AWS passende Software zu finden, zu testen, zu kaufen und zu starten. Die Abrechnung erfolgt zentral über die bestehende AWS-Rechnung.

Fazit

AWS-Kunden [15] schätzen die AWS Management und Governance Services, weil sie sowohl Agilität als auch umfassende Governance-Kontrollmöglichkeiten ermöglichen. Bspw. können neue AWS-Accounts von Entwicklungsteams ohne Wartezeit angelegt und genutzt werden, entsprechen aber unmittelbar der definierten Baseline.

Für den in diesem Artikel hauptsächlich beschriebenen Services AWS Control Tower fallen keine zusätzlichen Kosten an, diese entstehen lediglich für die genutzten darunterliegenden Services (bspw. Speicherkosten für das Logarchiv auf Amazon S3 je nach Größe). In Zukunft sind weitere Aktualisierungen mit Verbesserungen geplant, die vom Kunden automatisiert in die eigene Umgebung ausgerollt werden können.

Autoren

Dennis Kieselhorst

Dennis Kieselhorst ist Solutions Architect bei Amazon Web Services (AWS). Er hat 15 Jahre Erfahrung mit Java und verteilten, heterogenen Systemlandschaften.
>> Weiterlesen

Wladislaw Mitzel

Wladislaw Mitzel ist Solutions Architect bei Amazon Web Services (AWS). Er hat an verteilten Systemen, Big Data, Event Driven Architectures und Cloud Migrationen mitgearbeitet.
>> Weiterlesen
Das könnte Sie auch interessieren

Kommentare (0)

Neuen Kommentar schreiben