Share Kubernetes Gateway (VPC Lattice Service Network) between different AWS accounts¶
AWS Resource Access Manager (AWS RAM) helps you share your resources across AWS Accounts, within your AWS Organization or Organizational Units (OUs). RAM supports 2 types of VPC Lattice resource sharing: VPC Lattice services and service networks.
Let's build an example where Account A (sharer account) shares its service network with Account B (sharee account), and Account B can access all Kubernetes services
(VPC Lattice Target Groups) and Kubernetes HTTPRoutes
(VPC Lattice services) within this sharer account's service network.
Create a VPC Lattice Resources
In Account A, set up a cluster with the Controller and an example application installed. You can follow the Getting Started guide up to the "Single Cluster" section.
Share the VPC Lattice Service Network
Now that we have a VPC Lattice service network and service in Account A , share this service network to Account B.
-
Retrieve the
my-hotel
service network Identifier: -
Share the
my-hotel
service network, using the identifier retrieved in the previous step.- Open the AWS RAM console in Account A and create a resource share.
- Select
VPC Lattice service network
resource sharing type. - Select the
my-hotel
service network identifier retrieved in the previous step. - Associate AWS Managed Permissions.
- Set Account B as principal.
- Review and create the resource share.
-
Open the Account B's AWS RAM console and accept Account A's service network sharing invitation in the "Shared with me" section.
-
Switch back to Account A, retrieve the service network ID.
-
Switch to Account B and verify that
my-hotel
service network resource is available in Account B (referring to theSERVICE_NETWORK_ID
retrived in the previous step). -
Now choose an Amazon VPC in Account B to attach to the
my-hotel
service network.VPC_ID=<your_vpc_id> aws vpc-lattice create-service-network-vpc-association --service-network-identifier $SERVICE_NETWORK_ID --vpc-identifier $VPC_ID
Warning
VPC Lattice is a regional service, therefore the VPC must be in the same AWS Region of the service network you created in Account A.
Test cross-account connectivity
You can verify that the parking
and review
microservices - in Account A - can be consumed from resources in the assocuated VPC in Account B.
-
To simplify, let's create and connect to a Cloud9 environment in the VPC you previously attached to the
my-hotel
service network. -
In Account A, retrieve the VPC Lattice services urls.
``` -
In the Cloud9 instance in Account B, install
curl
in the instance and curlparking
andrates
microservices:
Cleanup
To avoid additional charges, remove the demo infrastructure from your AWS Accounts.
-
Delete the service network Association you created in Account B. In Account A:
VPC_ID=<accountB_vpc_id> SERVICE_NETWORK_ASSOCIATION_IDENTIFIER=$(aws vpc-lattice list-service-network-vpc-associations --vpc-id $VPC_ID --query "items[?serviceNetworkName=="\'my-hotel\'"].id" | jq -r '.[]') aws vpc-lattice delete-service-network-vpc-association --service-network-vpc-association-identifier $SERVICE_NETWORK_ASSOCIATION_IDENTIFIER
Ensure the service network Association is deleted:
-
Delete the service network RAM share resource in AWS RAM Console.
-
Follow the cleanup section of the getting Started guide to delete Cluster and service network Resources in Account A.
-
Delete the Cloud9 Environment in Account B.