🏗️ Resource Hierarchy

Level: Foundation Solves: Thiết kế và quản lý resource organization theo chuẩn enterprise với proper inheritance và governance

🎯 Mục tiêu (Outcomes)

Sau khi áp dụng kiến thức trong trang này, bạn sẽ có khả năng:

Thiết kế GCP Organization Structure với proper folder hierarchy
Triển khai Organization Policies cho governance và compliance
Xây dựng Project Naming Convention consistent và scalable
Cấu hình Labels và Tags cho cost allocation và IAM conditions
Hiểu Policy Inheritance và override mechanisms
So sánh với AWS Organizations và OUs

✅ Khi nào dùng

Pattern	Use Case	Lý do
Environment folders	Separate prod/non-prod	Policy isolation, blast radius
Team sub-folders	Multi-team organization	Ownership, self-service
Shared services folder	Central logging, monitoring	Cross-cutting concerns
Sandbox folder	Developer experimentation	Relaxed policies, isolation
Organization Policies	Compliance requirements	Enforce guardrails

❌ Khi nào KHÔNG dùng

Pattern	Vấn đề	Thay thế
Flat project structure	Khó manage scale	Folder hierarchy
Deep nesting (> 5 levels)	Complexity, policy conflicts	Flatter structure
One project per service	Project quota exhaustion	Consolidate related services
Same project cho all envs	Blast radius, access control	Separate proj per env

⚠️ Cảnh báo từ Raizo

"Một startup bắt đầu với 1 project cho tất cả. 2 năm sau với 50 microservices, billing là nightmare - không biết service nào tốn bao nhiêu. Migration sang multi-project mất 6 tháng. Plan hierarchy từ đầu."

Core Concepts

GCP Resource Hierarchy

┌─────────────────────────────────────────────────────────────────┐
│                  GCP RESOURCE HIERARCHY                         │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│                    ┌─────────────────┐                          │
│                    │  Organization   │  ← Cloud Identity/       │
│                    │  (example.com)  │    Workspace domain      │
│                    └────────┬────────┘                          │
│                             │                                   │
│         ┌───────────────────┼───────────────────┐               │
│         │                   │                   │               │
│         ▼                   ▼                   ▼               │
│  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐         │
│  │   Folder    │    │   Folder    │    │   Folder    │         │
│  │ Production  │    │   Staging   │    │    Dev      │         │
│  └──────┬──────┘    └──────┬──────┘    └──────┬──────┘         │
│         │                  │                  │                 │
│    ┌────┴────┐        ┌────┴────┐        ┌────┴────┐           │
│    │         │        │         │        │         │           │
│    ▼         ▼        ▼         ▼        ▼         ▼           │
│ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐         │
│ │Proj A│ │Proj B│ │Proj C│ │Proj D│ │Proj E│ │Proj F│         │
│ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘         │
│                                                                 │
│  KEY INSIGHT: IAM policies và Organization Policies             │
│  inherit DOWN the hierarchy                                     │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Hierarchy Components

Component	Purpose	Limit
Organization	Root node, tied to Cloud Identity domain	1 per domain
Folder	Grouping mechanism for projects	10 levels deep
Project	Container for resources, billing boundary	Unlimited
Resource	Actual GCP services (VMs, buckets, etc.)	Per-project quotas

Enterprise Folder Structure

Recommended Pattern

Organization (example.com)
├── 📁 Bootstrap
│   └── 📦 prj-bootstrap (Terraform state, CI/CD)
├── 📁 Common
│   ├── 📦 prj-logging (Centralized logs)
│   ├── 📦 prj-monitoring (Centralized monitoring)
│   └── 📦 prj-security (Security tools)
├── 📁 Network
│   ├── 📦 prj-network-hub (Shared VPC host)
│   └── 📦 prj-network-dns (Cloud DNS)
├── 📁 Production
│   ├── 📁 Team-A
│   │   ├── 📦 prj-prod-team-a-app1
│   │   └── 📦 prj-prod-team-a-app2
│   └── 📁 Team-B
│       └── 📦 prj-prod-team-b-app1
├── 📁 Non-Production
│   ├── 📁 Staging
│   │   └── 📦 prj-stg-*
│   └── 📁 Development
│       └── 📦 prj-dev-*
└── 📁 Sandbox
    └── 📦 prj-sandbox-* (Experimentation)

Folder Design Principles

💡 Design Guidelines

Environment-first: Top-level folders by environment (prod/non-prod)
Team ownership: Sub-folders by team or business unit
Shared services: Dedicated folders for cross-cutting concerns
Sandbox isolation: Separate folder for experimentation

Organization Policies

Policy Inheritance

Essential Organization Policies

yaml

# Restrict resource locations
constraints/gcp.resourceLocations:
  allowedValues:
    - asia-southeast1
    - asia-southeast2
    - us-central1

# Disable service account key creation
constraints/iam.disableServiceAccountKeyCreation:
  enforced: true

# Require OS Login for VMs
constraints/compute.requireOsLogin:
  enforced: true

# Restrict public IP on VMs
constraints/compute.vmExternalIpAccess:
  deniedValues:
    - all

# Restrict VPC peering
constraints/compute.restrictVpcPeering:
  allowedValues:
    - under:organizations/123456789

Policy Hierarchy Example

┌─────────────────────────────────────────────────────────────────┐
│              ORGANIZATION POLICY INHERITANCE                    │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  Organization Level:                                            │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │ • Disable SA key creation: ENFORCED                     │    │
│  │ • Require OS Login: ENFORCED                            │    │
│  │ • Resource locations: asia-*, us-*                      │    │
│  └─────────────────────────────────────────────────────────┘    │
│                          │                                      │
│                          ▼                                      │
│  Production Folder:                                             │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │ • Inherits all org policies                             │    │
│  │ • + Restrict external IPs: ENFORCED                     │    │
│  │ • + Resource locations: asia-southeast1 ONLY            │    │
│  └─────────────────────────────────────────────────────────┘    │
│                          │                                      │
│                          ▼                                      │
│  Sandbox Folder:                                                │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │ • Inherits org policies                                 │    │
│  │ • EXCEPTION: Allow external IPs (for testing)           │    │
│  │ • EXCEPTION: Allow SA keys (for local dev)              │    │
│  └─────────────────────────────────────────────────────────┘    │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Project Naming Convention

Recommended Format

{org-prefix}-{env}-{team}-{app}-{random}

Examples:
- acme-prod-platform-api-a1b2
- acme-dev-data-pipeline-c3d4
- acme-stg-mobile-backend-e5f6

Naming Rules

Component	Format	Example
org-prefix	2-4 chars, lowercase	`acme`
env	prod/stg/dev/sbx	`prod`
team	team or BU name	`platform`
app	application name	`api`
random	4 chars for uniqueness	`a1b2`

⚠️ Project ID Constraints

Globally unique across all of GCP
6-30 characters
Lowercase letters, digits, hyphens
Must start with letter
Cannot end with hyphen
Cannot be changed after creation

Labels & Tags

Label Strategy

yaml

# Required labels for all resources
labels:
  environment: production|staging|development|sandbox
  team: platform|data|mobile|security
  cost-center: cc-12345
  application: api-gateway
  managed-by: terraform|console|gcloud
  
# Optional labels
  owner: team-email@example.com
  compliance: pci|hipaa|sox
  data-classification: public|internal|confidential|restricted

Tags for IAM Conditions

┌─────────────────────────────────────────────────────────────────┐
│                    TAGS vs LABELS                               │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  LABELS                              TAGS                       │
│  ──────                              ────                       │
│  • Key-value metadata                • Hierarchical namespace   │
│  • For organization/billing          • For IAM conditions       │
│  • Applied to resources              • Applied to resources     │
│  • No IAM integration                • IAM-aware                │
│                                                                 │
│  Example Label:                      Example Tag:               │
│  environment: production             tagKeys/env/tagValues/prod │
│                                                                 │
│  Use Case:                           Use Case:                  │
│  Cost allocation, filtering          Conditional access control │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

GCP vs AWS Comparison

Concept	GCP	AWS
Root	Organization	Organization
Grouping	Folders (10 levels)	OUs (5 levels)
Workload Container	Project	Account
Policy Inheritance	Organization Policies	SCPs
Billing	Billing Account → Projects	Consolidated Billing
Identity Source	Cloud Identity/Workspace	IAM Identity Center

Best Practices Checklist

[ ] Organization linked to Cloud Identity domain
[ ] Folder structure reflects environment and team ownership
[ ] Organization policies enforced at appropriate levels
[ ] Project naming convention documented and enforced
[ ] Labels strategy defined for cost allocation
[ ] Tags configured for IAM conditions
[ ] Sandbox folder with relaxed policies for experimentation
[ ] Shared services in dedicated projects

⚖️ Trade-offs

Trade-off 1: Folder Depth vs Simplicity

Khía cạnh	Deep Hierarchy	Flat Hierarchy
Granularity	High	Low
Policy flexibility	More override points	Simpler inheritance
Management overhead	Cao	Thấp
Navigation	Complex	Simple

Khuyến nghị: 2-4 levels là optimal. Environment > Team > (Optional: Application)

Trade-off 2: Project Granularity

Approach	Project per...	Pros	Cons
Fine	Microservice	Isolation, billing clarity	Quota issues, many projects
Medium	Application	Balanced	Medium complexity
Coarse	Team	Simple	Blast radius, billing unclear

Trade-off 3: Shared VPC vs Standalone VPCs

Khía cạnh	Shared VPC	Standalone VPCs
IP management	Centralized	Distributed
Firewall rules	Host project	Per project
Complexity	Higher	Lower
Security	Better control	Project-level

🚨 Failure Modes

Failure Mode 1: Organization Policy Blocks Production

🔥 Incident thực tế

Org policy "Disable external IPs" enforced tại org level. Team cần external IP cho NAT Gateway trong new project. Deployment blocked 2 ngày pending exception approval.

Cách phát hiện	Cách phòng tránh
Deployment failures	Test policies trong sandbox
Policy violation errors	Exception process documented
Blocked resource creation	Folder-level overrides ready

Failure Mode 2: Project Quota Exhaustion

Cách phát hiện	Cách phòng tránh
"Quota exceeded" errors	Monitor project quotas
Cannot create new projects	Request quota increase early
Rate limiting	Use folders to distribute

Failure Mode 3: Label Inconsistency

Cách phát hiện	Cách phòng tránh
Cost allocation gaps	Terraform label enforcement
"Untagged" in billing	Organization policy for labels
Billing reconciliation issues	Regular label audit

🔐 Security Baseline

Essential Organization Policies

Policy	Setting	Vì sao
`iam.disableServiceAccountKeyCreation`	Enforced	Prevent key leaks
`compute.requireOsLogin`	Enforced	SSH key management
`compute.vmExternalIpAccess`	Deny all (prod)	Reduce attack surface
`storage.uniformBucketLevelAccess`	Enforced	Simplify ACLs
`iam.allowedPolicyMemberDomains`	Your domains only	Prevent external sharing

Hierarchy Security

Level	Security Focus
Organization	Identity, global policies
Folder (Prod)	Strictest policies
Folder (Non-prod)	Moderate policies
Folder (Sandbox)	Minimal restrictions
Project	Resource-specific

📊 Ops Readiness

Metrics cần Monitoring

Metric	Source	Alert Threshold
Project count	Resource Manager	> 80% quota
Policy violations	Security Command Center	Any
Unlabeled resources	Asset Inventory	> 5%
Folder depth	Custom	> 5 levels

Runbook Entry Points

Tình huống	Runbook
New project creation	`runbook/project-provisioning.md`
Organization policy exception	`runbook/org-policy-exception.md`
Folder restructuring	`runbook/folder-migration.md`
Label remediation	`runbook/label-enforcement.md`
Quota increase request	`runbook/quota-increase.md`

✅ Design Review Checklist

Structure

[ ] Organization linked và verified
[ ] Folder hierarchy reflects environment/team
[ ] Shared services isolated
[ ] Sandbox folder available

Governance

[ ] Organization policies defined
[ ] Exception process documented
[ ] Naming convention enforced
[ ] Labels mandatory

Security

[ ] Security policies at org level
[ ] Production folder stricter
[ ] SA key creation disabled
[ ] External IP restricted

Operations

[ ] Project quota monitored
[ ] Label compliance tracked
[ ] Runbooks documented
[ ] IaC for provisioning

📎 Liên kết

📎 AWS Account & Landing Zone - So sánh với AWS Organizations
📎 GCP IAM Model - IAM trong context của resource hierarchy
📎 Terraform State Management - Managing hierarchy với IaC
📎 Cost & Quotas - Billing structure và hierarchy
📎 GCP Security Perimeter - VPC Service Controls integration

🏗️ Resource Hierarchy ​

🎯 Mục tiêu (Outcomes) ​

✅ Khi nào dùng ​

❌ Khi nào KHÔNG dùng ​

Core Concepts ​

GCP Resource Hierarchy ​

Hierarchy Components ​

Enterprise Folder Structure ​

Recommended Pattern ​

Folder Design Principles ​

Organization Policies ​

Policy Inheritance ​

Essential Organization Policies ​

Policy Hierarchy Example ​

Project Naming Convention ​

Recommended Format ​

Naming Rules ​

Labels & Tags ​

Label Strategy ​

Tags for IAM Conditions ​

GCP vs AWS Comparison ​

Best Practices Checklist ​

⚖️ Trade-offs ​

Trade-off 1: Folder Depth vs Simplicity ​

Trade-off 2: Project Granularity ​

Trade-off 3: Shared VPC vs Standalone VPCs ​

🚨 Failure Modes ​

Failure Mode 1: Organization Policy Blocks Production ​

Failure Mode 2: Project Quota Exhaustion ​

Failure Mode 3: Label Inconsistency ​

🔐 Security Baseline ​

Essential Organization Policies ​

Hierarchy Security ​

📊 Ops Readiness ​

Metrics cần Monitoring ​

Runbook Entry Points ​

✅ Design Review Checklist ​

Structure ​

Governance ​

Security ​

Operations ​

📎 Liên kết ​

🏗️ Resource Hierarchy

🎯 Mục tiêu (Outcomes)

✅ Khi nào dùng

❌ Khi nào KHÔNG dùng

Core Concepts

GCP Resource Hierarchy

Hierarchy Components

Enterprise Folder Structure

Recommended Pattern

Folder Design Principles

Organization Policies

Policy Inheritance

Essential Organization Policies

Policy Hierarchy Example

Project Naming Convention

Recommended Format

Naming Rules

Labels & Tags

Label Strategy

Tags for IAM Conditions

GCP vs AWS Comparison

Best Practices Checklist

⚖️ Trade-offs

Trade-off 1: Folder Depth vs Simplicity

Trade-off 2: Project Granularity

Trade-off 3: Shared VPC vs Standalone VPCs

🚨 Failure Modes

Failure Mode 1: Organization Policy Blocks Production

Failure Mode 2: Project Quota Exhaustion

Failure Mode 3: Label Inconsistency

🔐 Security Baseline

Essential Organization Policies

Hierarchy Security

📊 Ops Readiness

Metrics cần Monitoring

Runbook Entry Points

✅ Design Review Checklist

Structure

Governance

Security

Operations

📎 Liên kết