Organization policies for Compute Engine Stay organized with collections Save and categorize content based on your preferences.

The Organization Policy Service provides centralized, programmatic control over your organization's resources. You can use organization policies to enforce constraints on how Compute Engine resources, such as virtual machine (VM) instances, disks, and networks, are configured. For more information about Organization Policy, see Introduction to the Organization Policy Service.

You can set policies at the organization, folder, or project level. Descendant resources inherit policies, which lets you enforce broad controls at the organization level and apply more specific constraints at the folder or project level.

This document provides an overview of how you can use Organization Policy to manage your Compute Engine resources.

Use cases

You can use organization policies to enforce governance across your Compute Engine resources. Common goals include:

• Cost management: Control spending by restricting which VM machine types or Persistent Disk sizes can be created in a given project.
• Security posture: Enforce security best practices, such as requiring OS Login for all VM instance access, or disabling the interactive serial console.
• Compliance: Meet regulatory requirements such as requiring VMs in a specific project to run on sole-tenant nodes to support hardware isolation.

Constraint types

When you use the Organization Policy, you can apply the following types of constraints:

• Managed constraints: Google-provided, predefined constraints that are built on a modern platform, identifiable by the compute.managed.* prefix. They support safe rollout tooling, such as dry run and Policy Simulator, and tag-conditioned statements, which let you grant granular exemptions to specific resources.
• Managed constraints (legacy): Google-provided, predefined constraints identifiable by the compute.* prefix. While functional, they generally lack support for modern safe rollout tools, such as Dry Run and Policy Simulator, and don't support tag-conditioned statements. When an equivalent alternative is available, we recommend migrating to managed constraints to take advantage of enhanced governance and safe rollout capabilities.
• Custom constraints: Constraints that you create for your specific needs using the Common Expression Language (CEL). Custom constraints let you enforce policies on specific fields that are not addressed by managed constraints. Like managed constraints, custom constraints support tag-conditioned statements and safe rollout tools, such as Dry Run and Policy Simulator. To learn more about creating and managing custom constraints for Compute Engine, see Custom constraints.

A limit of 20 constraints per Compute Engine resource applies to the total number of managed constraints and custom constraints combined. Legacy managed constraints don't count toward this limit.

Compute Engine constraints

The following sections list the Compute Engine constraints that Organization Policy supports.

Managed constraints

Managed constraints for Compute Engine simplify governance for common security scenarios and integrate with safe rollout tools, such as dry-run and Policy Simulator, which let you test their impact before enforcement. For a list of managed constraints for Compute Engine, see Managed constraints.

Managed constraints (legacy)

These constraints are from the previous generation and don't support safe rollout tools. We recommend migrating to managed constraints when an equivalent is available.

Legacy constraints

What's next

• To learn how to apply these constraints, see Creating and managing organization policies in the Resource Manager documentation.
• To test the effect of a new policy before enforcing it, see Test organization policy changes with Policy Simulator.
• To learn about creating custom constraints, see Custom constraints.
• To see a complete list of all constraints available across Google Cloud, see Organization policy constraints.