GCP Global VPC creates regional awareness between the VPC and Aviatrix gateways allowing you to restrict spoke gateway traffic to transit gateways in the same region as the spoke gateway. Without global VPC, communications between spokes over transit in the same region are routed outside the region.
Regional awareness is achieved by appending regional network tags to virtual machines and adding regional routes to the gateways in the routing table using tags.
From Google Cloud documentation:
“A tag is simply a character string added to a tags field in a resource, such as Compute Engine virtual machine (VM) instances or instance templates. A tag is not a separate resource, so you cannot create it separately. All resources with that string are considered to have that tag. Tags enable you to make firewall rules and routes applicable to specific VM instances.”
Network tags allow you to apply firewall rules and routes to a specific instance or set of instances:
- You make a firewall rule applicable to specific instances by using target tags and source tags.
- You make a route applicable to specific instances by using a tag.
You can assign network tags to new VMs at creation time, or you can edit the set of assigned tags at any time later. You can edit network tags without stopping a VM.
Constraints
- A network tag only applies to the VPC networks that are directly attached to the instance’s network interfaces.
Constraints (SW Version 7.1)
- Spokes using the Global VPC Routing for GCP feature cannot be connected to FireNet transit gateways.
Design
Deployment
East-1:
West-1:
VPC Routing
Before attachment:
After attachment:
Bringing up the extra HA gateways, we have:
Instance Tagging
There are three methods of tagging GCP spoke gateways:
- Tag on Changes – Aviatrix recommends this method. Any time there is a configuration change to the gateway or connections to the gateway, Aviatrix reevaluates the tags in your environment and verifies all gateways are regionally aware of the changes and that the regions can communicate with each other.
- Auto Tag – Aviatrix monitors virtual machines launched in the VPCs and automatically adds tags for newly launched virtual machines in the VPC or removes tags for virtual machines removed from the VPC.
- Manage Manually – You do all the tagging through the GCP console and Aviatrix becomes regionally aware of those tags.
We are going to explore Tag on Changes and Auto Tag.
Tag on Changes
- No Tags are added to a compute engine deployed
- Reapply Tags can be used to apply tags on new resources:
Whenever new subnets are added, the Reapply Tags operation must be performed to sync VPC subnets to update the routing tables and add the routes to the newly deployed regions. This operation applies tags to new or existing virtual machines in the new region that haven’t been tagged.
- Reattaching the gateway:
Auto Tag
After a few minutes AVX Controller commands tagging on the recently deployed compute engine instance:
AlloyDB
Google Cloud Platform (GCP) offers a fully managed database solution called AlloyDB. It has interoperability with the well-liked open-source relational database system PostgreSQL and is built to manage workloads at the enterprise level. By providing managed services like scaling and automated backups, it helps businesses run PostgreSQL-based apps on the cloud and takes advantage of Google’s database infrastructure management experience.
Deployment
AllowDB can be deployed from the Google Console creating a cluster:
AlloyDB is a regional service: pick up your region and your vpc:
AlloyDB uses Private Services Connection:
Once the cluster is deployed we can see the network peering and routes imported and exported:
Networking
Applications connect to an AlloyDB instance using a single, static IP address, even while the instance itself consists of several nodes. There are no IP addresses exposed by the instance to the public internet.
From Google documentation:
“Applications running outside the VPC require an intermediary service to connect to the AlloyDB instance. Solutions include running proxy services on a VM within the instance’s VPC, or using other Google Cloud products to establish a permanent connection between your application and your VPC.”
There are a few possible solutions like discussed before (https://rtrentinsworld.com/2023/04/23/apigee-not-bee/) but not all possible solution does not work well with routes using tagging.
- tagged routes are not exported to the AlloyDB while static route without tags is:
Possible solutions:
- AVX with spoke gateways with global vpc feature disabled
- Proxy VMs
- Load Balancer
- AVX with BGPoLAN peering with Google Cloud Routers deployed in different regions
AVX with BGPoLAN peering with Google Cloud Routers requires the use of Google Network Connectivity Center which has cost associated to it:
https://cloud.google.com/network-connectivity/docs/network-connectivity-center/pricing
Vertex AI
Vertex AI is an old friend of mine. I covered Vertex AI previously:
Vertex AI falls in the same category, cloud network speaking, as AlloyDB and multiple other services. They are deployed on Google Cloud Private VPCs and connected to a customer VPC using Private Services Access:
https://cloud.google.com/vertex-ai/docs/general/vpc-peering
What happens when all gateways in one Region fails?
AVX Controller does not take any re-tagging action in a failure scenario but an enterprise can create a Cloud Function to re-tag resources. AVX Professional Service can help you with that.
References
https://docs.aviatrix.com/documentation/latest/building-your-network/gcp-global-vpc.html
https://cloud.google.com/vpc/docs/add-remove-network-tags
https://cloud.google.com/alloydb/docs/configure-connectivity#about_network_connectivity
https://cloud.google.com/alloydb/docs/connect-external
https://cloud.google.com/network-connectivity/docs/network-connectivity-center/pricing
