HCP Terraform Enterprise Migration - What Actually Happens

First migration: We dumped 5,000 resources into one massive workspace because "it's easier to manage." Fucking stupid. Plans took 45 minutes. Some developer changed a security group and brought down our entire e-commerce platform at 2 PM on Black Friday. Try explaining that to the board.

The dependency cascades are real. Touch one thing, break everything downstream. We lost two senior engineers that quarter because they got tired of 3 AM calls fixing shit we broke during the day.

How Discover Financial Doesn't Burn Down Production

Discover Financial manages 2,000+ workspaces without constant fires because they figured out the hierarchy that actually works. HashiCorp's workspace organization patterns make sense when you stop trying to put everything in one bucket:

Foundation Layer: 15 workspaces max. Network, IAM, DNS, monitoring. Changes here require VP approval, which means nothing breaks silently at midnight.

Platform Layer: Database clusters, Kubernetes, load balancers. Around 80 workspaces. These can break without killing everything, but you'll get woken up.

App Layer: 300+ workspaces. Each service gets its own workspace per environment. Prod-payments-api-database, dev-auth-service-cache, that kind of naming. Break these all you want during business hours.

Business Unit Hell: 1000+ workspaces when legal makes you isolate everything because of compliance. Each department gets its own sandbox so they can't blame each other when costs spike.

The trick isn't the number of tiers - it's the blast radius. Foundation fucks up, everyone's down. App workspace fucks up, one team has a bad day.

The April 2026 Clusterfuck

HashiCorp killed Terraform Enterprise on Replicated. Support dies April 1, 2026 with the final release in March 2025. They shipped the tf-migrate tool but it's not magic - you're still fucked if you wait until November 2025 to start.

The Migration Tool That Mostly Works:

The tf-migrate tool shipped in March 2025. It's slow as hell for big state files but beats doing it by hand:

## This will take forever and half your workspaces will fail
tf-migrate -target=hcp-terraform \
  -organization=my-enterprise \
  -workspace-prefix=prod- \
  -source-dir=/terraform/workspaces/

## Common error you'll see:
## Error: workspace \"prod-payments-db\" failed: state file too large (>100MB)
## Fix: Split your massive workspaces before migrating

Humana's 12-Month Hell:

Humana wrote about their migration disaster because misery loves company:

• Month 1: "How many workspaces do we have?" "Uh..."
• Month 2: Found 300+ workspaces across 42 teams nobody talked to
• Month 4: Pilot with 5 volunteer teams went smooth (should've been suspicious)
• Month 6: Real teams started bitching about workflow changes
• Month 9: Production migration broke everything twice
• Month 12: Finally stopped getting emergency calls every weekend

What kept them from getting fired: Dynamic credentials stopped the weekly "who rotated the AWS keys?" incident reports. Policy automation caught two teams about to spin up $50K monthly bills. Templates prevented the usual "let's create 47 different ways to deploy a simple API" chaos.

When Your Bill Triples Overnight

RUM pricing (Resources Under Management) is HashiCorp's way of charging per resource instead of per user. Sounds reasonable until your first bill arrives. Our bill tripled overnight because we found a shitload of resources nobody knew about. ControlMonkey's analysis shows 60% of companies blow their budgets in year one.

Current HCP Terraform rates hit $0.10-$0.99 per resource monthly depending on tier. That 10,000-resource deployment? $1,000-$9,900 monthly. Plus the $39-$199 per user base fees. Plus overages when you miscounted. HashiCorp killed the free tier in March 2025, so there's no testing the waters anymore.

What Actually Works to Cut Costs:

Stop Duplicating Shit: Create shared resources once, reference everywhere else. Every duplicate security group costs you monthly.

## Bad: Creates a resource in every workspace (costs multiply)
resource \"aws_security_group\" \"web\" {
  name = \"web-sg-${workspace.name}\" # Now you have 50 identical security groups
}

## Good: Reference shared resources (no RUM hit)
data \"aws_security_group\" \"web\" {
  name = \"shared-web-sg\" # One security group, referenced everywhere
}

Module Everything: Terraform Registry modules can cut your resource count in half. We went from 300 individual resources to 80 module instances for the same functionality. AWS VPC module replaces 15 individual resources with one module call. Gruntwork's enterprise patterns saved us $40K monthly by consolidating common patterns.

Kill Dev Environments on Weekends: Nobody works weekends anyway. We destroy all non-prod stuff Friday evening, recreate Monday morning. Cut our dev/staging costs by 40%. Until someone forgets to run the Monday script and devs can't work until noon.

## Friday teardown script (runs in CI/CD)
terraform destroy -target=aws_instance.dev_instances -auto-approve
terraform destroy -target=aws_rds_instance.staging_db -auto-approve

## Monday recreation
terraform apply -auto-approve

AWS Lambda scheduled actions can automate this. GitHub Actions cron jobs work too if you're not scared of YAML hell.

Stop Developers from Bankrupting You

Without policies, someone will deploy a p4d.24xlarge instance in production "for testing" and forget about it. AWS bill spiked over a weekend when some data science team forgot about a massive GPU cluster they spun up. Sentinel policies prevent this shit from happening.

The Policies That Actually Save Money:

No GPU Instances Unless You're Rich:

## Block p4d.24xlarge instances that cost $58K monthly
forbidden_instances = [\"p4d.24xlarge\", \"p3dn.24xlarge\", \"x1e.32xlarge\"]

main = rule {
  all aws_instance as instance {
    instance.instance_type not in forbidden_instances
  }
}

S3 Buckets Must Be Encrypted (because auditors):

## Unencrypted buckets fail SOC2 audits
main = rule {
  all aws_s3_bucket as bucket {
    bucket.server_side_encryption_configuration is not empty
  }
}

Tag Everything or Finance Gets Mad:

required_tags = [\"CostCenter\", \"Environment\", \"Owner\"]

main = rule {
  all aws_instance as instance {
    all required_tags as tag {
      instance.tags contains tag
    }
  }
}

Without these tags, you can't do chargeback accounting and every department blames platform engineering for the cloud bill.

Dynamic Credentials Finally Work

OIDC-based dynamic credentials solve the "who the fuck rotated the AWS keys again?" problem. Instead of quarterly key rotations that break everything, dynamic provider credentials generate short-lived tokens for each Terraform run.

Before dynamic credentials: Every three months, someone rotates service account keys. Half the workspaces break because they're still using the old keys. Platform engineering spends a week fixing deployments that worked last Friday.

After: Tokens last 15 minutes, generated automatically per run. No more key rotation incidents. No more "InvalidAccessKeyId" errors in the middle of deployments.

## OIDC setup that actually works
resource \"aws_iam_role\" \"hcp_terraform\" {
  name = \"hcp-terraform-dynamic-role\"
  
  assume_role_policy = jsonencode({
    Version = \"2012-10-17\"
    Statement = [{
      Effect = \"Allow\"
      Principal = {
        Federated = aws_iam_openid_connect_provider.hcp_terraform.arn
      }
      Action = \"sts:AssumeRoleWithWebIdentity\"
      Condition = {
        StringEquals = {
          \"app.terraform.io:aud\" = \"aws.workload.identity\"
        }
        StringLike = {
          \"app.terraform.io:sub\" = \"organization:my-org:workspace:prod-*:*\"
        }
      }
    }]
  })
}

We went from 12 credential rotation incidents per quarter to zero. AWS dynamic credentials implementation walks through the AWS setup. AWS IAM security best practices covers the OIDC trust relationships. The HCP Terraform tutorials explain multi-cloud setups.

Alternative platforms like Spacelift and Env0 also support dynamic credentials, often with better multi-cloud coverage than HashiCorp's implementation. Platform comparison analysis covers real-world experiences across platforms.

You'll spend more time in meetings than writing Terraform. Security will hate everything you do. Budget 6 months of arguments before you write a single resource block. Watched a 6-month project die because security wouldn't approve dynamic credentials - they didn't understand OIDC and refused to learn.

How to Sneak Past Corporate Immune System

Find the one team that's desperate enough to try anything. We started with the mobile team who was spending 3 hours manually deploying to staging every day. Dev environments only - don't even whisper "production" until month 4.

Month 1-3: Underground Railroad
Pick AWS or Azure, not both. Focus on one workflow that saves the most time. Mobile team went from 3-hour manual deployments to 15-minute automated runs. Security didn't notice because we stayed in dev.

What Actually Happened:

• Went from manual 3-hour deployments to 15-minute automated runs
• Mobile team became evangelical because they could finally deploy without begging ops
• Configuration drift stopped being a daily crisis
• Zero production incidents (because we weren't in production yet)

Month 4-8: The Honeymoon Ends
Add 3 more teams from the same business unit. This is when you introduce templates and policies. Backend team complained about "unnecessary complexity" for 6 weeks until they realized they stopped breaking staging every Friday.

Month 9-15: Cross-Business Unit Nightmare
Everything goes to shit when you cross business unit boundaries. Legal has different compliance requirements than payments. Marketing wants different naming conventions than engineering. Finance wants cost allocation that doesn't exist.

Month 12 is when I started polishing my resume.

Critical Success Factors:

• Shared Service Model: Foundation infrastructure managed centrally, application infrastructure owned by teams (see platform team best practices)
• Cost Allocation: Clear chargeback mechanisms using workspace tags and cost estimation
• Security Boundaries: Separate organizations or strict RBAC for different compliance requirements
• Template Library: Standard patterns for common deployment scenarios

Phase 4: Full Enterprise Deployment (Months 16+)
Scale to hundreds of teams and thousands of workspaces. At this stage, automation and self-service become essential.

Organizational Patterns That Don't Completely Suck

The Hub and Spoke Model (Works Sometimes)

Platform team manages the foundation stuff, app teams do their own thing within guardrails. It's not perfect but it beats chaos.

Central Platform Team Responsibilities:

• Foundation infrastructure (networking, identity, monitoring)
• Workspace templates and module library
• Policy development and enforcement
• Cost optimization and governance
• Migration and upgrade management

Application Team Responsibilities:

• Application-specific infrastructure within templates
• Environment-specific configurations
• Feature deployment and rollback
• Application monitoring and alerting
• Development environment management

The Federation Model

Large enterprises (50+ teams) often require federation - multiple semi-autonomous HCP Terraform organizations with standardized patterns. This enables business unit independence while maintaining enterprise governance (see HashiCorp's federation patterns guide).

Enterprise Governance Council: Sets policies, standards, and templates across all organizations. Meets quarterly, includes representatives from security, finance, and engineering.

Business Unit Platform Teams: Implement governance standards within their domain. Manage organization-specific customizations and priorities.

Application Teams: Deploy and manage infrastructure within established boundaries. Focus on delivery velocity within compliance requirements.

Migration Strategies: Technical and Political

The "Strangler Fig" Approach

Don't attempt big-bang migrations. The terraform migrate tool introduced in 2025 supports incremental state migration, allowing gradual transition without service disruption. Also see Spacelift's migration guide and Scalr's platform migration resources for alternative approaches.

## This will take forever but it works
terraform migrate --target=hcp-terraform --workspace-filter="environment:dev" 

## Half the workspaces will fail validation, fix them manually
terraform migrate --workspace-filter="team:payments" --parallel-limit=3

Political Migration Strategy:

Month 1-2: Inventory and dependency mapping with stakeholder interviews. Document current pain points, cost inefficiencies, and security gaps.

Month 3-4: Executive presentation focusing on business outcomes:

• Risk reduction: Eliminate manual deployment processes and configuration drift
• Cost optimization: Prevent expensive mistakes through policy automation
• Compliance automation: Reduce audit preparation time by 80%
• Developer productivity: Self-service infrastructure reduces ticket queues

Month 5-6: Pilot deployment with measurable success criteria. Quantify improvements in deployment speed, error rates, and team satisfaction.

Month 7-12: Gradual rollout with continuous measurement and stakeholder communication. Regular steering committee updates with metrics and ROI calculations.

Advanced Configuration Management

Environment Promotion Strategies

Enterprise deployments require sophisticated environment promotion that goes beyond basic CI/CD. The pattern that works involves workspace chaining with automated validation gates.

Development → Staging Promotion:

## Automated testing and validation
resource "null_resource" "staging_promotion_gate" {
  triggers = {
    dev_workspace_run_id = data.tfe_workspace_run.dev.id
    integration_tests_passed = var.integration_tests_passed
    security_scan_clean = var.security_scan_passed
  }
  
  provisioner "local-exec" {
    command = "terraform workspace select staging && terraform plan -out=staging.tfplan"
  }
}

Staging → Production Promotion:
Production deployments require additional approval workflows, change management integration, and rollback capabilities.

## Production deployment with approval gate
resource "tfe_run" "production_deployment" {
  workspace_id = data.tfe_workspace.production.id
  
  # Require manual approval for production
  auto_apply = false
  
  # Integration with change management
  message = "Production deployment - Change Request: ${var.change_request_id}"
  
  # Rollback capability
  replace_addrs = var.force_replace_resources
}

Cross-Workspace Data Sharing

Enterprise architectures require careful dependency management between workspaces. The remote state data source enables sharing without tight coupling:

## Foundation networking workspace outputs
data "terraform_remote_state" "network" {
  backend = "remote"
  config = {
    organization = "enterprise-foundation"
    workspaces = {
      name = "network-production"
    }
  }
}

## Application workspace consumes shared networking
resource "aws_instance" "app_server" {
  subnet_id = data.terraform_remote_state.network.outputs.private_subnet_ids[0]
  vpc_security_group_ids = [data.terraform_remote_state.network.outputs.app_security_group_id]
}

Security and Compliance at Scale

Zero-Trust Architecture Implementation

Enterprise security requires assuming breach and implementing defense in depth. HCP Terraform's dynamic credentials enable zero-trust principles:

Principle 1: Short-Lived Credentials
Every Terraform run receives unique, time-limited credentials. Compromise window reduced from months to minutes.

Principle 2: Least Privilege Access
Workspace-specific IAM roles with minimal required permissions. Regular access reviews automated through policy.

Principle 3: Audit Everything
All infrastructure changes tracked with user attribution, approval chains, and rollback capability.

## Workspace-specific IAM role with minimal privileges
resource "aws_iam_role" "workspace_role" {
  name = "hcp-terraform-${var.workspace_name}"
  
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = {
        Federated = aws_iam_openid_connect_provider.hcp_terraform.arn
      }
      Action = "sts:AssumeRoleWithWebIdentity"
      Condition = {
        StringEquals = {
          "${var.tfc_hostname}:aud" = "aws.workload.identity"
          "${var.tfc_hostname}:workspace" = var.workspace_name
        }
      }
    }]
  })
}

## Attach minimal required policies
resource "aws_iam_role_policy_attachment" "workspace_policy" {
  count      = length(var.required_policies)
  role       = aws_iam_role.workspace_role.name
  policy_arn = var.required_policies[count.index]
}

Compliance Automation

Sentinel policies enable proactive compliance rather than reactive remediation. The AWS Terraform best practices guide provides enterprise-specific compliance patterns.

SOC 2 Compliance Automation:

## Require encryption for all data at rest
policy "encryption-required" {
  enforcement_level = "hard-mandatory"
}

main = rule {
  all aws_s3_bucket.buckets as bucket {
    bucket.server_side_encryption_configuration is not empty
  } and
  all aws_rds_cluster.clusters as cluster {
    cluster.storage_encrypted is true
  }
}

PCI DSS Network Segmentation:

## Enforce network isolation for PCI workloads
policy "pci-network-isolation" {
  enforcement_level = "hard-mandatory"
}

main = rule when environment == "pci" {
  all aws_security_group.groups as sg {
    sg.ingress as ingress {
      ingress.cidr_blocks not contains "0.0.0.0/0"
    }
  }
}

Performance Optimization at Enterprise Scale

Workspace Sizing Guidelines

The official workspace best practices recommend staying under 1,000 resources, but enterprise reality requires more nuanced sizing:

Small Workspaces (50-200 resources): Application-specific infrastructure, development environments

• Plan time: 30 seconds - 2 minutes
• Apply time: 2-5 minutes
• State size: < 1MB
• Team size: 1-3 engineers

Medium Workspaces (200-800 resources): Service clusters, environment-wide shared services

• Plan time: 2-8 minutes
• Apply time: 5-15 minutes
• State size: 1-5MB
• Team size: 3-8 engineers

Large Workspaces (800-2000 resources): Foundation infrastructure, multi-region deployments

• Plan time: 8-20 minutes
• Apply time: 15-45 minutes
• State size: 5-20MB
• Team size: 8+ engineers (platform team)

Parallelization Strategies

Enterprise deployments benefit from careful dependency management and parallel execution:

## Use depends_on sparingly - implicit dependencies are faster
resource "aws_instance" "app_servers" {
  count = var.instance_count
  
  # Implicit dependency through reference
  subnet_id = aws_subnet.app_subnets[count.index].id
  
  # Explicit dependency only when necessary
  depends_on = [aws_nat_gateway.main]
}

## Parallelize independent resource creation
resource "aws_s3_bucket" "app_buckets" {
  for_each = var.applications
  
  bucket = "${each.key}-${var.environment}-bucket"
  
  # Independent resources can be created in parallel
}

The key insight: enterprise Terraform deployments succeed when they solve organizational problems, not just technical ones. Focus on enabling team autonomy within governance boundaries, and the technical implementation becomes straightforward.

Cool, your POC works. Now everything goes to hell. Multi-cloud sounds great until AWS works fine but Azure randomly shits the bed. These patterns exist because someone 2 years ago made terrible decisions and now you get to fix them.

Multi-Cloud: When You Have No Choice

Nobody Chooses Multi-Cloud on Purpose

You're stuck with AWS and Azure because you acquired a company that went with Microsoft, not because you planned this nightmare. Spacelift's multi-cloud guide shows the technical side, but doesn't cover the political clusterfuck of coordinating teams across different clouds. Check out Google's multi-cloud architecture guide and Microsoft's hybrid cloud patterns for more context.

The Pattern That Doesn't Make You Want to Quit:

## Foundation module - cloud agnostic interface
module \"foundation\" {
  source = \"./modules/foundation\"
  
  # Standardized inputs across cloud providers
  environment     = var.environment
  business_unit   = var.business_unit
  cost_center     = var.cost_center
  
  # Provider-specific configuration
  provider_config = var.cloud_provider == \"aws\" ? {
    region = var.aws_region
    vpc_cidr = var.vpc_cidr
  } : {
    location = var.azure_location
    vnet_cidr = var.vnet_cidr
  }
}

## Provider-specific implementations behind common interface
resource \"aws_vpc\" \"main\" {
  count      = var.cloud_provider == \"aws\" ? 1 : 0
  cidr_block = var.provider_config.vpc_cidr
  
  tags = local.common_tags
}

resource \"azurerm_virtual_network\" \"main\" {
  count           = var.cloud_provider == \"azure\" ? 1 : 0
  address_space   = [var.provider_config.vnet_cidr]
  location        = var.provider_config.location
  
  tags = local.common_tags
}

Cross-Cloud Data Replication and DR

Enterprise deployments often require data replication across cloud providers for disaster recovery or compliance. The pattern that works involves treating each cloud as a separate HCP Terraform organization with standardized data interfaces:

## Primary site (AWS)
module \"primary_site\" {
  source = \"./modules/application-stack\"
  
  cloud_provider = \"aws\"
  region        = \"us-east-1\"
  
  # Cross-cloud replication configuration
  backup_targets = [{
    provider = \"azure\"
    region   = \"eastus\"
    workspace = \"disaster-recovery-azure\"
  }]
}

## DR site (Azure) - separate workspace, consistent interface
module \"dr_site\" {
  source = \"./modules/application-stack\"
  
  cloud_provider = \"azure\"
  region        = \"eastus\"
  
  # Synchronized from primary
  replica_source = data.terraform_remote_state.primary.outputs.replication_config
}

When Finance Starts Asking Questions About the Bill

Cost Estimation vs. Cost Reality

HCP Terraform's cost estimation is cute for demos but completely useless for budgeting. Your CFO wants to know why infrastructure costs doubled and "predictive modeling" won't save your ass in the quarterly review.

Dynamic Cost Allocation Pattern:

## Cost allocation through dynamic tagging
locals {
  cost_tags = merge(
    var.base_tags,
    {
      \"CostCenter\"     = var.cost_center
      \"Project\"        = var.project_code  
      \"Environment\"    = var.environment
      \"Owner\"          = var.team_email
      \"ExpirationDate\" = var.environment == \"dev\" ? 
        formatdate(\"YYYY-MM-DD\", timeadd(timestamp(), \"168h\")) : \"\"
    }
  )
}

## All resources inherit cost allocation tags
resource \"aws_instance\" \"app_servers\" {
  count = var.instance_count
  
  instance_type = var.instance_type
  ami           = data.aws_ami.app.id
  
  # Automatic cost attribution
  tags = local.cost_tags
  
  # Cost optimization through lifecycle management
  lifecycle {
    ignore_changes = [tags[\"ExpirationDate\"]]
  }
}

## Cost anomaly detection through policy
resource \"aws_budgets_budget\" \"team_budget\" {
  name     = \"${var.team_name}-${var.environment}-budget\"
  budget_type = \"COST\"
  limit_amount = var.monthly_budget_limit
  limit_unit   = \"USD\"
  time_unit    = \"MONTHLY\"
  
  # Alert when 80% of budget consumed
  cost_filters = {
    Tag = {
      \"CostCenter\" = [var.cost_center]
      \"Environment\" = [var.environment]
    }
  }
}

Reserved Instance and Savings Plan Orchestration:

Enterprise teams managing thousands of instances require coordinated purchasing strategies. The pattern that works involves central purchasing with distributed allocation:

## Central reservation management workspace
resource \"aws_ec2_capacity_reservation\" \"enterprise_capacity\" {
  instance_type     = \"m5.large\"
  instance_platform = \"Linux/UNIX\"
  availability_zone = \"us-west-2a\"
  instance_count    = 100
  
  # Enterprise-wide reservation
  tags = {
    \"ReservationType\" = \"Enterprise\"
    \"AllocationPool\"  = \"General\"
  }
}

## Application workspaces consume reserved capacity
data \"aws_ec2_capacity_reservation\" \"available\" {
  filter {
    name   = \"tag:AllocationPool\"
    values = [\"General\"]
  }
  
  filter {
    name   = \"state\"
    values = [\"available\"]
  }
}

resource \"aws_instance\" \"app\" {
  instance_type = \"m5.large\"
  
  # Automatic reserved instance utilization
  capacity_reservation_specification {
    capacity_reservation_preference = \"open\"
  }
}

Enterprise Integration Patterns

ServiceNow Integration for Change Management

Most enterprises require ITSM integration for production deployments. The pattern that works involves HCP Terraform run tasks integrated with change management workflows:

## Change management integration through run tasks
resource \"tfe_workspace_run_task\" \"servicenow_change\" {
  workspace_id      = data.tfe_workspace.production.id
  task_id          = data.tfe_organization_run_task.change_management.id
  enforcement_level = \"mandatory\"
  
  # Only for production deployments
  stage = \"pre_plan\"
}

## Automatic change request creation
data \"external\" \"create_change_request\" {
  program = [\"python\", \"${path.module}/scripts/servicenow_integration.py\"]
  
  query = {
    workspace_name = var.workspace_name
    planned_changes = jsonencode(var.planned_resources)
    business_justification = var.change_description
    risk_level = var.environment == \"prod\" ? \"Medium\" : \"Low\"
  }
}

Active Directory/LDAP Integration for Team Management

Enterprise teams change frequently, requiring automated user provisioning and team membership management:

## Automated team provisioning from AD groups
data \"external\" \"ad_team_members\" {
  program = [\"powershell\", \"${path.module}/scripts/get-ad-group-members.ps1\"]
  
  query = {
    group_name = \"TF-${upper(var.business_unit)}-${upper(var.environment)}\"
  }
}

## Dynamic team membership
resource \"tfe_team\" \"business_unit_team\" {
  name         = \"${var.business_unit}-${var.environment}\"
  organization = var.tfe_organization
  
  # Automatically sync with AD group
  members = data.external.ad_team_members.result.members
}

## Environment-specific access controls
resource \"tfe_team_access\" \"environment_access\" {
  access       = var.environment == \"prod\" ? \"plan\" : \"write\"
  team_id      = tfe_team.business_unit_team.id
  workspace_id = data.tfe_workspace.app.id
}

Advanced Security Patterns

Zero-Trust Network Architecture with HCP Terraform

Modern enterprise security requires zero-trust principles throughout the infrastructure deployment pipeline:

## Microsegmentation through automated security groups
resource \"aws_security_group\" \"app_tier\" {
  name_prefix = \"${var.app_name}-${var.environment}\"
  vpc_id      = data.terraform_remote_state.network.outputs.vpc_id
  
  # Default deny all
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = \"-1\"
    cidr_blocks = []
  }
}

## Explicit allow rules based on application topology  
resource \"aws_security_group_rule\" \"app_to_database\" {
  type                     = \"egress\"
  from_port               = 5432
  to_port                 = 5432
  protocol                = \"tcp\"
  security_group_id       = aws_security_group.app_tier.id
  source_security_group_id = aws_security_group.database_tier.id
  
  description = \"App tier to database - managed by Terraform\"
}

## Network access logging for compliance
resource \"aws_vpc_flow_log\" \"app_traffic\" {
  iam_role_arn    = aws_iam_role.flow_log.arn
  log_destination = aws_cloudwatch_log_group.app_flow_logs.arn
  traffic_type    = \"ALL\"
  vpc_id          = data.terraform_remote_state.network.outputs.vpc_id
  
  tags = merge(local.common_tags, {
    \"Purpose\" = \"SecurityCompliance\"
  })
}

Secrets Management Integration

Enterprise applications require sophisticated secrets management that integrates with existing vault solutions:

## Integration with enterprise HashiCorp Vault
data \"vault_generic_secret\" \"app_credentials\" {
  path = \"secret/${var.environment}/${var.app_name}\"
}

## Dynamic database credentials
resource \"vault_database_secret_backend_connection\" \"app_database\" {
  backend       = vault_mount.database.path
  name          = \"${var.app_name}-db\"
  allowed_roles = [\"${var.app_name}-role\"]

  postgresql {
    connection_url = \"postgresql://{{username}}:{{password}}@${aws_rds_cluster.app.endpoint}:5432/app\"
    username       = data.vault_generic_secret.app_credentials.data[\"db_admin_user\"]
    password       = data.vault_generic_secret.app_credentials.data[\"db_admin_password\"]
  }
}

## Application gets dynamic database credentials
resource \"vault_database_secret_backend_role\" \"app_role\" {
  backend             = vault_mount.database.path
  name                = \"${var.app_name}-role\"
  db_name             = vault_database_secret_backend_connection.app_database.name
  creation_statements = [
    \"CREATE ROLE \\\"{{name}}\\\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}';\",
    \"GRANT SELECT, INSERT, UPDATE ON ALL TABLES IN SCHEMA public TO \\\"{{name}}\\\";\"
  ]
  
  default_ttl = 3600  # 1 hour
  max_ttl     = 86400 # 24 hours
}

Performance Optimization: Massive Scale Patterns

Workspace Sharding for Large-Scale Deployments

When managing 10,000+ resources, traditional workspace organization breaks down. The pattern that works involves systematic resource sharding:

## Shard resources across multiple workspaces
locals {
  # Partition resources by hash of identifier
  shard_count = 10
  resource_shard = abs(crc32(var.resource_identifier)) % local.shard_count
}

## Deploy to specific shard workspace
data \"tfe_workspace\" \"shard_workspace\" {
  name         = \"${var.app_name}-shard-${local.resource_shard}\"
  organization = var.tfe_organization
}

## Resource deployment to appropriate shard
resource \"aws_instance\" \"sharded_instance\" {
  # Resource configuration based on shard assignment
  availability_zone = data.aws_availability_zones.available.names[local.resource_shard % length(data.aws_availability_zones.available.names)]
  
  tags = merge(local.common_tags, {
    \"Shard\" = local.resource_shard
  })
}

Parallel Deployment Orchestration

Enterprise deployments often require coordinated changes across hundreds of workspaces. The pattern that works involves orchestration workspaces that manage deployment waves:

## Deployment orchestration workspace
resource \"tfe_run\" \"wave_1_deployments\" {
  count = length(var.wave_1_workspaces)
  
  workspace_id = data.tfe_workspace.wave_1[count.index].id
  message     = \"Orchestrated deployment - Wave 1\"
  auto_apply  = false  # Require manual approval for production
}

## Wait for wave 1 completion before wave 2
resource \"time_sleep\" \"wait_for_wave_1\" {
  depends_on = [tfe_run.wave_1_deployments]
  
  create_duration = \"5m\"  # Allow time for deployments
}

resource \"tfe_run\" \"wave_2_deployments\" {
  depends_on = [time_sleep.wait_for_wave_1]
  count      = length(var.wave_2_workspaces)
  
  workspace_id = data.tfe_workspace.wave_2[count.index].id
  message     = \"Orchestrated deployment - Wave 2\"
}

Monitoring and Observability at Enterprise Scale

Infrastructure State Monitoring

Enterprise teams need visibility into drift, policy violations, and deployment health across thousands of resources:

## Automated drift detection and alerting
resource \"datadog_monitor\" \"terraform_drift\" {
  name    = \"Terraform Drift Detected - ${var.workspace_name}\"
  type    = \"metric alert\"
  message = \"Infrastructure drift detected in workspace ${var.workspace_name}. Investigate immediately.\"
  
  query = \"avg(last_5m):avg:terraform.drift.resources{workspace:${var.workspace_name}} > 0\"
  
  monitor_thresholds {
    critical = 0
  }
  
  notify_audit       = true
  notify_no_data    = false
  renotify_interval = 60
  
  tags = [\"team:${var.team_name}\", \"environment:${var.environment}\"]
}

## Cost anomaly detection
resource \"datadog_monitor\" \"cost_anomaly\" {
  name = \"Cost Anomaly - ${var.workspace_name}\"
  type = \"anomaly\"
  
  query = \"avg(last_7d):avg:aws.billing.estimated_charges{tag_costcenter:${var.cost_center}} > 0\"
  
  message = \"Cost anomaly detected for cost center ${var.cost_center}. Review deployments.\"
  
  monitor_thresholds {
    critical = 1.5  # 50% above baseline
  }
}

Bottom line: Advanced patterns exist because simple shit breaks at scale. You'll end up building these patterns after your third production incident, so might as well start now.