starting a demonstration and test of v5 changes to VPC and VPCSC design.
This is a dependency of upcoming work on the Data Mesh blueprint, which treats VPCSC as a critical control. We want to make sure the VPCSC configuration in the foundation is something we recommend rather than asking the blueprint authors to invest time making many exceptions to the current perimeter in their blueprint that will change and become obsolete.
The split between based VPC and restricted VPC is not a recommended patterns in any other archiecture that Google recommends to customers, it is a legacy design from to accommodate VPCSC when there were major limitations of which services were supported.
Enabling a perimeter in enforce mode is not recommend, we will initially implement in dry run mode with guidance of when to cutover to enforced mode.
current design for VPCSC configures a perimeter per environment, which requires an enormous administrative overhead (any shared service needs at least 3 exceptions made to be used from the 3 environments, etc), and does not protect critical resources like the CICD pipeline. In comparison, we will now recommend a unified perimeter that contains all projects, no exceptions should be required for internal service-to-serivce traffic.
Current design for VPCSC also relies on legacy concepts like perimeter bridges in the hub-and-spole pattern, bridges are no longer recommended for any scenario. Ingress/egress policies can accomplish the same, with more precision, and easier to reason about the intended state of allowed services across perimeters.
starting a demonstration and test of v5 changes to VPC and VPCSC design.