AWS Multicloud Interconnect Failures (AWS to GCP)

Troubleshooting guide for AWS Multicloud Interconnect connections that fail with no visible error. Covers a dual-blocker scenario where Organization SCPs blocking interconnect:* actions and GCP VPC Service Controls both prevented provisioning. Includes CloudTrail analysis and a pre-creation checklist.

AWS Multicloud Interconnect is a feature that allows customers to establish direct connectivity between AWS and other cloud providers. It supports connections with Google Cloud as the first available provider.

This article walks through a case where an interconnect hit repeated failures over 3 days with no visible error message. The interconnect kept going to a "failed" state — 8 times in a row — before the root cause was found.

How It Works — Two Initiation Methods

AWS offers two ways to create a Multicloud Interconnect:AWS-initiated — Create from AWS Console → AWS generates activation key → complete on GCPGCP-initiated — Create from GCP → GCP generates activation key → accept on AWS ConsoleThe documentation presents method 1 as the primary getting-started path. Method 2 is fully supported, but AWS recommends starting from the console for first-time setup.Reference: Getting Started with AWS Interconnect

What Happened

The environment was us-east-1 on the AWS side and us-east4 on Google Cloud. The AWS account was managed by AWS Organizations with Control Tower enabled.The interconnect was initiated using the GCP-initiated method — the transport was created using the gcloud beta CLI, then the activation key was provided to AWS in the console to accept the connection.Every attempt resulted in the interconnect showing "failed" in the AWS Console — no error message. On the GCP side, the transport sat in CREATING state and never moved:$ gcloud beta network-connectivity transports list NAME: gcp-aws-transport REGION: us-east4 REMOTE_PROFILE: aws-us-east-1 BANDWIDTH: BPS_1G STATE: CREATING To rule out a direction-specific issue, the AWS-initiated flow was attempted as well. The GCP side returned this error:gcloud beta network-connectivity transports create gcp-aws-interconnect \ --activation-key="<key>" \ --advertised-routes=<routes> \ --region=us-east4 \ --network=<network> Waiting for operation [...] to complete...failed. ERROR: (gcloud.beta.network-connectivity.transports.create) The AWS side auto-deleted the connection after the failure. Both directions failed. Over 3 days, 8 failed connections were created before the root cause was found.

What Was Found During Investigation

1) IAM Permissions — Not the Issue

The role in use had full admin access (Action: *, Resource: *). IAM was ruled out.

2) CloudTrail Logs

CloudTrail showed AcceptConnectionProposal succeeding and returning "state": "pending". The connection then went to "failed" during backend provisioning — no explicit error or denial in CloudTrail.CloudTrail for the failed attempt:{ "eventSource": "interconnect.amazonaws.com", "eventName": "AcceptConnectionProposal", "responseElements": { "connection": { "type": "Multicloud", "state": "pending", "provider": { "cloudServiceProvider": "gcp" } } } }The API returned "state": "pending" — the call appeared to succeed. But the connection went to "failed" during backend provisioning. No error was logged.Compare with the successful attempt:{ "eventSource": "interconnect.amazonaws.com", "eventName": "CreateConnection", "responseElements": { "connection": { "type": "Multicloud", "state": "requested" } } }The failed attempt used AcceptConnectionProposal (GCP-initiated flow). The successful one used CreateConnection (AWS-initiated flow) after the SCP was fixed.

3) GCP VPC Service Controls — Contributing Factor

VPC Service Controls (VPC-SC) were enabled on the GCP side. VPC-SC creates a security perimeter around GCP resources. For Partner Cross-Cloud Interconnect to work, VPC-SC users must set up ingress and egress rules to allow the networkconnectivity-transportmanager-clh@system.gserviceaccount.com service account through the perimeter. Without these rules, the transport creation will fail.Reference: Partner Cross-Cloud Interconnect for AWS — Set up ingress/egress rules

Root Cause

This was a dual-blocker situation — two issues at once:

BlockerCloudWhat It DidSCP blocking interconnect:*AWSPrevented backend provisioningVPC Service ControlsGCPPrevented transport creation

Why SCPs Were the Blocker

Account was under AWS Organizations with Control TowerOrganization had SCPs restricting which service API calls were allowedinterconnect.amazonaws.com is a separate service from directconnect.amazonaws.comSCPs didn't include interconnect:* in the allowed actionsFull IAM admin (Action: *, Resource: *) does NOT override SCPs — SCPs always win

Why This Was Hard to Diagnose

Console showed no error — just "failed"CloudTrail showed the API call succeeding (returned "pending")SCP denial was happening at the backend provisioning level, not at the API call levelNo SCP violation logs were generatedThe GCP side gave no useful signal — just stuck in CREATINGOnce interconnect:* was added to the SCP allow list and the VPC-SC ingress/egress rules were configured on GCP, the next attempt succeeded. Both had to be fixed for the interconnect to work.

What to Look Out For

SCPs: Ensure your organization SCPs allow interconnect:* actions. This is a separate namespace from directconnect:* — one does not cover the other.VPC Service Controls (GCP): If VPC-SC is enabled, configure ingress/egress rules for the networkconnectivity-transportmanager-clh@system.gserviceaccount.com service account.CloudTrail: A "pending" response does not mean the connection will succeed. SCP denials during provisioning will not surface as errors in CloudTrail.Console shows "failed" with no error? Check SCPs first.GCP transport stuck in "CREATING"? Check VPC Service Controls.First-time setup? Consider using the AWS-initiated flow to simplify troubleshooting.