내부 범위를 사용하면 내부 IP 주소 블록을 예약하고 해당 주소의 사용 방법을 지정할 수 있습니다. VPC 네트워크 피어링, 공유 VPC, Cloud VPN, Cloud Interconnect와 같은 기능으로 인해 네트워크가 더 복잡해졌을 때 내부 범위를 사용하면 Virtual Private Cloud(VPC) 네트워크 토폴로지를 관리하는 데 도움이 될 수 있습니다.
사양
내부 범위 리소스는 VPC 네트워크 내에서 할당된 내부 IPv4 또는 IPv6 CIDR 블록을 나타냅니다.
내부 범위를 예약할 때 다음을 구성하세요.
범위가 VPC 네트워크의 Google Cloud 리소스에서 사용할 수 있거나 외부 사용을 위해 예약할 수 있는지
VPC 네트워크 피어링이 구성된 경우 범위를 사용할 수 있는 방법
범위가 상위 VPC 네트워크의 서브넷 또는 경로와 겹칠 수 있는지
범위의 주소 블록 또는 중복 동작을 수정할 수 있는지
기본적으로 범위의 VPC 네트워크에 있는 다른 Google Cloud 리소스에서 사용하는 IP 주소가 포함된 내부 범위는 예약할 수 없습니다.
서브넷, 경로 또는 둘 다와의 중복을 사용 설정하면 지정된 리소스 유형의 IP 주소 범위와 겹치는 CIDR 블록으로 내부 범위를 만들 수 있습니다.
리소스를 내부 범위(서브넷의 경우)와 명시적으로 연결하거나 겹침을 허용(경로의 경우)하지 않는 한 기존 내부 범위의 IP 주소를 사용하는 Google Cloud 리소스를 만들 수 없습니다.
내부 범위가 변경 불가능한 경우 범위의 설명만 수정할 수 있습니다. 범위를 변경할 수 있는 경우(기본값), 범위의 CIDR 블록, 중복 동작, 설명을 수정할 수 있습니다.
범위를 만든 후에는 불변성을 변경할 수 없습니다.
예를 들어 겹침이 지정되지 않은 변경 가능한 10.0.0.0/24 내부 범위를 생각해 보세요.
10.0.0.0/25 범위를 사용하는 동일한 VPC 네트워크에서 서브넷을 만들려고 하면 서브넷을 내부 범위와 연결하지 않는 한 서브넷 생성이 실패합니다.
10.0.0.0/25 범위를 사용하는 동일한 VPC 네트워크에서 경로를 만들려고 하면 overlaps 속성을 OVERLAP_ROUTE_RANGE로 설정하여 내부 범위를 업데이트하지 않는 한 경로 생성이 실패합니다.
피어링 유형
내부 범위의 피어링 유형은 VPC 네트워크 피어링과 관련된 범위의 동작을 지정합니다. 피어링 유형은 다음 중 하나일 수 있습니다.
FOR_SELF: 내부 범위를 만든 VPC 네트워크에서만 내부 범위를 사용할 수 있습니다. 이 범위는 연결된 VPC 네트워크 및 해당 VPC 네트워크의 피어에서 액세스할 수 있습니다.
그러나 피어 네트워크의 피어는 이 범위를 사용할 수 없습니다. 기본 설정입니다.
FOR_PEER: 이 내부 범위는 피어 네트워크의 리소스와만 연결될 수 있습니다. 범위의 상위 VPC 네트워크 내에 있는 리소스는 범위와 연결될 수 없지만 피어 네트워크의 리소스는 연결될 수 있습니다.
NOT_SHARED: 범위를 만든 네트워크의 리소스와만 내부 범위를 연결할 수 있으며 범위가 피어와 공유되지 않습니다. 피어링된 네트워크는 상위 VPC 네트워크에 표시되는 방식으로 내부 범위를 사용할 수 없습니다. 두 네트워크 모두에서 피어링 유형이 NOT_SHARED인 경우 피어링된 네트워크에서 동일한 범위를 사용할 수 있습니다.
사용량 유형
내부 범위 리소스의 사용량 유형은 할당된 CIDR 블록을 상위 VPC 네트워크의 다른 Google Cloud 리소스와 연결할 수 있는지 여부를 지정합니다. 내부 범위의 사용량 유형은 다음 중 하나일 수 있습니다.
FOR_VPC: 범위를 상위 VPC 네트워크의 다른 Google Cloud리소스와 연결할 수 있습니다. 기본 설정입니다.
EXTERNAL_TO_VPC: 범위를 상위 VPC 네트워크의 다른Google Cloud 리소스와 연결할 수 없습니다.
FOR_MIGRATION: 이 범위를 사용하여 피어링된 VPC 네트워크 간에 서브넷 범위를 마이그레이션할 수 있습니다.
IPv4 서브넷 범위 이전
CIDR 범위를 한 서브넷에서 다른 서브넷으로 이전하려면 서브넷을 삭제한 후 다시 만들어야 합니다. 일반적으로 서브넷을 삭제하면 CIDR 범위가 해제되며 다른 리소스에서 사용할 수 있습니다. 이전 중에 CIDR 범위를 예약하려면(원래 서브넷이 삭제된 후 새 서브넷이 생성되기 전) FOR_MIGRATION 사용 유형이 있는 IPv4 내부 범위를 예약하면 됩니다.
이전을 위한 내부 범위는 CIDR 범위, 소스 서브넷, 대상 서브넷을 지정합니다.
IPv4 CIDR 범위는 소스 서브넷 범위와 일치하거나 소스 서브넷 범위를 포함해야 합니다.
소스 서브넷과 대상 서브넷은 동일한 프로젝트에 있을 수도 있고 다른 프로젝트에 있을 수도 있습니다.
소스 서브넷은 내부 범위 리소스와 동일한 프로젝트에 있어야 합니다.
내부 범위를 만들 때 대상 서브넷이 존재하지 않아도 됩니다.
소스 서브넷을 삭제하면 CIDR 범위는 대상 서브넷과 일치하는 서브넷에만 할당할 수 있습니다.
서브넷을 마이그레이션한 후 내부 범위를 삭제할 수 있습니다.
사용 유형이 FOR_MIGRATION인 내부 범위는 피어링 유형이 FOR_SELF여야 합니다.
사용 사례
다음 표에서는 다양한 사용 및 피어링 조합이 있는 내부 범위의 사용 사례를 설명합니다. IPv6 내부 범위에는 특정 사용 및 피어링 요구사항이 있으며 여기에 나열된 모든 사용 사례를 지원하지는 않습니다.
목적
사용량 유형
피어링 유형
IP 버전
범위의 VPC 네트워크 내에서만 사용할 범위를 예약합니다.
FOR_VPC
NOT_SHARED
IPv4
피어 VPC 네트워크 전용으로 범위를 예약하여 로컬 VPC 네트워크의 리소스가 이를 사용하지 못하도록 합니다.
FOR_VPC
FOR_PEER
IPv4
범위의 VPC 네트워크 외부에서 사용할 범위를 예약하여 범위의 VPC 네트워크에 있는 리소스가 해당 IP 주소를 사용하지 못하도록 합니다. IPv6 범위의 경우 범위의 IP 주소가 새 IPv6 전용 또는 이중 스택 서브넷에 자동으로 할당되지 않도록 합니다.
EXTERNAL_TO_VPC
FOR_SELF
IPv4 또는 IPv6
온프레미스 전용으로 범위를 예약하여 범위의 VPC 네트워크에 있는 리소스가 해당 IP 주소를 사용하지 못하도록 합니다.
EXTERNAL_TO_VPC
NOT_SHARED
IPv4
한 VPC 네트워크에서 다른 VPC 네트워크로 서브넷을 이전하기 위해 일시적으로 범위를 예약합니다.
FOR_MIGRATION
FOR_SELF
IPv4
IPv4 주소 할당 전략
IPv4 내부 범위를 예약할 때 CIDR 블록을 지정하거나 Google Cloud 가 자동으로 할당하도록 할 수 있습니다. 자동 할당의 경우 접두사 길이와 선택적 대상 CIDR 블록을 지정합니다. Google Cloud는 기존 IP 주소 할당을 고려하고 선택한 크기의 가용 CIDR 블록을 대상 또는 기본 CIDR 블록 내에서 내부 범위에 할당합니다.
자동 할당을 사용하는 경우 Google Cloud 가 사용해 여유 블록을 선택하는 할당 전략을 지정할 수 있습니다.
할당 전략은 자동으로 할당된 IPv4 내부 범위에만 사용할 수 있습니다. 다음 표에는 선택할 수 있는 할당 전략이 설명되어 있습니다.
전략
설명
장단점
RANDOM
무료 CIDR 블록을 무작위로 할당합니다. 이는 기본 전략입니다.
접두사 길이가 동일한 여러 CIDR 블록을 동시에 예약하는 데 가장 빠릅니다.
IP 주소 공간의 단편화를 유발할 수 있습니다.
FIRST_AVAILABLE
숫자가 가장 낮은 시작 IP 주소가 있는 사용 가능한 CIDR 블록을 할당합니다.
가장 예측 가능한 IP 범위 할당. 대상 CIDR 블록 내에서 남은 연속된 사용되지 않은 IP 주소 공간을 최대화합니다.
내부 범위를 동시에 예약할 때 경합이 발생하여 할당 시간이 느려집니다.
RANDOM_FIRST_N_AVAILABLE
숫자 N을 지정합니다.
Google Cloud 는 요청된 접두사 길이의 여유 CIDR 블록 N개를 찾고 시작 IP 주소가 가장 낮은 블록에 우선순위를 둡니다.
이 세트에서 무작위 CIDR 블록을 할당합니다.
연속된 사용되지 않는 IP 주소 공간을 유지하면서 동시 할당 중에 경합을 줄이는 데 가장 적합합니다.
N을 늘리면 동시 할당의 성능을 개선할 수 있습니다. 그러나 이렇게 하면 IP 주소 공간의 단편화가 증가할 수 있습니다.
FIRST_SMALLEST_FITTING
요청된 접두사 길이를 포함할 수 있는 가장 작은 여유 CIDR 블록(가장 긴 접두사 길이)을 찾습니다. 이 세트에서 시작 IP 주소가 가장 낮은 블록을 할당합니다.
IP 주소 단편화를 최소화하는 데 가장 적합합니다.
동시 예약에 대한 경합이 가장 심해 할당 시간이 느려집니다.
예를 들어 대상 블록 10.0.0.0/8에서 /24 CIDR 블록을 예약하려고 한다고 가정해 보겠습니다. 대상 블록 내에서는 10.1.0.0/25, 10.2.0.0/16, 10.3.0.0/23 IP 주소 범위만 사용할 수 있습니다. 다음 목록에는 각 할당 전략에 대해 선택될 수 있는 블록이 설명되어 있습니다.
RANDOM: Google Cloud 사용 가능한 /24 블록(예: 10.2.179.0/24)을 무작위로 결정합니다.
FIRST_AVAILABLE: Google Cloud 사용 가능한 가장 낮은 /24 블록(10.2.0.0/24)을 찾습니다.
RANDOM_FIRST_N_AVAILABLE: N에 3을 지정한다고 가정해 보겠습니다.Google Cloud 는 사용 가능한 가장 낮은 세 개의 /24 블록(10.2.0.0/24, 10.2.1.0/24, 10.2.2.0/24)의 집합을 만듭니다. 이 세트에서Google Cloud 는 10.2.2.0/24와 같은 세 블록 중 하나를 무작위로 선택합니다.
FIRST_SMALLEST_FITTING: Google Cloud 지정된 /24 접두사를 포함할 수 있는 사용 가능한 가장 작은 블록(가장 긴 접두사)을 찾습니다. 사용 가능한 가장 작은 블록은 10.3.0.0/23입니다. Google Cloud는 이 범위 내에서 가장 낮은 블록(10.3.0.0/24)을 할당합니다.
할당량
단일 프로젝트에서 만들 수 있는 내부 범위 리소스의 수에는 한도가 있습니다. 자세한 내용은 VPC 문서의 프로젝트별 할당량을 참조하세요.
[[["이해하기 쉬움","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-05(UTC)"],[],[],null,["# Internal ranges overview\n========================\n\nInternal ranges let you reserve blocks of internal IP addresses and specify\nhow those addresses can be used. You can use internal ranges to help you manage\nVirtual Private Cloud (VPC) network topology as networks grow more complex with\nfeatures like [VPC Network Peering](/vpc/docs/vpc-peering),\n[Shared VPC](/vpc/docs/shared-vpc),\n[Cloud VPN](/network-connectivity/docs/vpn/concepts/overview), and\n[Cloud Interconnect](/network-connectivity/docs/interconnect/concepts/overview).\n\nSpecifications\n--------------\n\n- An internal range resource represents an internal IPv4 or IPv6 CIDR block that is allocated from within a VPC network.\n- When you reserve an internal range, you configure the following:\n - If the range can be used by Google Cloud resources in its VPC network or is reserved for external use.\n - How the range can be used if VPC Network Peering is configured.\n - If the range can overlap with subnets or routes in its parent VPC network.\n - If the range's address block or overlap behavior can be modified.\n- By default, you can't reserve an internal range that contains IP addresses that are used by other Google Cloud resources in the range's VPC network.\n- If you enable overlap with subnets, routes, or both, you can create internal ranges with CIDR blocks that overlap with the IP address range of the specified resource types.\n- You can't create Google Cloud resources that use IP addresses from an existing internal range, unless you explicitly associate the resource with the internal range (for subnets) or allow overlapping (for routes).\n- If an internal range is immutable, you can only modify the range's description. If the range is mutable (the default), you can modify the range's CIDR block, overlap behavior, and description. Immutability can't be changed after the range is created.\n\nFor example, consider a mutable internal range for `10.0.0.0/24` with no overlap\nspecified.\n\nIf you try to create a subnet in the same VPC network that uses\nthe range `10.0.0.0/25`, the subnet creation fails, unless you\n[associate the subnet with the internal range](/vpc/docs/create-use-internal-ranges#create-subnets-with-ranges).\n\nIf you try to create a route in the same VPC network that uses\nthe range `10.0.0.0/25`, the route creation fails, unless you update the\ninternal range by [setting the `overlaps`\nproperty](/vpc/docs/create-use-internal-ranges#update-overlap) to\n`OVERLAP_ROUTE_RANGE`.\n\nPeering types\n-------------\n\nThe peering type of an internal range specifies the range's behavior with\nrespect to VPC Network Peering. The peering type can be one of the\nfollowing:\n\n- `FOR_SELF`: the internal range can only be used in the VPC\n network where it was created. The range is accessible from its associated\n VPC network and peers of that VPC network.\n Peers of peer networks, however, cannot use this range. This is the default\n setting.\n\n- `FOR_PEER`: the internal range can only be associated with resources in peer\n networks. No resource within the range's parent VPC network\n can be associated with the range, but resources in peer networks can.\n\n- `NOT_SHARED`: the internal range can only be associated with resources in\n the network where the range was created, without sharing the range with its\n peers. A peered network can't use the internal range in a way that is\n visible to the parent VPC network. A peered network can use\n the same range if the peering type is `NOT_SHARED` in both networks.\n\nUsage types\n-----------\n\nThe usage type of an internal range resource specifies whether the allocated\nCIDR block can be associated with other Google Cloud resources in its\nparent VPC network. The usage type for an internal range can be\none of the following:\n\n- `FOR_VPC`: the range can be associated with other Google Cloud\n resources in its parent VPC network. This is the default\n setting.\n\n- `EXTERNAL_TO_VPC`: the range cannot be associated with other\n Google Cloud resources in its parent VPC network.\n\n- `FOR_MIGRATION`: the range can be used to [migrate a subnet\n range](#for-migration), including from one peered VPC network\n to another.\n\n### Migrating IPv4 subnet ranges\n\nTo migrate a CIDR range from one subnet to another, you must delete the subnet\nand then recreate it. Normally, when you delete a subnet, its CIDR range is\nreleased and can be used by any other resource. To reserve the CIDR range during\na migration---after the original subnet is deleted but before the new subnet\nis created---you can [reserve an IPv4 internal range that has the `FOR_MIGRATION`\nusage type](/vpc/docs/create-use-internal-ranges#create-migration-range).\n\nAn internal range for migration specifies a CIDR range, a source subnet, and a\ntarget subnet.\n\n- The IPv4 CIDR range must match or contain the source subnet range.\n- The source and target subnets can be in the same project or in different projects.\n- The source subnet must be in the same project as the internal range resource.\n- The target subnet doesn't need to exist at the time that you create the internal range.\n\nWhen you delete the source subnet, the CIDR range can only be assigned to a\nsubnet that matches the target subnet.\n\nAfter you've migrated the subnet, you can delete the internal range.\n\nInternal ranges with usage type `FOR_MIGRATION` must have the peering type\n`FOR_SELF`.\n\nExample use cases\n-----------------\n\nThe following table describes use cases for internal ranges with\ndifferent usage and peering combinations. IPv6 internal ranges have specific\nusage and peering requirements and don't support all of the use cases listed\nhere.\n\nIPv4 address allocation strategies\n----------------------------------\n\nWhen you reserve an IPv4 internal range, you can either specify a CIDR block\nor let Google Cloud allocate one automatically. For automatic allocation,\nyou specify a prefix length and optional target CIDR blocks. Google Cloud\naccounts for existing IP address allocations and allocates the internal range a\nfree CIDR block of the chosen size from within the target or default CIDR\nblocks.\n\nIf you use automatic allocation, you can specify the allocation strategy\nthat Google Cloud uses to select a free block.\nAllocation strategies are only available for automatically allocated IPv4\ninternal ranges. The following table describes the allocation strategies\nthat you can choose from:\n\nFor example, suppose that you want to reserve a `/24` CIDR block from the target\nblock `10.0.0.0/8`. Within the target block, only the following IP address\nranges are available: `10.1.0.0/25`, `10.2.0.0/16`, and `10.3.0.0/23`. The\nfollowing list describes the blocks that might be selected for each allocation\nstrategy:\n\n- `RANDOM`: Google Cloud randomly determines any available `/24` block, such as `10.2.179.0/24`.\n- `FIRST_AVAILABLE`: Google Cloud finds the lowest available `/24` block, which is `10.2.0.0/24`.\n- `RANDOM_FIRST_N_AVAILABLE`: Suppose you specify `3` for N. Google Cloud creates a set of the three lowest available `/24` blocks---`10.2.0.0/24`, `10.2.1.0/24`, and `10.2.2.0/24`. From that set, Google Cloud randomly chooses one of the three blocks, such as `10.2.2.0/24`.\n- `FIRST_SMALLEST_FITTING`: Google Cloud finds the smallest available blocks (highest prefix) that can contain the specified prefix of `/24`. The smallest available block is `10.3.0.0/23`. Google Cloud allocates the lowest block from within that range, which is `10.3.0.0/24`.\n\nQuota\n-----\n\nThere is a limit to how many internal range resources you can create in a single\nproject. For more information, see the per-project\n[quotas](/vpc/docs/quota#internal-ranges-quota) in the VPC documentation.\n\nWhat's next\n-----------\n\n- [Create and use internal ranges](/vpc/docs/create-use-internal-ranges)"]]
