Multi-Cloud-Control-Vergleich: AWS, Azure, GCP, Alibaba Cloud
Nebeneinander-Referenz für die Controls, die in einer Landing Zone zählen. Nach Bereich filtern, Provider umschalten, kopieren was Sie brauchen.
Seitlich scrollen, um Provider zu vergleichen. Die Control-Spalte bleibt sichtbar.
| Control | AWS | Azure | GCP | Alibaba Cloud |
|---|
Bewertung fortsetzen
Häufige Fragen
AWS IAM nutzt JSON-Policy-Dokumente mit Allow/Deny-Regeln an Identities oder Resources. Azure RBAC weist Built-in- oder Custom-Roles auf einem Scope zu (Subscription, Resource Group oder Resource). Beide folgen Least Privilege, aber Policy-Sprache und Assignment-Modell sind nicht portabel. Beide über einen zentralen IdP wie Entra ID oder Okta zu federieren ist der Standardansatz. Siehe: RBAC patterns for production cloud environments.
Ja. Der aliyun/alicloud Terraform-Provider ist produktionsreif. Er unterstützt Resource Directory (Multi-Account), RAM Roles, VPC, OSS und SLS. State Locking läuft über OSS + Table Store (OTS). Offizielle Landing-Zone-Module gibt es unter alibabacloud-automation auf GitHub.
GCP VPCs sind standardmässig global. Subnets sind regional, aber eine einzelne VPC spannt alle Regionen. AWS- und Azure-VPCs/VNets sind regional. Das ändert Annahmen zu Cross-Region-Peering. GCP nutzt Shared VPC für Cross-Account-Netzwerksharing. AWS nutzt Transit Gateway. Azure nutzt Virtual WAN oder VNet Peering.
GCP Cloud Logging defaultet auf 30 Tage. AWS CloudWatch Log Groups defaulten auf Never Expire. Azure Log Analytics defaultet auf 30 Tage interaktiv. Alibaba SLS defaultet auf 30 Tage. Für die meisten Compliance-Frameworks mindestens 90 Tage setzen, ideal 1 Jahr für Management-Audit-Logs. Retention explizit beim Provisioning setzen.
Runbook-Format und On-Call-Eskalationspfad standardisieren. Alle Provider-Alerts auf eine einzige On-Call-Plattform routen. Bei nativem Alerting-Tooling divergieren, das ist provider-nativ und Abstraktion kostet ohne Nutzen.