// Example decision matrix:
IaaS: Legacy .NET app migration, custom networking
PaaS: Modern web app, need auto-scaling
SaaS: CRM, email, productivity tools

// Real example:
E-commerce Platform:
- IaaS: Payment processing (compliance requirements)
- PaaS: Web frontend and APIs (rapid deployment)
- SaaS: Email marketing, customer support

// Global Architecture:
US East (Primary): Full stack + primary database
EU West: Full stack + regional database (GDPR)
Asia Pacific: Full stack + regional database

// Traffic Routing:
- Route 53/Traffic Manager: Latency-based routing
- CloudFront/CDN: Static content globally cached
- Application Load Balancer: Regional traffic distribution

// Data Strategy:
- User profiles: Replicated globally (eventual consistency)
- Orders: Regional with cross-region backup
- Inventory: Global with regional caching
- Payment data: Encrypted, region-specific storage

// Disaster Recovery:
- RTO: < 15 minutes (automated failover)
- RPO: < 1 minute (synchronous replication for critical data)

// Decision Framework:
Public Cloud:
✓ Modern applications, web-scale workloads
✓ Startups to mid-size companies
✓ Development and testing environments

Private Cloud:
✓ Financial services (trading systems)
✓ Healthcare (PHI data)
✓ Government (classified workloads)

Hybrid Cloud:
✓ Large enterprises with legacy systems
✓ Gradual cloud migration strategy
✓ Bursting to public cloud for peak loads

// Cloud-Native Characteristics:
- Microservices architecture
- Containerized deployment (Docker, Kubernetes)
- DevOps and CI/CD pipelines
- Infrastructure as Code
- Auto-scaling and self-healing
- Event-driven, asynchronous communication

// Example Transformation:
Cloud-Enabled (Lift & Shift):
[Monolith App] => [EC2 Instance]

Cloud-Native (Rearchitected):
[API Gateway] => [Lambda Functions] => [DynamoDB]
                            ↓
                      [SQS/SNS Events]

// Multi-Cloud Strategy Example:
AWS: Primary compute, storage, AI/ML services
Azure: Microsoft ecosystem integration, AD
GCP: Data analytics, BigQuery, AI Platform
On-premise: Legacy systems, sensitive data

// Architecture Principles:
- Kubernetes for container orchestration
- Terraform for infrastructure provisioning
- Prometheus/Grafana for monitoring
- GitOps for deployment automation

// Service Mapping:
Compute: AWS EC2, Azure VMs, GCP Compute Engine
Storage: AWS S3, Azure Blob, GCP Cloud Storage
Databases: Managed services per cloud
Networking: VPN/ExpressRoute connections

// Pattern 1: Event Sourcing + CQRS
AWS: Event Store (DynamoDB) + Kinesis
Azure: Event Hubs + Cosmos DB views
GCP: Pub/Sub + BigQuery analytics

// Pattern 2: Master-Slave Replication
Primary: AWS RDS (master)
Secondary: Azure SQL (read replica)
Tertiary: GCP Cloud SQL (backup)

// Pattern 3: Domain-Based Segregation
User Service: AWS (low latency)
Inventory: GCP (analytics capabilities)
Payments: Azure (compliance tools)

// Consistency Guarantees:
- Strong: Within single cloud/region
- Eventual: Cross-cloud synchronization
- Conflict Resolution: Last-writer-wins or manual

// Database Selection Based on CAP:

CP (Consistency + Partition Tolerance):
- MongoDB, Redis Cluster
- Use case: Financial transactions, inventory
- Trade-off: May be unavailable during splits

AP (Availability + Partition Tolerance):
- Cassandra, DynamoDB, CosmosDB
- Use case: User profiles, content management
- Trade-off: Eventual consistency

CA (Consistency + Availability):
- Traditional RDBMS (MySQL, PostgreSQL)
- Use case: Single-region applications
- Trade-off: No network partition handling

// Cloud Service Examples:
AWS:
- RDS (CA): Traditional applications
- DynamoDB (AP): High-scale web apps
- DocumentDB (CP): Document storage

Azure:
- SQL Database (CA): Enterprise apps
- Cosmos DB (AP): Global distribution

// Core Patterns:

1. Service Discovery:
   - AWS: ELB + Route 53 + ECS Service Discovery
   - Kubernetes: Services + Ingress Controllers

2. API Gateway Pattern:
   - AWS API Gateway + Lambda
   - Kong/Istio for Kubernetes

3. Circuit Breaker:
   - Netflix Hystrix, AWS App Mesh
   - Fail fast, prevent cascade failures

4. Database per Service:
   - Users: PostgreSQL (ACID requirements)
   - Products: DynamoDB (high read volume)
   - Analytics: BigQuery (complex queries)

5. Event-Driven Communication:
   - AWS: SNS/SQS for async messaging
   - Apache Kafka for event streaming

// Example E-commerce Architecture:
API Gateway => [User Service] => User DB
            => [Order Service] => Order DB
            => [Inventory] => Inventory DB

Events: Order.Created => Inventory.Reserved

// Zero-Trust Components:

Identity & Access:
- AWS Cognito + OIDC/SAML federation
- Azure AD + Conditional Access policies
- Multi-factor authentication required

Network Security:
- Private subnets, no direct internet access
- WAF for application layer protection
- VPC/VNet peering with strict NACLs

Service-to-Service:
- mTLS for all communication
- AWS IAM roles, not hardcoded keys
- Service mesh (Istio) with automatic TLS

Data Protection:
- Encryption at rest (KMS/Key Vault)
- Encryption in transit (TLS 1.3+)
- Field-level encryption for PII

// Implementation Example:
[User] => [WAF] => [API Gateway + JWT]
                  => [Microservice + IAM Role]
                  => [Encrypted Database]

// GDPR Compliance Architecture:
Data Classification:
- PII: Separate encrypted storage
- Consent management: Audit trail required
- Right to erasure: Automated deletion workflows

Regional Boundaries:
- EU data stays in EU regions
- Cross-border transfers with SCCs
- Data residency validation

// HIPAA (Healthcare):
- BAA with cloud providers required
- Encrypted PHI at rest and transit
- Access logging and monitoring
- Automatic PHI discovery and tagging

// PCI-DSS (Payment Data):
- Cardholder data environment (CDE) isolation
- Network segmentation, no flat networks
- Quarterly vulnerability scans
- Secure key management (HSM)

// Implementation Pattern:
Data Discovery => Classification => Protection
                                => Monitoring => Auditing

// IAM Best Practices:

1. Principle of Least Privilege:
   - Grant minimum required permissions
   - Use managed policies, avoid inline
   - Regular access reviews and cleanup

2. Role-Based Access (RBAC):
   - Job function-based roles
   - Temporary elevated access
   - Just-in-time (JIT) permissions

3. Multi-Factor Authentication:
   - Required for all human users
   - Hardware tokens for privileged accounts
   - SMS as backup only

4. Service Accounts:
   - Use roles, not users for applications
   - Rotate credentials automatically
   - Scope permissions to specific resources

// Example AWS IAM Strategy:
Developers: ReadOnly + specific dev resources
DevOps: Infrastructure management roles
Applications: Cross-service roles
Administrators: Break-glass emergency access

// Secure CI/CD Pipeline:

Source Stage:
- Code signing and verification
- Dependency vulnerability scanning
- Secrets detection (TruffleHog, GitLeaks)

Build Stage:
- SAST (Static Analysis Security Testing)
- Container image scanning (Clair, Twistlock)
- Infrastructure as Code validation

Test Stage:
- DAST (Dynamic Application Security Testing)
- Security regression tests
- Compliance policy validation

Deploy Stage:
- Immutable infrastructure deployment
- Zero-downtime blue/green deployments
- Automated rollback on security failures

Monitor Stage:
- Runtime security monitoring
- Compliance drift detection
- Threat intelligence integration

// Example Implementation:
GitHub => [Security Scan] => CodeBuild
      => [Image Scan] => ECR
      => [Deploy] => ECS/EKS
      => [Monitor] => GuardDuty

// Cost Optimization Framework:

1. Visibility & Tagging:
   - Resource tagging strategy (Environment, Owner, Project)
   - Cost allocation by business unit
   - Real-time cost monitoring dashboards

2. Right-Sizing & Scaling:
   - Auto-scaling based on metrics
   - Scheduled scaling for predictable workloads
   - Reserved instances for steady-state
   - Spot instances for fault-tolerant workloads

3. Storage Optimization:
   - S3 Intelligent Tiering
   - Lifecycle policies (Standard -> IA -> Glacier)
   - Data deduplication and compression

4. Serverless First:
   - Lambda instead of always-on servers
   - Pay-per-request pricing model
   - Auto-scaling without capacity planning

// Example Savings:
Production: Reserved Instances (40-60% savings)
Development: Spot Instances (70-90% savings)
Storage: Intelligent Tiering (20-30% savings)
Compute: Right-sizing (25-50% savings)

// Cost Comparison Analysis:

Serverless (Lambda, Cloud Functions):
- Pay per execution (100ms increments)
- No idle costs, perfect for sporadic workloads
- Higher per-request cost at scale
- Cold start latency costs

Containers (ECS, GKE, AKS):
- Pay for allocated resources (even if idle)
- Lower per-request costs at high volume
- Predictable pricing with reserved capacity
- More control over runtime environment

// Decision Matrix:
Use Serverless when:
✓ Sporadic, event-driven workloads
✓ Traffic with high variance
✓ Quick prototyping and development
✓ <15 minute execution time

Use Containers when:
✓ Consistent, high-volume traffic
✓ Long-running processes
✓ Custom runtime requirements
✓ Microservices with steady load

// Break-even Analysis:
Traffic < 1M requests/month: Serverless wins
Traffic > 10M requests/month: Containers win

// Cost Control Implementation:

1. Budget Alerts:
   - AWS Budgets with SNS notifications
   - Azure Cost Management alerts
   - GCP Budget notifications

2. Automated Actions:
   - Stop non-production instances outside hours
   - Scale down development environments
   - Delete untagged resources after 7 days
   - Snapshot and terminate unused volumes

3. Policy Enforcement:
   - Service Control Policies (SCPs)
   - Prevent expensive instance types
   - Require approval for high-cost resources

4. Cost Anomaly Detection:
   - Machine learning-based alerts
   - Unusual spending pattern detection
   - Root cause analysis automation

// Example Automation:
if cost_increase > 20% and environment == "dev":
    send_alert_to_team()
    scale_down_non_critical_services()

if untagged_resource.age > 7_days:
    tag_for_deletion()
    notify_owner()

// Cloud Pricing Models:

1. On-Demand:
   - Pay as you go, no commitment
   - Optimization: Auto-scaling, scheduled shutdown
   - Best for: Variable workloads, development

2. Reserved Instances:
   - 1-3 year commitment, 40-75% discount
   - Optimization: Right-size before purchasing
   - Best for: Steady-state production workloads

3. Spot Instances:
   - Bid on spare capacity, up to 90% discount
   - Optimization: Fault-tolerant architecture
   - Best for: Batch processing, analytics

4. Savings Plans:
   - Commitment to usage level, flexibility
   - Optimization: Compute Savings Plans for variety
   - Best for: Mixed workload environments

// Optimization Strategy:
Baseline: Reserved Instances (60%)
Variable: On-Demand (25%)
Batch: Spot Instances (15%)

// Portfolio Approach:
Critical Production: Reserved + On-Demand
Development: Spot + On-Demand
Analytics: Spot + Preemptible

// DR Architecture (Active-Passive):

Primary Region (US-East-1):
- Auto Scaling Groups with health checks
- RDS Multi-AZ with synchronous replication
- ELB with health check endpoints
- Route 53 health check monitoring

DR Region (US-West-2):
- Warm standby infrastructure (scaled down)
- RDS Read Replica with automated promotion
- S3 Cross-Region Replication (CRR)
- Lambda functions for automated failover

// Failover Process:
1. Route 53 detects primary region failure (30s)
2. DNS switches to DR region automatically
3. Lambda promotes RDS read replica (2-5 min)
4. Auto Scaling scales up DR infrastructure (3-5 min)
5. Application validates data consistency

// RTO/RPO Breakdown:
Detection: 30 seconds
DNS Propagation: 1-2 minutes
Database Promotion: 2-5 minutes
Infrastructure Scale-up: 3-5 minutes
Total RTO: 6-12 minutes
RPO: 5-15 minutes (replication lag)

// 99.99% Architecture Principles:

1. No Single Points of Failure:
   - Multi-AZ deployment (99.5% -> 99.95%)
   - Load balancers with health checks
   - Database clustering or managed services
   - CDN for static content delivery

2. Fault Isolation:
   - Circuit breakers between services
   - Bulkhead pattern for resource isolation
   - Graceful degradation (core features work)
   - Timeout and retry with exponential backoff

3. Automated Recovery:
   - Auto Scaling Groups replace failed instances
   - Database automated backup and restore
   - Infrastructure as Code for rapid rebuild
   - Blue/Green deployments with instant rollback

4. Operational Excellence:
   - Comprehensive monitoring and alerting
   - Runbook automation (no human dependency)
   - Chaos engineering to find weaknesses
   - Change management with gradual rollout

// Availability Calculation:
Load Balancer: 99.99%
Compute (Multi-AZ): 99.95%
Database (Multi-AZ): 99.95%
Overall: 99.89% (still need more redundancy)

// Backup Strategy Comparison:

1. Snapshot-based (Basic):
   - EBS snapshots, VM snapshots
   - RTO: 10-30 minutes, RPO: Hours
   - Cost: Low (storage only)
   - Use case: Development, non-critical apps

2. Continuous Replication:
   - AWS DMS, Azure Site Recovery
   - RTO: 5-15 minutes, RPO: <1 minute
   - Cost: Medium (compute + storage)
   - Use case: Production databases

3. Multi-Region Active-Passive:
   - Cross-region read replicas
   - RTO: 2-10 minutes, RPO: <1 minute
   - Cost: High (duplicate infrastructure)
   - Use case: Mission-critical applications

4. Multi-Region Active-Active:
   - Global database replication
   - RTO: 0 (transparent), RPO: Minimal
   - Cost: Very High (full duplication)
   - Use case: Global applications, 24/7 uptime

// Implementation Example:
Critical Data: Multi-region replication
Application Data: Cross-region snapshots
Logs & Analytics: Single region with backup
Development: Local snapshots only

// Global Load Balancing Architecture:

DNS Layer (Global):
- Route 53 with latency-based routing
- Health checks for each region
- Weighted routing for gradual rollouts

Application Layer (Regional):
- AWS ALB, Azure Application Gateway
- Regional health checks and auto-scaling
- SSL termination and WAF protection

// Routing Strategies:

1. Latency-based:
   - Route to closest healthy region
   - Best user experience
   - May cause uneven load distribution

2. Geographic:
   - Route based on user location
   - Compliance requirements (GDPR)
   - Predictable traffic distribution

3. Weighted:
   - Manual traffic splitting
   - Blue/green deployments
   - Gradual feature rollouts

4. Health-based:
   - Automatic failover on region failure
   - Health check dependencies
   - Graceful degradation

// Example Configuration:
Primary (US-East): 60% traffic
Secondary (EU-West): 30% traffic
Tertiary (AP-Southeast): 10% traffic
Failover: Healthy regions absorb failed region

// IaC Tool Comparison:

Terraform:
✓ Multi-cloud support (AWS, Azure, GCP)
✓ Rich provider ecosystem
✓ State management and drift detection
✓ Plan before apply (preview changes)
- Requires separate state management
- Learning curve for HCL syntax

CloudFormation:
✓ Native AWS integration
✓ Automatic rollback on failure
✓ Stack-based resource management
✓ No additional state management
- AWS only, no multi-cloud
- Verbose YAML/JSON syntax

ARM Templates (Azure):
✓ Native Azure integration
✓ Resource dependency resolution
✓ Integrated with Azure DevOps
- Azure only
- Complex nested template syntax

// Decision Matrix:
Multi-cloud architecture: Terraform
AWS-only environment: CloudFormation
Azure-heavy environment: ARM Templates
Team new to IaC: CloudFormation (easier)

// GitOps Architecture:

Git Repository Structure:
├── environments/
│   ├── dev/
│   │   ├── terraform/
│   │   └── k8s/
│   ├── staging/
│   └── prod/
├── modules/
│   ├── networking/
│   ├── compute/
│   └── database/

// Deployment Flow:
1. Developer creates PR with infrastructure changes
2. CI pipeline runs terraform plan/validate
3. PR review + approval process
4. Merge triggers deployment to target environment
5. ArgoCD/Flux syncs infrastructure state
6. Monitoring validates successful deployment

// Example Implementation:
GitHub → GitHub Actions → Terraform Cloud
      → ArgoCD → Kubernetes Clusters
      → Monitoring → Slack notifications

// Benefits:
- Declarative infrastructure definition
- Full audit trail of infrastructure changes
- Automatic drift detection and correction
- Easy rollback to previous known state

// Secrets Management Strategies:

1. External Secret Stores:
   - AWS Secrets Manager / Parameter Store
   - Azure Key Vault
   - HashiCorp Vault
   - Google Secret Manager

2. IaC Integration:
   // Terraform example:
   data "aws_secretsmanager_secret_version" "db_password" {
     secret_id = "prod/database/password"
   }

   resource "aws_db_instance" "main" {
     password = data.aws_secretsmanager_secret_version.db_password.secret_string
   }

3. Runtime Injection:
   - Kubernetes secrets from external stores
   - AWS IAM roles for service accounts
   - Azure Workload Identity
   - GCP Workload Identity

4. Secret Rotation:
   - Automated rotation policies
   - Application restart coordination
   - Zero-downtime secret updates

// Anti-patterns to Avoid:
❌ Hardcoded secrets in IaC files
❌ Environment variables in CI/CD
❌ Secrets in container images
❌ Shared secrets across environments

// Infrastructure Testing Pyramid:

1. Static Analysis:
   - Terraform validate, plan
   - Checkov for security compliance
   - tflint for best practices
   - Cost estimation (Infracost)

2. Unit Tests:
   - Terratest for Terraform modules
   - Test individual components in isolation
   - Mock external dependencies

3. Integration Tests:
   - Deploy to ephemeral test environment
   - Test component interactions
   - Validate network connectivity

4. End-to-End Tests:
   - Full application deployment
   - Synthetic user journeys
   - Performance and load testing

5. Compliance Tests:
   - Security policy validation
   - Cost threshold checks
   - Disaster recovery validation

// Example CI/CD Integration:
PR Creation → Static Analysis
           → Unit Tests
           → Deploy Test Environment
           → Integration Tests
           → Security Scans
           → Compliance Checks
           → Manual Approval
           → Production Deploy

// Migration Strategy (Strangler Fig Pattern):

Phase 1: Assessment & Planning (2-4 weeks):
- Application discovery and dependency mapping
- Performance baseline and SLA requirements
- Security and compliance requirements analysis
- Cost analysis and business case

Phase 2: Lift & Shift (2-3 months):
- Rehost critical components to cloud
- Minimal code changes, focus on stability
- Database migration with minimal downtime
- Validate functionality and performance

Phase 3: Re-platform (6-12 months):
- Containerize applications
- Move to managed services (RDS, managed Kubernetes)
- Implement cloud-native monitoring and logging
- Optimize for cloud cost and performance

Phase 4: Re-architect (12+ months):
- Extract microservices from monolith
- Implement event-driven architecture
- Serverless for appropriate workloads
- Full cloud-native transformation

// Risk Mitigation:
- Blue/green deployment for cutover
- Database replication for zero-downtime migration
- Rollback plan for each phase
- Extensive testing in staging environment

// Cost Investigation Playbook:

1. Immediate Assessment (0-30 minutes):
   - Check AWS Cost Explorer for service breakdown
   - Identify top cost services and resources
   - Look for resource creation spikes
   - Check for unusual data transfer costs

2. Resource Analysis (30-60 minutes):
   - List all resources created in last 24-48 hours
   - Identify untagged or orphaned resources
   - Check for auto-scaling events gone wrong
   - Verify spot instance interruptions causing scale-up

3. Common Culprits:
   - Auto Scaling Group misconfiguration
   - Runaway Lambda functions
   - Large data processing jobs
   - Database connection leaks causing scaling
   - Accidental large EC2 instance launches

4. Immediate Actions:
   - Stop/terminate unnecessary resources
   - Modify auto-scaling policies
   - Set up billing alerts for future
   - Contact AWS support for analysis

// Investigation Commands:
aws ec2 describe-instances --query 'Reservations[*].Instances[*].[InstanceId,LaunchTime,InstanceType]'
aws logs describe-log-groups --query 'logGroups[*].[logGroupName,storedBytes]'
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=RunInstances

// Zero-Downtime Migration Strategy:

Phase 1: Setup Replication
- AWS DMS or Azure Database Migration Service
- Setup source and target databases
- Initial data load during low-traffic period
- Continuous replication of changes

Phase 2: Validation & Testing
- Data consistency validation scripts
- Performance testing on cloud database
- Application testing with read replicas
- Rollback procedure validation

Phase 3: Cutover Preparation
- Application deployment with database switching capability
- DNS/load balancer reconfiguration scripts
- Monitoring and alerting setup
- Team coordination and communication plan

Phase 4: Execution (5-15 minutes)
1. Enable maintenance page (optional)
2. Stop application writes to source DB
3. Wait for replication lag to reach zero
4. Switch application to cloud database
5. Validate data and application functionality
6. Update DNS/load balancer configuration
7. Remove maintenance page

// Rollback Plan:
- Reverse replication setup (cloud to on-premise)
- Application configuration rollback
- DNS rollback capability
- Data consistency validation

// Troubleshooting Methodology:

1. Stabilize (0-15 minutes):
   - Implement circuit breakers if not already present
   - Scale out healthy regions to handle traffic
   - Enable detailed monitoring and logging
   - Gather initial data on failure patterns

2. Observe & Correlate (15-45 minutes):
   - Analyze error rates, latency patterns
   - Check infrastructure metrics (CPU, memory, network)
   - Review application logs for error patterns
   - Cross-reference with recent deployments

3. Hypothesize & Test:
   - Network connectivity issues between regions
   - Database replication lag causing inconsistency
   - Load balancer health check failures
   - Shared resource contention (API rate limits)
   - Recent configuration changes

4. Investigation Tools:
   - AWS X-Ray for distributed tracing
   - CloudWatch Insights for log analysis
   - Route 53 health check history
   - VPC Flow Logs for network analysis

// Common Multi-Region Issues:
- DNS propagation delays
- Cross-region network latency spikes
- Database connection pool exhaustion
- Shared service rate limiting
- Clock synchronization issues