AWS Cloud Practitioner 07: Integration, Deployment und Monitoring

Bis hierher haben wir die Bausteine einzeln kennengelernt, also Compute, Storage, Datenbanken und Netz. In diesem Teil geht es um das, was zwischen den Bausteinen passiert und was nach dem Aufbau kommt. Nachrichtendienste verbinden Anwendungen, ohne sie fest aneinanderzuketten, Vorlagen bauen Infrastruktur reproduzierbar auf, und eine Handvoll Monitoring-Dienste beantwortet, was gerade läuft und wer was geändert hat. Dazu kommen Dienste für virtuelle Desktops, IoT-Geräte, Web-Frontends und E-Mail. In der Prüfung tauchen diese Themen in Domain 2 (Monitoring und Auditing, Task 2.2) und Domain 3 (Application Integration und Developer Tools, Task 3.8) auf, meist als Zuordnungsfrage nach dem Muster „Stichwort → Dienst“.

Entkoppeln statt direkt aufrufen

Ruft ein Webshop nach jeder Bestellung den Versanddienst direkt auf, hängen beide Systeme aneinander. Fällt der Versand aus, scheitert auch die Bestellung. Kommt eine Lastspitze, muss der Versand sie im selben Moment verkraften. Messaging-Dienste setzen einen Puffer dazwischen. Der Shop legt eine Nachricht ab und ist fertig, der Versand holt sie ab, wenn er Kapazität hat.

SQS, SNS und Kinesis entkoppeln Anwendungen, damit Lastspitzen nicht bis zum nächsten System durchschlagen. Unterschiedlich ist, wer die Nachricht bewegt, wie viele Empfänger sie bekommen und wie lange sie liegen bleibt.

Queue, Topic und Datenstrom

Amazon SQS (Simple Queue Service) ist eine Warteschlange. Ein Producer schreibt Nachrichten hinein, Consumer fragen die Queue ab (Pull) und holen sich je eine Nachricht. Mehrere Consumer teilen sich so die Arbeit, jede Nachricht wird nur von einem verarbeitet und danach aus der Queue gelöscht. Unverarbeitete Nachrichten bleiben standardmäßig vier Tage liegen, einstellbar von einer Minute bis zu vierzehn Tagen (SQS FAQ). Wer eine feste Reihenfolge braucht, nimmt eine FIFO-Queue.

Amazon SNS (Simple Notification Service) arbeitet umgekehrt. Ein Publisher schickt eine Nachricht an ein Topic, und SNS schiebt sie aktiv an alle Subscriber (Push). Subscriber können E-Mail-Adressen, Telefonnummern für SMS, Lambda-Funktionen, HTTP-Endpunkte oder SQS-Queues sein. Jeder bekommt jede Nachricht. SNS ist kein Speicher zum späteren Abholen. Ist ein Empfänger nicht erreichbar, versucht SNS die Zustellung nach einer Retry-Policy erneut. Ist sie ausgeschöpft, verwirft SNS die Nachricht, sofern an der Subscription keine Dead-Letter-Queue hängt (SNS Doku).

Daraus ergibt sich das bekannteste Muster, der Fan-out. Ein SNS-Topic verteilt jede Bestellung an mehrere SQS-Queues, etwa eine für den Versand und eine für die Buchhaltung. SNS sorgt für die Verteilung, SQS für den Puffer. Genau diese Kombination bauen wir weiter unten im Hands-on auf.

Amazon Kinesis ist für Datenströme gedacht, nicht für einzelne Aufträge. Clickstreams einer Website, Messwerte von IoT-Geräten oder Logdaten laufen in Echtzeit in Kinesis Data Streams, Firehose lädt sie in Ziele wie S3 oder Redshift.

Amazon EventBridge reagiert auf Ereignisse und Zeitpläne. Eine Regel kann zum Beispiel bei jedem Root-Login eine Nachricht an ein SNS-Topic schicken, ein Schedule startet zu festen Zeiten eine Lambda-Funktion, so wie ein Cron-Job. EventBridge kann Ereignisse archivieren und später erneut abspielen (Archive und Replay). AWS Step Functions baut serverlose Workflows aus mehreren Schritten, typischerweise Lambda-Funktionen, und kann dabei auf eine menschliche Freigabe warten. EventBridge nennt der Exam Guide in Task 3.8 ausdrücklich neben SQS und SNS, Step Functions steht in der In-Scope-Liste unter Application Integration.

Amazon MQ ist der verwaltete Message Broker für ActiveMQ und RabbitMQ. Er spricht offene Protokolle wie MQTT oder AMQP und ist für bestehende Anwendungen gedacht, die schon einen solchen Broker nutzen und migriert werden. In der In-Scope-Liste des Exam Guide steht er nicht.

Infrastruktur als Vorlage

Wer eine Umgebung in der Konsole zusammenklickt, kann sie kaum identisch ein zweites Mal bauen. AWS CloudFormation löst das mit Infrastructure as Code. Eine Vorlage in JSON oder YAML beschreibt deklarativ, welche Ressourcen es geben soll, CloudFormation legt sie als Stack an, in der richtigen Reihenfolge und mit den nötigen Abhängigkeiten. Dieselbe Vorlage lässt sich in anderen Regionen und Accounts wiederholen. Löschen wir den Stack, verschwinden alle Ressourcen darin.

Das AWS CDK (Cloud Development Kit) setzt eine Ebene höher an. Infrastruktur wird in einer Programmiersprache wie TypeScript, JavaScript, Python, Java, C# oder Go geschrieben (CDK Developer Guide) und zu einer CloudFormation-Vorlage übersetzt. Im Exam Guide steht das CDK nicht in der In-Scope-Liste, CloudFormation dagegen schon.

AWS Elastic Beanstalk ist die PaaS-Variante. Wir laden Anwendungscode hoch, Beanstalk baut die Umgebung dafür selbst auf, mit EC2-Instanzen, Auto Scaling Group, Load Balancer und bei Bedarf einer RDS-Datenbank. Beanstalk selbst kostet nichts, bezahlt werden nur die Ressourcen, die es anlegt. Der Unterschied zu CloudFormation liegt in der Verantwortung. Bei CloudFormation beschreiben wir jede Ressource selbst, bei Beanstalk entscheidet die Plattform und wir liefern nur den Code.

Betrieb ohne SSH

AWS Systems Manager verwaltet Server im Betrieb, in AWS wie im eigenen Rechenzentrum. Er spielt Patches ein, führt per Run Command Befehle auf vielen Maschinen gleichzeitig aus und hält im Parameter Store Konfigurationswerte vor. Voraussetzung ist der SSM Agent auf der Maschine, egal ob sie eine EC2-Instanz ist oder im eigenen Rechenzentrum steht.

Der Session Manager ist ein Teil davon und öffnet eine Shell auf der Instanz, ohne SSH, ohne offenen Port 22 und ohne Bastion Host. Die Sitzungen lassen sich nach S3 oder CloudWatch protokollieren. Für die Security Group aus Teil 06 heißt das, die SSH-Regel kann entfallen.

Für Build und Auslieferung von Software nennt der Exam Guide AWS CodeBuild (baut und testet Code) und AWS CodePipeline (orchestriert den Ablauf vom Repository bis zum Rollout) als prüfungsrelevant. AWS CodeDeploy, das Anwendungen auf EC2 und eigene Server ausrollt, steht dagegen auf der Out-of-Scope-Liste, ebenso CodeArtifact und CloudShell. Für das Stichwort „hybrid“ ist in der Prüfung daher Systems Manager die sichere Antwort.

Desktops, Geräte, Frontends und E-Mail

Task 3.8 des Exam Guide nennt neben Messaging und Developer Tools eine Reihe weiterer Dienste. Sie bringen Desktops und Anwendungen auf Endgeräte, binden IoT-Geräte an, stellen Web- und Mobile-Frontends bereit und verschicken E-Mails (Exam Guide, Domain 3). In der Prüfung erscheinen sie als Zuordnungsfrage, oft mit einem Nachbardienst als falscher Antwort.

Amazon WorkSpaces stellt virtuelle Desktops als verwalteten Dienst bereit, also Desktop as a Service. Mitarbeitende bekommen einen Windows- oder Linux-Desktop, der in AWS läuft, und greifen von ihrem eigenen Gerät darauf zu (Amazon WorkSpaces). Wir nehmen WorkSpaces, wenn ein vollständiger Arbeitsplatz gebraucht wird, etwa für Remote-Arbeit, ohne dass Hardware verteilt werden muss. Nah dran liegt EC2, aber eine EC2-Instanz ist ein Server, den wir selbst betreiben, ein WorkSpace ist ein fertiger Arbeitsplatz für Endanwender.

Amazon AppStream 2.0 streamt einzelne Desktop-Anwendungen in den Browser. Die Anwendung läuft in AWS, die Nutzer sehen nur ihr Fenster. AWS führt den Dienst inzwischen unter dem Namen Amazon WorkSpaces Applications, der Exam Guide verwendet weiterhin AppStream 2.0 (WorkSpaces Applications FAQ, What’s New zu WorkSpaces Applications, Administration Guide). Wir nehmen ihn, wenn nur ein bestimmtes Programm bereitgestellt werden soll und kein ganzer Desktop. Die typische Prüfungsfrage zielt auf genau diese Grenze, ganzer Desktop gegen einzelne Anwendung.

Amazon WorkSpaces Secure Browser gibt Mitarbeitenden über den Browser Zugriff auf interne Websites und SaaS-Anwendungen, ohne dass Unternehmensdaten auf dem Endgerät landen (WorkSpaces Secure Browser). Wir nehmen ihn, wenn es nur um Web-Anwendungen geht. Die Verwechslungsgefahr heißt hier AppStream 2.0, das beliebige Anwendungen streamt und nicht nur Webseiten. Ab dem 29. Oktober 2026 nimmt AWS für WorkSpaces Secure Browser keine Neukunden mehr an (laut Produktseite). Prüfungsstoff bleibt der Dienst, solange der Exam Guide ihn nennt.

AWS IoT Core verbindet Geräte wie Sensoren oder Maschinen mit der Cloud. Die Geräte schicken ihre Nachrichten per MQTT oder HTTPS an IoT Core, und Regeln leiten sie an andere AWS-Dienste weiter, etwa an Lambda, S3 oder Kinesis (AWS IoT Core, IoT-Regelaktionen). Verwechselt wird IoT Core mit Kinesis. Kinesis nimmt Datenströme auf und verarbeitet sie, IoT Core ist der Anschlusspunkt, an dem sich die Geräte melden. Amazon MQ spricht zwar ebenfalls MQTT, ist aber ein Broker für bestehende Anwendungen und kein Dienst für Geräteflotten.

AWS Amplify richtet sich an Web- und Mobile-Frontends. Es hostet Webanwendungen direkt aus einem Git-Repository und bindet Backend-Funktionen wie Anmeldung, Daten und Dateispeicher an, ohne dass wir die Dienste dahinter einzeln einrichten (AWS Amplify). Wir nehmen Amplify, wenn ein Frontend-Team eine Web- oder Mobile-App bauen und ausliefern will. Gegenstück ist Elastic Beanstalk. Beanstalk betreibt serverseitige Anwendungen auf EC2, Amplify zielt auf Frontend- und Mobile-Entwicklung.

Amazon SES (Simple Email Service) versendet E-Mails aus Anwendungen, etwa Bestellbestätigungen, Links zum Zurücksetzen von Passwörtern oder Newsletter, und kann E-Mails auch empfangen (Amazon SES). Verwechselt wird SES mit SNS, weil auch SNS E-Mails zustellen kann. SNS schickt dieselbe Benachrichtigung an alle Subscriber eines Topics, SES verschickt individuelle E-Mails an Kunden, mit eigenem Absender und eigener Gestaltung.

Monitoring und Audit nach Fragen sortiert

Die Monitoring-Dienste lassen sich am besten über die Frage auseinanderhalten, die jeder von ihnen beantwortet. Der Exam Guide fasst das in Task 2.2 zusammen: Monitoring mit CloudWatch, Auditing mit CloudTrail und Config.

Amazon CloudWatch ist der Sammelpunkt für Betriebsdaten und besteht aus mehreren Teilen. Metrics liefern Zahlen über die Zeit. Für EC2 kommen im Basic Monitoring die Statuscheck-Metriken im Minutentakt, alle übrigen wie CPU und Netzwerk im Fünf-Minuten-Takt. Mit dem kostenpflichtigen Detailed Monitoring gibt es auch diese im Minutentakt (EC2 User Guide). Den Arbeitsspeicher misst CloudWatch ohne zusätzlichen Agent nicht. Die Billing-Metrik für die geschätzten Kosten gibt es nur in us-east-1.

Alarms beobachten eine Metrik und kennen die Zustände OK, INSUFFICIENT_DATA und ALARM. Als Aktion können sie eine Auto Scaling Group skalieren lassen, eine EC2-Instanz stoppen, neu starten oder wiederherstellen oder eine Nachricht an ein SNS-Topic schicken. CloudWatch Logs sammelt Protokolle von Lambda, ECS, Elastic Beanstalk oder Route 53. Von einer EC2-Instanz kommen Logs nur mit dem CloudWatch Agent, und derselbe Agent liefert auch die fehlende RAM-Metrik.

AWS CloudTrail zeichnet API-Aufrufe im Account auf, also wer wann welche Aktion ausgeführt hat. Das ist standardmäßig eingeschaltet. In der Event History stehen die Management Events der letzten 90 Tage, auch wenn nie ein Trail angelegt wurde. Wer die Aufrufe länger aufbewahren will, legt einen Trail an. Er schreibt die Events dauerhaft in einen S3-Bucket und auf Wunsch zusätzlich in CloudWatch Logs. Ein Trail, den wir in der Konsole anlegen, gilt immer für alle Regionen. Einen Trail für eine einzelne Region legen wir ausschließlich über die CLI an (CloudTrail User Guide). Wo sicherheitsrelevante Logs erfasst und abgelegt werden, fragt der Exam Guide in Task 2.2 ausdrücklich ab. CloudTrail Insights erkennt zusätzlich ungewöhnliche Muster in den Aufrufen.

AWS Config zeichnet dagegen den Zustand der Ressourcen auf. Wir sehen, wie eine Security Group oder ein Bucket zu einem bestimmten Zeitpunkt konfiguriert war, und können mit Compliance-Regeln prüfen, ob Ressourcen bestimmte Vorgaben einhalten. Config arbeitet pro Region.

Der Unterschied zwischen beiden ist eine der häufigsten Prüfungsfallen. CloudTrail beantwortet „wer hat was getan“, Config beantwortet „wie sah es aus und ist das regelkonform“. Ein gelöschter Bucket ist ein Fall für CloudTrail, eine Security Group, die seit drei Wochen Port 22 für alle öffnet, einer für Config.

AWS X-Ray verfolgt einzelne Requests durch verteilte Anwendungen und zeigt, in welchem Dienst eine Anfrage hängen bleibt. Das AWS Health Dashboard meldet Störungen auf AWS-Seite. Die Service History ist für alle einsehbar, die Ansicht „Your Account“ zeigt Ereignisse, die den eigenen Account betreffen. AWS hat die früheren Dienste Service Health Dashboard und Personal Health Dashboard im AWS Health Dashboard zusammengeführt (AWS-Blog). Taucht einer der alten Namen auf, ist dieser Dienst gemeint.

Hands-on

Bleiben Ressourcen länger stehen oder wird der Free Plan überschritten, können Kosten entstehen. Deshalb gehört das Löschen zum Hands-on dazu.

Für das Hands-on bauen wir den Fan-out im Kleinen mit CloudFormation. Ein SNS-Topic für Bestellungen, eine SQS-Queue für den Versand, eine Queue Policy, die nur diesem Topic das Senden erlaubt, und eine Subscription, die beides verbindet. RawMessageDelivery sorgt dafür, dass die Nachricht ohne SNS-Umschlag in der Queue landet.

# messaging.yaml
AWSTemplateFormatVersion: "2010-09-09"
Description: CCP Teil 07, SNS-Topic mit SQS-Queue als Subscriber
Resources:
  Bestellungen:
    Type: AWS::SNS::Topic
    Properties:
      TopicName: ccp-demo-bestellungen
  Versand:
    Type: AWS::SQS::Queue
    Properties:
      QueueName: ccp-demo-versand
  VersandPolicy:
    Type: AWS::SQS::QueuePolicy
    Properties:
      Queues:
        - !Ref Versand
      PolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              Service: sns.amazonaws.com
            Action: sqs:SendMessage
            Resource: !GetAtt Versand.Arn
            Condition:
              ArnEquals:
                aws:SourceArn: !Ref Bestellungen
  VersandAbo:
    Type: AWS::SNS::Subscription
    Properties:
      TopicArn: !Ref Bestellungen
      Protocol: sqs
      Endpoint: !GetAtt Versand.Arn
      RawMessageDelivery: true
Outputs:
  TopicArn:
    Value: !Ref Bestellungen
  QueueUrl:
    Value: !Ref Versand

Legen wir den Stack an und warten, bis er fertig ist.

aws cloudformation create-stack --stack-name ccp-demo-messaging \
  --template-body file://messaging.yaml --region eu-central-1
aws cloudformation wait stack-create-complete \
  --stack-name ccp-demo-messaging --region eu-central-1
aws cloudformation describe-stacks --stack-name ccp-demo-messaging \
  --region eu-central-1 --query 'Stacks[0].StackStatus' --output text

CREATE_COMPLETE

In der Konsole: CloudFormation → Stacks → Create stack → With new resources (standard) → Upload a template file → Stack name → Next … Submit. Die Detailseite des Stacks listet im Tab Resources die angelegten Ressourcen, der Tab Outputs zeigt TopicArn und QueueUrl.

Nach 68 Sekunden stand der Stack mit vier Ressourcen. Jetzt schicken wir eine Bestellung an das Topic und holen sie auf der anderen Seite aus der Queue. Topic-ARN und Queue-URL enthalten die Account-ID und sind in jedem Account anders. Wir lesen sie deshalb aus den Outputs des Stacks, statt sie abzutippen.

TOPIC_ARN=$(aws cloudformation describe-stacks --stack-name ccp-demo-messaging \
  --region eu-central-1 --output text \
  --query "Stacks[0].Outputs[?OutputKey=='TopicArn'].OutputValue")
QUEUE_URL=$(aws cloudformation describe-stacks --stack-name ccp-demo-messaging \
  --region eu-central-1 --output text \
  --query "Stacks[0].Outputs[?OutputKey=='QueueUrl'].OutputValue")

aws sns publish --topic-arn "$TOPIC_ARN" --region eu-central-1 \
  --message '{"bestellung": 4711, "artikel": "Lernkarten CLF-C02"}'

aws sqs receive-message --queue-url "$QUEUE_URL" --region eu-central-1 \
  --query 'Messages[0].Body' --output text

{"bestellung": 4711, "artikel": "Lernkarten CLF-C02"}

In der Konsole: SNS → Topics → ccp-demo-bestellungen → Publish message, danach Amazon SQS → Queues → ccp-demo-versand → Send and receive messages → Poll for messages; ein Klick auf die Message-ID öffnet die Nachricht.

In der Queue lag genau die Nachricht, die wir an SNS geschickt hatten. Der Publisher wusste dabei nichts von der Queue, er kannte nur das Topic. Abgeholt heißt in SQS noch nicht gelöscht. Nach der Verarbeitung entfernt der Consumer die Nachricht mit dem ReceiptHandle aus der Antwort von receive-message (dafür die Abfrage ohne --query ausführen).

aws sqs delete-message --queue-url "$QUEUE_URL" --region eu-central-1 \
  --receipt-handle "<ReceiptHandle aus receive-message>"

In der Konsole: in der Liste der empfangenen Nachrichten die Nachricht anhaken → Delete.

In Teil 04 haben wir am Ende den Bucket ccp-demo-edf11cfc gelöscht. Suchen wir den Aufruf.

aws cloudtrail lookup-events --region eu-central-1 \
  --lookup-attributes AttributeKey=EventName,AttributeValue=DeleteBucket \
  --query 'Events[].[EventTime,Username,Resources[0].ResourceName]' --output text

2026-10-25T10:02:16Z    demo-admin    ccp-demo-edf11cfc

Die Ausgabe ist nachgebaut und gekürzt, das Zeitformat vereinfacht und der IAM-Username maskiert. Zeitpunkt, IAM-User und Bucketname stehen in einem Eintrag.

In der Konsole: **CloudTrail → Event history → **, unter Lookup attributes „Event name“ wählen und DeleteBucket eintragen.

Der Screenshot stammt aus einem späteren Lauf und enthält deshalb weitere DeleteBucket-Einträge aus der Serie. Die Konsole zeigt die Uhrzeit in der eingestellten Zeitzone, hier UTC+1, daher steht beim Eintrag für ccp-demo-edf11cfc 11:02:16 statt 10:02:16.

Interessant ist, was im Account fehlt.

aws cloudtrail describe-trails --region eu-central-1

{
    "trailList": []
}

In der Konsole: CloudTrail → Trails.

Es ist kein einziger Trail angelegt. Die Event History mit den Management Events der letzten 90 Tage ist trotzdem da, weil CloudTrail sie für jeden Account standardmäßig führt.

Zum Aufräumen genügt es, den Stack zu löschen. CloudFormation entfernt Topic, Queue, Policy und Subscription gemeinsam.

aws cloudformation delete-stack --stack-name ccp-demo-messaging --region eu-central-1
aws cloudformation wait stack-delete-complete \
  --stack-name ccp-demo-messaging --region eu-central-1

Für die Prüfung

Typische Fallen:

• CloudTrail oder Config. CloudTrail protokolliert Aktionen, Config den Zustand von Ressourcen. „Wer“ zeigt auf CloudTrail, „wie war es konfiguriert“ auf Config.
• Event History endet nach 90 Tagen. Sollen API-Aufrufe länger nachvollziehbar sein, braucht es einen Trail, der nach S3 schreibt.
• SNS ist keine Warteschlange. Soll eine Nachricht liegen bleiben, bis jemand sie abholt, ist SQS die Antwort, bei mehreren Empfängern SNS mit SQS dahinter.
• SNS oder SES. Eine Benachrichtigung an alle Subscriber ist SNS, die individuelle E-Mail an Kunden ist SES.
• WorkSpaces oder AppStream 2.0. Ein ganzer Desktop ist WorkSpaces, eine einzelne Anwendung im Browser AppStream 2.0, das AWS heute als WorkSpaces Applications führt.
• Beanstalk selbst kostet nichts. Bezahlt werden nur die Ressourcen, die Beanstalk anlegt, also etwa EC2-Instanzen und Load Balancer.
• Alte Namen, gleicher Dienst. Service Health Dashboard und Personal Health Dashboard sind heute das AWS Health Dashboard.
• RAM ist keine Standardmetrik. Arbeitsspeicher und Logs von EC2 gibt es nur mit dem CloudWatch Agent.
• Billing-Alarm nur in us-east-1. Die Kostenmetrik liegt ausschließlich in dieser Region.
• Hybrid heißt nicht CodeDeploy. CodeDeploy ist laut Exam Guide out of scope, die prüfungsrelevante Hybrid-Antwort im Betrieb ist Systems Manager.

Quellen

• AWS Certified Cloud Practitioner (CLF-C02), Exam Guide: https://docs.aws.amazon.com/aws-certification/latest/cloud-practitioner-02/cloud-practitioner-02.html
• Exam Guide, Domain 2 (Task 2.2, Monitoring und Auditing): https://docs.aws.amazon.com/aws-certification/latest/cloud-practitioner-02/cloud-practitioner-02-domain2.html
• Exam Guide, Domain 3 (Task 3.8, Application Integration, Developer Tools): https://docs.aws.amazon.com/aws-certification/latest/cloud-practitioner-02/cloud-practitioner-02-domain3.html
• In-Scope-Services: https://docs.aws.amazon.com/aws-certification/latest/cloud-practitioner-02/clf-02-in-scope-services.html
• Out-of-Scope-Services: https://docs.aws.amazon.com/aws-certification/latest/cloud-practitioner-02/clf-02-out-of-scope-services.html
• Amazon SQS FAQ (Aufbewahrung): https://aws.amazon.com/sqs/faqs/
• Amazon SNS, Zustellversuche und Dead-Letter-Queues: https://docs.aws.amazon.com/sns/latest/dg/sns-message-delivery-retries.html
• AWS CDK, unterstützte Sprachen: https://docs.aws.amazon.com/cdk/v2/guide/languages.html
• EC2 Basic und Detailed Monitoring: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/manage-detailed-monitoring.html
• AWS CloudTrail, Trail anlegen: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html
• AWS Health Dashboard, Zusammenführung der früheren Dashboards: https://aws.amazon.com/blogs/mt/learning-about-aws-service-health-with-the-new-aws-health-dashboard/
• Amazon WorkSpaces: https://aws.amazon.com/workspaces/
• Amazon WorkSpaces Applications (ehemals AppStream 2.0), FAQ: https://aws.amazon.com/workspaces/applications/faqs/
• Amazon WorkSpaces Applications, Administration Guide: https://docs.aws.amazon.com/appstream2/latest/developerguide/what-is-appstream.html
• What’s New, WorkSpaces Applications (AppStream 2.0) mit IPv6: https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-appstream-2-0-supports-ipv6/
• Amazon WorkSpaces Secure Browser: https://aws.amazon.com/workspaces/secure-browser/
• AWS IoT Core: https://aws.amazon.com/iot-core/
• AWS IoT, Regelaktionen: https://docs.aws.amazon.com/iot/latest/developerguide/iot-rule-actions.html
• AWS Amplify: https://aws.amazon.com/amplify/
• Amazon SES: https://aws.amazon.com/ses/
• AWS Elastic Beanstalk, Preise: https://aws.amazon.com/elasticbeanstalk/pricing/

Im nächsten Teil geht es um Sicherheit und Compliance, von Shield und WAF über KMS bis zu GuardDuty und Security Hub, in AWS Cloud Practitioner 08.