Secure Spoke VPC or VNet

By securing the spoke VPCs, you create a more robust and resilient network that can respond to security threats. Securing spoke VPCs helps protect sensitive data that may be transmitted between the service VPC and the spoke VPCs; this can help reduce the overall attack surface as well as proper security measures in spoke VPCs support network segmentation, which is a key strategy in limiting the spread of potential security incidents.

We strongly recommend you secure you spoke VPCs for AWS and GCP accounts before you create or add a gateway.

Below is an example of how spoke VPCs interact with your network:

Azure Combined Hub - Multisubscriptions

Prerequisites and Limitations

Be sure the following is completed prior to securing your spoke VPC or VNet:

AWS

  • AWS does not support adding or removing availability zones from a service VPC after its creation for environments deployed in edge or centralized mode. If you need to modify the availabilty zones after creating a service VPC, you must create a new VPC with the correct zones included.

  • AWS accounts with CloudWAN must have the following configured through the AWS Network Manager before you secure a spoke VPC or add a gateway:

    • For AWS accounts that are already onboarded, manually modify the permissions list in the AWS dashboard to include networkmanager:* to the MCDControllerRole IAM policy. See AWS' "Adding and removing IAM Identity permission" documentation for more information.

    • You must attach an egress/east-west gateway to the service VPC.

    • You must have at least one global network configured.

    • You must have at least one core network already created, does not have to contain segments already.

Azure

  • VNet pairing is supported across accounts within the same CSP type. You can add spoke VPC/VNets within an account and across accounts. In Azure, for spoke VPCs peering across subscriptions, the CSP accounts should be onboarded using the same app registrations, and subscriptions should be within the same Active Directory.

  • Azure environments require a route table attached prior to securing spoke VPC/VNet. See the "Associate a route table to a subnet" chapter in the Azure user guide for more.

  • Azure does not support adding or removing availability zones from a service VPC after its creation for environments deployed in edge or centralized mode. If you need to modify the availabilty zones after creating a service VPC, you must create a new VPC with the correct zones included.

GCP

  • GCP does not support adding or removing availability zones from a service VPC after its creation for environments deployed in edge or centralized mode; this also applies to Azure, GCP, and OCI for environments deployed in edge mode. If you need to modify the availabilty zones after creating a service VPC, you must create a new VPC with the correct zones included.

OCI

  • OCI does not support adding or removing availability zones from a service VPC after its creation for environments deployed in edge or centralized mode. If you need to modify the availabilty zones after creating a service VPC, you must create a new VPC with the correct zones included.