Einführung in Cloud Computing: Vergleich von AWS, Azure und Google Cloud und Bereitstellung einer einfachen App

Cloud-Computing ermöglicht es, Infrastrukturmanagement auszulagern und bedarfsgerecht zu skalieren, doch die Vielzahl an Diensten und Optionen kann überwältigend sein. Dieses Tutorial vergleicht Amazon Web Services (AWS), Microsoft Azure und Google Cloud Platform (GCP) aus der Perspektive eines fortgeschrittenen Entwicklers und führt Sie durch die Bereitstellung einer einfachen containerisierten Web-App auf den modernen, verwalteten Plattformen der jeweiligen Anbieter. Am Ende können Sie einen Anbieter gezielt auswählen und einen grundlegenden Dienst in wenigen Minuten bereitstellen.

Cloud-Service-Modelle in einer Minute

• IaaS (Infrastructure as a Service): Sie verwalten virtuelle Maschinen (VMs), Festplatten und Netzwerke. Maximale Kontrolle, mehr Betriebsoverhead. Beispiele: AWS EC2, Azure Virtual Machines, Google Compute Engine.
• PaaS (Platform as a Service): Sie deployen Code oder Container; die Plattform verwaltet OS, Skalierung und Patches. Schneller Einstieg, weniger niedrigstufige Kontrolle. Beispiele: AWS App Runner/Elastic Beanstalk, Azure App Service/Container Apps, Google Cloud Run/App Engine.
• Serverless/Funktionen: Ereignisgetriebener Code; skaliert bis auf null; Abrechnung nach Nutzung. Beispiele: AWS Lambda, Azure Functions, Google Cloud Functions.

Für die meisten Teams zu Beginn bietet ein PaaS bzw. serverless Container (Cloud Run, App Runner, Azure Container Apps) das beste Verhältnis von Geschwindigkeit zu Kontrolle.

AWS vs Azure vs Google Cloud: worauf es ankommt

Compute und Container

• AWS
  • VMs: EC2 für feinkörnige Kontrolle.
  • Container: ECS (einfacher) oder EKS (Kubernetes). App Runner für serverlose Container; Elastic Beanstalk für verwaltete Apps.
• Azure
  • VMs: Azure Virtual Machines.
  • Container: Azure Kubernetes Service (AKS), Azure Container Apps (serverlose Container), Azure App Service (Code oder Container).
• Google Cloud
  • VMs: Compute Engine.
  • Container: Google Kubernetes Engine (GKE), Cloud Run (serverlose Container), App Engine (PaaS).

Tipp: Bevorzugen Sie serverlose Container (Cloud Run, Azure Container Apps, AWS App Runner) für zustandslose Web-APIs und Frontends.

Speicher und Datenbanken

• Objektspeicher: AWS S3, Azure Blob Storage, Google Cloud Storage.
• Verwaltete Datenbanken: AWS RDS/Aurora, Azure Database (MySQL/Postgres), Cloud SQL/AlloyDB. Alle bieten automatische Backups, hohe Verfügbarkeit und Skalierungsoptionen.

Netzwerk und Regionen

• Alle drei bieten globale Präsenz, Load Balancer, CDN (CloudFront, Azure Front Door, Cloud CDN), VPC/VNet-Isolierung und private Netzwerke.
• Achten Sie auf regionale Verfügbarkeit. Manche Dienste sind nur regional verfügbar. Wählen Sie Regionen in der Nähe Ihrer Nutzer.

IAM und Sicherheit

• AWS IAM: feinkörnig, Richtlinien in JSON.
• Azure Entra ID (ehemals Azure AD) + Azure RBAC: Rollenzuweisungen auf Abonnement-/Ressourcenebene.
• Google Cloud IAM: Rollen, die Principals auf Projekt-/Ordner-/Organisationsebene zugewiesen werden.
• Best Practice: Prinzip der geringsten Rechte anwenden, verwaltete Identitäten/Servicekonten für Deployments verwenden, Geheimnisse rotieren oder einen verwalteten Geheimnisspeicher nutzen (AWS Secrets Manager, Azure Key Vault, Secret Manager in GCP).

Preise und Free-Tiers

• Alle bieten nutzungsbasierte Preise und kostenlose Stufen. Serverlose Container sind kosteneffizient für sporadische oder wenig frequentierte Workloads (Cloud Run kann auf null skalieren).
• Achten Sie auf versteckte Kosten: Datenausgang, NAT-Gateways, verwaltete Load Balancer und Log-Ingestion/-Aufbewahrung.

Tooling und IaC

• CLIs: aws, az, gcloud. Alle sind ausgereift und skriptfähig.
• Infrastructure as Code: Terraform funktioniert cloudübergreifend; native Optionen sind AWS CDK/CloudFormation, Azure Bicep/ARM und Google Cloud Deploy/Config Connector.

Wahl eines Anbieters: schnelle Checkliste

• Sprache/Laufzeit: Alle unterstützen gängige Laufzeiten. Cloud Run/Container Apps/App Runner verarbeiten beliebige Container.
• Operative Präferenzen: Sind Sie bereits in Microsoft 365/Azure integriert oder haben Sie AWS-Erfahrung? Bevorzugen Sie GCPs Entwickler-Tooling?
• Region und Compliance: Datenlokalität, Zertifizierungen und Serviceverfügbarkeit.
• Preisvorhersagbarkeit: Serverless für variable Last, Reserved Instances für gleichmäßige Last.
• Ökosystem: Wenn Sie verwaltetes ML (Vertex AI, SageMaker, Azure ML) oder Analytics (BigQuery, Redshift, Synapse) benötigen, wählen Sie entsprechend.

Wenn Sie keine Zwänge haben, sind Cloud Run (GCP), Azure Container Apps und AWS App Runner hervorragende Ausgangspunkte für Web-APIs.

Voraussetzungen

• Eine aktuelle Docker-Installation.
• Git und ein Terminal.
• Konten bei AWS, Azure und Google Cloud.
• Installierte CLIs:
  • AWS: brew install awscli oder siehe AWS-Dokumentation.
  • Azure: brew install azure-cli oder siehe Azure-Dokumentation.
  • GCP: brew install --cask google-cloud-sdk oder siehe GCP-Dokumentation.
• Anmeldung:
  • AWS: aws configure (oder aws configure sso, wenn Ihre Organisation SSO nutzt); Standardregion setzen (z. B. us-east-1).
  • Azure: az login; az account set --subscription "<SUBSCRIPTION_ID>".
  • GCP: gcloud init; gcloud auth login; gcloud config set project <PROJECT_ID>; gcloud config set run/region us-central1.

Eine einfache containerisierte App bauen

Wir erstellen einen minimalen Node.js-HTTP-Server, packen ihn in Docker und führen ihn lokal aus.

App-Dateien

package.json

{
  "name": "hello-cloud",
  "version": "1.0.0",
  "main": "server.js",
  "scripts": { "start": "node server.js" },
  "dependencies": { "express": "^4.18.0" }
}

server.js

const express = require('express');
const app = express();
const port = process.env.PORT || 8080;

app.get('/', (req, res) => {
  res.send(`Hello, Cloud! Deployed at ${new Date().toISOString()}\n`);
});

app.listen(port, () => console.log(`Listening on ${port}`));

Dockerfile

FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
ENV PORT=8080
EXPOSE 8080
CMD ["npm", "start"]

Lokal bauen und testen

docker build -t hello-cloud:v1 .
docker run -p 8080:8080 hello-cloud:v1
# In einem anderen Terminal:
curl http://localhost:8080

Wenn Sie „Hello, Cloud!“ sehen, ist die App bereit für die Bereitstellung.

Bereitstellungsoptionen für AWS, Azure und GCP

Wir deployen denselben Container auf die serverlosen Containerplattformen der Anbieter. Jeder Pfad veröffentlicht das Image im Registry des Anbieters und erzeugt eine öffentliche HTTPS-URL.

Option A: AWS App Runner (einfach, verwaltet)

App Runner startet Ihren Container mit HTTPS, Auto-Scaling und ohne direkte VM-/Kubernetes-Verwaltung. Der einfachste Weg ist über die Konsole (diese erstellt automatisch IAM-Rollen). Die CLI ist möglich, aber aufwändiger.

Schritte (Konsole-zuerst zur Vereinfachung):

1. Image nach Amazon ECR pushen

• Erstellen Sie ein Repository in ECR mit dem Namen hello-cloud.
• Authentifizieren und pushen:

AWS_REGION=us-east-1
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
aws ecr create-repository --repository-name hello-cloud --region $AWS_REGION || true
aws ecr get-login-password --region $AWS_REGION | docker login --username AWS --password-stdin $ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com
docker tag hello-cloud:v1 $ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/hello-cloud:v1
docker push $ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/hello-cloud:v1

1. Einen App Runner Service erstellen

• In der AWS-Konsole > App Runner > Create service.
• Quelle: Container registry > Amazon ECR.
• Wählen Sie Ihr Image und den Tag v1.
• Laufzeit: Port 8080. Auto deploy: aus (für anfängliche manuelle Kontrolle).
• Erstellen und auf den Status „Running“ warten.

1. Testen

• Öffnen Sie die Default-Domain-URL (z. B. https://<random>.<region>.awsapprunner.com/).
• Sie sollten „Hello, Cloud!“ sehen.

Hinweise und Tipps:

• App Runner erstellt eine Service-Rolle; halten Sie die Berechtigungen minimal.
• Zum Aktualisieren: pushen Sie einen neuen Tag und deployen Sie eine neue Revision in App Runner oder aktivieren Sie Auto-Deploy von ECR.
• Kosten: Abrechnung nach bereitgestellten CPU-/Speicherressourcen und Requests; stoppen Sie den Service nach Gebrauch, um Kosten zu vermeiden.

CLI-Alternative (fortgeschritten):

• Sie können aws apprunner create-service mit einem ECR-Image-Identifier und einer Service-Rolle skripten; konsultieren Sie die AWS-Dokumentation für das aktuelle JSON-Service-Konfigurationsschema.

Option B: Azure Container Apps (serverlose Container, verwaltete Revisions)

Azure Container Apps betreibt Container auf einer serverlosen Steuerungsebene mit automatischer Skalierung.

1. Azure Container Registry (ACR) erstellen und Image pushen

RESOURCE_GROUP=rg-hello-cloud
LOCATION=eastus
ACR_NAME=myhellocloudacr$RANDOM

az group create --name $RESOURCE_GROUP --location $LOCATION
az acr create --name $ACR_NAME --resource-group $RESOURCE_GROUP --sku Basic
az acr login --name $ACR_NAME

ACR_LOGIN_SERVER=$(az acr show -n $ACR_NAME --query loginServer -o tsv)
docker tag hello-cloud:v1 $ACR_LOGIN_SERVER/hello-cloud:v1
docker push $ACR_LOGIN_SERVER/hello-cloud:v1

1. Die Container Apps-Erweiterung aktivieren und eine Umgebung erstellen

az extension add --name containerapp --upgrade
az provider register --namespace Microsoft.App
az provider register --namespace Microsoft.OperationalInsights

LOG_ANALYTICS_WORKSPACE=law-hello-cloud$RANDOM
LOG_RG=$RESOURCE_GROUP

az monitor log-analytics workspace create -g $LOG_RG -n $LOG_ANALYTICS_WORKSPACE -l $LOCATION
LOG_ID=$(az monitor log-analytics workspace show -g $LOG_RG -n $LOG_ANALYTICS_WORKSPACE --query customerId -o tsv)
LOG_KEY=$(az monitor log-analytics workspace get-shared-keys -g $LOG_RG -n $LOG_ANALYTICS_WORKSPACE --query primarySharedKey -o tsv)

ENV_NAME=cae-hello-cloud
az containerapp env create \
  -g $RESOURCE_GROUP -n $ENV_NAME -l $LOCATION \
  --logs-workspace-id $LOG_ID --logs-workspace-key $LOG_KEY

1. Die Container-App deployen

APP_NAME=hello-cloud
az containerapp create \
  -g $RESOURCE_GROUP -n $APP_NAME \
  --environment $ENV_NAME \
  --image $ACR_LOGIN_SERVER/hello-cloud:v1 \
  --target-port 8080 \
  --ingress external \
  --registry-server $ACR_LOGIN_SERVER \
  --query properties.configuration.ingress.fqdn -o tsv

Öffnen Sie die zurückgegebene FQDN in Ihrem Browser, um die Antwort zu überprüfen.

Hinweise:

• Revisions ermöglichen Blue/Green-Deployments und Traffic-Splitting.
• Skalierungsregeln unterstützen HTTP- und ereignisgetriebene Skalierung.
• Achten Sie auf Kosten für Log Analytics.

Option C: Google Cloud Run (serverless, skaliert auf null)

Cloud Run deployt einen Container als voll verwalteten HTTPS-Dienst und skaliert bei Inaktivität auf null.

Option 1: Direkt aus dem Quellcode bauen (kein lokales Docker-Push nötig):

gcloud run deploy hello-cloud \
  --source . \
  --region us-central1 \
  --allow-unauthenticated \
  --port 8080

Option 2: Image in Artifact Registry pushen und dann deployen:

REGION=us-central1
REPO=hello-repo
PROJECT_ID=$(gcloud config get-value project)
gcloud artifacts repositories create $REPO --repository-format=docker --location=$REGION || true
gcloud auth configure-docker $REGION-docker.pkg.dev

docker tag hello-cloud:v1 $REGION-docker.pkg.dev/$PROJECT_ID/$REPO/hello-cloud:v1
docker push $REGION-docker.pkg.dev/$PROJECT_ID/$REPO/hello-cloud:v1

gcloud run deploy hello-cloud \
  --image $REGION-docker.pkg.dev/$PROJECT_ID/$REPO/hello-cloud:v1 \
  --region $REGION \
  --allow-unauthenticated \
  --port 8080

Der Befehl gibt eine Service-URL aus (z. B. https://hello-cloud-xyz-uc.a.run.app). Öffnen Sie diese im Browser.

Hinweise:

• Cloud Run unterstützt min/max-Instanzen, Concurrency, CPU im Leerlauf und VPC-Zugriff.
• Timeouts für Requests/Responses standardmäßig 5 Minuten; bei Bedarf anpassen.

Aktualisieren und Rollout von Änderungen

• Version erhöhen: Ändern Sie den Code, bauen/pushen Sie ein neues Image-Tag (v2) und aktualisieren Sie den Dienst.
• Zero-Downtime-Deployments:
  • App Runner: Deployment erstellt eine neue Revision; Traffic verschiebt sich automatisch.
  • Container Apps: Verwenden Sie Revisions und Traffic-Splitting-Flags für Canary-Releases.
  • Cloud Run: Deploy erstellt eine neue Revision; Sie können Traffic pinnen oder splitten.

Beispiel (Cloud Run Canary):

gcloud run services update-traffic hello-cloud \
  --to-revisions REVISION-NEW=10,REVISION-OLD=90

Observability und Troubleshooting

• Logs:
  • AWS: CloudWatch Logs (App Runner streamt automatisch).
  • Azure: Log Analytics + Container Apps Insights.
  • GCP: Cloud Logging (gcloud logs tail für CLI).
• Metriken:
  • Achten Sie auf Request-Count, Latenz, Fehlerquote, CPU-/Speicherauslastung und Instanzanzahl.
• Debugging-Tipps:
  • Stellen Sie sicher, dass PORT mit der Service-Konfiguration übereinstimmt.
  • Validieren Sie Health-Checks (HTTP 200 auf /).
  • Prüfen Sie die Container-Image-Architektur (linux/amd64 vs arm64).
  • Bestätigen Sie Registry-Berechtigungen und Image-Pull-Secrets.

Best Practices

• Konfiguration und Geheimnisse
  • Speichern Sie nicht-sensitive Konfiguration in Umgebungsvariablen.
  • Nutzen Sie verwaltete Geheimnisspeicher (Secrets Manager, Key Vault, Secret Manager).
  • Vermeiden Sie, Geheimnisse in Images einzubacken.
• Sicherheit
  • Beschränken Sie öffentlichen Ingress wo möglich; verwenden Sie privates Networking und identity-aware Proxies bei Bedarf.
  • Verwenden Sie für Deployment-Automation Rollen mit geringsten Rechten.
• Kostenkontrolle
  • Bevorzugen Sie Serverless für burstige/gering frequentierte Dienste.
  • Setzen Sie Max-Instanzen und Autoscaling-Grenzen.
  • Bereinigen Sie ungenutzte Images, alte Revisions und Log-Aufbewahrung.
• Zuverlässigkeit
  • Implementieren Sie Health-Endpunkte und angemessene Timeouts.
  • Nutzen Sie mehrere Zonen/Regionen für kritische Workloads.
  • Fügen Sie ein CDN oder Edge-Caching für statische Inhalte hinzu.

Häufige Fallstricke

• Port-Mismatch: Ihre App hört auf einem anderen Port als die Plattform erwartet.
• Fehlende Authentifizierung zum Pullen von Images: Gewähren Sie dem Dienst Zugriff auf Ihr Registry (ACR/ECR/Artifact Registry).
• Verwirrung bei Regionen: Ressourcen in unterschiedlichen Regionen können Latenz und Cross-Region-Kosten verursachen.
• Egress-Kosten: Aufrufe externer APIs oder cross-region Services können teuer werden; halten Sie Daten lokal.
• Cold Starts: Serverless skaliert auf null; setzen Sie Min-Instanzen für latenzkritische Endpunkte (Cloud Run min-instances, Container Apps minReplicas, App Runner provisioned settings).

Wohin als Nächstes

• HTTPS mit eigenen Domains und verwalteten Zertifikaten hinzufügen.
• Eine Datenbank anbinden:
  • AWS: RDS/Aurora mit Security Groups und privatem Networking.
  • Azure: Azure Database for PostgreSQL/MySQL mit VNet-Integration.
  • GCP: Cloud SQL mit Cloud Run Connector.
• CI/CD:
  • GitHub Actions zum Bauen/Pushen und Deployen via CLIs.
  • Native: AWS CodePipeline, Azure DevOps/GitHub Actions, Google Cloud Build/Deploy.
• Infrastructure as Code: Dokumentieren Sie Ihre Konfiguration mit Terraform, um Umgebungen reproduzierbar zu machen.

Wenn Sie mit serverlosen Containern auf App Runner, Azure Container Apps oder Cloud Run starten, minimieren Sie den operativen Aufwand und halten gleichzeitig einen klaren Weg zur Skalierung offen. Wählen Sie den Anbieter, der am besten zu den Tools und Einschränkungen Ihres Teams passt, und automatisieren Sie anschließend alles von Builds bis zu Rollouts.