Azure Infrastructure Design & Naming

Create Azure infrastructure following Microsoft's Cloud Adoption Framework and infrastructure-as-code best practices. Default to West Europe region unless specified otherwise.

Quick Reference

Default Region: westeurope (West Europe) Naming Pattern: {resourceType}-{workload}-{environment}-{region}-{instance} Example: app-prism-prod-weu-001 Environment Progression: dev → test → prod (always deploy lower environments first)

Resource Naming Convention

Standard Pattern

{resourceType}-{workload}-{environment}-{region}-{instance}

Components:

• resourceType: Azure resource abbreviation (see table below)
• workload: Application/project name (e.g., prism, portal)
• environment: dev, test, prod (use this standard progression)
• region: Region abbreviation (weu, eus, neu, etc.)
• instance: Zero-padded number for uniqueness (001, 002)

Resource Type Abbreviations

Resource	Abbreviation	Example
Resource Group	rg	rg-prism-prod-weu-001
App Service Plan	plan	plan-prism-prod-weu-001
App Service	app	app-prism-prod-weu-001
Function App	func	func-prism-prod-weu-001
PostgreSQL Server	psql	psql-prism-prod-weu-001
Redis Cache	redis	redis-prism-prod-weu-001
Storage Account	st + unique	stprismprodweu001 (no hyphens, 3-24 chars)
Key Vault	kv + unique	kv-prism-prod-weu-001 (3-24 chars)
Virtual Network	vnet	vnet-prism-prod-weu-001
Subnet	snet	snet-prism-app-prod-weu-001
Network Security Group	nsg	nsg-prism-app-prod-weu-001
Application Insights	appi	appi-prism-prod-weu-001
Log Analytics Workspace	log	log-prism-prod-weu-001
Container Registry	cr + unique	crprismprodweu001 (no hyphens, 5-50 chars)
API Management	apim	apim-prism-prod-weu-001
Service Bus Namespace	sb	sb-prism-prod-weu-001
Cosmos DB Account	cosmos	cosmos-prism-prod-weu-001

Region Abbreviations

Region	Abbreviation
West Europe	weu
North Europe	neu
East US	eus
East US 2	eus2
West US 2	wus2
UK South	uks
Southeast Asia	sea

Special Cases

Storage Accounts:

• Only lowercase letters and numbers (no hyphens)
• 3-24 characters
• Pattern: st{workload}{environment}{region}{instance}
• Example: stprismprodweu001

Key Vaults:

• Alphanumeric and hyphens only
• 3-24 characters
• Must start with letter
• Example: kv-prism-prod-weu-001

Container Registries:

• Only alphanumeric (no hyphens)
• 5-50 characters
• Pattern: cr{workload}{environment}{region}{instance}
• Example: crprismprodweu001

Resource Tagging Strategy

Apply consistent tags to all resources for governance, cost tracking, and operations:

var commonTags = {
  Environment: 'Production'           // Development, Test, Production
  Project: 'Merkle Prism'            // Project name
  CostCenter: 'Engineering'          // Business unit
  Owner: 'platform-team@merkle.com'  // Responsible team
  ManagedBy: 'Bicep'                 // IaC tool
  CreatedDate: '2024-01-15'          // Creation date
  Criticality: 'High'                // Low, Medium, High, Critical
  DataClassification: 'Internal'     // Public, Internal, Confidential
}

Environment Strategy

Standard Environment Progression

CRITICAL: Always deploy environments in this order:

dev → test → prod

Rules:

1. Deploy Lower Environments First: NEVER deploy to a higher environment before all lower environments are fully created and validated
2. Complete Lower Environments: Each environment must be 100% complete and working before proceeding to the next
3. Test Before Promote: Validate infrastructure and applications in each environment before moving up
4. No Skipping: Do not skip environments (e.g., don't go directly from dev to prod)

Environment Naming

Use these standard environment names consistently:

• dev - Development environment for active development and experimentation
• test - Testing/staging environment for QA, integration testing, and pre-production validation
• prod - Production environment for live user traffic

Examples:

• rg-prism-dev-weu-001 → rg-prism-test-weu-001 → rg-prism-prod-weu-001
• app-prism-dev-weu-001 → app-prism-test-weu-001 → app-prism-prod-weu-001

Deployment Workflow

Phase 1: Development Environment

1. Deploy all infrastructure to dev environment
2. Validate all resources are created successfully
3. Test deployments and configurations
4. Verify application works end-to-end
5. Document any issues or required changes

Phase 2: Test Environment

1. Only proceed after dev is fully complete and validated
2. Deploy identical infrastructure to test environment
3. Run integration tests and QA validation
4. Perform load testing and performance validation
5. Practice deployment procedures and runbooks

Phase 3: Production Environment

1. Only proceed after test is fully validated
2. Schedule production deployment during approved change window
3. Deploy infrastructure to prod environment
4. Perform smoke tests and health checks
5. Monitor closely for the first 24-48 hours

Environment-Specific Configurations

Each environment should have its own parameter file:

infrastructure/bicep/parameters/
├── dev.bicepparam      # Deploy first
├── test.bicepparam     # Deploy second
└── prod.bicepparam     # Deploy last

Never deploy production first! Start with dev, validate, then progress through test to prod.

Infrastructure as Code Best Practices

Bicep Template Organization

infrastructure/
├── bicep/
│   ├── main.bicep                 # Orchestration template
│   ├── modules/                   # Reusable modules
│   │   ├── app-service.bicep
│   │   ├── postgresql.bicep
│   │   ├── redis.bicep
│   │   ├── networking.bicep
│   │   ├── monitoring.bicep
│   │   └── security.bicep
│   ├── parameters/                # Environment configs
│   │   ├── dev.bicepparam         # Deploy first
│   │   ├── test.bicepparam        # Deploy second
│   │   └── prod.bicepparam        # Deploy last
│   └── policies/                  # Azure Policy definitions
└── scripts/
    ├── deploy.sh
    └── validate.sh

Module Design Principles

1. Single Responsibility: Each module deploys one logical resource or tightly coupled set
2. Parameterization: Make environment-specific values parameters
3. Outputs: Return resource IDs and connection strings for dependent modules
4. Idempotency: Modules must be safely rerunnable
5. Validation: Use @allowed, @minValue, @maxValue decorators

Example Module Pattern

@description('Application name')
param workloadName string

@description('Environment name')
@allowed(['dev', 'test', 'prod'])
param environment string

@description('Azure region')
param location string = 'westeurope'

@description('Resource instance number')
param instance string = '001'

@description('Common resource tags')
param tags object

var appServiceName = 'app-${workloadName}-${environment}-weu-${instance}'

resource appService 'Microsoft.Web/sites@2023-01-01' = {
  name: appServiceName
  location: location
  tags: tags
  properties: {
    // ... configuration
  }
}

output appServiceId string = appService.id
output appServiceName string = appService.name
output defaultHostName string = appService.properties.defaultHostName

Security Best Practices

Network Security

1. Private Endpoints: Use for databases, storage, Key Vault
2. Network Segmentation: Separate subnets for app tier, data tier, management
3. NSG Rules: Least-privilege access, document each rule
4. Service Endpoints: Enable for PaaS services when private endpoints aren't available
5. Azure Firewall: Centralize egress traffic control for production

Identity & Access

1. Managed Identities: Always prefer over service principals or keys
2. RBAC: Grant least-privilege roles at appropriate scope
3. Key Vault: Store all secrets, connection strings, certificates
4. Key Rotation: Automate rotation for secrets and certificates
5. Conditional Access: Require MFA for portal/ARM access

Data Protection

1. Encryption at Rest: Enable for all storage (default for most services)
2. Encryption in Transit: Enforce TLS 1.2+ for all connections
3. Backup: Enable automatic backups with appropriate retention
4. Geo-Redundancy: Use for production databases and storage
5. Soft Delete: Enable for Key Vault and Storage Accounts

Azure Security Benchmark (ASB)

Apply relevant ASB controls:

• NS-1: Implement network segmentation boundaries
• NS-2: Secure cloud services with network controls
• PA-7: Use just-in-time network access
• IM-1: Use centralized identity and authentication
• IM-3: Manage application identities securely
• DP-1: Discover, classify, and label sensitive data
• DP-3: Encrypt sensitive data in transit
• LT-1: Enable logging for security investigation

Cost Optimization

Right-Sizing Strategy

1. Start Small: Begin with lower SKUs and scale up based on metrics
2. Reserved Instances: Purchase 1-year or 3-year reservations for stable workloads
3. Auto-Scaling: Configure for App Services and databases
4. Dev/Test Pricing: Use for non-production environments
5. Spot Instances: Consider for fault-tolerant batch workloads

Resource Tiers by Environment

Development:

• App Service: B1 or B2 (Basic tier)
• PostgreSQL: B_Gen5_1 or B_Gen5_2 (Burstable)
• Redis: C0 or C1 (Basic)

Test:

• App Service: S1 (Standard tier)
• PostgreSQL: GP_Gen5_2 (General Purpose)
• Redis: C2 (Standard)

Production:

• App Service: P1v3 or P2v3 (Premium v3 with zone redundancy)
• PostgreSQL: GP_Gen5_4 or MO_Gen5_4 (General Purpose or Memory Optimized)
• Redis: P1 (Premium with persistence and clustering)

Cost Monitoring

// Add budget alerts
resource budget 'Microsoft.Consumption/budgets@2023-05-01' = {
  name: 'budget-${workloadName}-${environment}'
  properties: {
    category: 'Cost'
    amount: 5000  // Monthly budget
    timeGrain: 'Monthly'
    notifications: {
      'Actual_GreaterThan_80_Percent': {
        enabled: true
        operator: 'GreaterThan'
        threshold: 80
        contactEmails: ['platform-team@merkle.com']
      }
    }
  }
}

High Availability & Disaster Recovery

Availability Zones

Enable for production resources (West Europe supports AZs):

• App Service: Premium v3 tier with zone redundancy
• PostgreSQL Flexible Server: Zone-redundant HA
• Redis Cache: Premium tier with zone redundancy

Backup Strategy

Resource	Backup Method	Retention	RPO	RTO
PostgreSQL	Automated backups	35 days	5 min	30 min
Redis	RDB persistence	24 hours	15 min	1 hour
Blob Storage	Soft delete + versioning	30 days	Immediate	15 min
Key Vault	Soft delete + purge protection	90 days	Immediate	Immediate

Multi-Region Considerations

For critical workloads requiring geo-redundancy:

• Primary Region: West Europe (westeurope)
• Secondary Region: North Europe (northeurope)
• Traffic Manager: DNS-based failover with health probes
• Geo-Replication: Enable for PostgreSQL and Storage Accounts

Monitoring & Observability

Application Insights Configuration

resource appInsights 'Microsoft.Insights/components@2020-02-02' = {
  name: 'appi-${workloadName}-${environment}-weu-${instance}'
  location: location
  kind: 'web'
  properties: {
    Application_Type: 'web'
    WorkspaceResourceId: logAnalyticsWorkspace.id
    IngestionMode: 'LogAnalytics'
    RetentionInDays: environment == 'prod' ? 90 : 30
    DisableIpMasking: false  // GDPR compliance
  }
}

Diagnostic Settings

Enable for all resources:

• Send logs to Log Analytics Workspace
• Archive to Storage Account for long-term retention
• Create alerts for critical errors and performance thresholds

Key Metrics to Monitor

• App Service: CPU, Memory, Response Time, HTTP errors
• PostgreSQL: Connections, CPU, Storage, Query performance
• Redis: Cache hit ratio, Memory usage, Connections
• Application: Request rate, Failure rate, Dependency failures

Deployment Best Practices

Pre-Deployment Validation

# Validate Bicep syntax
az bicep build --file main.bicep

# Lint for best practices
az bicep lint --file main.bicep

# Run what-if analysis
az deployment sub what-if \
  --location westeurope \
  --template-file main.bicep \
  --parameters parameters/prod.bicepparam

Deployment Strategy

1. Dev First: Test all changes in dev environment
2. Blue-Green: Use deployment slots for App Services
3. Incremental Mode: Default for safety (never use Complete mode without extreme caution)
4. Change Windows: Schedule production deployments during off-peak hours
5. Rollback Plan: Document rollback procedure for each deployment

CI/CD Integration

# Azure Pipelines example
- task: AzureCLI@2
  inputs:
    azureSubscription: 'Production'
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    inlineScript: |
      az deployment sub create \
        --location westeurope \
        --template-file infrastructure/bicep/main.bicep \
        --parameters infrastructure/bicep/parameters/prod.bicepparam \
        --what-if  # Remove for actual deployment

Compliance & Governance

Azure Policy

Enforce organizational standards:

• Allowed locations (West Europe, North Europe)
• Required tags (Environment, Project, Owner)
• Allowed resource types
• Mandatory encryption
• Network restrictions

Resource Locks

// Prevent accidental deletion in production
resource deleteLock 'Microsoft.Authorization/locks@2020-05-01' = if (environment == 'prod') {
  name: 'DoNotDelete'
  scope: resourceGroup()
  properties: {
    level: 'CanNotDelete'
    notes: 'Prevent accidental deletion of production resources'
  }
}

Quick Decision Tree

Choosing Region:

• Default: West Europe (GDPR-compliant, low latency for EU)
• Data residency requirements? → Specific region required
• Multi-region HA? → West Europe + North Europe

Choosing SKU:

• Development? → Basic tier
• Test? → Standard tier
• Production (<100 users)? → Standard/General Purpose tier
• Production (>100 users)? → Premium tier with zone redundancy

Network Security:

• Internet-facing? → Public endpoint + NSG + WAF
• Internal only? → Private endpoint + service endpoint
• Hybrid connectivity? → VPN Gateway or ExpressRoute

Additional Resources

• Azure Naming Conventions
• Azure Security Benchmark
• Bicep Best Practices
• Cost Optimization

For detailed examples and reference architectures, see references/.