Azureで覚えた言葉に似たGoogle Cloudの言葉を見つけると、同じものとして置き換えたくなります。しかし、名前が近くても、管理する範囲、権限が継承される範囲、費用を負担する単位、地域の扱いは同じとは限りません。

私はMicrosoft資格群とGoogle Cloud認定5件を取得しました。本稿で扱う本人の一次事実は、この取得・学習経験だけです。AzureからGoogle Cloudへの本番移行、顧客環境の構築・運用、組織のIAMや請求設計を行った実務経験としては扱いません。

この記事はcloud移行手順や推奨architectureではありません。資格学習で用語を1対1対応として暗記せず、公式ページへ戻って確認するための概念整理です。

先に6つの問いへ置き換える

確認する問いAzureで確認する語Google Cloudで確認する語1対1対応にしない理由
方針や権限をどこへ置くかmanagement group、subscription、resource group、resourceorganization、folder、project、service resource階層名より、親子関係と継承範囲を確認する必要がある
workloadをどの単位で分けるかsubscription、resource groupprojectsubscriptionは管理・請求・scaleの単位でもあり、projectと責務が完全には一致しない
誰を認証し、どのresourceへ権限を付けるかMicrosoft Entra ID、Azure RBAC scopeprincipal、Google Cloud IAM、resource hierarchyidentity基盤とresource上の権限scopeを分けて読む必要がある
誰が費用を負担するかsubscriptionとAzureのbilling scopeprojectにlinkしたCloud Billing accountCloud Billing accountはprojectのIAM上の親ではない
networkはどの地域範囲を持つかVirtual NetworkとsubnetVPC networkとsubnetAzure VNetはsingle-region、Google Cloud VPC networkはglobalでsubnetはregional
障害範囲と冗長化責任は何かAzure region、Availability Zone、service別supportGoogle Cloud region、zone、resourceのlocation typezoneという語だけではserviceの配置・replication・failover責任を決められない

この表はservice対応表ではありません。右から左、左から右へ置き換えるためではなく、公式情報で追加確認する問いを選ぶために使います。

1. resource hierarchyは「似た箱」ではなく継承範囲で読む

Azure Resource Managerは、management group、subscription、resource group、resourceという4段階のmanagement scopeを示しています。policyやaccess controlをどのscopeへ置くかによって、下位へ適用される範囲が変わります。

Google Cloudのresource整理は、organizationをroot、folderを任意のgrouping、projectをservice resourceを含む基本のorganizing entityとして説明しています。上位へ設定したaccess policyは下位へ適用されます。

どちらも階層を持ちますが、「management groupはfolderと同じ」のようには覚えません。資格問題や設計資料では、次を確認します。

  • resourceの直接の親は何か
  • policyとroleはどのscopeへ付くか
  • 下位へ何が継承され、何が継承されないか
  • environmentやteamの分離をどの単位で行うか

2. Azure subscriptionとGoogle Cloud projectは完全な対応語ではない

Azure subscriptionの公式guidanceは、subscriptionをmanagement、billing、scaleの単位と説明しています。quota、cost、governance、security、identity controlの境界にもなります。

Google Cloudのprojectはservice resourceを含む基本のorganizing entityです。一方、費用を支払う主体はprojectそのものだけで完結せず、Cloud Billing accountとのlinkで決まります。

したがって、学習時は「subscriptionに当たるGoogle Cloudの語は何か」ではなく、管理単位、policy境界、quota、resource lifecycle、請求のうち、どの責務を比較しているかを先に分けます。

3. identityとresource permissionを一つの箱にしない

Microsoft Entra IDは、user、device、application、resourceに対するauthentication、policy enforcement、protectionを提供するcloud-based identity and access management serviceです。Azure resourceへのrole assignmentでは、さらにmanagement group、subscription、resource group、resourceなどのscopeを選びます。

Google Cloud IAMでは、principalへroleを付与し、organization、folder、project、個別service resourceのhierarchy上でpolicy inheritanceを確認します。

ここでも、「Entra tenantとGoogle Cloud projectが同じ」とは扱いません。次の三つを分離します。

  1. identityをどこで管理するか
  2. 誰または何をprincipalとして認証するか
  3. どのresource scopeへ、どのroleを付けるか

4. 請求上のlinkとIAM上の親子関係を分ける

Azureのbilling accountとscopeは、Microsoft Online Services Program、Enterprise Agreement、Microsoft Customer Agreement、Microsoft Partner Agreementで構造が異なります。Azure subscriptionはbillingの単位を含みますが、契約形態によって上位のbilling accountやscopeも変わります。資格学習では、subscriptionが管理・請求・scaleの複数責務を持つことを確認します。

Google Cloud Billingの公式overviewでは、projectをCloud Billing accountへlinkすると、そのprojectの利用費がlinked accountへ請求されます。ただし、Cloud Billing accountはIAM上のprojectの親ではなく、projectはlinked billing accountからpermissionを継承しません。

この違いは、組織階層の図と請求関係の図を同じ図として読まないために重要です。「resourceのownerは誰か」と「費用を支払うaccountはどれか」を別々に確認します。

5. Azure VNetとGoogle Cloud VPCは地域scopeが違う

Azure Virtual Networkのreliability guidanceは、VNetをsingle-region serviceと説明しています。VNetとsubnetは配置したregion内のavailability zoneをまたぎますが、region全体の障害へ備えるには別regionのVNetと接続・traffic routingを設計する必要があります。

Google Cloud VPC networkは、network、そのroute、firewall ruleをglobal resource、subnetをregional resourceと説明しています。一つのVPC networkに複数regionのsubnetを置けます。

両方にvirtual networkとsubnetがあっても、network resource自体のscopeは同じではありません。資格学習では、network、subnet、route、firewall rule、workloadの各resourceがglobal、regional、zonalのどれかを個別に確認します。

6. regionとzoneはservice別の配置・責任まで確認する

Azure Availability Zonesは、region内にある、一つ以上の物理的に分離されたdatacenterの論理groupです。Azure serviceによってzonal、zone-redundant、nonzonalのsupportや必要な設定が異なります。

Google Cloudのregions and zonesは、regionをzoneの集合、zoneをregion内のdeployment areaと説明しています。Compute Engineでもzonal resourceとregional resourceがあり、利用できる範囲や冗長化方法が異なります。

どちらも複数zoneを可用性へ使えますが、「zoneがあるから自動的に冗長」とは判断しません。対象serviceごとに、配置scope、replication、failover、data residency、利用者が設定する項目を公式のreliability pageで確認します。

資格学習へ戻すチェックリスト

次の一歩は、service名ではなく、管理範囲、権限、請求、network、可用性を確認する問いへ分けることです。

新しい用語を見つけたら、service名の対応表を作る前に次を確認します。

  1. resourceはどのhierarchyに属し、直接の親は何か
  2. policyとroleはどのscopeへ付き、どこまで継承されるか
  3. management、quota、resource lifecycle、billingの単位は同じか
  4. network、subnet、route、firewall ruleの地域scopeは何か
  5. resourceはglobal、regional、zonalのどれか
  6. 冗長化とfailoverはproviderが自動で行うのか、利用者の設定が必要か

資格や認定が示す範囲と実務経験を分ける基準は、資格・認定が証明すること・しないことで整理しています。Azure側で次の資格を役割から選ぶ場合は、AZ-900の次は何を取るかを参照してください。

この記事にはaffiliate linkがありません。特定教材、試験申込み、cloud契約への誘導も行いません。