In unserem ersten Artikel haben wir einen Überblick über das Thema Continuous Integration & Continuous Deployment (CI/CD) gegeben.

In den nachfolgenden Artikeln wollen wir gängige Tools im Detail vorstellen und konkrete Handlungsempfehlungen geben.

GitLab CI ist ein Teil des GitLab-Ökosystems, das dem Entwickler Tools zur Automatisierung in der Softwareentwicklung bietet. Es ermöglicht Entwicklern Code-Änderungen kontinuierlich zu integrieren, zu testen, und automatisiert bereitzustellen. Dies  erhöht die Software-Qualität, steigert die Effizienz und verkürzt die Auslieferung von neuen Features.

Definition (Pipelines, Jobs, Stages)

Gitlab CI arbeitet mit einer Pipeline-basierten Struktur, die es ermöglicht, den Entwicklungsprozess in einzelne, in sich gekapselte und aufeinanderfolgende Schritte zu unterteilen. Diese Schritte werden als sog. „Jobs“ bezeichnet und in „Stages“ zusammengefasst. Eine Pipeline beschreibt alle im Entwicklungsprozess beteiligten Aufgaben für ein Projekt, vom Build über den Test hin zur Bereitstellung.

Job: Ein Job kann das kompilieren, testen oder ausbringen (deployen) von Code sein. Jobs laufen unabhängig voneinander und werden von sog. Runnern ausgeführt.

Stages: Stages sind Gruppen von Jobs. Stages werden sequentiell nacheinander ausgeführt, wobei Jobs  innerhalb einer Stage parallel ausgeführt werden. Alle Jobs innerhalb müssen erfolgreich ausgeführt werden, damit die nächste Stage in einer Pipeline ausgeführt wird – ist dies nicht der Fall – bricht die Pipeline vorzeitig ab.

Laufzeitumgebung – Gitlab Runner

Die Ausführung von Pipeline Jobs erfolgt durch sog. „Runner“. Ein Gitlab Runner ist eine eigenständige Applikation, die in der Pipeline definierte Jobs ausführt.

Runner können auf unterschiedlichen Umgebungen ausgeführt werden – hierzu gehören:

• Virtuelle Maschinen
• Docker Container
• Kubernetes Pod

Folgende Typen von Runnern werden unterschieden:

• Shared Runners: Von Gitlab verwaltete Runner – stehen allen Projekten innerhalb einer Gitlab Instanz zur Verfügung
• Specific Runners: Individuell konfigurierte Runner für bestimmte Projekte oder Benutzergruppen

Projektbasierte Konfiguration (.gitlab-ci.yml)

• Integration in Gitlab: Gitlab CI ist nahtlos in die Gitlab-Plattform rund um Code-Verwaltung, Issue-Tracking und Security & Compliance integriert
• Automatisierung: Gitlab CI ermöglicht eine hohe Automatisierung von Software Entwicklungsprozessen – dies reduziert die Fehleranfälligkeit und den manuellen Aufwand im Projekt
• Qualität: Durch die Automatisierung von manuellen Tätigkeiten wird sichergestellt, das Abläufe im Prozess immer gleich ausgeführt werden – dies erhöht die Lösungsqualität maßgeblich

• Komplexität: Die große Flexibilität der Lösung kann zu komplexen Konfigurationen führen, die schwer zu verwalten oder zu debuggen sind
• Kosten: Für umfangreiche Nutzung oder spezielle Funktionen können zusätzliche Kosten (Hardware, Wartung, etc.) entstehen
• Vendor Lock-In: Eine starke Abhängigkeit von Gitlab kann den Wechsel zu einer anderen CI/CD Lösung erschweren

• Gitlab Runner: https://docs.gitlab.com/runner/

Wenn dein Team gerade dabei ist CI/CD zu adaptieren oder Probleme mit den Konzepten von CI/CD hat, dann bist Du hier genau richtig.

Wir wollen im Rahmen unserer Blog-Serie ein Verständnis für CI/CD schaffen, konkrete Anwendungsfälle und Tools beleuchten und aufzeigen wie man CI/CD im Kubernetes Kontext umsetzt.

CI/CD steht für Continuous Integration und Continuous Delivery (oder Deployment). In der Softwareentwicklung ist es ein Vorgehen bei welchem Code-Änderungen von unterschiedlichen Entwickler frühzeitig in einem Repository zusammengeführt werden. Ziel ist es Code-Änderungen häufig und in kurzen Abständen zusammenzuführen.

• Continuous Integration (CI) bedeutet, dass Entwickler ihre Codeänderungen häufig in einem gemeinsamen Repository zusammenführen. Dies hilft, frühzeitig Fehler zu finden und zu beheben, bevor sie sich im Code ansammeln.
• Continuous Delivery (CD) bedeutet, dass Softwareänderungen automatisch in einer weiteren Umgebung (Bsp. QA/PROD) bereitgestellt werden können. Dies ermöglicht es Entwicklungsteams, Softwareänderungen schneller und mit weniger Aufwand bereitzustellen.

• Höhere Qualität: CI/CD hilft, Fehler zu finden und zu beheben, bevor sie sich im Code ansammeln. Dies führt zu qualitativ hochwertigerer Software.
• Geringere Kosten: CI/CD kann die Kosten für die Softwareentwicklung und -bereitstellung senken. Dies liegt daran, dass der Prozess automatisiert ist und weniger manuelle Arbeit erfordert.
• Besserer Überblick: CI/CD bietet Entwicklungsteams einen besseren Überblick über den Softwareentwicklungs- und Bereitstellungsprozess. Dies kann dazu beitragen, Risiken zu minimieren und die Effizienz zu verbessern.

Eine CI/CD-Pipeline ist ein automatisierter Prozess, der die Softwareentwicklung und -bereitstellung steuert. Die Pipeline besteht aus einer Reihe von Schritten, die in der Regel in folgender Reihenfolge ausgeführt werden:

1. Code-Kompilierung: Der Code wird in ausführbaren Code kompiliert.

2. Code-Tests: Der Code wird auf Fehler getestet (Integrations, UI, API-Tests)

3. Code-Integration: Der Code wird in ein gemeinsames Repository integriert.

4. Code-Freigabe: Der Code wird in eine Produktionsumgebung bereitgestellt.

Die CI/CD-Pipeline kann in der Regel mithilfe von CI/CD-Tools automatisiert werden. Diese Tools bieten eine Reihe von Funktionen, die die Automatisierung des Prozesses erleichtern.

CI/CD hat sich als Quasi-Standard in der Entwicklung und Bereitstellung von Software und Infrastruktur etabliert.

Hier sind einige Beispiele für CI/CD-Anwendungen:

• Software-Unternehmen (ISV): Software-Unternehmen verwenden CI/CD, um neue Softwarefunktionen schneller und zuverlässiger bereitzustellen.
• DevOps & Plattform-Teams: DevOps & Plattform Teams nutzen CI/CD um komplette Umgebungen (DEV, TEST, PROD) automatisiert auszurollen – hier kommt oft der sog. GitOps Ansatz zum tragen.
• E-Commerce-Unternehmen: E-Commerce-Unternehmen verwenden CI/CD, um neue Funktionen und Microservices innerhalb Ihrer bestehenden Umgebungen schnell verfügbar zu machen.
• Finanzunternehmen: Finanzunternehmen verwenden CI/CD, um Sicherheitsupdates und Compliance-Ergänzungen schnell und effizient bereitzustellen.

CI/CD ist eine wichtige Methode, um die Softwareentwicklung und -bereitstellung zu verbessern. Es bietet eine Reihe von Vorteilen, darunter höhere Qualität, geringere Kosten durch den Wegfall von manuellen Arbeitsschritten sowie eine höhere Produktivität & Zufriedenheit bei den Mitarbeitern.

• Cloud-Computing: Unternehmen, die Cloud-Computing-Ressourcen verwenden, können CI/CD verwenden, um die Bereitstellung von Cloud-Instanzen, -Netzwerken und -Speichern zu automatisieren. Dies kann dazu beitragen, die Kosten für Cloud-Ressourcen zu senken und die Bereitstellung von Cloud-Diensten zu beschleunigen.
• Virtuelle Maschinen: Unternehmen, die virtuelle Maschinen (VMs) verwenden, können CI/CD verwenden, um die Bereitstellung von VMs und -Konfigurationen zu automatisieren. Dies kann dazu beitragen, die Effizienz der VM-Bereitstellung zu verbessern und die Sicherheit von VMs zu erhöhen.
• Container & Kubernetes: Unternehmen, die Container verwenden, können CI/CD verwenden, um die Bereitstellung von Containern und -Konfigurationen zu automatisieren. Dies kann dazu beitragen, die Flexibilität der Container-Bereitstellung zu verbessern und die Skalierbarkeit von Container-Anwendungen zu erhöhen.

• Automatisierte Builds und Tests: CI wird verwendet, um Builds und Tests von Software automatisch durchzuführen.
• Automatisierte Bereitstellungen: CD wird verwendet werden, um Softwareänderungen automatisch in Produktionsumgebungen bereitzustellen.
• Automatisierte Überwachung: CI/CD kann verwendet werden, um die Leistung und den Zustand von Software automatisch zu überwachen. Dies kann dazu beitragen, Probleme frühzeitig zu erkennen und zu beheben.
• Automatisiertes Rollback: CI/CD-Pipelines können auch verwendet werden, um Softwareänderungen automatisch rückgängig zu machen, wenn Probleme im Betrieb erkannt werden. Dies trägt dazu bei, die Downtime von Applikationen zu reduzieren und einen möglichen Schaden, der durch fehlerhaft Softwareänderungen verursacht wurde, zu minimieren.

Wenn Ihr Unternehmen plant, auf Microsoft Azure als Public-Cloud Provider zu setzen, dann sind Sie hier genau richtig. In diesem Artikel stellen wir das Microsoft Cloud Adoption Framework und die Enterprise-Scale Landing Zone Konzepte vor und erklären, wie sie Ihr Unternehmen bei der erfolgreichen Einführung und Optimierung von Cloud-Lösungen unterstützen können.

Das Microsoft Cloud Adoption Framework (CAF) für Azure ist ein bewährter Ansatz, der Unternehmen dabei hilft, eine effektive Cloud-Strategie zu entwickeln. Das Framework unterstützt Sie dabei, die Geschäftsziele Ihres Unternehmens zu identifizieren und eine Roadmap für Ihre Cloud-Adoption zu erstellen. Es bietet auch technische und betriebliche Leitlinien, um Ihre Cloud-Bereitstellung und -Verwaltung zu optimieren.

Die Schlüsselelemente des CAF sind:

1. Strategie: Definieren Sie Ihre Geschäftsziele und entwickeln Sie eine entsprechende Cloud-Strategie.
2. Planung: Identifizieren Sie die notwendigen technischen und betrieblichen Änderungen und erstellen Sie einen Umsetzungsplan.
3. Bereitstellung und Migration: Implementieren Sie die notwendigen technischen Änderungen und migrieren Sie Ihre Anwendungen und Daten in die Cloud.
4. Verwaltung und Optimierung: Stellen Sie die Leistung und Kostenoptimierung Ihrer Cloud-Lösung sicher und stellen Sie sicher, dass Ihre Cloud-Umgebung sicher und compliant ist.

Für eine effiziente Implementierung und Skalierung von Azure empfiehlt Microsoft die Nutzung von „Landing Zones“. Diese sind vordefinierte Umgebungen, die Unternehmen dabei helfen, Cloud-Ressourcen zu organisieren, zu verwalten und zu sichern.

Das Enterprise-Scale Landing Zone Konzept ist speziell darauf ausgerichtet, komplexe, skalierbare Cloud-Umgebungen zu unterstützen. Es gibt drei Hauptvarianten dieses Konzepts:

1. Enterprise-Scale Foundation: Diese Variante bietet eine grundlegende Azure-Umgebung für Unternehmen, die einen moderaten Umfang an Cloud-Ressourcen benötigen.
2. Enterprise-Scale Virtual WAN: Diese Variante richtet sich an Unternehmen, die eine umfangreiche Netzwerkverbindung zu Azure benötigen und zahlreiche Standorte und Netzwerke in ihre Cloud-Umgebung integrieren möchten.
3. Enterprise-Scale Hub and Spoke: Diese Variante ist ideal für Unternehmen, die eine erweiterte Netzwerk- und Sicherheitsinfrastruktur in Azure benötigen.

Jede dieser Varianten kann an die spezifischen Anforderungen Ihres Unternehmens angepasst werden und bietet leistungsstarke Tools und Services zur Verwaltung Ihrer Cloud-Ressourcen.

In der dynamischen Welt der Public Cloud und speziell bei Amazon Web Services (AWS) ist das Konzept der Compliance von entscheidender Bedeutung. Aber was genau meinen wir, wenn wir von Compliance in Bezug auf die Public Cloud und AWS sprechen?

Kurz gesagt, bezieht sich Compliance auf die effektive Kontrolle und Verwaltung von Cloud-Ressourcen, um sicherzustellen, dass sie den geltenden Gesetzen, Vorschriften und Standards entsprechen. Dies beinhaltet die Überwachung, die Anwendung von Best Practices und Richtlinien, die Sicherstellung der Einhaltung von Datenschutz- und Sicherheitsstandards, sowie ein effizientes Management von Ressourcen.

Die Implementierung von IT-Standards in der Cloud kann mit einer Vielzahl von Herausforderungen verbunden sein:

• Sicherheitsbedenken: Cloud-Anbieter müssen strenge Sicherheitsmaßnahmen ergreifen, um Daten zu schützen. Unternehmen müssen sicherstellen, dass diese Maßnahmen den Compliance-Anforderungen entsprechen.
• Compliance-Vorschriften: Unterschiedliche Regionen und Branchen haben unterschiedliche Compliance-Anforderungen. Es kann herausfordernd sein, diese zu verstehen und sicherzustellen, dass die Cloud-Dienste diesen Anforderungen entsprechen.
• Datenstandort und -zugriff: Die physische Lage der Daten in der Cloud kann Auswirkungen auf die Compliance haben, insbesondere wenn die Daten spezifischen rechtlichen Anforderungen unterliegen.
• Datenverschlüsselung und -integrität: Die Übertragung und Speicherung sensibler Daten erfordert robuste Verschlüsselungsmethoden, um die Integrität und Vertraulichkeit zu gewährleisten.
• Auditierbarkeit und Transparenz: Unternehmen müssen in der Lage sein, ihre Daten in der Cloud zu überwachen, um sicherzustellen, dass sie den Compliance-Anforderungen entsprechen. Dies kann durch Audit-Protokolle und Transparenzmechanismen erzielt werden.

AWS bietet eine Vielzahl an hauseigenen Tools und Diensten zur Bewältigung spezifischer Governance-Probleme:

AWS Organizations: AWS Organizations ist Ihr Helfer, wenn Sie mit der Verwaltung mehrerer Konten und Ressourcen zu kämpfen haben. Es ermöglicht eine zentrale Steuerung und Kontrolle aller Ihrer Konten und Ressourcen, was die Komplexität reduziert und die Einhaltung von Richtlinien verbessert.

AWS Control Tower: AWS Control Tower ist eine automatisierte Lösung zur Einrichtung und Verwaltung mehrerer AWS-Konten. Es nutzt Funktionen von AWS Organizations und bietet automatisierte Sicherheits- und Compliance-Regeln für Ihre AWS-Umgebung. Mit den „Landing Zones“ können Konten automatisch konfiguriert werden, während die „Guardrails“ als Richtlinien zur Steuerung Ihrer AWS Konten dienen. Dieses Tool ermöglicht eine vereinfachte und standardisierte Einrichtung und Verwaltung von AWS-Konten, was die Einhaltung von Compliance verbessert und das Risiko reduziert. Hinsichtlich des Audits erleichtert AWS Control Tower den Prozess, indem es dedizierte Rollen für die Überwachung und Kontrolle bereitstellt. Diese Rollen können Zugriff auf spezifische Informationen und Funktionen haben, was eine effektive Überprüfung der Compliance und der Systemaktivitäten ermöglicht.

AWS Config: Die Nachverfolgbarkeit und Kontrolle von Ressourcenkonfigurationen ist mit AWS Config kein Problem mehr. Sie können Ihre AWS-Ressourcen inventarisieren, Konfigurationen prüfen und Änderungen nachverfolgen, was zu einer verbesserten Compliance führt und das Risiko von Konfigurationsfehlern minimiert.

AWS CloudTrail: Sicherheits- und Compliance-Probleme lassen sich durch die Protokollierung und Überwachung von Aktivitäten in Ihrem AWS-Konto mit AWS CloudTrail lösen. Es erhöht die Transparenz und ermöglicht eine schnellere Erkennung und Reaktion auf sicherheitsrelevante Vorfälle.

AWS Trusted Advisor: AWS Trusted Advisor bietet Echtzeitbeobachtungen und Empfehlungen, um Kosten zu sparen, die Leistung zu verbessern und Sicherheitslücken zu schließen. Es unterstützt dabei, unnötige Kosten zu vermeiden, die Systemleistung zu optimieren und die allgemeine Sicherheitslage zu verbessern.

StackGuardian: StackGuardian ist eine kommerzielle „Compliance as a Service“ Lösung, welche es Unternehmen ermöglicht Ihre zentralen Policies zu verwalten, Drift innerhalb der Cloud-Umgebungen zu erkennen und Infrastruktur zentral Compliance-Konform zu deployen. Bemerkenswert ist, dass StackGuardian die bestehende Infrastruktur gegen bestehenden Standardkataloge (CIS, NIST, GDPR, PCI-DSS, etc.) abgleichen kann – sodaß man sehr schnell eine Beurteilung der eigenen Cloud Umgebung erreicht. Neben dem Policy Management bietet StackGuardian auch eine FinOps Analyse Komponenten mit welcher Optimierungspotentiale in der Infrastruktur aufgedeckt werden.

Cloud Custodian: Cloud Custodian ist eine OpenSource Regeln Engine, die in verschiedenen Cloud-Umgebungen, einschließlich AWS, implementiert werden kann. Es ermöglicht Benutzern, Regeln für das Management von Cloud-Ressourcen zu definieren und durchzusetzen. Cloud Custodian bietet eine einheitliche, regelbasierte Sprache für die Ressourcenverwaltung und erlaubt es, Aktionen direkt auf Cloud-Ressourcen anzuwenden. Es kann zum Überprüfen von Ressourcen auf Compliance, zur Verwaltung von Kosten, zur Sicherstellung der Verschlüsselung von Daten und zur Durchsetzung von Sicherheitsbestimmungen (z.B. Tagging Konzepten) verwendet werden. Zudem ist es hochgradig anpassbar und kann komplexe Compliance-Anforderungen erfüllen, was es zu einer leistungsfähigen Ergänzung des Compliance-Toolsets für Cloud-Plattformen, einschließlich AWS, macht.

terraform-compliance: terraform-compliance ist ein Tool, das dabei hilft, IaC (Infrastructure as Code) Umgebungen, die mit Terraform bereitgestellt wurden, auf verschiedene Compliance-Anforderungen zu prüfen. Idealerweise wird es in CI/CD-Prozesse integriert, sodass der Aufbau von Cloud-Infrastrukturen, die nicht den gegebenen Compliance-Anforderungen entsprechen, verhindert wird. Policies folgen den BDD (Behavior Driven Development) Prinzipien und werden in einfacher englischer Sprache verfasst. Dies hilft auch weniger technisch versierten Personen, Policies zu verfassen und damit Compliance-Anforderungen sicherzustellen.

Im Folgenden schauen wir uns ein konkretes Beispiel an, welches in Cloud-Umgebungen eine wichtige Rolle spielt: Ressourcen & Asset Tagging

Hierbei geht es darum, sicherzustellen, dass jede Cloud-Ressource inventarisiert ist – im Regelfall wird dies mit Hilfe von „Tags“ realisiert. Der Tag kennzeichnet und identifiziert verschiedene Merkmale wie z.B. Cost-Center, Environment (DEV, QA, PROD), Region,…

Es ist wichtig zu betonen, dass dies lediglich ein einzelnes Beispiel aus einer Vielzahl an möglichen Compliance relevanten Themen ist.
Die nächsten Abschnitte zeigen auf, wie man Ressourcen Tagging mit AWS-eigenen Tools wie AWS Organizations und AWS Config, sowie mit den zuvor vorgestellten Third-Party Tools, Cloud Custodian und terraform-compliance, durchsetzen kann.

Mit Hilfe von AWS Organizations lassen sich AWS Umgebungen einfach aufbauen und verwalten. Ein Feature von AWS Organizations sind die sogenannten “Service Control Policies”.

Service Control Policies (SCPs) sind Richtlinien in AWS Account Strukturen (AWS Organizations), die zur Definition von Berechtigungen für AWS-Konten dienen. Sie legen fest, welche Aktionen Benutzer, Rollen und IAM-Gruppen ausführen können und bieten eine zusätzliche Kontrollebene über Standard-IAM-Richtlinien. SCPs können zudem dazu genutzt werden, die Einhaltung von Tag Compliance durchzusetzen.

Das folgende Beispiel stellt sicher, dass beim Erstellen von Secrets im Secret Manager oder beim Starten von EC2 Instanzen die Tags „Project“ und „CostCenter“ vorhanden sein müssen.

Vorteile:

• AWS native Funktionalität, die Nutzung ist kostenlos
• Kann auch ohne Infrastructure as Code genutzt werden

Nachteile:

• Policies werden lang und komplex für relativ einfache Tag Enforcement Szenarien
• max. 5120 Zeichen pro Policy → Lange Policies müssen geteilt werden
• Komplexere Szenarien, bei denen mehrere Tags zusammenarbeiten müssen, können nur schwer oder gar nicht abgedeckt werden
• Kann nicht für einzelne Accounts ohne AWS Organizations genutzt werden

AWS Config Regeln können zur Durchsetzung der Tag Compliance genutzt werden. Sie erlauben die kontinuierliche Überwachung der AWS-Ressourcenkonfigurationen. Regeln können erstellt werden, die bestimmte Tags auf den Ressourcen erfordern. Wenn eine Ressource diese Anforderung nicht erfüllt, kennzeichnet AWS Config sie als nicht konform.

Dieses Beispiel zeigt ein Verhalten, das den Service Control Policies ähnelt. Es verhindert jedoch nicht die Erstellung von Ressourcen, sondern prüft nach der Erstellung der Ressourcen die Tag Compliance. Optional kann AWS Config fehlende Tags ergänzen, wenn dies gewünscht ist.

Vorteile:

• AWS native Funktionalität
• Kann mit oder ohne AWS Organizations genutzt werden
• Kann auch ohne Infrastructure as Code genutzt werden
• Regeln sind vergleichsweise kompakt und übersichtlich

Nachteile:

• Die Nutzung ist nicht kostenlos
• Überwacht bestehende Ressourcen → Kann die Erstellung von nicht-konformen Ressourcen nicht verhindern, sondern kann nur danach handeln

Auch Cloud Custodian kann zur Durchsetzung der Tag Compliance eingesetzt werden. Mit Cloud Custodian können Richtlinien erstellt werden, die AWS-Ressourcen auf die Einhaltung von bestimmten Tag Anforderungen überprüfen. Wenn eine Ressource diese Anforderungen nicht erfüllt, markiert Cloud Custodian sie als nicht konform und kann automatisch Korrekturmaßnahmen durchführen, wie das Hinzufügen fehlender Tags.

Ein Beispiel für eine Cloud Custodian Richtlinie, die die Anforderung von ‚Project‘ und ‚CostCenter‘ Tags auf Secrets im Secret Manager und auf EC2 Instanzen durchsetzt, könnte folgendermaßen aussehen:

Vorteile:

• Kann komplexere Szenarien abdecken
• Kann genutzt werden, um Tag Compliance über verschiedene Cloud Anbieter (AWS, Azure und GCP) hinweg zu überprüfen
• Vielseitige Handlungsmöglichkeiten:
  • Kann automatisch fehlende Tags hinzufügen
  • Kann nicht konforme Ressourcen löschen
  • Kann im Fall von nicht konformen Ressourcen E-Mails versenden
• Kann auch ohne Infrastructure as Code genutzt werden

Nachteile:

• Nicht AWS-native Funktionalität
• Komplexer als AWS native Tools
• Überwacht bestehende Ressourcen → Kann die Erstellung von nicht-konformen Ressourcen nicht verhindern, sondern kann nur danach handeln

Die Nutzung von terraform-compliance kann ebenfalls dazu beitragen, die Einhaltung von Tagging-Anforderungen zu gewährleisten.

Terraform-compliance ist ein Kommandozeilen-Tool zur Prüfung von Infrastructure as Code (IaC) Umgebungen, die mit Terraform bereitgestellt wurden. Es ermöglicht unteranderem das Erstellen von Policies, die bestimmte Tags auf den Ressourcen erfordern. Wenn eine Ressource diese Anforderungen nicht erfüllt, markiert terraform-compliance sie als nicht konform und kann das Deployment dieser Ressourcen verhindern.

Ein Beispiel für eine terraform-compliance Richtlinie, welche die Anforderung von ‚Project‚ und ‚CostCenter‚ Tags auf Secrets im Secret Manager und auf EC2 Instanzen durchsetzt, könnte folgendermaßen aussehen:

Kubernetes Umgebungen sind schnell aufgebaut und Applikationen installiert – jedoch stellt sich spätestens nach dem erstmaligen Deployment die Frage – Wie lassen sich diese Umgebungen und die darin befindlichen Applikationen überwachen, sodaß der Zustand der Umgebung beurteilt und im Fehlerfall eine Analyse (Debugging) durchgeführt werden kann?

• Kritische Komponenten: API-Server, Scheduler, Controller-Manager sowie Etcd Storage.
• Ressourcennutzung: Die Ressourcennutzung der Knoten und Pods sollte überwacht werden, um sicherzustellen, dass diese nicht überlastet sind.
• Leistung: Die Leistung der Anwendungen sollte überwacht werden, um sicherzustellen, dass sie die gewünschten Anforderungen erfüllen.
• Log-Dateien: Die Logmeldungen der Anwendungen und Komponenten sollten überwacht werden, um Fehlermeldungen zu identifizieren und eine spätere Fehleranalyse zu vereinfachen.

• Native Überwachungstools (im Regelfall Open-Source)
  • Metrics Server: Der Metrics Server stellt Metriken für die kritischen Komponenten von Kubernetes bereit.
  • Prometheus: Prometheus ist ein Open-Source-Monitoring-Tool, das Metriken aus verschiedenen Quellen sammeln und speichern kann.
  • Grafana: Grafana ist eine Open-Source-Visualisierungs-Plattform, die Metriken aus Prometheus anzeigen kann.
• Kommerzielle Überwachungstools
  • New Relic: New Relic bietet eine umfassende Monitoring-Lösung für Kubernetes-Umgebungen.
  • Datadog: Datadog bietet ebenfalls eine umfassende Monitoring-Lösung für Kubernetes-Umgebungen.
  • Site24x7: Site24x7 bietet eine kostengünstige Monitoring-Lösung für Kubernetes-Umgebungen.

• Individual-Konfiguration: Aufbau einer eigenständigen MLA (Monitoring, Logging, Alerting) Umgebung
• Managed-Services: Nutzung von Managed Service Angeboten der Hyper-Scaler – hier: AWS

Wir wollen uns nachfolgend die konkrete Implementierung einer Monitoring & Logging Umgebung basierend auf dem Managed-Service Angebot von AWS näher anschauen.

Ausgangssituation:

Ein EKS-Cluster wurde bereits bereitgestellt und unsere Beispiel-Applikation wurde auf dem Cluster deployed – wir wollen nun den Cluster-Zustand sowie die darauf befindliche Workload (Applikation) überwachen.

Implementierung:

• Definition der gewünschten Monitoring Metriken:
  • Node: Node-Health, CPU Usage, Memory Usage
  • Kubernetes Pods: Pod Memory Usage, Pod CPU Usage, Application Health
• Allgemeines:
  • Das Deployment der Komponenten auf AWS Seite erfolgt über Terraform
  • Die Deployment Konfigurationen sind in HCL (HashiCorp configuration language) verfasst

• Deployen einer Logging Group für Managed Prometheus sowie des Managed Prometheus Services, anlegen eines IAM Service Accounts fuer das schreiben von Metriken einer In-Cluster Prometheus Instanz

• Deployen und Konfigurieren einer In-Cluster Prometheus Instanz zum einsammeln der Cluster-Metriken, wahlweise Prometheus Operator oder einen einfachen Prometheus Server mittels Helm.Es wird eine Remote Write Konfiguration vorgenommen um die Datenhaltung bei dem Managed Service zu belassen. Die folgenden Werte sollten in der Datei prometheus.yml gespeichert werden wobei der Platzhalter PROMETHEUS_ENDPOINT durch die URL vom Managed Prometheus Service ersetzt werden sollte:

Abschliessend kann die In-Cluster Prometheus Instanz mit den folgenden Befehlen installiert werden:

• Konfigurieren von dem Managed Prometheus Service innerhalb von dem Managed Grafana Service als Datasource, wahlweise kann diese Datenquelle durch die Grafana Benutzeroberfläche erfolgen, oder durch Terraform basierend auf dem Grafana Provider:

• Konfigurieren eines Grafana Dashboards zum visualisieren der gewünschten Metriken

• Logmeldungen werden mit Hilfe eines Collectors wie z.B. FluentBit an CloudWatch übertragen. CloudWatch ist die Lösung von AWS zum Sammeln und Aggregieren von Logs und Metriken. Damit Fluentbit dazu berechtigt ist Logmeldungen and CloudWatch zu übertragen, benötigen wir eine entsprechende Policy sowie einen IAM Service Account:

• Anschliessend kann Fluentbit mittles Helm im EKS Cluster installiert werden. Die folgenden Werte sollten in der Datei fluentbit.yml gespeichert werden. Die Platzhalter CLUSTER_NAME und AWS_ACCOUNT_ID müssen durch den Namen des EKS Clusters und die ID des AWS Kontos, in dem die Lösung ausgerollt wird, ersetzt werden.

• Abschliessend kann Fluentbit mit den folgenden Befehlen installiert werden:

• Konfigurieren von CloudWatch innerhalb von dem Managed Grafana Service als Datasource

• Konfigurieren eines Grafana Dashboards zum visualisieren der gesammelten Logdaten

Als Ziel für die Alarmmeldungen nutzen wir AWS SNS (Simple Notification Service). SNS ist ein vollständig von AWS verwalteter Pub/Sub-Service für A2A (Application to Application) und A2P (Application to Person) Nachrichten.

• In SNS wird ein sogenanntes “Topic” gebraucht, in das wir unsere Nachrichten schreiben können:

• Ein Alertmanager ist bereits Bestandteil des Managed Prometheus Service, hier kann die Konfiguration entsprechend der eigenen Vorstellungen vorgenommen werden. Als Beispiel wird hier eine Standardroute mittels des oben genannten SNS (Simple Notification Service) Topics konfiguriert:

• Abschliessend können Abonnenten durch die AWS Konsole für das angelegt SNS (Simple Notification Service) Topic angelegt werden
• Konfigurieren von Alarmmeldungen mittels Prometheus Regeln welche vom Alertmanager and SNS (Simple Notification Service) übertragen werden

• Schnelle Bereitstellung einer Monitoring, Logging und Alerting Lösung für Kubernetes
• Skalierbarkeit – die Lösung skaliert mit dem Log-Volumen – Hochlast Situation sind im Preismodell des Managed Service bereits berücksichtigt
• Geringe Betriebskosten – Kein Patch-Management und Wartung der Systeme notwendig
• Hohe Verfügbarkeit – Amazon Managed Prometheus ist von Haus aus in verschiedenen Availability Regionen ausgerollt und damit für eine hohe Verfügbarkeit ausgelegt

• Grafana Dashboard Library: https://grafana.com/grafana/dashboards/?pg=docs-grafana-latest-dashboards
• Amazon Managed Service for Prometheus: https://docs.aws.amazon.com/grafana/latest/userguide/prometheus-data-source.html
• Amazon Managed Grafana: https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html

Mit Infrastructure as Code (IaC) wird die Bereitstellung und Verwaltung von Infrastruktur durch Code und nicht händische Eingriffe durchgeführt. IaC standardisiert und optimiert die Infrastrukturbereitstellung, verbessert die Skalierbarkeit und reduziert das Potenzial für menschliche Fehler. Continuous Integration und Continuous Delivery (CI/CD) Pipelines ermöglichen die Prüfung und Bereitstellung von Änderungen am Infrastrukturcode, was Downtimes weiter reduzieren kann.

Mit Terraform kannst du sowohl Cloud- als auch On-Premise-Ressourcen in menschenlesbaren Konfigurationsdateien definieren. Diese Dateien kannst du versionieren, wiederverwenden und teilen. Anschließend kannst du einen konsistenten Workflow verwenden, um deine Infrastruktur während ihres gesamten Lebenszyklus zu bereitstellen und zu verwalten. Terraform kann Low-Level-Komponenten wie Compute-, Storage- und Networking-Ressourcen sowie High-Level-Komponenten wie DNS-Einträge und SaaS-Funktionen verwalten.

Terraform-Provider sind Plugins, die es Terraform ermöglichen, mit verschiedenen Arten von Infrastruktur zu interagieren, wie zum Beispiel Public Cloud-Services oder On-Premise Infrastruktur. Es gibt offizielle und von der Community bereitgestellte Terraform-Provider, die verwendet werden können. Offizielle Provider werden von HashiCorp entwickelt und gepflegt, dem Unternehmen, das Terraform erstellt hat, während Third-Party-Provider von der Community erstellt werden. Offizielle Provider sind in der Regel zuverlässiger und haben besseren Support, aber Third-Party-Provider können nützlich sein, um Nischen- oder spezialisierte Produkte zu integrieren.

Der Terraform State ist eine Datei, in der wir den aktuellen Zustand der von Terraform verwalteten Ressourcen speichern. Diese Datei enthält Informationen über die Ressourcen, einschließlich ihrer aktuellen Konfiguration, ihrer IDs und ihrer Abhängigkeiten. Wir verwenden den Status, um zu verfolgen, welche Ressourcen erstellt, aktualisiert oder gelöscht werden müssen. Der Status wird normalerweise in einer Datei namens terraform.tfstate gespeichert, die sich im Arbeitsverzeichnis befindet. Wenn wir jedoch Remote-Backends wie AWS S3 oder Terraform Cloud verwenden, kann der Status auch an einem zentralen Speicherort gespeichert werden, um Zusammenarbeit und Konsistenz zu ermöglichen.

Der übliche Terraform Workflow umfasst vier Schritte:

• terraform init: Initialisiert ein neues oder schon vorhandenes Terraform Arbeitsverzeichnis. Dabei werden die erforderlichen Module und Provider heruntergeladen und konfiguriert
• terraform plan: Gibt eine Vorschau auf die Änderungen, die Terraform an Infrastrukturressourcen vornehmen wird.
• terraform apply: Wendet alle erforderlichen Änderungen auf die tatsächlichen Ressourcen an.
• terraform destroy: Entfernte alle von Terraform verwalteten Ressourcen und macht somit alle Änderungen des Apply-Schritts rückgängig.

Um Ressourcen auf AWS provisionieren zu können spricht Terraform mit der AWS API und muss sich logischerweise auch mit dieser authentifizieren. Dafür müssen wir Credentials mit entsprechenden Berechtigungen auf AWS anlegen

1. Melde dich bei der AWS Management Console an und navigiere zum IAM-Service.
2. Wähle im IAM-Dashboard die Registerkarte Benutzer aus und klicke auf die Schaltfläche Benutzer hinzufügen.
3. Gib einen Namen für den Benutzer an und setze keine Haken bei Gewähren des Benutzerzugriffs auf die AWS-Managementkonsole (wird nicht benötigt für Terraform).
4. Wähle auf der Seite Berechtigungen festlegen die Option Direktes Anfügen von Richtlinien.
5. Gib im Suchfeld AmazonEC2FullAccess ein, um die managed Policy zu finden, die den Zugriff auf EC2-Ressourcen gewährt.
6. Wähle AmazonEC2FullAccess aus, indem du das Kontrollkästchen daneben aktivierst.
7. Klicke auf die Schaltfläche Weiter: Tags, wenn du dem Benutzer Tags hinzufügen möchtest. Andernfalls fährst du mit dem nächsten Schritt fort.
8. Überprüfe auf der Seite Überprüfen die Details und Berechtigungen für den Benutzer.
9. Klicke auf die Schaltfläche Benutzer erstellen, um den Automation User zu erstellen.
10. Nachdem der Benutzer erstellt wurde, klicke auf seinen Nutzernamen in der Liste
11. Wechsel nun zur Registerkarte Sicherheitsanmeldeinformationen
12. Unter Zugriffsschlüssel, drücke den Button Zugriffsschlüssel erstellen
13. Wähle die Option Befehlszeilenschnittstelle (CLI)
14. Setze auf der Seite ganz unten einen Haken, dass du eventuelle Hinweise zu Alternativen von AWS gelesen hast und drücke auf Weiter
15. Gib dem Zugriffsschlüssel eine sinnvolle Beschreibung wie terraform und drücke auf Zugriffsschlüssel erstellen
16. Auf der letzten Seite siehst du den Access Key und den Secret Access Key für den User. Notiere dir beide Keys oder lade das CSV File herunter, du kannst dir den Secret Access Key hinterher nicht noch einmal anzeigen lassen.

Nachdem wir nun AWS Credentials Credentials generiert haben, werden wir diese nun so setzen, dass Terraform sie nutzen kann.

1. Öffnen dein Terminal bzw. deine Shell
2. Exportieren den Access Key und den Secret Access Key als Umgebungsvariable mit den folgenden Befehlen:

Stelle sicher, dass du YOUR_ACCESS_KEY und YOUR_SECRET_ACCESS_KEY durch deine eigenen Credentials für deinen Automation User ersetzt. Diese Umgebungsvariablen erlauben es Terraform, sich bei AWS zu authentifizieren und deine Infrastruktur zu verwalten.

In Terraform ist eine Ressource eine logische Abstraktion einer Infrastrukturkomponente wie einer EC2-Instanz, einem S3-Bucket oder einer Datenbank. Ressourcen werden in Terraform Konfigurationsdateien definiert, und ihr Zustand wird im Terraform State gespeichert. Terraform Ressourcen haben mehrere Attribute wie Name, Region, Größe und Typ, die an bestimmte Anwendungsfälle angepasst werden können.

Terraform Definitionen werden in HCL (HashiCorp Configuration Language) geschrieben.

Im folgenden Beispiel werden wir eine einfache EC2 Instanz mit Terraform erstellen:

1. Lege eine neue Datei mit der Endung .tf (z.B. ec2.tf) und folgendem Inhalt an:

Unsere Terraform Konfiguration besagt folgendes:

• Der AWS Provider wird konfiguriert Ressourcen in der eu-central-1 Region zu erstellen
• Mit Hilfe einer datasource können wir in Terraform Informationen zu bereits bestehenden Cloud Ressourcen außerhalb unseren Workspaces abrufen. In unserem Falle rufen wir die ID eines Amazon Machine Images (AMI) , das wir für die Erstellung unserer EC2 Instanz brauchen, ab. Die Filter dienen dazu ein bestimmtes Image von Amazon Linux zu finden.
• Die Ressource mit dem Typ aws_instance und dem Namen example erstellt eine neue EC2 Instanz mit dem Instanz-Typ t2.micro. Für das Attribut AMI referenzieren wir auf die zuvor abgerufene AMI ID unter Verwendung folgender Syntax: data.<DATA_SOURCE_TYPE>.<DATA_SOURCE>.<ATTRIBUTE>

Um unseren Code nun auszuführen, müssen folgende Schritte ausgeführt werden:

1. Öffne eine neue Shell und navigiere zum Verzeichnis, in dem du die .tf-Datei erstellt hast.
2. Intialisiere mit terraform init dein Arbeitsverzeichnis. Terraform wird nun entsprechend der .tf Datei den AWS Provider herunterladen und ihn mit den zuvor gesetzten Zugangsdaten konfigurieren.
3. Führe den Befehl terraform plan aus. Die Ausgabe sollte besagen, dass versucht wird, eine Ressource zu erstellen. Überprüfe dies anhand deiner .tf-Datei.
4. Führe nun terraform apply aus, um deine Änderungen anzuwenden. Terraform gibt den Plan erneut aus und fordert dich zur Bestätigung auf. Gib yes ein, um fortzufahren.
5. Terraform wird jetzt versuchen, die EC2-Instanz zu erstellen. Nach wenigen Sekunden sollte Terraform dir mitteilen, dass es die Ressourcen erfolgreich erstellt hat. Gehe nun in die AWS Management Console (oder nutze die aws-cli) und überprüfe, ob deine EC2-Instanz erstellt wurde.
6. Um deine Instanz wieder zu zerstören, führe terraform destroy aus. Terraform wird dir mitteilen, dass es versucht, eine Ressource zu zerstören, und dich erneut um Bestätigung bitten. Gib yes ein, um fortzufahren. Nach wenigen Sekunden sollte Terraform dir mitteilen, dass es eine Ressource erfolgreich zerstört hat. Überprüfe erneut die Management Console, um zu verifizieren, dass die Instanz verschwunden ist.

1. Organisiere deinen Terraform Code in wiederverwendbaren Modulen, die verwandte Ressourcen zusammenfassen und eine modulare Architektur für deinen Infrastrukturcode bereitstellen.
2. Befolge das DRY-Prinzip (Don’t repeat yourself): Vermeide mehrfach den gleichen Code zu schreiben, indem du Variablen, Datenquellen und Module effektiv verwendest. Zentralisiere gemeinsame Konfigurationen und Parameter, um die Redundanzen zu reduzieren und ihn gleichzeitig lesbarer zu machen.
3. Nutze Variablen, um deinen Code flexibler und wiederverwendbarer zu machen. Du kannst Variablen für konfigurierbare Parameter wie z.B. Ressourcennamen oder Instanzgrößen verweden.
4. Versioniere deinen Code. Speichere deinen Terraform Code in einem Git Repository, um Zusammenarbeit zu ermöglichen, Änderungen im Laufe der Zeit zu verfolgen und Rollbacks bei Bedarf zu erleichtern.
5. Verwalte deinen Terraform State ordnungsgemäß und nutze keinen lokalen State für produktive Umgebungen, um den aktuellen Zustand deiner Infrastruktur zu verfolgen. Verwende Remote-Backends wie AWS S3 oder Terraform Cloud für die gemeinsame Statusverwaltung, um Zusammenarbeit zu ermöglichen und Konsistenz zwischen Teammitgliedern zu gewährleisten.

AWS (Amazon Web Services) ist eine Cloud-Computing-Plattform von Amazon, die eine Vielzahl von Diensten für Computing, Storage, Netzwerk und Datenbanken bietet. Mit AWS kannst du Kosten senken, Ressourceneffizienz erhöhen und Skalierbarkeit, Sicherheit und Zuverlässigkeit von Anwendungen und Infrastruktur verbessern.

Durch das Erlernen von AWS kannst du wertvolle Cloud-Fähigkeiten entwickeln und dadurch in der Lage sein, Cloud-basierte Anwendungen und Infrastrukturen zu entwerfen, zu implementieren und zu verwalten. Dies ist insbesondere in Zeiten der Digitalisierung und des Wachstums von Cloud-Computing-Technologien von Bedeutung, um auf dem Markt wettbewerbsfähig zu bleiben.

Skalierbarkeit:

Cloud Computing ermöglicht es Unternehmen, ihre Rechenressourcen einfach zu erhöhen oder zu verringern, basierend auf sich ändernden Anforderungen. Dadurch haben sie die benötigte Rechenleistung, ohne teure Infrastruktur-Upgrades durchführen zu müssen.

Geo-Redundanz:

Cloud-Provider speichern Daten und Anwendungen an mehreren geografischen Standorten, was zusätzliche Zuverlässigkeit bietet und den Zugriff auf Daten und Anwendungen im Falle des Ausfalls eines Standortes sicherstellt.

Bedarfsgerechte Ressourcenplanung:

Cloud Computing ermöglicht es Unternehmen, schnell Rechenressourcen bereitzustellen und abzubauen, um sich an sich ändernde Anforderungen und Bedürfnisse anzupassen, während sie die Kosten kontrollieren. Längerfristige Commitments hingegen können die Kosten noch weiter senken.

Was ist das AWS Free Tier und wie melde ich mich an?

Das AWS Free Tier ist ein Programm, das neuen AWS-Benutzern kostenlosen Zugang zu bestimmten AWS-Diensten für bis zu 12 Monate nach Erstellung eines AWS-Kontos bietet. Es bietet Benutzern die Möglichkeit, AWS-Dienste auszuprobieren, bevor sie sich für die Bezahlung entscheiden.

Wie erstelle ich ein AWS Account?

1. Besuche amazon.com
2. Klicke auf „AWS-Konto erstellen“
3. Gib deine Kontoinformationen ein (E-Mail-Adresse, Passwort und Kontoname)
4. Gib deine Kontaktdaten ein
5. Führe die Zahlungsverifizierung durch
   1. Gib Kreditkartendetails ein
   2. AWS wird der Karte einen kleinen Betrag belasten, um sicherzustellen, dass sie gültig ist (wird sofort zurückerstattet)
6. Führe die Identitätsverifizierung durch, wähle zwischen:
   • SMS
   • Anruf
   • Kreditkarte
7. Lese und akzeptiere die AWS-Kundenvereinbarung
8. Du kannst dich jetzt in deinem neuen AWS-Konto anmelden

Die AWS Management Console ist eine webbasierte Benutzeroberfläche, die es Benutzern ermöglicht, ihre AWS-Ressourcen und -Dienste an einem zentralen Ort zu verwalten und zu kontrollieren. Es bietet eine benutzerfreundliche grafische Benutzeroberfläche, mit der Benutzer Aufgaben wie Starten und Verwalten von EC2-Instanzen, Konfigurieren von Sicherheitsgruppen, Erstellen und Verwalten von S3-Buckets sowie Einrichten von Abrechnungs- und Zahlungsinformationen durchführen können.

Die wichtigsten Funktionen der AWS Management Console

• Navigationsmenü: Das Navigationsmenü befindet sich auf der linken Seite der Konsole und bietet Zugriff auf alle AWS-Services und -Ressourcen. Du kannst die verschiedenen Abschnitte erweitern und zusammenfalten, um den gewünschten Service einfach zu finden.
• Dashboard: Das Dashboard bietet eine Übersicht über dein AWS-Konto, einschließlich Verwendungs- und Abrechnungsinformationen, kürzlicher Aktivitäten und Empfehlungen zur Kostenoptimierung und Verbesserung der Sicherheit.
• Service-Seiten: Jeder AWS-Service hat seine eigene Seite in der Konsole, die Zugriff auf alle Funktionen und Einstellungen für diesen Service bietet. Diese Seiten werden aufgerufen, indem du auf den Servicenamen im Navigationsmenü klickst.
• Suchleiste: Die Suchleiste ermöglicht es dir, AWS-Ressourcen und -Dienste schnell anhand von Schlüsselwörtern zu finden.
• Support-Center: Das Support-Center bietet Zugang zu Dokumentationen, Foren und Support-Optionen, um bei der Fehlerbehebung zu helfen und mehr über AWS zu erfahren.
• Benachrichtigungen: Die Konsole zeigt Benachrichtigungen für wichtige Ereignisse an, wie z.B. neue Service-Starts, Updates und Sicherheitswarnungen.
• Einstellungen: Das Einstellungsmenü ermöglicht es dir, deine Kontoeinstellungen zu verwalten, wie z.B. die Konfiguration der Multi-Faktor-Authentifizierung, die Einrichtung von Abrechnungs- und Zahlungsinformationen sowie die Verwaltung von Benutzern und Berechtigungen.

Was sind EC2-Instanzen?

EC2-Instanzen sind virtuelle Maschinen, die von Amazon Web Services (AWS) auf Bedarf gemietet werden können. Sie bieten eine flexible, skalierbare, kosteneffektive, zuverlässige und sichere Möglichkeit, Anwendungen in der Cloud zu erstellen und auszuführen.

Schritt-für-Schritt-Anleitung zur Erstellung deiner ersten EC2-Instanz

1. Melde dich in deinem AWS-Konto an und navigiere zum EC2-Dashboard.
2. Klicke auf die Schaltfläche „Instanz starten“, um den Prozess zum Erstellen einer neuen Instanz zu starten.
3. Wähle ein Amazon Machine Image (AMI) aus, das zum Betriebssystem und zur Software passt, die du für deine Instanz benötigst.
4. Wähle einen Instanztyp aus, der deinen Anforderungen an Rechenleistung, Speicher und Speicherplatz entspricht.
5. Konfiguriere zusätzliche Einstellungen wie Netzwerkeinstellungen, Security Groups und Storageoptionen nach Bedarf.
6. Überprüfe und bestätige die Instanzdetails und -einstellungen, klicke dann auf die Schaltfläche „Starten“, um deine neue Instanz zu erstellen.
7. Du wirst aufgefordert, einen neuen Schlüsselpaar zu erstellen oder ein vorhandenes auszuwählen, um auf deine Instanz sicher zuzugreifen. Folge den Anweisungen, um ein neues Schlüsselpaar zu erstellen, wenn du noch keines hast.
8. Sobald deine Instanz gestartet ist, kannst du über SSH oder andere Remote-Access-Tools mit der IP-Adresse oder dem DNS-Namen darauf zugreifen.

Was sind weitere beliebte AWS Services?

• Amazon S3: Amazon Simple Storage Service (S3) ist ein Service, der hoch skalierbaren, dauerhaften und sicheren Objektspeicher in der Cloud bietet. Er ist für eine Vielzahl von Anwendungsfällen konzipiert, einschließlich Datensicherung und -archivierung, Web- und Mobilanwendungen sowie Big-Data-Analyse.
• Amazon RDS: Amazon Relational Database Service (RDS) ist ein Service, der das Einrichten, Betreiben und Skalieren einer relationalen Datenbank in der Cloud einfach macht. Es unterstützt mehrere Datenbank-Engines, einschließlich MySQL, PostgreSQL, Oracle und SQL Server.
• Amazon DynamoDB: Amazon DynamoDB ist ein schneller und flexibler NoSQL-Datenbankdienst, der bei jeder Skalierung eine konsistente Latenz im einstelligen Millisekundenbereich bietet. Er ist für Anwendungen konzipiert, die eine geringe Latenz und hohe Skalierbarkeit erfordern, wie z.B. Gaming, Ad-Tech und IoT.
• AWS Lambda: AWS Lambda ist ein serverless Computing-Dienst, mit dem du Code ausführen kannst, ohne Server bereitzustellen oder zu verwalten. Du kannst Code in Reaktion auf Ereignisse ausführen, z.B. Änderungen an Daten in einem Amazon S3-Bucket oder einer Amazon DynamoDB-Tabelle, und er skaliert automatisch, um jede Menge an Traffic zu bewältigen.

• Verwende Multi-Faktor-Authentifizierung (MFA) – Erzwinge MFA für alle Benutzerkonten, einschließlich des Root-Accounts.
• Implementiere Zugriffskontrolle: Verwende AWS Identity and Access Management (IAM), um Benutzerzugriff auf AWS-Ressourcen zu verwalten und nur die benötigten Berechtigungen für jeden Benutzer oder jede Gruppe zuzuweisen, um ihre Aufgaben auszuführen.
• Erstelle separate Konten für verschiedene Umgebungen: Erstelle separate Accounts für Produktions-, Entwicklungs- und Testumgebungen, um versehentliche Änderungen oder Sicherheitsverletzungen zu vermeiden.
• Richte Abrechnungsalarme ein: AWS bietet eine Reihe von Abrechnungs- und Kostenverwaltungstools, mit denen du deine Ausgaben überwachen und kontrollieren kannst. Richte Abrechnungsalarme ein, um Benachrichtigungen zu erhalten, wenn deine Ausgaben bestimmte Grenzwerte überschreiten.