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.
DAX AWS Kontenübergreifender Zugriff
Stellen Sie sich vor, Sie haben einen DynamoDB Accelerator (DAX) -Cluster, der in einem AWS Konto (Konto A) läuft und der DAX Cluster muss von einer Amazon Elastic Compute Cloud (AmazonEC2) -Instance in einem anderen AWS Konto (Konto B) aus zugänglich sein. In diesem Tutorial starten Sie dazu eine EC2 Instance in Konto B mit einer IAM Rolle von Konto B. Anschließend verwenden Sie temporäre Sicherheitsanmeldedaten von der EC2 Instance, um eine IAM Rolle von Konto A anzunehmen. Schließlich verwenden Sie die temporären Sicherheitsanmeldedaten von der Übernahme der IAM Rolle in Konto A, um Anwendungsaufrufe über eine VPC Amazon-Peering-Verbindung zum DAX Cluster in Konto A durchzuführen. Um diese Aufgaben ausführen zu können, benötigen Sie Administratorzugriff für beide AWS Konten.
Wichtig
Es ist nicht möglich, dass ein DAX Cluster von einem anderen Konto aus auf eine DynamoDB-Tabelle zugreift.
Themen
Einrichten von IAM
-
Erstellen Sie eine Textdatei
AssumeDaxRoleTrust.json
mit dem folgenden Inhalt, die es Amazon ermöglicht, in Ihrem Namen EC2 zu arbeiten.{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
-
Erstellen Sie in Konto B eine Rolle, die Amazon beim Starten von Instances verwenden EC2 kann.
aws iam create-role \ --role-name AssumeDaxRole \ --assume-role-policy-document file://AssumeDaxRoleTrust.json
-
Erstellen Sie eine Textdatei
AssumeDaxRolePolicy.json
mit dem folgenden Inhalt, die es Code ermöglicht, der auf der EC2 Instance in Konto B ausgeführt wird, eine IAM Rolle in Konto A anzunehmen.accountA
Ersetzen Sie sie durch die tatsächliche ID von Konto A.{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::
accountA
:role/DaxCrossAccountRole" } ] } -
Fügen Sie diese Richtlinie der gerade erstellten Rolle hinzu.
aws iam put-role-policy \ --role-name AssumeDaxRole \ --policy-name AssumeDaxRolePolicy \ --policy-document file://AssumeDaxRolePolicy.json
-
Erstellen Sie ein Instance-Profil, damit Instances die Rolle verwenden können.
aws iam create-instance-profile \ --instance-profile-name AssumeDaxInstanceProfile
-
Ordnen Sie die Rolle dem Instance-Profil zu.
aws iam add-role-to-instance-profile \ --instance-profile-name AssumeDaxInstanceProfile \ --role-name AssumeDaxRole
-
Erstellen Sie die Textdatei
DaxCrossAccountRoleTrust.json
mit dem folgenden Inhalt, der es Konto B gestattet, eine Rolle von Kontos A zu übernehmen.accountB
Durch die tatsächliche ID von Konto B ersetzen.{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::
accountB
:role/AssumeDaxRole" }, "Action": "sts:AssumeRole" } ] } -
Erstellen Sie in Konto A die Rolle, die Konto B übernehmen kann.
aws iam create-role \ --role-name DaxCrossAccountRole \ --assume-role-policy-document file://DaxCrossAccountRoleTrust.json
-
Erstellen Sie eine Textdatei mit dem Namen
DaxCrossAccountPolicy.json
, die den Zugriff auf den DAX-Cluster ermöglicht.dax-cluster-arn
Ersetzen Sie es durch den richtigen Amazon-Ressourcennamen (ARN) Ihres DAX Clusters.{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dax:GetItem", "dax:BatchGetItem", "dax:Query", "dax:Scan", "dax:PutItem", "dax:UpdateItem", "dax:DeleteItem", "dax:BatchWriteItem", "dax:ConditionCheckItem" ], "Resource": "
dax-cluster-arn
" } ] } -
Fügen Sie in Konto A die Richtlinie zur Rolle hinzu.
aws iam put-role-policy \ --role-name DaxCrossAccountRole \ --policy-name DaxCrossAccountPolicy \ --policy-document file://DaxCrossAccountPolicy.json
Richten Sie ein VPC
-
Suchen Sie die Subnetzgruppe des DAX-Clusters von Konto A.
cluster-name
Ersetzen Sie ihn durch den Namen des DAX Clusters, auf den Konto B zugreifen muss.aws dax describe-clusters \ --cluster-name
cluster-name
--query 'Clusters[0].SubnetGroup' -
Suchen Sie damit
subnet-group
nach dem ClusterVPC.aws dax describe-subnet-groups \ --subnet-group-name
subnet-group
\ --query 'SubnetGroups[0].VpcId' -
Finden Sie damit
vpc-id
die VPC'sCIDR.aws ec2 describe-vpcs \ --vpc
vpc-id
\ --query 'Vpcs[0].CidrBlock' -
Erstellen Sie aus Konto B ein und VPC verwenden Sie dabei ein anderes, nicht überlappendes Konto CIDR als das, das Sie im vorherigen Schritt gefunden haben. Erstellen Sie dann mindestens ein Subnetz. Sie können entweder den VPCErstellungsassistenten im AWS Management Console oder im verwenden. AWS CLI
-
Fordern Sie von Konto B aus eine Peering-Verbindung zu Konto A an, VPC wie unter Eine VPC Peering-Verbindung erstellen und annehmen beschrieben. Akzeptieren Sie die Verbindung in Konto A.
-
Suchen Sie von Konto B aus nach der Routingtabelle VPC des neuen Benutzers.
vpc-id
Ersetzen Sie es durch die ID des Kontos, das VPC Sie in Konto B erstellt haben.aws ec2 describe-route-tables \ --filters 'Name=vpc-id,Values=
vpc-id
' \ --query 'RouteTables[0].RouteTableId' -
Fügen Sie eine Route hinzu, um Datenverkehr, der für Konto A bestimmt ist, CIDR an die VPC Peering-Verbindung weiterzuleiten. Denken Sie daran, jeden Wert
user input placeholder
durch die richtigen Werte für Ihre Konten zu ersetzen.aws ec2 create-route \ --route-table-id
accountB-route-table-id
\ --destination-cidraccountA-vpc-cidr
\ --vpc-peering-connection-idpeering-connection-id
-
Suchen Sie von Konto A aus nach der Routing-Tabelle des DAX Clusters, indem
vpc-id
Sie die zuvor gefundene Tabelle verwenden.aws ec2 describe-route-tables \ --filters 'Name=vpc-id, Values=
accountA-vpc-id
' \ --query 'RouteTables[0].RouteTableId' -
Fügen Sie von Konto A aus eine Route hinzu, um den für Konto B bestimmten Datenverkehr an die VPC Peering-Verbindung CIDR weiterzuleiten. Ersetzen Sie jeden Wert
user input placeholder
durch die richtigen Werte für Ihre Konten.aws ec2 create-route \ --route-table-id
accountA-route-table-id
\ --destination-cidraccountB-vpc-cidr
\ --vpc-peering-connection-idpeering-connection-id
-
Starten Sie von Konto B aus eine EC2 Instanz in demVPC, das Sie zuvor erstellt haben. Ordnen Sie ihr das
AssumeDaxInstanceProfile
zu. Sie können entweder den Startassistenten im AWS Management Console oder im verwenden AWS CLI. Notieren Sie sich die Sicherheitsgruppe der Instance. -
Suchen Sie in Konto A die Sicherheitsgruppe, die vom DAX-Cluster verwendet wird. Denken Sie daran, es
cluster-name
durch den Namen Ihres DAX Clusters zu ersetzen.aws dax describe-clusters \ --cluster-name
cluster-name
\ --query 'Clusters[0].SecurityGroups[0].SecurityGroupIdentifier' -
Aktualisieren Sie die Sicherheitsgruppe des DAX Clusters, um eingehenden Datenverkehr von der Sicherheitsgruppe der EC2 Instance zuzulassen, die Sie in Konto B erstellt haben. Denken Sie daran, die
user input placeholders
durch die richtigen Werte für Ihre Konten zu ersetzen.aws ec2 authorize-security-group-ingress \ --group-id
accountA-security-group-id
\ --protocol tcp \ --port 8111 \ --source-groupaccountB-security-group-id
\ --group-owneraccountB-id
Zu diesem Zeitpunkt kann eine Anwendung auf der EC2 Instanz von Konto B das Instanzprofil verwenden, um die arn:aws:iam::
Rolle zu übernehmen und den DAX Cluster zu verwenden.accountA-id
:role/DaxCrossAccountRole
Ändern Sie den DAX Client, um kontoübergreifenden Zugriff zu ermöglichen
Anmerkung
AWS Security Token Service (AWS STS) Anmeldeinformationen sind temporäre Anmeldeinformationen. Einige Clients nehmen automatisch Aktualisierungen vor, während andere zusätzliche Logik benötigen, um die Anmeldeinformationen zu aktualisieren. Wir empfehlen Ihnen, die Anleitung der entsprechenden Dokumentation zu befolgen.