Speichervergleich für Azure und AWS

Dieser Leitfaden richtet sich an Organisationen oder Einzelpersonen, die von Amazon Web Services (AWS) zu Azure migrieren oder eine Multicloudstrategie verfolgen. Ziel dieses Leitfadens ist es, AWS-Architekten dabei zu helfen, die Speicherfunktionen von Azure zu verstehen, indem Azure-Dienste mit AWS-Diensten verglichen werden.

S3, EBS, EFS und Azure Storage

Auf der AWS-Plattform wird Cloudspeicher in der Regel auf drei Arten bereitgestellt:

Amazon Simple Storage Service (S3). Einfacher Objektspeicher, der Daten über eine API verfügbar macht.
Amazon Elastic Block Store (EBS). Blockebenenspeicher, der in der Regel für den Zugriff durch einen einzelnen virtuellen Computer (VM) vorgesehen ist. Sie können sie mit bestimmten Speicherklassen und Dateisystemen an mehrere Volumes anfügen.
Freigegebener Speicher. Verschiedene gemeinsame Speicherdienste, die AWS bereitstellt, wie Amazon Elastic File System (EFS) und die Amazon FSx-Familie von verwalteten Dateisystemen.

In Azure Storage können mit an Abonnements gebundene Speicherkonten die folgenden Speicherdienste erstellt und verwaltet werden:

Azure Blob Storage speichert jeden Text- oder Binärdatentyp, z. B. ein Dokument, eine Mediendatei oder ein Anwendungsinstallationsprogramm. Sie können Blob Storage für den privaten Zugriff festlegen oder Inhalte öffentlich im Internet freigeben. Blob Storage ist Objektspeicher, sodass es denselben Zweck wie AWS S3 erfüllt. Die Azure Entsprechung von EBS ist verwaltete Datenträger, die nicht Teil eines Speicherkontos sind.
Azure Table Storage speichert strukturierte Datasets. Table Storage ist ein NoSQL-Schlüssel-Attribut-Datenspeicher, der eine schnelle Entwicklung und einen schnellen Zugriff auf große Datenmengen ermöglicht. Es ist vergleichbar mit den AWS SimpleDB- und DynamoDB-Diensten.
Azure Queue Storage bietet Messaging für die Workflowverarbeitung und für die Kommunikation zwischen Komponenten von Clouddiensten.
Azure Files bietet gemeinsam genutzten Speicher für Anwendungen. Es verwendet das standardmäßige Server Message Block (SMB) oder Network File System (NFS)-Protokoll. Verwenden Sie Azure Files auf eine Weise, die der Verwendung von EFS oder FSx für Windows File Server ähnelt.

Azure bietet auch andere verwaltete Dateisysteme, einschließlich Azure Managed Lustre, Azure NetApp Files und Azure Native Qumulo. Weitere Informationen finden Sie unter "Speichervergleich".

Glacier und Azure Storage

Azure Blob Storage bietet drei Speicherstufen unterhalb der heißen Ebene an, und die AWS S3 Glacier-Speicherklassen entsprechen zwei dieser Stufen statt nur einer.

Azure Archiv-Blob Storage ist vergleichbar mit S3 Glacier Flexible Retrieval und S3 Glacier Deep Archive. Blob Storage Archiv ist eine Offlineebene, daher müssen Sie ein Blob rehydratisieren, bevor Sie es lesen können. Speichern Sie dort Daten für mindestens 180 Tage, und rechnen Sie mit einer Abruflatenz von mehreren Stunden.

Die Cold-Tier ist vergleichbar mit S3 Glacier Instant Retrieval. Es handelt sich um eine Onlineebene für selten aufgerufene Daten, die weiterhin in Millisekunden abgerufen werden müssen. Es hat einen Mindestaufbewahrungszeitraum von 90 Tagen.

Für Daten, auf die selten zugegriffen wird, die aber sofort verfügbar sein müssen, bietet die Cool-Zugriffsebene günstigeren Speicher als die Hot-Zugriffsebene mit einem Mindestaufbewahrungszeitraum von 30 Tagen. Diese Stufe ist vergleichbar mit S3 Standard-Infrequent Access.

Jede Stufe unterhalb des Hot-Tiers berechnet eine Gebühr für vorzeitige Löschungen, wenn Sie Daten löschen oder verschieben, bevor der Mindestaufbewahrungszeitraum verstrichen ist.

Objektspeicher-Zugriffssteuerung

In AWS wird der Zugriff auf S3 in der Regel über eine Identitäts- und Zugriffsverwaltungsrolle (IAM) oder direkt in der S3-Bucket-Richtlinie gewährt. Der Netzwerkzugriff auf Datenebene wird in der Regel über S3-Bucketrichtlinien gesteuert.

Bei Azure Blob Storage wird ein mehrstufiger Ansatz verwendet. Die Azure Storage-Firewall wird verwendet, um den Netzwerkzugriff auf die Datenebene zu steuern.

In Amazon S3 ist es üblich, vorsignierte URLs zu verwenden, um zeitlich begrenzten Berechtigungszugriff zu gewähren. In Azure Blob Storage können Sie ein ähnliches Ergebnis erzielen, indem Sie eine Shared Access Signature verwenden.

Regionale Redundanz und Replikation für Objektspeicher

Organisationen schützen ihre Speicherobjekte häufig mithilfe redundanter Kopien. Sowohl in AWS als auch in Azure werden Daten in einer bestimmten Region repliziert. In Azure steuern Sie, wie Daten repliziert werden, indem Sie lokal redundanten Speicher (LRS) oder zonenredundanten Speicher (ZRS) verwenden. Wenn Sie LRS verwenden, werden Kopien aus Kosten- oder Compliancegründen im selben Rechenzentrum gespeichert. ZRS ähnelt der AWS-Replikation: Sie repliziert Daten über Verfügbarkeitszonen innerhalb einer Region.

AWS-Kunden replizieren ihre S3-Buckets häufig mithilfe der regionsübergreifenden Replikation in eine andere Region. Sie können diesen Replikationstyp in Azure mithilfe der Azure Blob-Replikation implementieren. Eine weitere Option besteht darin, georedundanten Speicher (GEO-redundant storage, GRS) oder geozonenredundanten Speicher (GZRS) zu konfigurieren. GRS und GZRS replizieren Daten synchron in eine sekundäre Region, ohne dass eine Replikationskonfiguration erforderlich ist. Auf die Daten kann nur zugegriffen werden, wenn ein geplantes oder ungeplantes Failover auftritt.

Vergleichen von Blockspeicheroptionen

Beide Plattformen bieten unterschiedliche Arten von Datenträgern, um bestimmte Leistungsanforderungen zu erfüllen. Obwohl die Leistungsmerkmale nicht exakt übereinstimmen, bietet die folgende Tabelle einen generalisierten Vergleich. Sie sollten immer Tests durchführen, um zu ermitteln, welche Speicherkonfigurationen ihrer Anwendung am besten entsprechen. Für leistungsfähigere Datenträger müssen Sie sowohl bei AWS als auch bei Azure sicherstellen, dass die Speicherleistung der VM mit dem bereitgestellten Datenträgertyp und der Konfiguration übereinstimmt.

AWS EBS-Volumetyp	Von Azure verwalteter Datenträger	Verwendung für	Kann dieser verwaltete Datenträger als Betriebssystemdatenträger verwendet werden?
gp2/gp3	Standard-SSD	Webserver und leicht verwendete Anwendungsserver oder Entwicklungs-/Testumgebungen	Ja
gp2	SSD Premium	Produktionsworkloads und leistungsabhängige Workloads	Ja
gp3	SSD Premium v2	Leistungsabhängige Workloads oder Workloads, die hohe IOPS und niedrige Latenz erfordern	Nein
io2	Ultra-Disk-Speicher	E/A-intensive Workloads, leistungsintensive Datenbanken und Workloads mit vielen Transaktionen, die einen hohen Durchsatz und hohe IOPS erfordern	Nein

In Azure können Sie viele VM-Typen für die Hostzwischenspeicherung konfigurieren. Wenn Host-Cache aktiviert ist, wird der Cachespeicher dem virtuellen Computer als verfügbar gemacht und kann für den schreibgeschützten oder Lesen-/Schreibmodus konfiguriert werden. Bei einigen Workloads kann der Cache die Speicherleistung verbessern.

Informationen zu den aktuellen Kapazitäts-, Durchsatz- und IOPS-Grenzwerten jedes Datenträgertyps finden Sie unter verwaltete Azure-Datenträgertypen.