假設您有網路設定，其中包含三項後端服務，每項服務都有一項安全性政策。此外，您也有一份已知的惡意 IP 位址清單。在每個安全性政策中建立 deny 規則時，您可以建立一個地址群組，並將其用於所有三項安全性政策，不必在每個安全性政策中新增 IP 位址清單。這樣一來，每當您建立新的安全性政策時，就能再次使用地址群組來制定新規則。
假設您所屬的機構有許多專案，這些專案會分組到資料夾中，而您有三份 IP 位址清單，每份清單都只需要存取部分資料夾。您可以建立三個機構範圍的地址群組 (每個 IP 位址清單各一個)，然後建立三個階層式安全政策。您可以為每個階層式安全性政策指派allow規則，比對三組地址群組中的一組，然後將階層式安全性政策與允許的 IP 位址群組需要存取的每個資料夾建立關聯。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-04 (世界標準時間)。"],[[["\u003cp\u003eAddress groups contain multiple IP addresses or IP ranges, and can be referenced by multiple resources like Cloud NGFW firewall policies or Google Cloud Armor security policies.\u003c/p\u003e\n"],["\u003cp\u003eUpdates made to an address group are automatically applied to all resources that reference it, ensuring consistency across security policies.\u003c/p\u003e\n"],["\u003cp\u003eEach address group is uniquely identified by a URL containing the container type, container ID, location, and the address group's name, and they can be project or organization scoped.\u003c/p\u003e\n"],["\u003cp\u003eAddress groups have a type (IPv4 or IPv6) and capacity, which must be set upon creation and cannot be changed later, with capacity limits varying by the product using the address group.\u003c/p\u003e\n"],["\u003cp\u003eUsing address groups with security policies simplifies configuration by allowing the same list of IP addresses to be shared across multiple policies, but it requires enrollment in Cloud Armor Enterprise.\u003c/p\u003e\n"]]],[],null,["# Address groups overview\n\nAn *address group* contains multiple IP addresses, IP address ranges in CIDR\nformat, or both. Each address group can be used by multiple resources, such as\nrules in Cloud NGFW firewall policies or rules in\nCloud Armor security policies.\n\nUpdates to an address group are automatically propagated to the resources that\nreference the address group. For example, you can create an address group\ncontaining a set of trusted IP addresses. To change the set of trusted IP\naddresses, you update the address group. Your updates to the address group are\nreflected in each associated resource automatically.\n\nSpecifications\n--------------\n\nAddress group resources have the following characteristics:\n\n- Each address group is uniquely identified by a URL with the following elements:\n - **Container type:** Determines the address group type---`organization` or `project`.\n - **Container ID:** ID of the organization or the project.\n - **Location:** Specifies if the address group is a `global` or regional resource (such as `europe-west`).\n - **Name:** The address group name with the following format:\n - A string 1-63 characters long\n - Includes only alphanumeric characters\n - Must not start with a number\n- You can construct a unique URL identifier for an address group in the\n following format:\n\n \u003ccontainerType\u003e/\u003ccontainerId\u003e/locations/\u003clocation\u003e/addressGroups/\u003caddress-group-name\u003e\n\n For example, a `global` address group `example-address-group` in project\n `myproject`has the following unique 4-tuple identifier: \n\n projects/myproject/locations/global/addressGroups/example-address-group\n\n- Each address group has an associated type that can be either IPv4 or IPv6,\n but not both. The address group type cannot be changed later.\n\n- Each IP address or IP range in an address group is referred to as an *item*.\n The number of items that you can add to an address group depends on the\n address group's capacity. You can define the item capacity during address\n group creation. This capacity cannot be changed later. The maximum capacity\n that you can configure for an address group varies depending on the product\n with which you use the address group.\n\n- You must specify the capacity and type when you create an address group. In\n addition, when you use Cloud Armor, you must set the `purpose`\n field to `CLOUD_ARMOR`.\n\n- When you create an address group with a purpose that is *not*\n `CLOUD_ARMOR`, the address group has a maximum capacity of 1,000 IP\n addresses.\n\nTypes of address groups\n-----------------------\n\nAddress groups are classified based on their scope. The scope identifies the level\nat which the address group is applicable in the\n[resource hierarchy](/resource-manager/docs/cloud-platform-resource-hierarchy).\nAddress groups are categorized into the following types:\n\n- [Project-scoped address groups](#project-scoped-address-group)\n- [Organization-scoped address groups](#organization-scoped-address-group)\n\nAn address group can be either project-scoped or organization-scoped, but not\nboth.\n\n### Project-scoped address groups\n\nUse project-scoped address groups when you want to define your own list of IP\naddresses to be used within a project or a network to block or allow a list of\nchanging IP addresses. For example, if you want to define your own threat\nintelligence list and add it to a rule, create an address group with the\nrequired IP addresses.\nThe container type for project-scoped address groups is always set to `project`. For more information about how to create and modify project-scoped address groups, see [Use project-scoped address groups](/armor/docs/address-groups-using#project-scoped-address-group).\n\n### Organization-scoped address groups\n\n|\n| **Preview**\n|\n|\n| This product or feature is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1).\n|\n| Pre-GA products and features are available \"as is\" and might have limited support.\n|\n| For more information, see the\n| [launch stage descriptions](/products#product-launch-stages).\nUse organization-scoped address groups when you want to define a central list of IP addresses that can be used in high-level rules to provide consistent control for the entire organization and reduce the overhead for individual network and project owners to maintain common lists, such as trusted services and internal IP addresses.\n\n\u003cbr /\u003e\n\nThe container type for organization-scoped address groups is always set to\n`organization`. For more information about how to create and modify\norganization-scoped address groups, see\n[Use organization-scoped address groups](/armor/docs/address-groups-using#organization-scoped-address-group).\n\n\nHow address groups work with security policies\n----------------------------------------------\n\nAddress groups simplify the configuration and maintenance of security policies\nbecause you can share each list of IP addresses across many security policies.\nConsider the following additional specifications when you use address groups\nwith security policies:\n\n- Address groups are only available for globally scoped [backend security policies](/armor/docs/security-policy-overview#backend-policies).\n- Organization-scoped address groups are available for both service-level security policies and hierarchical security policies.\n- The capacity of an address group is added to the total attribute count of the security policy where the address group is used. Make sure that you set the capacity to an appropriate value based on your use case.\n- To use address groups, your project must be enrolled in [Cloud Armor Enterprise](/armor/docs/armor-enterprise-overview). If you downgrade to standard billing, you can't create new address groups or modify existing address groups. You also can't create rules that reference an exsisting address group, and your security policies that reference address groups are frozen. This means that they are still active, but that you can't modify them until you delete all of the rules that reference an address group.\n\nWe recommend that you view the [quotas](/armor/quotas#address-group-quotas)\nand [limits](/armor/quotas#address-group-limits) for address groups.\n\nIn addition to configuring organization-scoped address groups for your backend\nsecurity policies, you can configure organization-scoped address groups for your\nhierarchical security policies. You can't use project-scoped address groups in any\nsecurity policies outside of the project in which they exist, but you can share\norganization-scoped address groups with security policies across your entire\norganization; this makes organization-scoped address groups with security\npolicies especially helpful when you use them with hierarchical security policies. For\nmore information about hierarchical security policies, see the\n[Hierarchical security policies overview](/armor/docs/hierarchical-policies-overview).\n\n### Examples\n\nThe following examples demonstrate how you might use address groups to help\nyou configure security policies:\n\n- Imagine that you have a network configuration in which you have three backend services, each of which has one security policy. In addition, you have a list of IP addresses that you know are malicious. When you create a `deny` rule in each security policy, you can create one address group and use it with all three security policies instead of adding the list of IP addresses to each security policy. Then, whenever you create a new security policy, you can use the address group again to make new rules.\n- Imagine that you have an organization with many projects that are grouped into folders, and you have three lists of IP addresses that each need access to only some of these folders. You can create three organization-scoped address groups, one for each list of IP addresses, and then create three hierarchical security policies. You can give each hierarchical security policy an `allow` rule that matches on one of the three address groups, then associate the hierarchical security policy with each folder that the allowed IP address group needs to access.\n\nWhat's next\n-----------\n\n- [Configure address groups](/armor/docs/address-groups-using)."]]
