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. # Verwaltung Ihrer eigenen Amazon VPC-Endpunkte auf Amazon MWAA Amazon MWAA verwendet Amazon VPC-Endpunkte zur Integration mit verschiedenen AWS Services, die für die Einrichtung einer Apache Airflow Airflow-Umgebung erforderlich sind. Die Verwaltung eigener Endpunkte hat zwei Hauptanwendungsfälle: 1. Das bedeutet, dass Sie Apache Airflow Airflow-Umgebungen in einer gemeinsam genutzten Amazon VPC erstellen können, wenn Sie mehrere [AWS Organizations](https://aws.amazon.com/organizations/)Ressourcen verwalten AWS-Konten und gemeinsam nutzen. 1. Sie können damit restriktivere Zugriffsrichtlinien verwenden, indem Sie Ihre Berechtigungen auf die spezifischen Ressourcen einschränken, die Ihre Endgeräte verwenden. Wenn Sie sich dafür entscheiden, Ihre eigenen VPC-Endpunkte zu verwalten, sind Sie dafür verantwortlich, Ihre eigenen Endpunkte für die Umgebung RDS für die PostgreSQL-Datenbank und für den Umgebungswebserver zu erstellen. Weitere Informationen darüber, wie Amazon MWAA Apache Airflow in der Cloud bereitstellt, finden Sie im [Amazon](what-is-mwaa.md#architecture-mwaa) MWAA-Architekturdiagramm. **Wichtig** Amazon MWAA validiert die Auswahl des IP-Adresstyps (`AddressType`) für vom Kunden verwaltete Endgeräte nicht. Stellen Sie daher sicher, dass Sie diese korrekt angeben `AddressType` (gültige Optionen sind oder). IPv4 IPv6 ## Eine Umgebung in einer gemeinsam genutzten Amazon VPC erstellen Wenn Sie mehrere AWS-Konten gemeinsam [AWS Organizations](https://aws.amazon.com/organizations/)genutzte Ressourcen verwalten, können Sie vom Kunden verwaltete VPC-Endpunkte mit Amazon MWAA verwenden, um Umgebungsressourcen mit einem anderen Konto in Ihrer Organisation gemeinsam zu nutzen. Wenn Sie den gemeinsamen VPC-Zugriff konfigurieren, teilt sich das Konto, dem die Haupt-Amazon-VPC (*Eigentümer*) gehört, die beiden von Amazon MWAA benötigten privaten Subnetze mit anderen Konten (*Teilnehmern*), die derselben Organisation angehören. Teilnehmerkonten, die diese Subnetze gemeinsam nutzen, können Umgebungen in der gemeinsam genutzten Amazon VPC anzeigen, erstellen, ändern und löschen. Angenommen, Sie haben ein Konto`Owner`, das als `Root` Konto in der Organisation fungiert und Eigentümer der Amazon VPC-Ressourcen ist, und ein Teilnehmerkonto`Participant`, ein Mitglied derselben Organisation. Wenn eine neue Amazon MWAA in Amazon VPC `Participant` erstellt wird`Owner`, mit der sie gemeinsam genutzt wird, erstellt Amazon MWAA zunächst die Service-VPC-Ressourcen und wechselt dann in einen [https://docs.aws.amazon.com/mwaa/latest/API/API_Environment.html#mwaa-Type-Environment-Status](https://docs.aws.amazon.com/mwaa/latest/API/API_Environment.html#mwaa-Type-Environment-Status)Status für bis zu 72 Stunden. Nachdem sich der Umgebungsstatus von `CREATING` zu geändert hat, erstellt ein Principal`PENDING`, der im Namen von handelt, die erforderlichen Endpunkte. `Owner` Zu diesem Zweck listet Amazon MWAA die Datenbank und den Webserver-Endpunkt in der Amazon MWAA-Konsole auf. Sie können auch die []()API-Aktion aufrufen, um die Service-Endpunkte abzurufen. **Anmerkung** Wenn es sich bei der Amazon-VPC, die Sie für die gemeinsame Nutzung von Ressourcen verwenden, um eine private Amazon-VPC handelt, müssen Sie dennoch die unter beschriebenen Schritte ausführen. [Verwaltung des Zugriffs auf servicespezifische Amazon VPC-Endpunkte auf Amazon MWAA](vpc-vpe-access.md) Das Thema behandelt die Einrichtung verschiedener Amazon VPC-Endpunkte im Zusammenhang mit anderen AWS Services, die AWS sich in Amazon ECR, Amazon ECS und Amazon SQS integrieren lassen. Diese Dienste sind für den Betrieb und die Verwaltung Ihrer Apache Airflow Airflow-Umgebung in der Cloud unerlässlich. ### Voraussetzungen Bevor Sie eine Amazon MWAA-Umgebung in einer gemeinsam genutzten VPC erstellen, benötigen Sie die folgenden Ressourcen: + Ein AWS-Konto, `Owner` das als Konto verwendet werden soll, dem die Amazon VPC gehört. + Eine [AWS Organizations](https://aws.amazon.com/organizations/)Organisationseinheit, die als *Stamm `MyOrganization`* erstellt wurde. + Eine zweite AWS-Konto,`Participant`, unter`MyOrganization`, dient dem Teilnehmerkonto, das die neue Umgebung erstellt. Darüber hinaus empfehlen wir Ihnen, sich mit den [Verantwortlichkeiten und Berechtigungen für Eigentümer und Teilnehmer](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html#vpc-share-limitations) bei der gemeinsamen Nutzung von Ressourcen in Amazon VPC vertraut zu machen. ### Erstellen Sie die Amazon VPC Erstellen Sie zunächst eine neue Amazon VPC, die die Eigentümer- und Teilnehmerkonten gemeinsam nutzen werden: 1. Melden Sie sich bei der Konsole an`Owner`, indem Sie die CloudFormation Konsole öffnen. Verwenden Sie die folgende Vorlage, um einen Stack zu erstellen. Dieser Stack stellt eine Reihe von Netzwerkressourcen bereit, darunter eine Amazon-VPC und die Subnetze, die sich die beiden Konten in diesem Szenario teilen werden. ``` AWSTemplateFormatVersion: "2010-09-09" Description: >- This template deploys a VPC, with a pair of public and private subnets spread across two Availability Zones. It deploys an internet gateway, with a default route on the public subnets. It deploys a pair of NAT gateways (one in each AZ), and default routes for them in the private subnets. Parameters: EnvironmentName: Description: An environment name that is prefixed to resource names Type: String Default: mwaa- VpcCIDR: Description: Please enter the IP range (CIDR notation) for this VPC Type: String Default: 10.192.0.0/16 PublicSubnet1CIDR: Description: >- Please enter the IP range (CIDR notation) for the public subnet in the first Availability Zone Type: String Default: 10.192.10.0/24 PublicSubnet2CIDR: Description: >- Please enter the IP range (CIDR notation) for the public subnet in the second Availability Zone Type: String Default: 10.192.11.0/24 PrivateSubnet1CIDR: Description: >- Please enter the IP range (CIDR notation) for the private subnet in the first Availability Zone Type: String Default: 10.192.20.0/24 PrivateSubnet2CIDR: Description: >- Please enter the IP range (CIDR notation) for the private subnet in the second Availability Zone Type: String Default: 10.192.21.0/24 Resources: VPC: Type: 'AWS::EC2::VPC' Properties: CidrBlock: !Ref VpcCIDR EnableDnsSupport: true EnableDnsHostnames: true Tags: - Key: Name Value: !Ref EnvironmentName InternetGateway: Type: 'AWS::EC2::InternetGateway' Properties: Tags: - Key: Name Value: !Ref EnvironmentName InternetGatewayAttachment: Type: 'AWS::EC2::VPCGatewayAttachment' Properties: InternetGatewayId: !Ref InternetGateway VpcId: !Ref VPC PublicSubnet1: Type: 'AWS::EC2::Subnet' Properties: VpcId: !Ref VPC AvailabilityZone: !Select - 0 - !GetAZs '' CidrBlock: !Ref PublicSubnet1CIDR MapPublicIpOnLaunch: true Tags: - Key: Name Value: !Sub '${EnvironmentName} Public Subnet (AZ1)' PublicSubnet2: Type: 'AWS::EC2::Subnet' Properties: VpcId: !Ref VPC AvailabilityZone: !Select - 1 - !GetAZs '' CidrBlock: !Ref PublicSubnet2CIDR MapPublicIpOnLaunch: true Tags: - Key: Name Value: !Sub '${EnvironmentName} Public Subnet (AZ2)' PrivateSubnet1: Type: 'AWS::EC2::Subnet' Properties: VpcId: !Ref VPC AvailabilityZone: !Select - 0 - !GetAZs '' CidrBlock: !Ref PrivateSubnet1CIDR MapPublicIpOnLaunch: false Tags: - Key: Name Value: !Sub '${EnvironmentName} Private Subnet (AZ1)' PrivateSubnet2: Type: 'AWS::EC2::Subnet' Properties: VpcId: !Ref VPC AvailabilityZone: !Select - 1 - !GetAZs '' CidrBlock: !Ref PrivateSubnet2CIDR MapPublicIpOnLaunch: false Tags: - Key: Name Value: !Sub '${EnvironmentName} Private Subnet (AZ2)' NatGateway1EIP: Type: 'AWS::EC2::EIP' DependsOn: InternetGatewayAttachment Properties: Domain: vpc NatGateway2EIP: Type: 'AWS::EC2::EIP' DependsOn: InternetGatewayAttachment Properties: Domain: vpc NatGateway1: Type: 'AWS::EC2::NatGateway' Properties: AllocationId: !GetAtt NatGateway1EIP.AllocationId SubnetId: !Ref PublicSubnet1 NatGateway2: Type: 'AWS::EC2::NatGateway' Properties: AllocationId: !GetAtt NatGateway2EIP.AllocationId SubnetId: !Ref PublicSubnet2 PublicRouteTable: Type: 'AWS::EC2::RouteTable' Properties: VpcId: !Ref VPC Tags: - Key: Name Value: !Sub '${EnvironmentName} Public Routes' DefaultPublicRoute: Type: 'AWS::EC2::Route' DependsOn: InternetGatewayAttachment Properties: RouteTableId: !Ref PublicRouteTable DestinationCidrBlock: 0.0.0.0/0 GatewayId: !Ref InternetGateway PublicSubnet1RouteTableAssociation: Type: 'AWS::EC2::SubnetRouteTableAssociation' Properties: RouteTableId: !Ref PublicRouteTable SubnetId: !Ref PublicSubnet1 PublicSubnet2RouteTableAssociation: Type: 'AWS::EC2::SubnetRouteTableAssociation' Properties: RouteTableId: !Ref PublicRouteTable SubnetId: !Ref PublicSubnet2 PrivateRouteTable1: Type: 'AWS::EC2::RouteTable' Properties: VpcId: !Ref VPC Tags: - Key: Name Value: !Sub '${EnvironmentName} Private Routes (AZ1)' DefaultPrivateRoute1: Type: 'AWS::EC2::Route' Properties: RouteTableId: !Ref PrivateRouteTable1 DestinationCidrBlock: 0.0.0.0/0 NatGatewayId: !Ref NatGateway1 PrivateSubnet1RouteTableAssociation: Type: 'AWS::EC2::SubnetRouteTableAssociation' Properties: RouteTableId: !Ref PrivateRouteTable1 SubnetId: !Ref PrivateSubnet1 PrivateRouteTable2: Type: 'AWS::EC2::RouteTable' Properties: VpcId: !Ref VPC Tags: - Key: Name Value: !Sub '${EnvironmentName} Private Routes (AZ2)' DefaultPrivateRoute2: Type: 'AWS::EC2::Route' Properties: RouteTableId: !Ref PrivateRouteTable2 DestinationCidrBlock: 0.0.0.0/0 NatGatewayId: !Ref NatGateway2 PrivateSubnet2RouteTableAssociation: Type: 'AWS::EC2::SubnetRouteTableAssociation' Properties: RouteTableId: !Ref PrivateRouteTable2 SubnetId: !Ref PrivateSubnet2 SecurityGroup: Type: 'AWS::EC2::SecurityGroup' Properties: GroupName: mwaa-security-group GroupDescription: Security group with a self-referencing inbound rule. VpcId: !Ref VPC SecurityGroupIngress: Type: 'AWS::EC2::SecurityGroupIngress' Properties: GroupId: !Ref SecurityGroup IpProtocol: '-1' SourceSecurityGroupId: !Ref SecurityGroup Outputs: VPC: Description: A reference to the created VPC Value: !Ref VPC PublicSubnets: Description: A list of the public subnets Value: !Join - ',' - - !Ref PublicSubnet1 - !Ref PublicSubnet2 PrivateSubnets: Description: A list of the private subnets Value: !Join - ',' - - !Ref PrivateSubnet1 - !Ref PrivateSubnet2 PublicSubnet1: Description: A reference to the public subnet in the 1st Availability Zone Value: !Ref PublicSubnet1 PublicSubnet2: Description: A reference to the public subnet in the 2nd Availability Zone Value: !Ref PublicSubnet2 PrivateSubnet1: Description: A reference to the private subnet in the 1st Availability Zone Value: !Ref PrivateSubnet1 PrivateSubnet2: Description: A reference to the private subnet in the 2nd Availability Zone Value: !Ref PrivateSubnet2 SecurityGroupIngress: Description: Security group with self-referencing inbound rule Value: !Ref SecurityGroupIngress ``` 1. Nachdem die neuen Amazon VPC-Ressourcen bereitgestellt wurden, navigieren Sie zur AWS Resource Access Manager Konsole und wählen Sie **Create resource** share aus. 1. Wählen Sie die Subnetze, die Sie im ersten Schritt erstellt haben, aus der Liste der verfügbaren Subnetze aus, mit denen Sie Daten teilen können. `Participant` ### Erstellen der -Umgebung Gehen Sie wie folgt vor, um eine Amazon MWAA-Umgebung mit kundenverwalteten Amazon VPC-Endpunkten zu erstellen. 1. Melden Sie sich mit `Participant` der Amazon MWAA-Konsole an und öffnen Sie sie. Schließen Sie **Schritt eins ab: Geben Sie Details** an, um einen Amazon S3 S3-Bucket, einen DAG-Ordner und Abhängigkeiten für Ihre neue Umgebung anzugeben. Weitere Informationen finden Sie unter [Erste Schritte](create-environment.md#create-environment-start-details). 1. Wählen Sie auf der Seite **Erweiterte Einstellungen konfigurieren** unter **Netzwerk** die Subnetze aus der gemeinsam genutzten Amazon VPC aus. 1. Wählen Sie unter **Endpoint Management** die Option **CUSTOMER** aus der Dropdownliste aus. 1. Behalten Sie die Standardeinstellung für die übrigen Optionen auf der Seite bei und wählen Sie dann auf der Seite **Überprüfen und **erstellen die Option Umgebung** erstellen** aus. Die Umgebung beginnt in einem `CREATING` Zustand und wechselt dann zu`PENDING`. Wenn die Umgebung aktiviert ist`PENDING`, notieren Sie sich mithilfe der **Konsole den Namen des Datenbankendpunkts** und den **Dienstnamen des Webserver-Endpunkts** (wenn Sie einen privaten Webserver einrichten). Wenn Sie mit der Amazon MWAA-Konsole eine neue Umgebung erstellen. Amazon MWAA erstellt eine neue Sicherheitsgruppe mit den erforderlichen Regeln für eingehenden und ausgehenden Datenverkehr. Notieren Sie sich die Sicherheitsgruppen-ID. Im nächsten Abschnitt `Owner` werden die Service-Endpunkte und die Sicherheitsgruppen-ID verwendet, um neue Amazon VPC-Endpunkte in der gemeinsam genutzten Amazon VPC zu erstellen. ### Amazon VPC-Endpoints erstellen Gehen Sie wie folgt vor, um die erforderlichen Amazon VPC-Endpoints für Ihre Umgebung zu erstellen. 1. Melden Sie sich AWS-Managementkonsole mit dem Öffnen `Owner` an. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) 1. Wählen Sie im linken Navigationsbereich **Sicherheitsgruppen** aus und erstellen Sie dann eine neue Sicherheitsgruppe in der gemeinsam genutzten Amazon VPC mit den folgenden Regeln für eingehende und ausgehende Nachrichten: [See the AWS documentation website for more details](http://docs.aws.amazon.com/de_de/mwaa/latest/userguide/vpc-endpoint-management.html) **Warnung** Das `Owner` Konto muss eine Sicherheitsgruppe im `Owner` Konto einrichten, um den Datenverkehr von der neuen Umgebung zur gemeinsam genutzten Amazon-VPC zuzulassen. Sie können dies tun, indem Sie eine neue Sicherheitsgruppe in `Owner` erstellen oder eine bestehende bearbeiten. 1. Wählen Sie **Endpoints** aus und erstellen Sie dann neue Endpoints für die Umgebungsdatenbank und den Webserver (falls im privaten Modus). Verwenden Sie dabei die Namen der Endpunktdienste aus den vorherigen Schritten. Wählen Sie die gemeinsam genutzte Amazon-VPC, die Subnetze, die Sie für die Umgebung verwendet haben, und die Sicherheitsgruppe der Umgebung aus. Im Erfolgsfall ändert sich die Umgebung zunächst von `PENDING` Zurück zu `CREATING` und dann endgültig zu. `AVAILABLE` Wenn dies der Fall ist`AVAILABLE`, können Sie sich bei der Apache Airflow Airflow-Konsole anmelden. ### Gemeinsame Amazon VPC-Fehlerbehebung Verwenden Sie die folgende Referenz, um Probleme zu lösen, die beim Erstellen von Umgebungen in einer gemeinsam genutzten Amazon VPC auftreten. **Umgebung im Status „`CREATE_FAILED`Danach`PENDING`“** + Stellen Sie sicher, `Owner` dass die Subnetze gemeinsam `Participant` genutzt werden [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html). + Stellen Sie sicher, dass die Amazon VPC-Endpoints für die Datenbank und den Webserver in denselben Subnetzen erstellt wurden, die der Umgebung zugeordnet sind. + Vergewissern Sie sich, dass die für Ihre Endgeräte verwendete Sicherheitsgruppe Datenverkehr von den für die Umgebung verwendeten Sicherheitsgruppen zulässt. Das `Owner` Konto erstellt Regeln, die `Participant` wie folgt auf die Sicherheitsgruppe verweisen`{{123456789012}}/{{security-group-id}}`:. [See the AWS documentation website for more details](http://docs.aws.amazon.com/de_de/mwaa/latest/userguide/vpc-endpoint-management.html) Weitere Informationen finden Sie unter [Zuständigkeiten und Berechtigungen für Eigentümer und Teilnehmer](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html#vpc-share-limitations) **Die Umgebung ist im `PENDING` Status stecken geblieben** Überprüfen Sie den Status jedes VPC-Endpunkts, um sicherzustellen, dass dies der Fall ist`Available`. Wenn Sie eine Umgebung mit einem privaten Webserver konfigurieren, müssen Sie auch einen Endpunkt für den Webserver erstellen. Wenn die Umgebung nicht mehr funktioniert`PENDING`, kann dies darauf hindeuten, dass der private Webserver-Endpunkt fehlt. **Fehler empfangen `The Vpc Endpoint Service '{{vpce-service-name}}' does not exist`** Wenn Sie auf den folgenden Fehler verweisen, stellen Sie sicher, dass das Konto, das die Endpoints erstellt, das `Owner` Konto ist, dem die gemeinsam genutzte VPC gehört: ``` ClientError: An error occurred (InvalidServiceName) when calling the CreateVpcEndpoint operation: The Vpc Endpoint Service '{{vpce-service-name}}' does not exist ```