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, AWS Outposts und Wavelength Zones.

AWS betreibt hochmoderne, hoch verfü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.

Wählen Sie beim Starten einer Instance eine Region aus, in der Instances nah an bestimmten Kunden platziert werden oder mit der rechtliche oder andere Anforderungen erfüllt werden. Sie können Instances in mehreren Regionen starten.

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.

Verfügbare Regionen

Eine Liste der verfügbaren Regionen finden Sie unter AWS-Regionen.

Regionale Endpunkte für Amazon EC2

Wenn Sie über die Befehlszeilenschnittstelle oder über API-Aktionen mit einer Instance arbeiten, müssen Sie ihren regionalen Endpunkt angeben. Weitere Informationen über Regionen und Endpunkte für Amazon EC2 finden Sie unter Amazon-EC2-Service-Endpunkte im Entwicklerhandbuch für Amazon EC2.

Weitere Informationen finden Sie unter AWS-Regionen im Benutzerhandbuch für AWS-Regionen und Availability Zones.

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.

Indem Sie EC2-Instances in mehreren Availability Zones starten, können Sie Ihre Anwendungen vor dem Ausfall eines einzelnen Standorts in der Region schützen.

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

Weitere Informationen finden Sie unter Virtual Private Clouds für Ihre EC2-Instances.

Availability Zones nach Region

Eine Liste der Availability Zones nach Regionen finden Sie unter AWS Availability Zones.

Instances in Availability Zones

Wenn Sie eine Instance starten, wählen Sie eine Region und eine Virtual Private Cloud (VPC) aus. Dann können Sie entweder ein Subnetz aus einer der Availability Zones auswählen oder uns eines für Sie auswählen lassen. Beim Starten Ihrer ersten Instances empfehlen wir, dass Sie uns die beste Availability Zone basierend auf dem Systemzustand und der verfügbaren Kapazität für Sie auswählen lassen. Geben Sie beim Starten weiterer Instances nur dann eine Availability Zone an, wenn die neuen Instances entweder nah bei Ihren laufenden Instances oder getrennt davon sein müssen.

Wenn Sie 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.

Weitere Informationen finden Sie unter AWS Availability Zones im Benutzerhandbuch für AWS-Regionen und Availability Zones.

Local Zones

Eine Local Zone ist eine Erweiterung einer AWS-Region in geografischer Nähe zu Ihren Benutzern. Local Zones haben ihre eigenen Internetverbindungen und unterstützen Direct Connect. Ressourcen, die in einer lokalen Zone erstellt wurden, können so von lokalen Benutzern mit Netzwerkverbindungen mit geringer Latenz genutzt werden. Weitere Informationen finden Sie unter Was sind AWS Local Zones? im AWS-Benutzerhandbuch zu Local Zones.

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 veranschaulicht die AWS-Region us-west-2, zwei ihrer Availability Zones und zwei ihrer lokalen Zonen. Die VPC erstreckt sich über die Availability Zones und eine der lokalen Zonen. Jede Zone in der VPC hat ein Subnetz und jedes Subnetz eine Instance.

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 ein eindeutiger Satz von Availability Zones, Local Zones oder Wavelength Zones, aus denen AWS IP-Adressen ankündigt, zum Beispiel 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 Erste Schritte mit AWS Local Zones im Benutzerhandbuch zu AWS Local Zones.

Wavelength-Zones

AWS WavelengthMit können Developer Anwendungen mit ultra-niedriger Latenz für Mobilgeräte und Endbenutzer erstellen. Wavelength stellt standardmäßige AWS-Datenverarbeitungs- und Speicher-Services für die Grenze der 5G-Netze von Telekommunikationsanbietern bereit. Entwickler können eine Virtual Private Cloud (VPC) auf eine oder mehrere Wavelength-Zonen ausweiten und dann AWS-Ressourcen wie Amazon-EC2-Instances verwenden, um Anwendungen auszuführen, die eine extrem niedrige Latenz und eine Verbindung zu AWS-Services 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 veranschaulicht die AWS-Region us-west-2, zwei ihrer Availability Zones und eine Wavelength-Zone. Die VPC erstreckt sich über die Availability Zones und die Wavelength-Zone. Jede Zone in der VPC hat ein Subnetz und jedes Subnetz eine Instance.

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.

Weitere Informationen 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-Infrastruktur, Services, APIs und Tools auf Kundenstandorte ausweitet. Durch die Bereitstellung des lokalen Zugriffs auf die von AWS verwaltete Infrastruktur ermöglicht AWS Outposts Kunden, Anwendungen On-Premises mit denselben Programmierschnittstellen wie in AWS-Regionen zu erstellen und auszuführen, während lokale Datenverarbeitungs- und Speicherressourcen für geringere Latenz und lokale Datenverarbeitungsanforderungen verwendet werden.

Ein Outpost ist ein Pool von AWS-Rechen- und Speicherkapazitäten, die an einem Kundenstandort bereitgestellt werden. AWS betreibt, überwacht und verwaltet diese Kapazität als Teil einer AWS-Region. Sie können Subnetze in Ihrem Outpost erstellen und diese angeben, wenn Sie AWS-Ressourcen erstellen. Instances in Outpost-Subnetzen kommunizieren mit anderen Instances in der AWS-Region mithilfe privater IP-Adressen, sämtlich innerhalb derselben VPC.

Das folgende Diagramm veranschaulicht die AWS-Region us-west-2, zwei ihrer Availability Zones und einen Outpost. Die VPC erstreckt sich über 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 eine Instance.

Starten von Instances in einem Outpost

Um mit der Verwendung von AWS Outposts zu beginnen, müssen Sie einen Outpost erstellen und die 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 Ihres Outpost-Equipments steht Ihnen die Datenverarbeitungs- und Speicherkapazität zur Verfügung, wenn Sie Amazon-EC2-Instances in 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 Instances in Outpost-Subnetzen mit SSH herzustellen, geben Sie beim Starten der Instance ein Schlüsselpaar an, genauso wie bei Instances in einem Availability-Zone-Subnetz.

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

Volumes in einem Outposts-Rack

Wenn sich Ihre Dantenverabeitungskapazität in einem Outpost-Rack befindet, können Sie EBS-Volumes in dem Outpost-Subnetz erstellen, das Sie erstellt haben. 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 Ihres Amazon EBS gp2-Volumes dynamisch ändern, ohne sie zu trennen. Weitere Informationen zum Ändern eines Volumes ohne es abzuhängen finden Sie unter Anfordern von Änderungen an Ihren EBS-Volumes im Amazon-EBS-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 Daten-Volumes in der Blockgeräte-Zuweisung des AMI oder der Instance angeben, um zusätzlichen Speicher bereitzustellen. Informationen zum Begrenzen nicht verwendeter Blöcke vom Boot-Volume finden Sie unter So erstellen Sie Sparse-EBS-Volumes im AWS-Partner-Netzwerk-Blog.

Es wird empfohlen, das NVMe-Timeout für das Root-Volume zu erhöhen. Weitere Informationen finden Sie unter E/A-Betriebs-Timeout im Amazon-EBS-Benutzerhandbuch.

Volumes in einem Outposts-Server

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