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.
# Freigeben Ihrer VPC-Subnetze für andere Konten
Die gemeinsame Nutzung von VPC-Subnetzen ermöglicht es mehreren AWS-Konten , ihre Anwendungsressourcen wie Amazon EC2 EC2-Instances, Amazon Relational Database Service (RDS) -Datenbanken, Amazon Redshift Redshift-Cluster und AWS Lambda Funktionen in gemeinsam genutzten, zentral verwalteten virtuellen privaten Clouds () zu erstellen. VPCs In diesem Modell teilt sich das Konto, dem die VPC gehört (Eigentümer), ein oder mehrere Subnetze mit anderen Konten (Teilnehmern), die derselben Organisation angehören. AWS Organizations Wenn ein Subnetz freigegeben wurde, können die Teilnehmer ihre Anwendungsressourcen in den für sie freigegebenen Subnetzen anzeigen, erstellen, ändern oder löschen. Teilnehmer können keine Ressourcen anzeigen, ändern oder löschen, die anderen Teilnehmern oder dem VPC-Eigentümer gehören.
Sie können Ihre VPC-Subnetze freigeben, um das implizite Routing innerhalb eines VPCs für Anwendungen zu verwenden, die einen hohen Grad an Interaktivität erfordern und sich innerhalb derselben Vertrauensbereiche befinden. Dadurch wird die Anzahl der Konten reduziert VPCs , die Sie erstellen und verwalten, und gleichzeitig separate Konten für Abrechnung und Zugriffskontrolle verwenden. Sie können Netzwerktopologien vereinfachen, indem Sie gemeinsam genutzte Amazon VPC-Subnetze mithilfe von Konnektivitätsfunktionen wie AWS PrivateLink Transit-Gateways und VPC-Peering miteinander verbinden. Weitere Informationen zu den Vorteilen der VPC-Subnetz-Freigabe finden Sie unter [VPC-Freigabe: Ein neuer Ansatz für mehrere Konten und für die VPC-Verwaltung](https://aws.amazon.com/blogs/networking-and-content-delivery/vpc-sharing-a-new-approach-to-multiple-accounts-and-vpc-management/).
Es gibt Quoten für die VPC-Subnetz-Freigabe. Weitere Informationen finden Sie unter [VPC-Subnetz-Freigabe](amazon-vpc-limits.md#vpc-share-limits).
**Topics**
+ [Voraussetzungen für die Arbeit mit freigegebenen Subnetzen](vpc-share-prerequisites.md)
+ [Arbeiten mit freigegebenen Subnetzen](vpc-sharing-share-subnet-working-with.md)
+ [Fakturierung und Messung für den Eigentümer und Teilnehmer](vpc-share-billing.md)
+ [Verantwortlichkeiten und Berechtigungen für Besitzer und Teilnehmer](vpc-share-limitations.md)
+ [AWS Ressourcen und gemeinsam genutzte VPC-Subnetze](vpc-sharing-service-behavior.md)
# Voraussetzungen für die Arbeit mit freigegebenen Subnetzen
Dieser Abschnitt enthält die Voraussetzungen für die Arbeit mit freigegebenen Subnetzen:
+ Die Konten für den VPC-Besitzer und -Teilnehmer müssen von AWS Organizations verwaltet werden.
+ Sie müssen die gemeinsame Nutzung von Ressourcen in der AWS RAM Konsole über das Verwaltungskonto Ihrer Organisation aktivieren. Weitere Informationen finden Sie unter [Ressourcenfreigabe für AWS Organizations aktivieren](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs) im *AWS RAM -Benutzerhandbuch*.
+ Sie müssen eine Ressourcenfreigabe erstellen. Sie können bei der Erstellung der Ressourcenfreigabe angeben, welche Subnetze freigegeben werden sollen, oder Sie können später mithilfe des Verfahrens im nächsten Abschnitt die Subnetze zur Ressourcenfreigabe hinzufügen. Weitere Informationen finden Sie unter [Erstellen einer Ressourcenfreigabe](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-create) im *AWS RAM -Benutzerhandbuch*.
# Arbeiten mit freigegebenen Subnetzen
In diesem Abschnitt wird beschrieben, wie Sie mit gemeinsam genutzten Subnetzen in der AWS Konsole und AWS CLI arbeiten.
**Topics**
+ [Freigeben eines Subnetzes](#vpc-sharing-share-subnet)
+ [Freigeben eines freigegebenen Subnetzes rückgängig machen](#vpc-sharing-stop-share-subnet)
+ [Identifizieren des Eigentümers eines freigegebenen Subnetzes](#vpc-sharing-view-owner)
## Freigeben eines Subnetzes
Sie können Nichtstandard-Subnetze für andere Konten innerhalb Ihrer Organisation wie folgt freigeben. Darüber hinaus können Sie Sicherheitsgruppen unternehmensweit gemeinsam AWS Organizations. Weitere Informationen finden Sie unter [Sicherheitsgruppen mit AWS Organizations teilen](security-group-sharing.md).
**Ein Subnetz mit der Konsole freigeben**
1. Öffnen Sie die Amazon-VPC-Konsole unter [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Wählen Sie im Navigationsbereich **Subnets (Subnetze)** aus.
1. Wählen Sie Ihr Subnetz und anschließend **Actions (Aktionen)**, **Share subnet (Subnetz freigeben)** aus.
1. Wählen Sie Ihre Ressourcenfreigabe und anschließend **Share subnet (Subnetz freigeben)** aus.
**Um ein Subnetz gemeinsam zu nutzen, verwenden Sie AWS CLI**
Verwenden Sie die Befehle [create-resource-share](https://docs.aws.amazon.com/cli/latest/reference/ram/create-resource-share.html) und [associate-resource-share](https://docs.aws.amazon.com/cli/latest/reference/ram/associate-resource-share.html).
### Zuweisung von Subnetzen über Availability Zones hinweg
Um sicherzustellen, dass Ressourcen auf die Availability Zones einer Region verteilt sind, ordnen wir Availability Zones einzeln Namen für jedes -Konto zu. Beispielsweise hat die Availability Zone `us-east-1a` für Ihr AWS Konto möglicherweise nicht denselben Standort wie `us-east-1a` für ein anderes AWS Konto.
Um die Availability Zones kontenübergreifend für die VPC-Freigabe zu koordinieren, müssen Sie eine *AZ-ID* verwenden, die eine eindeutige und konsistente Kennung für eine Availability Zone ist. Beispielsweise ist `use1-az1` die AZ-ID einer der Availability Zones in der Region `us-east-1`. Verwenden Sie AZ IDs , um den Standort von Ressourcen in einem Konto im Verhältnis zu einem anderen Konto zu ermitteln. Sie können die AZ-ID für jedes Subnetz in der Amazon VPC-Konsole anzeigen.
Das folgende Diagramm veranschaulicht zwei Konten mit unterschiedlichen Zuordnungen von Availability Zone-Code zur AZ-ID.
![\[Zwei Konten mit unterschiedlichen Zuordnungen von Availability Zone-Code zur AZ-ID.\]](http://docs.aws.amazon.com/de_de/vpc/latest/userguide/images/availability-zone-mapping.png)
## Freigeben eines freigegebenen Subnetzes rückgängig machen
Der Eigentümer kann die Freigabe eines Subnetzes für Teilnehmer jederzeit aufheben. Nachdem der Eigentümer die Freigabe eines Subnetzes aufgehoben hat, gelten die folgenden Regeln:
+ Bestehende Teilnehmerressourcen werden weiterhin im nicht gemeinsam genutzten Subnetz ausgeführt. AWS Managed Services (z. B. Elastic Load Balancing) mit automated/managed Workflows (wie Auto Scaling oder Node Replacement) erfordern möglicherweise für einige Ressourcen kontinuierlichen Zugriff auf das gemeinsam genutzte Subnetz.
+ Teilnehmer können keine neuen Ressourcen mehr im nicht länger freigegebenen Subnetz erstellen.
+ Teilnehmer können ihre Ressourcen im Subnetz ändern, beschreiben und löschen.
+ Wenn Teilnehmer noch über Ressourcen im nicht länger freigegebenen Subnetz verfügen, kann der Eigentümer das nicht länger freigegebene Subnetz oder dessen VPC nicht löschen. Der Eigentümer kann das nicht länger freigegebene Subnetz oder dessen VPC erst löschen, nachdem die Teilnehmer alle Ressourcen im nicht länger freigegebenen Subnetz gelöscht haben.
**Die Freigabe eines Subnetzes unter Verwendung der Konsole aufheben**
1. Öffnen Sie die Amazon-VPC-Konsole unter [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Wählen Sie im Navigationsbereich **Subnets (Subnetze)** aus.
1. Wählen Sie Ihr Subnetz und anschließend **Actions (Aktionen)**, **Share subnet (Subnetz freigeben)** aus.
1. Wählen Sie **Actions (Aktionen)** und **Stop sharing (Freigabe aufheben)** aus.
**Um die gemeinsame Nutzung eines Subnetzes aufzuheben, verwenden Sie den AWS CLI**
Verwenden Sie den Befehl [disassociate-resource-share](https://docs.aws.amazon.com/cli/latest/reference/ram/disassociate-resource-share.html).
## Identifizieren des Eigentümers eines freigegebenen Subnetzes
Teilnehmer können die für sie freigegebenen Subnetze mit der Amazon VPC-Konsole oder dem Befehlszeilen-Tool anzeigen.
**So identifizieren Sie den Eigentümer eines Subnetzes mit der Konsole**
1. Öffnen Sie die Amazon-VPC-Konsole unter [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Wählen Sie im Navigationsbereich **Subnets (Subnetze)** aus. Die Spalte **Owner (Eigentümer)** zeigt den Eigentümer des Subnetzes an.
**Um einen Subnetzbesitzer mit dem zu identifizieren AWS CLI**
Verwenden Sie die Befehle [describe-subnets](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-subnets.html) und [describe-vpcs](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-vpcs.html), in deren Ausgabe die ID des Besitzers enthalten ist.
# Fakturierung und Messung für den Eigentümer und Teilnehmer
Dieser Abschnitt enthält Fakturierungs- und Nutzungsdetails für diejenigen, denen das freigegebene Subnetz gehört, und für diejenigen, die mit dem freigegebenen Subnetz arbeiten:
+ In einer gemeinsam genutzten VPC zahlt jeder Teilnehmer für seine Anwendungsressourcen, einschließlich Amazon EC2 EC2-Instances, Amazon Relational Database Service Service-Datenbanken, Amazon Redshift Redshift-Cluster und Funktionen. AWS Lambda Die Teilnehmer zahlen auch die Datenübertragungsgebühren im Zusammenhang mit der Datenübertragung zwischen den Availability Zones sowie der Datenübertragung über VPC-Peering-Verbindungen, über Internet-Gateways und über Gateways hinweg. AWS Direct Connect
+ VPC-Besitzer zahlen Stundengebühren (falls zutreffend), Datenverarbeitungs- und Datenübertragungsgebühren für NAT-Gateways, virtuelle private Gateways, Transit-Gateways und VPC-Endpunkte. AWS PrivateLink Darüber hinaus werden öffentliche IPv4 Adressen, die in Shared verwendet VPCs werden, den VPC-Besitzern in Rechnung gestellt. Weitere Informationen zu den Preisen für öffentliche IPv4 Adressen finden Sie auf der [Amazon VPC-Preisseite](https://aws.amazon.com/vpc/pricing/) auf der Registerkarte **Öffentliche IPv4 Adressen**.
+ Datenübertragungen innerhalb derselben Availability Zone (durch die eindeutige AZ-ID angegeben) sind kostenlos – unabhängig davon, wer der Besitzer des Kontos der kommunizierenden Ressourcen ist.
# Verantwortlichkeiten und Berechtigungen für Besitzer und Teilnehmer
Dieser Abschnitt enthält detaillierte Informationen zu den Verantwortlichkeiten und Berechtigungen für diejenigen, denen das freigegebene Subnetz gehört (Eigentümer), und für diejenigen, die das freigegebene Subnetz verwenden (Teilnehmer).
## Besitzer-Ressourcen
Eigentümer sind für die VPC-Ressourcen verantwortlich, die sie besitzen. VPC-Besitzer sind dafür verantwortlich, die Ressourcen zu erstellen, zu verwalten und zu löschen, die mit einer gemeinsam genutzten VPC verknüpft sind. Dazu gehören Subnetze, Routing-Tabellen, Netzwerk- ACLs, Peering-Verbindungen, Gateway-Endpunkte, Schnittstellenendpunkte, Route 53-Resolver-Endpunkte, Internet-Gateways, NAT-Gateways, virtuelle private Gateways und Transit-Gateway-Anlagen.
## Teilnehmer-Ressourcen
Teilnehmer sind für die VPC-Ressourcen verantwortlich, die sie besitzen. Teilnehmer können eine begrenzte Anzahl von VPC-Ressourcen in einer freigegebenen VPC erstellen. Teilnehmer können beispielsweise Netzwerkschnittstellen und Sicherheitsgruppen und VPC-Ablaufprotokolle für die Netzwerkschnittstellen, deren Eigentümer sie sind, erstellen. Die VPC-Ressourcen, die ein Teilnehmer erstellt, werden auf die VPC-Kontingente im Teilnehmerkonto angerechnet, nicht auf das Eigentümerkonto. Weitere Informationen finden Sie unter [VPC-Subnetz-Freigabe](amazon-vpc-limits.md#vpc-share-limits).
## VPC-Ressourcen
Die folgenden Verantwortlichkeiten und Berechtigungen gelten für VPC-Ressourcen, wenn Sie mit gemeinsam genutzten VPC-Subnetzen arbeiten:
**Flow-Protokolle**
+ Teilnehmer können Flow-Protokolle für Netzwerkschnittstellen, deren Eigentümer sie sind, in einem freigegebenen VPC-Subnetz erstellen, löschen und beschreiben.
+ Teilnehmer können Flow-Protokolle für Netzwerkschnittstellen, deren Eigentümer sie nicht sind, in einem freigegebenen VPC-Subnetz nicht erstellen, löschen oder beschreiben.
+ Teilnehmer können für ein freigegebenes VPC-Subnetz keine Flow-Protokolle erstellen, löschen oder beschreiben.
+ VPC-Eigentümer können Flow-Protokolle für Netzwerkschnittstellen, deren Eigentümer sie nicht sind, in einem freigegebenen VPC-Subnetz erstellen, löschen und beschreiben.
+ VPC-Eigentümer können Flow-Protokolle für ein freigegebenes VPC-Subnetz erstellen, löschen und beschreiben.
+ VPC-Eigentümer können von einem Teilnehmer erstellte Flow-Protokolle nicht beschreiben oder löschen.
**Internet-Gateways und Internet-Gateways nur für ausgehenden Datenverkehr**
+ Teilnehmer können in einem gemeinsam genutzten VPC-Subnetz keine Internet-Gateways und Internet-Gateways nur für ausgehenden Verkehr erstellen, anfügen oder löschen. Teilnehmer können Internet-Gateways in einem freigegebenen VPC-Subnetz beschreiben. Teilnehmer können Internet-Gateways für ausgehenden Verkehr in einem freigegebenen VPC-Subnetz nicht beschreiben.
**NAT gateways (NAT-Gateways)**
+ Teilnehmer können NAT-Gateways in einem gemeinsam genutzten VPC-Subnetz nicht erstellen, löschen oder beschreiben.
**NACLsListen zur Netzwerkzugriffskontrolle ()**
+ Teilnehmer können NACLs in einem gemeinsam genutzten VPC-Subnetz nichts erstellen, löschen oder ersetzen. Die Teilnehmer können beschreiben, die von VPC-Besitzern in einem gemeinsam genutzten VPC-Subnetz NACLs erstellt wurden.
**Netzwerkschnittstellen**
+ Teilnehmer können Netzwerkschnittstellen in einem gemeinsam genutzten VPC-Subnetz erstellen. Teilnehmer können nicht auf andere Weise mit Netzwerkschnittstellen arbeiten, die von VPC-Besitzern in einem gemeinsam genutzten VPC-Subnetz erstellt wurden, z. B. Anhängen, Trennen oder Ändern der Netzwerkschnittstellen. Teilnehmer können Netzwerkschnittstellen in einer gemeinsam genutzten VPC, die sie erstellt haben, ändern oder löschen. So können Teilnehmer beispielsweise IP-Adressen mit den von ihnen erstellten Netzwerkschnittstellen verknüpfen bzw. die Verknüpfung aufheben.
+ VPC-Eigentümer können Netzwerkschnittstellen beschreiben, die Teilnehmern in einem freigegebenen VPC-Subnetz gehören. VPC-Eigentümer können nicht auf andere Weise mit Netzwerkschnittstellen arbeiten, die den Teilnehmern gehören, z. B. Anhängen, Trennen oder Ändern der Netzwerkschnittstellen, die den Teilnehmern in einem freigegebenen VPC-Subnetz gehören.
**Routing-Tabellen**
+ Teilnehmer können in einem gemeinsam genutzten VPC-Subnetz nicht mit Routing-Tabellen arbeiten (z. B. Routing-Tabellen erstellen, löschen oder verknüpfen). Teilnehmer können Routing-Tabellen in einem gemeinsam genutzten VPC-Subnetz beschreiben.
**Sicherheitsgruppen**
+ Teilnehmer können Regeln für eingehenden und ausgehenden Datenverkehr für eigene Sicherheitsgruppen in einem freigegebenen VPC-Subnetz erstellen, löschen, beschreiben oder ändern. Teilnehmer können mit Sicherheitsgruppen arbeiten, die von VPC-Besitzern erstellt wurden, wenn [der VPC-Besitzer die Sicherheitsgruppe für den Teilnehmer freigegeben hat](security-group-sharing.md).
+ Teilnehmer können in den Sicherheitsgruppen, deren Eigentümer sie sind, Regeln erstellen, die auf Sicherheitsgruppen verweisen, die anderen Teilnehmern oder dem VPC-Besitzer gehören, wie folgt: Kontonummer/ security-group-id
+ Teilnehmer können keine Instances mit der Standard-Sicherheitsgruppe für die VPC starten, da diese dem Besitzer gehört.
+ Teilnehmer können keine Instances mit Nicht-Sicherheitsgruppen starten, die anderen Teilnehmern oder dem VPC-Besitzer gehören, sofern die Sicherheitsgruppe [für sie freigegeben ist](security-group-sharing.md).
+ VPC-Besitzer können Sicherheitsgruppen beschreiben, die von Teilnehmern in einem gemeinsam genutzten VPC-Subnetz erstellt wurden. VPC-Besitzer können auf keine andere Weise mit Sicherheitsgruppen arbeiten, die von Teilnehmern erstellt wurden. VPC-Besitzer können beispielsweise keine Instances mithilfe von Sicherheitsgruppen starten, die von Teilnehmern erstellt wurden.
**Subnets**
+ Teilnehmer können gemeinsam genutzte Subnetze oder ihre zugehörigen Attribute nicht ändern. Das kann nur der VPC-Besitzer. Teilnehmer können Subnetze in einem gemeinsam genutzten VPC-Subnetz beschreiben.
+ VPC-Besitzer können Subnetze nur mit anderen Konten oder Organisationseinheiten teilen, die sich in derselben Organisation von Organizations aus AWS befinden. VPC-Besitzer können keine Subnetze in Standard-VPCs freigeben.
**Transit Gateways**
+ Nur ein VPC-Besitzer kann ein Transit-Gateway an das gemeinsam genutzte VPC-Subnetz anfügen. Teilnehmer können das nicht.
**VPCs**
+ Die Teilnehmer können ihre zugehörigen VPCs Attribute nicht ändern. Das kann nur der VPC-Besitzer. Die Teilnehmer können ihre Attribute und die DHCP-Optionssätze beschreiben VPCs.
+ VPC-Tags und Tags für die Ressourcen innerhalb der freigegebenen VPC werden nicht für die Teilnehmer freigegeben.
+ Teilnehmer können ihre eigenen Sicherheitsgruppen mit einer freigegebenen VPC verknüpfen. Auf diese Weise kann der Teilnehmer die Sicherheitsgruppe mit Elastic Network-Schnittstellen verwenden, die er in der freigegebenen VPC besitzt.
# AWS Ressourcen und gemeinsam genutzte VPC-Subnetze
Die folgenden AWS-Services Support-Ressourcen in gemeinsam genutzten VPC-Subnetzen. Weitere Informationen finden Sie unter den Links zur entsprechenden Servicedokumentation.
+ [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html#USER_VPC.Shared_subnets)
+ [AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.VPC.html#CHAP_ReplicationInstance.VPC.Configurations.ScenarioVPCShared)
+ [Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-vpc.html#ec2-shared-VPC-subnets)
+ [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-regions-zones.html)
+ Amazon ElastiCache (Redis OSS)
+ [Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/mount-fs-diff-account-same-vpc.html)
+ [Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/eks/latest/userguide/network-reqs.html#network-requirements-shared)
+ Elastic Load Balancing
+ [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-register-targets.html#register-targets-shared-subnets)
+ [ Gateway Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/getting-started.html#prerequisites)
+ [Network Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-targets-shared-subnets)
+ [Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-clusters-in-a-vpc.html#emr-vpc-shared-subnet)
+ [AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/shared-vpc.html)
+ AWS Lambda
+ Amazon MQ mit Apache MQ (nicht Rabbit MQ)
+ Amazon MSK
+ AWS Network Manager
+ [AWS Cloud-WAN](https://docs.aws.amazon.com/network-manager/latest/cloudwan/cloudwan-vpc-attachment.html#cloudwan-vpc-attachments-shared-subnets)
+ [Network Access Analyzer](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/how-network-access-analyzer-works.html#analyzer-limitations)
+ [Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/how-reachability-analyzer-works.html#considerations)
+ OpenSearch Amazon-Dienst
+ [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#interface-endpoint-shared-subnets)†
+ [Amazon Relational Database Service (RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html#USER_VPC.Shared_subnets)
+ [Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/rs-shared-subnet-vpc.html)
+ [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-associate-vpcs-different-accounts.html)
+ [ SageMaker Vereinheitlichtes Amazon Studio](https://docs.aws.amazon.com/sagemaker-unified-studio/latest/adminguide/create-domain-sagemaker-unified-studio-quick.html)
+ [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/working-with-transit-gateways.html#transit-gateway-shared-subnets)
+ [AWS Verified Access](https://docs.aws.amazon.com/verified-access/latest/ug/verified-access-endpoints.html#shared-vpc)
+ Amazon VPC
+ [Peering](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-basics.html#vpc-peering-limitations)
+ [Datenverkehrsspiegelung](https://docs.aws.amazon.com/vpc/latest/mirroring/traffic-mirroring-network-limitations.html)
+ [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/create-target-group.html#target-group-shared-subnets)
† Sie können eine Verbindung zu allen AWS Diensten herstellen, die die PrivateLink Verwendung eines VPC-Endpunkts in einer gemeinsam genutzten VPC unterstützen. *Eine Liste der Dienste, die unterstützt werden PrivateLink, finden Sie AWS PrivateLink im Handbuch unter [AWS Services, die sich integrieren lassen](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html).AWS PrivateLink *
In dieser Liste sollen alle Services aufgeführt werden, die das Starten von Ressourcen in freigegebenen VPC-Subnetzen unterstützen. Trotz unserer besten Bemühungen gibt es möglicherweise Services, die das Starten von Ressourcen in freigegebenen VPC-Subnetzen unterstützen und hier nicht aufgeführt sind. Wenn Sie Fragen haben, können Sie gern Feedback zu Dokumentationen senden.