Professional Cloud Network Engineer
VPC firewall rules and Cloud Next Generation Firewall (Cloud NGFW) policies use fundamentally different architectures. VPC firewall rules apply to a single VPC network and are edited individually, which becomes inefficient as the rule set grows. They rely on network tags for targeting, but network tags lack robust Identity and Access Management (IAM) controls. In contrast, Cloud NGFW supports global and regional network firewall policies that can be defined once and applied across multiple VPC networks and regions. This enables centralized management with IAM-governed secure tags for granular micro-segmentation. Global network firewall policies support batch editing, advanced features like fully qualified domain name (FQDN) objects, geolocation objects, threat detection, and intrusion prevention, and flexible data residency. VPC firewall rules can only be applied globally and do not support these advanced features. Additionally, global network firewall policy rules require unique priority numbers within each policy, while VPC firewall rules allow duplicate priorities.
Google Cloud provides a VPC firewall rules migration tool that automatically converts existing VPC firewall rules into a global network firewall policy. The tool is a command-line utility accessed through the Google Cloud CLI. It creates a global network firewall policy, converts the existing VPC firewall rules into firewall policy rules, and adds the new rules to the policy. When two or more VPC firewall rules have the same priority, the migration tool automatically updates the rule priorities to avoid overlap. It gives deny rules higher priority than allow rules while preserving the relative sequence of the original VPC firewall rules. For example, if four VPC firewall rules have a priority of 1000 and a fifth rule has a priority of 2000, the tool assigns unique priorities of 1000, 1001, 1002, and 1003 to the first four rules in sequence, then assigns priority 1004 to the fifth rule. This automatic adjustment ensures the original rule evaluation order is maintained even when duplicate priorities existed in the source VPC firewall rules.
A successful migration strategy involves running both VPC firewall rules and Cloud NGFW policies in parallel before decommissioning the legacy rules. This coexistence period allows network administrators to validate that the NGFW policy set provides equivalent or improved security coverage without creating gaps or overly permissive rules. During this phase, traffic flow analysis should be performed to compare how packets are evaluated under both rule sets and ensure that the same traffic is allowed or denied consistently. The migration should begin by using the migration tool to create the target network firewall policy, then associating that policy with the VPC networks while the existing VPC firewall rules remain active. Administrators can then monitor traffic logs from both systems to identify any discrepancies in enforcement. Only after validation confirms that the NGFW policies correctly handle all expected traffic patterns should the VPC firewall rules be decommissioned.
Validation procedures should include reviewing Firewall Insights to identify shadowed rules, unused allow rules, and overly permissive IP address ranges in both the legacy VPC firewall rules and the new NGFW policies. The comparison should verify that the NGFW policy set maintains the same security boundaries as the original rules while taking advantage of advanced features like secure tags for IAM-governed access control. Traffic flow analysis during the parallel operation period should examine whether the NGFW policies correctly match the same connections that the VPC firewall rules would match, paying particular attention to priority ordering and the evaluation of deny versus allow actions. Security posture comparison should confirm that moving to IAM-governed secure tags does not weaken access controls and that any new capabilities enabled by the migration (such as FQDN-based filtering or threat detection) are properly configured.
VPC firewall rules and Cloud NGFW policies differ in how they are structured and applied. VPC firewall rules are standalone rules bound directly to a single VPC network. Cloud NGFW policies function as centralized policy container resources that can be associated with multiple VPC networks across regions. An administrator creates a global network firewall policy once and associates it with one or more VPC networks in the same project. Each VPC network can be associated with only one global network firewall policy at a time. This container model enables batch editing, policy cloning, and seamless policy replacement without leaving the network unprotected. While legacy VPC firewall rule quotas scale strictly on rule counts, Cloud NGFW policy quotas evaluate attribute counts based on total rule complexity.
Both architectures rely on stateful direction matching, but they enforce different priority rules and match actions. VPC firewall rules permit duplicate priority numbers across multiple rules, whereas Cloud NGFW policies require every rule within a policy to have a strictly unique priority number. When migrating rules with identical priority values, migration utilities automatically assign sequential unique priority numbers, prioritizing deny actions over allow actions to preserve security order. In addition to standard allow and deny actions, Cloud NGFW rules introduce actions such as goto_next to pass traffic down the evaluation hierarchy and proceed to L7 inspection to route matching traffic to security endpoints.
Identity-based filtering differs significantly between legacy network tags and the secure tags used by Cloud NGFW. Legacy VPC firewall rules rely on network tags that lack IAM controls, which limits their effectiveness for strict micro-segmentation. Cloud NGFW policies use IAM-governed secure tags, which administrators can attach to specific virtual machine (VM) network interfaces to enforce least-privilege access across user groups and workloads. While both firewall models support service accounts as target destinations to identify backend workloads, Cloud NGFW policies do not support service accounts as source filters for ingress rules.
Cloud NGFW policies extend traditional Layer 4 filtering to application-aware inspection, geolocation matching, and threat detection. Instead of evaluating only static IP addresses and port numbers, Cloud NGFW policy rules can filter outbound connections using fully qualified domain name (FQDN) objects and address groups. For deep packet inspection, a rule configured with the apply_security_profile_group action forwards matched traffic to a zonal firewall endpoint. This endpoint applies security profile groups containing threat prevention security profiles to execute intrusion detection and prevention, URL filtering, and optional Transport Layer Security (TLS) inspection.
The migration tool converts existing VPC firewall rules into a new global network firewall policy. It preserves the original intent of the rules by translating their components, such as IP ranges, protocols, and ports, into equivalent NGFW policy rules. A key function of the tool is handling rule priorities: it assigns unique priority numbers to all migrated rules, even converting grouped rules with the same original priority into a sequence (e.g., four rules with priority 1000 become 1000, 1001, 1002, 1003) to maintain their relative order. You must review these auto-generated priorities after migration to ensure they align with your original network configuration before attaching the new policy.
If your VPC firewall rules use network tags or target service accounts as dependencies, the migration tool can leverage IAM-governed Tags as a replacement. You must first create Tags that correspond to your existing network tags and service accounts, then bind these Tags to your VM instances. The migration process maps the old dependencies to the new Tags, allowing the NGFW policy to enforce access controls based on the same logical groupings. This step is crucial for maintaining security posture continuity, as it ensures the policy applies to the correct workloads without relying on the legacy tagging system.
The migration tool only generates the new global network firewall policy; it does not delete old VPC firewall rules or attach the new policy to your network. You must manually associate the generated policy with the required VPC network. After attachment, you enter a transition period where both the NGFW policy and the original VPC firewall rules can be active on the same network. During this period, traffic is evaluated according to a defined order: NGFW policies are evaluated first, and only if they allow the traffic does evaluation proceed to VPC firewall rules. You should monitor the new policy's performance and, once confirmed it is working as intended, disable the old VPC firewall rules to avoid complexity and potential conflicts, though keeping both active is technically supported by the evaluation order.
VPC firewall rules allow multiple rules to share the same priority number, while Cloud NGFW policies require every rule within a policy to have a strictly unique priority number. The migration tool automatically resolves duplicate priorities by assigning sequential numbers, giving deny rules higher priority than allow rules.
Run both systems in parallel during a transition period. Use Firewall Insights to identify shadowed rules and overly permissive ranges, and compare traffic logs to confirm that both systems allow and deny the same traffic. Only decommission the VPC firewall rules after validation confirms equivalent or improved security coverage.
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts