AWS account linking is part of the SDDC deployment process. For new customers or those who plan to create only a few SDDCs, the process is straightforward and typically requires little or no involvement with the underlying AWS objects and protocols. Administrators who deploy multiple SDDCs might require a better understanding of the details of this process, along with the AWS roles and permissions involved.
About AWS Account Linking
The VMware Cloud on AWS CloudFormation template (CFT) runs in the AWS US West (Oregon) region. This doesn't affect where the resulting SDDCs are created, since the required permissions are valid in all regions, but the AWS account that runs the CFT must not be restricted by AWS Service Control Policies (SCP) from accessing the Oregon region. Once the CFT is loaded, you can edit it to change the region if you need to. You can run the CFT in any region, but you should keep an internal document noting where it was run. If your organization has no members who can access the Oregon region, you can download the CFT from the link provided when you click OPEN AWS CONSOLE WITH CLOUDFORMATION TEMPLATE or just send that link to an AWS Administrator to run, since linking an AWS account to a VMC organization happens only once.
As part of account linking, and periodically during ongoing SDDC operations, the linked AWS account takes an inventory of the organization's VPCs and subnets in all regions so that it can have an up-to-date list of AWS regions and AZs available to the organization. This operation can fail if the SCP restrictions prevent the account from accessing those regions or VPCs. This sort of failure is acceptable if the restricted regions and VPCs won't be used by VMware Cloud on AWS.
We recommend creating a subnet in every AZ prior to account linking. Any AZ that does not contain a subnet when the account is linked will be unavailable for future use by VMware Cloud on AWS, even if you create a subnet later, until a system-initiated rescan is performed. You can initiate a rescan by running the CFT again, but we don’t recommend this for an organization that is already linked and has SDDCs deployed.
There's more information about account linking in the VMware Cloud Tech Zone designlet VMware Cloud on AWS Connected VPC to Native AWS. For information about how to unlink an account, see VMware Knowledge Base article 83400.
AWS Roles Used by Account Linking
Role Name | Trusted Entities | Used For |
---|---|---|
vmware-sddc-formation-********-*-RemoteRoleService-********* |
347******669 |
VMware Cloud on AWS uses these accounts to query AWS resources such as subnets and VPCs, and for ENI creation and association during SDDC deployment or host additions. |
vmware-sddc-formation-********-***-RemoteRolePayer-********* |
909******262 |
|
vmware-sddc-formation-********-****-***-RemoteRole-************* |
A 12-digit AWS account ID that is unique for each organization. | VMware Cloud on AWS uses this account for ongoing operations such as updating route tables when segments are added or removed or an NSX Edge migration or failover occurs. |
The IAM roles created by the CFT grant AWS AssumeRole privileges to the VMware AWS accounts used by the VMware Cloud on AWS service for a specific AWS Policy. This policy is defined and managed by AWS, and for security reasons, VMware does not have rights to change it. If you modify or delete these roles, the account link is broken, communication with the connected VPC fails, and you can no longer deploy new SDDCs or add new hosts to existing SDDCs linked to that account. Contact VMware support to request remediation.
AWS Roles and Permissions
To run the CloudFormation template that links a VMware Cloud on AWS organization to an AWS VPC, your AWS account must have the permissions shown in AWS Permissions Required to Run the CFT. Account linking sets up AWS AssumeRole
access to the AWS-defined policy AmazonVPCCrossAccountNetworkInterfaceOperations
for the VMware-owned accounts shown in AWS Roles Used by Account Linking, which grants the permissions shown in AWS Permissions Required for Ongoing SDDC Operations.
- AWS Permissions Required to Run the CFT
-
The account that runs this template must have these permissions.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:DescribeRouteTables", "ec2:CreateRoute", "ec2:DeleteRoute", "ec2:ReplaceRoute" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "ec2:DescribeNetworkInterfaces", "ec2:CreateNetworkInterface", "ec2:DeleteNetworkInterface", "ec2:CreateNetworkInterfacePermission", "ec2:ModifyNetworkInterfaceAttribute", "ec2:DescribeNetworkInterfaceAttribute", "ec2:DescribeVpcs", "ec2:DescribeSubnets" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "ec2:AssignPrivateIpAddresses", "ec2:UnassignPrivateIpAddresses" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "cloudformation:CreateStack", "cloudformation:DescribeStacks", "cloudformation:DescribeStackEvents", "cloudformation:DescribeStackResource", "cloudformation:DescribeStackResources", "cloudformation:GetTemplateSummary", "cloudformation:ListStackResources", "cloudformation:GetTemplate", "cloudformation:ListChangeSets", "cloudformation:GetStackPolicy" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "iam:CreateRole", "iam:CreatePolicy", "iam:AttachRolePolicy", "iam:GetRole", "iam:PassRole", "iam:PutRolePolicy", "lambda:CreateFunction", "lambda:InvokeFunction", "lambda:GetFunctionConfiguration", "lambda:GetFunction", "cloudformation:DescribeStackResource", "cloudformation:DescribeStackResources" ], "Resource": "*" } ] }
- AWS Permissions Required for Ongoing SDDC Operations
-
After account linking completes, only these permissions (granted by the IAM roles) are needed.Important:To see the associated Policy Permissions document, log into the AWS Console and open
You must not change any of these roles and permissions. Doing so will render your SDDC inoperable.
https://console.aws.amazon.com/iam/home?region=us-east-1#/policies/arn:aws:iam::aws:policy/AmazonVPCCrossAccountNetworkInterfaceOperations$jsonEditor
. Here's the summary description of that policy.{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:DescribeRouteTables", "ec2:CreateRoute", "ec2:DeleteRoute", "ec2:ReplaceRoute" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "ec2:DescribeNetworkInterfaces", "ec2:CreateNetworkInterface", "ec2:DeleteNetworkInterface", "ec2:CreateNetworkInterfacePermission", "ec2:DeleteNetworkInterfacePermission", "ec2:DescribeNetworkInterfacePermissions", "ec2:ModifyNetworkInterfaceAttribute", "ec2:DescribeNetworkInterfaceAttribute", "ec2:DescribeAvailabilityZones", "ec2:DescribeVpcs", "ec2:DescribeSubnets" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "ec2:AssignPrivateIpAddresses", "ec2:UnassignPrivateIpAddresses" ], "Resource": [ "*" ] } ] }
Because VMware Cloud on AWS requires these AWS rights for SDDC deployment and ongoing operations such as routing table updates and host replacements, you need to ensure that the roles can use the AWS AssumeRole
function as needed and won't be blocked by AWS features such as Control Tower Guardrails or Service Control Policies (SCP). The IAM roles require only a minimal set of permissions, all managed by AWS in the policy AmazonVPCCrossAccountNetworkInterfaceOperations
. This is the only access granted by the IAM roles created by the template.
The CFT also creates a lambda function and grants it access to Describe VPCs, Describe Route Tables and Describe Subnets in the account, as well as the rights to create logs. This lambda function is used only once, when the CFT is run. Its purpose is to register the completion of the cloud formation stack with VMware and provide the ARNs of the roles created. After the account has been registered and appears in the Choose an AWS account drop-down control during the Deploy an SDDC from the VMware Cloud Console workflow, you can delete the Lambda function NotifyOfStatus
and the vmware-sddc-formation-******-*****-BasicLambdaRole-******
role if you need to.