名前には長期間変わらない識別情報だけを入れ、owner・cost center・lifecycle等の可変情報はtagへ分離する。命名/タグを見た目の統一ではなく、operations・Policy・Network Group dynamic membership・IaC import/driftのcontrol inputとして扱い、機密情報は埋め込まない。
Network Resource Naming & Taggingを理解するための前提
Microsoft Cloud Adoption Frameworkは多くのAzure resource名は作成後に変更できないため、名前には変化しない情報だけを含めるよう推奨している。 resource typeごとにname scope、長さ、利用可能文字、global uniqueness等の制約が異なる。組織命名規則よりAzure resource-specific naming rulesを優先する。
environment / region / resource type / workload / instance等から、運用で本当に必要なcomponentだけを選ぶ。owner名・ticket番号・IP addressなど変化しやすい情報を名前へ固定しない。 tagはowner、cost center、environment、criticality、data classification、lifecycle等のmutable metadataに向く。ただし全resourceで同じtag capabilityやinheritanceを仮定しない。
Azure Policyを使ってrequired tag、allowed value、inherit/append/remediation等をgovernanceへ組み込める。tag schema変更自体もversioned policy changeとして扱う。 AVNM dynamic Network Groupがtagをselectorに使う場合、そのtag変更はnetwork policy対象のjoin/leaveを起こし得る。単なる分類変更として承認しない。
resource nameやtagにpersonal data、credential、secret、confidential informationを入れない。portal/search/log/export等、多くの場所へmetadataが露出する前提で設計する。
Ownership / Control / Data plane boundary
resource nameはstable identifierとして扱い、作成後変更を前提にしない。
tagはowner / cost / lifecycle等、時間とともに変わる情報を保持する。
required/allowed tagやAVNM dynamic membershipに使う値はcontrol inputとしてchange管理する。
portal検索、人間のchange review、automation/importの双方で同じ意味になるschemaにする。
Architecture model
設計判断
| 判断軸 | 推奨する問い | 設計時に固定するもの |
|---|---|---|
| Name components | 何がresource lifetime中に不変か。 | component order、delimiter、abbreviation dictionary、instance numbering。 |
| Region code | locationを名前へ含める価値がresource move/DR時の不整合リスクを上回るか。 | region code standard、global resource例外。 |
| Tag schema | 運用・会計・security・automationで必須のmetadataは何か。 | required tags、allowed values、owner system、defaulting rule。 |
| Control tags | AVNM/Policy等のselectorに使うtagを一般tagと分離するか。 | network-impacting tags、RBAC、change approval、validation。 |
| Legacy resources | 既存命名をrenameできない場合どう扱うか。 | alias/tag補完、new-resource-only enforcement、migration threshold。 |
| Sensitive data | metadataへ入れてはいけない情報をどう防ぐか。 | prohibited patterns、review、secret scanner/documentation。 |
実装・展開の順序
- resource type inventoryを取る。 Azure naming rulesと既存実名を突合し、現実に適用できるcomponent setを決める。
- minimum schemaを定義する。 nameにstable component、tagにmutable componentを分離し、例外を明文化する。
- IaC moduleへ組み込む。 name/tag生成を各teamの文字列手入力に任せず、shared module/helperへ寄せる。
- Policyをauditから開始する。 required tag / allowed valueをまず可視化し、既存legacy resourceへの影響を測る。
- network-impacting tagを保護する。 AVNM dynamic membership等で使うtagはRBAC/change reviewを追加し、canaryでjoin/leaveを検証する。
- enforcementを段階強化する。 new resource → selected subscription → broader scopeの順でaudit/deny/modifyを展開する。
Platform team / Workload team の責任分界
| 領域 | Platform / central team | Workload / application team |
|---|---|---|
| Naming standard | component/delimiter/abbreviationとresource-specific例外を管理。 | shared standardに従いworkload identifierを選択。 |
| Tag schema | required tag/allowed value/Policyを管理。 | owner・criticality等の値を正しく維持。 |
| IaC | shared module/helperでname/tag generationを提供。 | manual overrideを最小化しmoduleを利用。 |
| Control metadata | AVNM selector等network-impacting tagの変更権限を管理。 | 変更時にnetwork impactを確認。 |
| Legacy | migration/exception policyを管理。 | exception ownerと期限を維持。 |
実用的な分離例
| 情報 | Nameに入れる? | Tagに入れる? | 理由 |
|---|---|---|---|
| workload/service identifier | 条件付きで入れる | 入れることも可 | resource lifetime中に安定し、検索価値が高い場合。 |
| environment (prod/dev) | 多くの場合入れる | 入れる | resource separationに有用だが組織規則に合わせる。 |
| region | 必要なresourceのみ | 入れる | regional resourceの判別には有用。global resourceや移行設計では注意。 |
| resource type | 入れることが多い | 通常不要 | 人間が一覧で識別しやすい。Azure constraintsに合わせる。 |
| owner /担当者 | 入れない | 入れる | 人・teamは変更される。 |
| cost center / ticket | 入れない | 入れる | 可変でありresource identityではない。 |
| CIDR / IP address | 原則入れない | 必要なら別inventory | renumberで陳腐化しやすい。 |
Verification / review evidence
設計レビューで残す証拠
- resource type別のAzure naming constraints一覧
- 命名component / abbreviation / delimiter dictionary
- required tag / allowed value / owner schema
- Azure Policy definition / assignment / exemption
- network-impacting tagとAVNM membershipの依存一覧
- legacy exceptionとmigration plan
runtimeで確認すること
- 新規resource名がAzure constraintsと組織schemaの両方に適合すること
- required tagsがIaC/Policy経由で一貫して付与されること
- tag変更が意図しないAVNM group join/leaveを起こさないこと
- portal/Resource Graphでowner/environment/resource roleを検索できること
- legacy resourceがnew enforcementで突然deploy不能にならないこと
- resource name/tagにsecretやconfidential metadataが混入していないこと
az resource list --query "[].{Name:name,Type:type,ResourceGroup:resourceGroup,Tags:tags}" -o jsonGet-AzResource | Select-Object Name, ResourceType, ResourceGroupName, TagsCommon failure modes
| 症状 / anti-pattern | 原因になりやすい設計 | 確認・是正 |
|---|---|---|
| 担当team変更で名前が嘘になる | ownerをimmutable nameへ埋め込んだ。 | ownerをtag/CMDBへ移し、名前はstable identityに限定。 |
| 同じ命名規則が一部resourceで作成失敗 | resource-specific length/character/scope制約を無視。 | Azure naming rulesをresource typeごとにvalidate。 |
| tag変更でVNetが別policyへ入る | AVNM dynamic membership selectorであることを知らず変更。 | network-impacting tagを明示しRBAC/reviewを強化。 |
| Policy enforcementでlegacy deployが大量失敗 | audit期間なしでrequired tagsをdeny。 | compliance inventory→exception→new resource→段階enforce。 |
| metadataに顧客名/secretが残る | 名前/tagを非機密とは限らないmetadata surfaceとして扱っていない。 | prohibited data policyとreviewを導入し、既存metadataをscan。 |