Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Regionen und Zonen

Amazon EC2 wird an mehreren Standorten weltweit gehostet. Diese Standorte bestehen aus AWS-Regionen Availability Zones, Local Zones und AWS Outposts Wavelength Zones.

AWS betreibt state-of-the-art hochverfügbare Rechenzentren. In seltenen Fällen kann es aber zu Ausfällen kommen, die die Verfügbarkeit von Instances desselben Standorts beeinträchtigen. Wenn Sie alle Ihre Instances an einem einzigen Standort hosten, der von einem Ausfall dieser Art betroffen ist, ist keine Ihrer Instances verfügbar.

Weitere Informationen finden Sie unter AWS -Globale Infrastruktur.

Regionen

Jede -Region ist darauf ausgelegt, vollständig von den anderen -Regionen getrennt zu sein. Dies sorgt für die größtmögliche Fehlertoleranz und Stabilität.

Wenn Sie sich Ihre Ressourcen anzeigen lassen, werden nur die Ressourcen angezeigt, die mit der von Ihnen angegebenen Region verknüpft sind. Der Grund hierfür ist, dass die -Regionen voneinander isoliert sind und Ressourcen nicht automatisch über unterschiedliche -Regionen repliziert werden.

Wenn Sie eine Instance starten, müssen Sie eine Instance auswählenAMI, die sich in derselben Region befindet. Wenn AMI sich die in einer anderen Region befindet, können Sie sie in AMI die Region kopieren, die Sie verwenden. Weitere Informationen finden Sie unter Einen Amazon kopieren EC2 AMI.

Beachten Sie, dass für die Datenübertragung zwischen Regionen eine Gebühr anfällt. Weitere Informationen finden Sie unter EC2Amazon-Preise — Datenübertragung.

Verfügbare Regionen

Ihr Konto bestimmt die Regionen, die für Sie verfügbar sind.

Sie können keine weiteren Regionen aus einer Region beschreiben oder darauf zugreifen AWS-Konto, z. B. aus der Region China. AWS GovCloud (US) Regions

In der folgenden Tabelle sind die Regionen aufgeführt, die von einem bereitgestellt werden AWS-Konto. Rufen Sie alternativ den Befehl list-regions auf.

Um eine nach dem 20. März 2019 eingeführte Region verwenden zu können, müssen Sie die Region aktivieren. Weitere Informationen finden Sie im AWS Account Management Referenzhandbuch unter Aktivieren oder Deaktivieren von AWS Regionen in Ihrem Konto.

Verwenden Sie den folgenden get-parameters-by-pathBefehl, um den Namen einer Region abzurufen. region-codeErsetzen Sie ihn durch den Code für die Region. Möglicherweise müssen Sie die Anführungszeichen ändern, damit das Beispiel mit Ihrem Terminal funktioniert.

aws ssm get-parameters-by-path \
    --path /aws/service/global-infrastructure/regions/region-code \
    --query 'Parameters[?Name.contains(@,`longName`)].Value' \
    --output text

Regionale -Endpunkte

Wenn Sie mit einer Instance über die Befehlszeilenschnittstelle oder API Aktionen arbeiten, müssen Sie ihren regionalen Endpunkt angeben. Weitere Informationen zu den Regionen und Endpunkten für Amazon EC2 finden Sie unter Amazon EC2 Service Endpoints im Amazon EC2 Developer Guide.

Weitere Informationen zu Endpunkten und Protokollen in AWS GovCloud (USA West) finden Sie unter Service Endpoints im Benutzerhandbuch.AWS GovCloud (US)

Availability Zones

Jede Region verfügt über mehrere isolierte Standorte, die als Availability Zones bezeichnet werden. Der Code für eine Availability Zone ist der Regionscode gefolgt von einem Buchstaben als Bezeichner. Beispiel, us-east-1a.

Wenn Sie eine Instanz starten, wählen Sie eine Region und eine virtuelle private Cloud (VPC) aus. Anschließend können Sie entweder ein Subnetz aus einer der Availability Zones auswählen oder uns eine für Sie auswählen lassen. Wenn Sie Ihre Instances auf mehrere Availability Zones verteilen, ist es sinnvoll, Ihre Anwendung so zu entwerfen, dass bei einem Ausfall einer Instance die Anforderungen von einer Instance in einer anderen Availability Zone verarbeitet werden können. Außerdem können Sie Elastic IP-Adressen verwenden, um den Ausfall einer Instance in einer Availability Zone zu maskieren, indem Sie die Adresse schnell einer Instance in einer anderen Availability Zone zuordnen.

Das folgende Diagramm zeigt mehrere Availability Zones in einer AWS Region. Availability Zone A und Availability Zone B haben jeweils ein Subnetz, und jedes Subnetz verfügt über Instances. Availability Zone C hat keine Subnetze, daher können Sie keine Instances in diese Availability Zone starten.

Da Availability Zones im Laufe der Zeit größer werden, werden die Erweiterungsmöglichkeiten in der Regel immer weiter eingeschränkt. Wenn dies eintritt, wird für Sie das Starten einer Instance in einer eingeschränkten Availability Zone unter Umständen verhindert, es sei denn, sie verfügen bereits über eine Instance in dieser Availability Zone. Es kann auch sein, dass wir die eingeschränkte Availability Zone aus der Liste mit den Availability Zones für neue Konten entfernen. Daher besteht die Möglichkeit, dass Ihr Konto in einer Region über eine andere Anzahl von verfügbaren Availability Zones als ein anderes Konto verfügt.

A-Z IDs

Um sicherzustellen, dass die Ressourcen auf die Availability Zones einer Region verteilt werden, ordnen wir die Availability Zones unabhängig voneinander den Codes für jeden AWS-Konto unserer ältesten Regionen zu. Zum Beispiel ist der us-east-1a für Sie AWS-Konto möglicherweise nicht derselbe physische Standort wie der us-east-1a für einen anderen AWS-Konto.

Verwenden Sie die AZ, d. h. eindeutige und konsistente Kennungen für eine Availability Zone, um Availability Zones zwischen Konten in allen Regionen zu koordinierenIDs, auch wenn sie Availability Zones zuordnen. Dies use1-az1 ist beispielsweise eine AZ-ID für die us-east-1 Region, und sie hat in jeder AWS-Konto Region denselben physischen Standort. Sie können die AZ IDs für Ihr Konto einsehen, um den physischen Standort Ihrer Ressourcen im Verhältnis zu den Ressourcen in einem anderen Konto zu ermitteln. Wenn Sie beispielsweise ein Subnetz in der Availability Zone mit der AZ-ID use1-az2 mit einem anderen Konto teilen, steht dieses Subnetz dem Konto in der Availability Zone zur Verfügung, dessen AZ-ID ebenfalls use1-az2 ist.

Um die AZ IDs für Ihr Konto einzusehen, überprüfen Sie den Servicestatus auf dem EC2Dashboard oder verwenden Sie den describe-availability-zones AWS CLI Befehl.

Das folgende Diagramm veranschaulicht zwei Konten mit unterschiedlichen Mappings von Availability-Zone-Code zur AZ ID.

Verfügbare Availability Zones

Jede Region verfügt über mehrere Availability Zones, wie in der folgenden Liste dargestellt.

† Neuere Konten können auf zwei Availability Zones in USA West (Nordkalifornien) zugreifen.

Instances in Availability Zones

Wählen Sie beim Starten einer Instance eine Region aus, in der Instances näher an bestimmten Kunden platziert werden oder mit der rechtliche oder andere Anforderungen erfüllt werden. Indem Sie Instances in separaten Availability Zones starten, können Sie Ihre Anwendungen vor dem Ausfall eines einzelnen Standorts in der Region schützen.

Beim Starten einer Instance können Sie optional eine Availability Zone in der Region angeben, die Sie verwenden. Wenn Sie keine Availability Zone angeben, wählen wir eine Availability Zone für Sie aus. Beim Starten Ihrer ersten Instances ist es ratsam, die standardmäßig vorgegebene Availability Zone zu akzeptieren. Wir können so basierend auf dem Systemzustand und der verfügbaren Kapazität die beste Availability Zone für Sie auswählen. Geben Sie beim Starten weiterer Instances eine Availability Zone nur dann an, wenn Ihre Instances nah bei Ihren laufenden Instances oder getrennt davon angeordnet werden müssen.

Local Zones

Eine lokale Zone ist eine Erweiterung einer AWS Region in geografischer Nähe zu Ihren Benutzern. Local Zones verfügen über eigene Verbindungen zum Internet und unterstützen sie AWS Direct Connect, sodass Ressourcen, die in einer lokalen Zone erstellt wurden, lokalen Benutzern mit Kommunikation mit niedriger Latenz dienen können. Weitere Informationen finden Sie unter Was sind AWS Local Zones? im AWS Local Zones User Guide.

Der Code für die lokale Zone wird durch einen Regionscode dargestellt, gefolgt von einer ID, die den physischen Standort angibt. Beispiel: us-west-2-lax-1 in Los Angeles.

Das folgende Diagramm zeigt die AWS Regionus-west-2, zwei ihrer Availability Zones und zwei ihrer Local Zones. Das VPC umfasst die Availability Zones und eine der Local Zones. Jede Zone in der VPC hat ein Subnetz, und jedes Subnetz hat eine Instanz.

Verfügbare Local Zones

Eine Liste der verfügbaren lokalen Zonen finden Sie unter Verfügbare Local Zones im AWS -Benutzerhandbuch für Local Zones. Eine Liste der angekündigten Local Zones finden Sie unter AWS -Local-Zones-Standorte.

Instances in Local Zones

Um eine Local Zone verwenden zu können, müssen Sie diese zunächst aktivieren. Dann erstellen Sie ein Subnetz in der Local Zone. Sie können das Subnetz der Local Zone angeben, wenn Sie Instances starten, wodurch es im Subnetz der Local Zone in der lokalen Zone platziert wird.

Wenn Sie eine Instance in einer Local Zone starten, weisen Sie auch eine IP-Adresse aus einer Netzwerkgrenzgruppe zu. Eine Netzwerkgrenzgruppe ist eine eindeutige Gruppe von Availability Zones, Local Zones oder Wavelength Zones, aus denen AWS beispielsweise IP-Adressen bekannt gegeben werden. us-west-2-lax-1a Sie können die folgenden IP-Adressen aus einer Netzwerkgrenzgruppe zuweisen:

Weitere Informationen zum Starten einer Instance in einer Local Zone finden Sie unter Getting started with AWS Local Zones im AWS Local Zones User Guide.

Wavelength Zones

AWS Wavelength ermöglicht es Entwicklern, Anwendungen zu entwickeln, die extrem niedrige Latenzen für mobile Geräte und Endbenutzer bieten. Wavelength stellt AWS Standard-Rechen- und Speicherdienste am Rand der 5G-Netzwerke von Telekommunikationsanbietern bereit. Entwickler können eine virtuelle private Cloud (VPC) auf eine oder mehrere Wellenlängenzonen erweitern und dann AWS Ressourcen wie EC2 Amazon-Instances verwenden, um Anwendungen auszuführen, die eine extrem niedrige Latenz und eine Verbindung zu AWS Diensten in der Region erfordern.

Eine Wavelength-Zone ist eine isolierte Zone am Standort des Carriers, an dem die Wavelength-Infrastruktur bereitgestellt wird. Wavelength Zones sind an eine Region gebunden. Eine Wavelength-Zone ist eine logische Erweiterung einer Region und wird von der Steuerungsebene in der Region verwaltet.

Der Code für die Wavelength-Zone wird durch einen Regionscode dargestellt, gefolgt von einer ID, die den physischen Standort angibt. Beispiel: us-east-1-wl1-bos-wlz-1 in Boston.

Das folgende Diagramm zeigt die AWS Regionus-west-2, zwei ihrer Availability Zones und eine Wellenlängenzone. Das VPC umfasst die Availability Zones und die Wavelength Zone. Jede Zone in der VPC hat ein Subnetz, und jedes Subnetz hat eine Instanz.

Wavelength Zones sind nicht in jeder Region verfügbar. Weitere Informationen zu den Regionen, die Wavelength Zones unterstützen, finden Sie unter Verfügbare Wavelength Zones im AWS Wavelength Developerhandbuch.

Verfügbare Wavelength Zones

Weitere Informationen zu verfügbaren Wavelength Zones finden Sie unter Verfügbare Wavelength Zones im AWS Wavelength -Entwicklerhandbuch.

Instances in Wavelength Zones

Um eine Wavelength-Zone zu verwenden, müssen Sie sich zunächst für die Zone anmelden. Dann erstellen Sie ein Subnetz in der Wavelength Zone. Sie können das Wavelength-Subnetz angeben, wenn Sie Instances starten. Sie weisen auch eine Carrier-IP-Adresse aus einer Netzwerkgrenzgruppe zu, bei der es sich um einen eindeutigen Satz von Availability Zones, Local Zones oder Wavelength Zones handelt, von denen AWS IP-Adressen präsentiert, zum Beispiel us-east-1-wl1-bos-wlz-1.

step-by-stepAnweisungen zum Starten einer Instance in einer Wavelength Zone finden Sie unter Erste Schritte mit AWS Wavelength im AWS Wavelength Entwicklerhandbuch.

AWS Outposts

AWS Outposts ist ein vollständig verwalteter Service, der AWS InfrastrukturAPIs, Dienste und Tools auf Kundenstandorte ausdehnt. Durch den lokalen Zugriff auf die AWS verwaltete Infrastruktur AWS Outposts können Kunden Anwendungen vor Ort mit denselben Programmierschnittstellen wie in AWS Regionen erstellen und ausführen und gleichzeitig lokale Rechen- und Speicherressourcen für geringere Latenz und lokale Datenverarbeitungsanforderungen nutzen.

Ein Outpost ist ein Pool von AWS Rechen- und Speicherkapazität, der am Standort eines Kunden bereitgestellt wird. AWS betreibt, überwacht und verwaltet diese Kapazität als Teil einer AWS Region. Sie können Subnetze in Ihrem Outpost erstellen und diese bei der Erstellung AWS von Ressourcen angeben. Instances in Outpost-Subnetzen kommunizieren mit anderen Instances in der AWS Region über private IP-Adressen, die sich alle innerhalb derselben befinden. VPC

Das folgende Diagramm zeigt die AWS Regionus-west-2, zwei ihrer Availability Zones und einen Outpost. Das VPC umfasst die Availability Zones und den Outpost. Der Outpost befindet sich in einem On-Premises Kundenrechenzentrum. Jede Zone in der VPC hat ein Subnetz, und jedes Subnetz hat eine Instanz.

Starten von Instances in einem Outpost

Um mit der Nutzung zu beginnen AWS Outposts, müssen Sie einen Outpost erstellen und Outpost-Kapazität bestellen. AWS Outposts bietet zwei Formfaktoren: Outposts-Racks und Outposts-Server. Weitere Informationen zu Outpost-Konfigurationen finden Sie in AWS Outposts -Familie. Nach der Installation Ihrer Outpost-Geräte steht Ihnen die Rechen- und Speicherkapazität zur Verfügung, wenn Sie EC2 Instances auf Ihrem Outpost starten.

Um EC2 Instances zu starten, müssen Sie ein Outpost-Subnetz erstellen. Sicherheitsgruppen steuern den eingehenden und ausgehenden VPC-Datenverkehr für Instances in einem Outpost-Subnetz genauso wie für Instances in einem Availability-Zone-Subnetz. Um eine Verbindung zu einer EC2 Instance in einem Outpost-Subnetz herzustellen, können Sie beim Starten der Instance ein key pair angeben, genau wie Sie es für Instances in einem Availability Zone-Subnetz tun, um Verbindungen über zu ermöglichen. SSH

Weitere Informationen finden Sie unter Erste Schritte mit Outposts-Racks oder Erste Schritte mit Outposts-Servern.

Volumes in einem Outposts-Rack

Wenn sich die Rechenkapazität Ihrer Outposts in einem Outpost-Rack befindet, können Sie EBS Volumes in dem von Ihnen erstellten Outpost-Subnetz erstellen. Wenn Sie das Volume erstellen, geben Sie den Amazon-Ressourcennamen (ARN) des Outposts an.

Der folgende Befehl create-volume erstellt ein leeres 50 GB-Volume auf dem angegebenen Outpost.

aws ec2 create-volume --availability-zone us-east-2a --outpost-arn arn:aws:outposts:us-east-2:123456789012:outpost/op-03e6fecad652a6138 --size 50

Sie können die Größe Ihrer Amazon EBS GP2-Volumes dynamisch ändern, ohne sie zu trennen. Weitere Informationen zum Ändern eines Volumes, ohne es zu trennen, finden Sie unter Änderungen an Ihren EBS Volumes beantragen im EBSAmazon-Benutzerhandbuch.

Wir empfehlen, das Root-Volume für eine Instance in einem Outpost-Rack auf 30 GiB oder kleiner zu beschränken. Sie können in der Block-Device-Zuordnung der Instance AMI oder der Instance Datenvolumen angeben, um zusätzlichen Speicherplatz bereitzustellen. Informationen zum Entfernen ungenutzter Blöcke aus dem Startvolume finden Sie unter How to Build Sparse EBS Volumes im AWS Partner Network-Blog.

Wir empfehlen, das NVMe Timeout für das Root-Volume zu erhöhen. Weitere Informationen finden Sie unter I/O-Betriebs-Timeout im EBSAmazon-Benutzerhandbuch.

Volumes in einem Outposts-Server

Instances auf Outposts-Servern bieten Instance-Speicher-Volumes, unterstützen aber keine EBS Volumes. Wählen Sie ein EBS Amazon-gestütztes Gerät AMI mit nur einem einzigen EBS Snapshot. Wählen Sie eine ausreichende Instance-Speicher-Größe, um die Anforderungen Ihrer Anwendung zu erfüllen. Weitere Informationen finden Sie unter Instance-Speicher-Limits.