496 lines
25 KiB
Markdown
496 lines
25 KiB
Markdown
# ☁️ Cloud Architecture
|
|
|
|
## Providers
|
|
|
|
- **AWS** — largest market share, broadest portfolio
|
|
- **Azure** — strong integration with Microsoft ecosystem
|
|
- **GCP** — Kubernetes (GKE), data & ML, network connectivity
|
|
|
|
## Deployment Models
|
|
|
|
| Model | Description |
|
|
|-------|-------------|
|
|
| Public cloud | Shared provider infrastructure |
|
|
| Private cloud | Dedicated infrastructure (on-prem or hosted) |
|
|
| Hybrid cloud | Public + private interconnection |
|
|
| Multi-cloud | Multiple public providers |
|
|
|
|
## Multi-cloud Strategy
|
|
|
|
### Reasons for Multi-cloud
|
|
- **Vendor lock-in prevention** — risk diversification
|
|
- **Regulatory requirements** — data residency in specific regions
|
|
- **Best-of-breed** — each provider has strengths (AWS networking, Azure enterprise, GCP data/ML)
|
|
- **Acquisition scenarios** — merge & acquisition unification
|
|
|
|
### Multi-cloud Connectivity
|
|
|
|
| Method | Latency | Throughput | Cost |
|
|
|--------|---------|------------|------|
|
|
| Site-to-Site VPN | Medium | Limited | Low |
|
|
| Private interconnect (Direct Connect / ExpressRoute / Dedicated Interconnect) | Low | High | High |
|
|
| Cloud-to-cloud VPN | Medium | Medium | Medium |
|
|
| SD-WAN | Low | High | Medium |
|
|
|
|
### Challenges
|
|
- **Network complexity** — different VPC/VNet concepts, security models
|
|
- **IAM federation** — unified identities across clouds (SSO, SAML, OIDC)
|
|
- **Data gravity** — moving data between clouds is expensive and slow
|
|
- **Monitoring** — single pane of glass across clouds (Grafana, Datadog)
|
|
|
|
### Cloud Adoption Frameworks (CAF)
|
|
|
|
Each major provider has its own Cloud Adoption Framework for a structured approach to cloud adoption:
|
|
|
|
| Provider | Framework | Focus |
|
|
|----------|-----------|-------|
|
|
| AWS | AWS CAF | 6 perspectives: Business, People, Governance, Platform, Security, Operations |
|
|
| Azure | Microsoft CAF | 8 methodologies: Strategy, Plan, Ready, Migrate, Innovate, Govern, Manage, Secure |
|
|
| GCP | Google CAF | 4 pillars: Learn, Scale, Modernize, Operate |
|
|
|
|
Multi-Cloud Administration Guide (Mulder, 2024) recommends combining CAF frameworks across providers for unified governance models, especially in:
|
|
- **Interoperability** — standardization of APIs and IaC across clouds (Terraform, Pulumi)
|
|
- **Data governance** — unified policy for data residency and lifecycle
|
|
- **Compliance automation** — automated audits across clouds (AWS Config, Azure Policy, GCP Org Policies)
|
|
- **Access management** — identity federation and centralized RBAC
|
|
|
|
## Migration Strategies — 6 Rs
|
|
|
|
| Strategy | Description | Difficulty | Typical Scenario |
|
|
|----------|-------------|------------|------------------|
|
|
| **Rehost** (Lift & Shift) | Move VM/as-is without changes | Low | Quick migration, datacenter exit, minimal risk |
|
|
| **Replatform** (Lift & Reshape) | Migration with minor adjustments (e.g., RDS instead of self-managed DB) | Medium | Optimization without rewriting the application |
|
|
| **Refactor** (Re-architect) | Rewrite application as cloud-native (microservices, serverless) | High | Maximize cloud benefit, long-term strategy |
|
|
| **Repurchase** | Move to SaaS (e.g., Salesforce, Workday) | Low | Application is outdated, SaaS alternative exists |
|
|
| **Retire** | Decommission unused applications | Low | Application no longer in use |
|
|
| **Retain** | Keep on-prem | None | Regulatory reasons, too high migration risk |
|
|
|
|
### Decision Framework for 6 Rs
|
|
|
|
```
|
|
Start: Is the application needed?
|
|
├── No → Retire
|
|
└── Yes → Does a SaaS alternative exist?
|
|
├── Yes → Repurchase
|
|
└── No → Is refactoring worthwhile?
|
|
├── Yes → Refactor
|
|
└── No → Is platform change sufficient?
|
|
├── Yes → Replatform
|
|
└── No → Rehost
|
|
```
|
|
|
|
## Well-Architected Framework (AWS)
|
|
|
|
1. **Operational Excellence** — automation, monitoring, documentation
|
|
2. **Security** — IAM, encryption, compliance
|
|
3. **Reliability** — recovery, scaling, backup plans
|
|
4. **Performance Efficiency** — right-sizing, choosing the right services
|
|
5. **Cost Optimization** — FinOps, reserved instances, spot instances
|
|
6. **Sustainability** (since 2022) — carbon footprint, energy efficiency
|
|
|
|
Analogues: Azure Well-Architected Framework, GCP Architecture Framework
|
|
|
|
### Key Questions from Well-Architected Review (~60 questions)
|
|
|
|
**Operational Excellence (12 questions)**
|
|
- How are changes managed and automated?
|
|
- How are operations documented and shared within the team?
|
|
- How are expected and unexpected events reflected in operations?
|
|
- What runbooks exist for common operational scenarios?
|
|
- How is incident management and postmortem process conducted?
|
|
|
|
**Security (12 questions)**
|
|
- How is identity & access management implemented?
|
|
- How is data protected at rest and in transit?
|
|
- How is security incident detection ensured?
|
|
- What are the procedures for patch management and vulnerability remediation?
|
|
- How are infrastructure credentials and secrets managed?
|
|
|
|
**Reliability (12 questions)**
|
|
- How is service availability ensured during a component failure?
|
|
- How is backup and disaster recovery implemented?
|
|
- How do service limits (quotas, throttling) affect reliability?
|
|
- How does automatic scaling work under changing load?
|
|
- What are the SLI/SLO metrics and how are they monitored?
|
|
|
|
**Performance Efficiency (12 questions)**
|
|
- How is the correct type and size of compute/storage selected?
|
|
- How is the database layer optimized (indexes, queries, caching)?
|
|
- How is monitoring used to identify bottlenecks?
|
|
- How is scaling implemented (vertical vs horizontal)?
|
|
|
|
**Cost Optimization (12 questions)**
|
|
- How are costs allocated to teams/projects (chargeback/showback)?
|
|
- What tools are used for cost analysis?
|
|
- How are unused resources identified and eliminated?
|
|
- How is licensing optimized (BYOL, hybrid benefit)?
|
|
|
|
## Key Components
|
|
|
|
### Compute Layer
|
|
|
|
- **VM / instances** — EC2, Azure VMs, GCE
|
|
- **Container orchestration** — EKS, AKS, GKE
|
|
- **Serverless** — Lambda, Azure Functions, Cloud Functions
|
|
- **PaaS** — App Engine, Elastic Beanstalk, Azure App Service
|
|
|
|
### Compute Comparison Matrix (AWS EC2)
|
|
|
|
| Family | Type | vCPU:Memory | Use Case | Example Pricing (on-demand, us-east-1) |
|
|
|--------|------|-------------|----------|----------------------------------------|
|
|
| **General purpose** | M7g, m7i | 1:4 | Web servers, microservices, dev/test | m7i.large ~$0.088/h |
|
|
| **Compute optimized** | C7g, c7i | 1:2 | HPC, batch processing, CI/CD, gaming | c7i.large ~$0.078/h |
|
|
| **Memory optimized** | R7g, r7i, x2idn | 1:8 to 1:32 | In-memory DB (Redis), SAP HANA, real-time analytics | r7i.large ~$0.118/h |
|
|
| **Storage optimized** | I4i, im4gn | 1:4 + NVMe | Transactional DB, data warehousing, Kafka | i4i.large ~$0.138/h |
|
|
| **GPU / ML** | P5, g5, trn1 | GPU attach | AI training (P5), inference (g5), ML (trn1) | g5.xlarge ~$1.006/h |
|
|
|
|
See [GPU.md](GPU.md) for GPU model and configuration details.
|
|
|
|
### Storage
|
|
|
|
- **Object storage** — S3, Blob Storage, Cloud Storage
|
|
- **Block storage** — EBS, managed disks, persistent disks
|
|
- **File storage** — EFS, Azure Files, Filestore
|
|
- **CDN** — CloudFront, Azure CDN, Cloud CDN
|
|
|
|
### S3 Storage Classes
|
|
|
|
| Class | Availability | Retrieval Time | Price / GB / Month | Use Case |
|
|
|-------|-------------|----------------|--------------------|----------|
|
|
| **S3 Standard** | 99.99 % | milliseconds | ~$0.023 | Active data, frequent access |
|
|
| **S3 Intelligent-Tiering** | 99.9 % | milliseconds | ~$0.023 + monitoring fee | Unknown/variable access patterns |
|
|
| **S3 Standard-IA** | 99.9 % | milliseconds | ~$0.0125 | Less frequent but fast access |
|
|
| **S3 One Zone-IA** | 99.5 % | milliseconds | ~$0.01 | Reproducible data |
|
|
| **S3 Glacier Instant** | 99.9 % | milliseconds | ~$0.004 | Archive with occasional access |
|
|
| **S3 Glacier Flexible** | 99.99 % | 1-5 min (expedite) / 3-5 h (standard) | ~$0.0036 | Long-term archive |
|
|
| **S3 Glacier Deep Archive** | 99.99 % | 12 h (standard) / 48 h (bulk) | ~$0.00099 | Cheapest, compliance archives |
|
|
|
|
## Multi-AZ and Multi-Region Architecture
|
|
|
|
```
|
|
Region ┌──────────────────────────────┐
|
|
│ AZ-1 AZ-2 AZ-3 │
|
|
│ ┌───┐ ┌───┐ ┌───┐ │
|
|
│ │APP│──────│APP│──────│APP│ │
|
|
│ └─┬─┘ └─┬─┘ └─┬─┘ │
|
|
│ │ │ │ │
|
|
│ ┌─▼──────────▼──────────▼─┐ │
|
|
│ │ Load Balancer │ │
|
|
│ └────────────┬────────────┘ │
|
|
│ │ │
|
|
│ ┌────────────▼────────────┐ │
|
|
│ │ Database (Primary) │ │
|
|
│ │ + Read Replica │ │
|
|
│ └─────────────────────────┘ │
|
|
└──────────────────────────────┘
|
|
```
|
|
|
|
## Disaster Recovery Strategies
|
|
|
|
### DR Strategies on AWS (from least to most prepared)
|
|
|
|
| Strategy | RTO | RPO | Cost | Description |
|
|
|----------|-----|-----|------|-------------|
|
|
| **Backup & Restore** | hours | 24 h | Low | Regular data backups to S3/Glacier, restore in DR region |
|
|
| **Pilot Light** | tens of minutes | minutes | Medium | Minimal running copy (DB, core services), scale on failover |
|
|
| **Warm Standby** | minutes | seconds | High | Reduced production copy running, scale on failover |
|
|
| **Active-Active (Multi-Region)** | seconds | < 1 s | Very high | Fully active in multiple regions, traffic routing (Route53, Global Accelerator) |
|
|
|
|
Key books on the topic:
|
|
- **Engineering Resilient Systems on AWS** (Schwarz, Moran, Bachmeier, 2024) — practical labs for resilience patterns: back off and retry, multi-Region failover, circuit breaker, chaos engineering using AWS Fault Injection Simulator
|
|
- **Building Resilient Architectures on AWS** (2025) — data security, backup strategies, recovery plan automation
|
|
|
|
### Chaos Engineering
|
|
|
|
Deliberate fault injection to verify system resilience:
|
|
- **AWS Fault Injection Simulator (FIS)** — managed fault injection for EC2, ECS, EKS, RDS
|
|
- **Tools**: Chaos Mesh (Kubernetes), Gremlin, Litmus
|
|
- **Process**: define hypothesis → run experiment → measure impact → improve system
|
|
- **Safety**: experiments in isolated environment, safety controls, automatic rollback
|
|
|
|
## Cloud Design Patterns
|
|
|
|
### Strangler Fig
|
|
Gradually replacing parts of a monolithic application with microservices.
|
|
- Legacy functionality is progressively redirected to new services
|
|
- Strangler Fig proxy (route headers, feature flags) controls traffic migration
|
|
- Advantage: incremental value delivery without big-bang rewrite
|
|
|
|
### Circuit Breaker
|
|
Prevents cascading failures when a dependent service fails.
|
|
- Three states: **Closed** (normal operation), **Open** (requests immediately fail), **Half-Open** (test request after timeout)
|
|
- Parameters: failure threshold, timeout (reset timeout), half-open max requests
|
|
- Implementations: resilience4j, Hystrix (legacy), Istio (envoy), AWS App Mesh
|
|
|
|
### Saga
|
|
Distributed transaction across microservices — a series of local transactions with compensating actions.
|
|
- **Choreography** — each service publishes an event, the next service reacts (Kafka, EventBridge)
|
|
- **Orchestration** — central orchestrator manages steps (Step Functions, Temporal, Camunda)
|
|
|
|
### CQRS (Command Query Responsibility Segregation)
|
|
Separation of write (Command) and read (Query) models.
|
|
- Command model: optimized for writes (normalized, transactional)
|
|
- Query model: optimized for reads (denormalized, read-optimized views)
|
|
- Eventual consistency between models (event bus propagates changes)
|
|
- Use case: reporting, audit logs, high-throughput systems
|
|
|
|
### Event Sourcing
|
|
Storing state as a sequence of events, not the current state.
|
|
- Each change is an append-only event in an event store
|
|
- Current state = fold of all events
|
|
- Advantages: audit trail, time travel, CQRS compatibility
|
|
- Implementations: EventStoreDB, Kafka (log), DynamoDB + CDC
|
|
|
|
### Additional Cloud Patterns (Wilder — Cloud Architecture Patterns)
|
|
|
|
| Pattern | Category | Description |
|
|
|---------|----------|-------------|
|
|
| **Horizontally Scaling Compute** | Scalability | Adding/removing instances based on load, elasticity |
|
|
| **Queue-Centric Workflow** | Scalability | Decoupling components via queues (SQS, RabbitMQ), async processing |
|
|
| **Auto-Scaling** | Scalability | Automatic scaling based on metrics (CPU, memory, request count) |
|
|
| **MapReduce** | Big Data | Distributed data processing (Hadoop, EMR, BigQuery) |
|
|
| **Database Sharding** | Big Data | Horizontal data partitioning across databases |
|
|
| **Busy Signal** | Failure Handling | Graceful degradation under overload (HTTP 503, throttling, backpressure) |
|
|
| **Node Failure** | Failure Handling | Detection and automatic recovery from compute node failure |
|
|
| **Colocation** | Distributed Users | Placing compute close to data to reduce latency |
|
|
| **Valet Key** | Distributed Users | Delegated storage access (SAS tokens, S3 presigned URLs) |
|
|
| **Multi-Site Deployment** | Distributed Users | Active deployment in multiple geographic locations |
|
|
|
|
## Evolutionary Architecture
|
|
|
|
Definition (Ford, Parsons, Kua, 2022): *An evolutionary architecture supports guided, incremental change across multiple dimensions.*
|
|
|
|
### Fitness Functions
|
|
|
|
Automated checks of architectural characteristics — analogous to tests for architecture:
|
|
|
|
| Type | Description | Example |
|
|
|------|-------------|---------|
|
|
| **Atomic** | Checks a single metric | Cyclomatic complexity < 10 |
|
|
| **Holistic** | Checks the overall system | End-to-end latency < 200 ms |
|
|
| **Triggered** | Triggered by event (CI/CD commit, deployment) | API contract verification |
|
|
| **Continuous** | Runs continuously in production | Monitoring dependency freshness |
|
|
| **Static** | Code analysis without execution | SonarQube, ESLint |
|
|
| **Dynamic** | Runtime analysis | Load tests, chaos experiments |
|
|
|
|
### Principles of Evolutionary Architecture
|
|
|
|
1. **Incremental change** — small, safe changes thanks to CI/CD, deployment pipelines, mature DevOps
|
|
2. **Fitness functions** — automated protection of architectural characteristics (scalability, performance, security)
|
|
3. **Coupling management** — conscious work with component connections (affinity, volatility, cycles)
|
|
4. **Evolutionary data** — database migrations as first-class citizens (evolutionary schemas, expand-contract pattern)
|
|
|
|
### Antipatterns
|
|
- **Big Design Up Front (BDUF)** — trying to design everything upfront, ignoring change
|
|
- **No Design at All** — absence of architectural thinking, purely emergent design
|
|
- **Premature Standardization** — introducing standards before the domain is understood
|
|
|
|
## Hybrid Cloud Connectivity
|
|
|
|
See also: [NETWORKING.md](NETWORKING.md) — network architecture (VPN, BGP, VPC design).
|
|
|
|
- **Site-to-Site VPN** — IPSec tunnel over the internet
|
|
- **Direct Connect / ExpressRoute / Dedicated Interconnect** — private physical connection
|
|
- **Cloud VPN / Transit Gateway** — hub-and-spoke topology
|
|
|
|
## Cost Optimization Detail
|
|
|
|
### Savings Plans vs Reserved Instances
|
|
|
|
| Property | Compute Savings Plan | EC2 Instance Savings Plan | Reserved Instances |
|
|
|----------|----------------------|---------------------------|-------------------|
|
|
| Flexibility | Instance family, region, OS | Instance family + region | Specific instance |
|
|
| Term | 1 or 3 years | 1 or 3 years | 1 or 3 years |
|
|
| Discount (typical) | ~30-50 % | ~40-60 % | ~40-60 % |
|
|
| Change instance | Yes (any) | Yes (within family) | No |
|
|
| Change region | Yes | No | No |
|
|
| Payment options | All Upfront / Partial / No Upfront | All Upfront / Partial / No Upfront | All Upfront / Partial / No Upfront |
|
|
|
|
### Spot Instance Best Practices
|
|
|
|
- **Diversification** — use a mix of instance types (spot fleet) for higher availability
|
|
- **Graceful handling** — application must handle termination notice (2 minute warning)
|
|
- **Checkpointing** — regular state saving for restart after spot interruption
|
|
- **Spot block** (AWS) — protection for 1-6 h (limited availability)
|
|
- **Use cases**: batch processing, CI/CD runners, stateless microservices, ML training
|
|
- **Avoid**: stateful workloads, databases (without special design)
|
|
|
|
## Organization and Governance
|
|
|
|
### AWS Organizations
|
|
|
|
```
|
|
Root OU
|
|
├── Security OU
|
|
│ ├── Audit Account (CloudTrail, Config)
|
|
│ └── Security Tooling Account (GuardDuty, Security Hub)
|
|
├── Infrastructure OU
|
|
│ ├── Network Account (Transit Gateway, VPN)
|
|
│ ├── Shared Services Account (AD, SSO)
|
|
│ └── Log Archive Account
|
|
├── Workloads OU
|
|
│ ├── Dev OU → individual dev accounts
|
|
│ ├── Staging OU → staging accounts
|
|
│ └── Prod OU → production accounts
|
|
└── Sandbox OU → isolated experimental accounts
|
|
```
|
|
|
|
- **SCP** (Service Control Policies) — whitelist/blacklist services at OU level
|
|
- **Tag policies** — enforce tagging across accounts
|
|
- **AI services opt-out** — control data usage in AWS AI services
|
|
|
|
### Azure Management Groups
|
|
|
|
```
|
|
Tenant Root Group
|
|
├── Platform MG
|
|
│ ├── Connectivity (hub VNet, ExpressRoute)
|
|
│ ├── Management (Log Analytics, Automation)
|
|
│ └── Identity (AD DS, PIM)
|
|
├── Application MG
|
|
│ ├── DEV (dev subscriptions)
|
|
│ ├── TEST (test subscriptions)
|
|
│ └── PROD (production subscriptions)
|
|
└── Sandbox MG
|
|
```
|
|
|
|
- **Azure Policy** — built-in and custom policies (similar to SCP)
|
|
- **Management Group hierarchy** — up to 6 levels deep
|
|
- **Subscription limits** — max 10,000 subscriptions per tenant
|
|
|
|
### GCP Projects
|
|
|
|
```
|
|
Organization Node
|
|
├── Folder: Platform
|
|
│ ├── Project: Shared Networking (VPC, Cloud NAT, VPN)
|
|
│ ├── Project: Security (Cloud KMS, Secret Manager, Chronicle)
|
|
│ └── Project: Monitoring (Cloud Monitoring, Logging)
|
|
├── Folder: Workloads
|
|
│ ├── Folder: Dev
|
|
│ │ └── Project: [app]-dev
|
|
│ ├── Folder: Staging
|
|
│ │ └── Project: [app]-staging
|
|
│ └── Folder: Prod
|
|
│ └── Project: [app]-prod
|
|
└── Folder: Sandbox
|
|
└── Project: [user]-sandbox
|
|
```
|
|
|
|
- **Organization policies** — constraints at organization/folder level
|
|
- **Resource Manager** — hierarchy: Organization → Folder → Project → Resources
|
|
- **Project limits** — max 30 projects (can be increased), 10k resources per project
|
|
|
|
## 12-Factor App Methodology
|
|
|
|
Methodology for building cloud-native applications (Heroku, 2011), expanded by the book **Multi-Cloud Handbook for Developers** (Natarajan, Jacob, 2024).
|
|
|
|
| # | Factor | Description | Cloud Implementation |
|
|
|---|--------|-------------|----------------------|
|
|
| 1 | **Codebase** | One repo, many deployments | Git + CI/CD pipeline |
|
|
| 2 | **Dependencies** | Explicit dependency declaration | package.json, requirements.txt, Docker image |
|
|
| 3 | **Config** | Configuration in environment variables | Secrets Manager, Parameter Store, env vars |
|
|
| 4 | **Backing services** | Dependent services as attached resources | RDS, S3, Redis — connection via connection string |
|
|
| 5 | **Build, release, run** | Strict separation of build stages | CI/CD pipeline (GitHub Actions, GitLab CI) |
|
|
| 6 | **Processes** | Application as stateless processes | Horizontal scaling, session in Redis |
|
|
| 7 | **Port binding** | Service exports port, not embedded in server | Express, FastAPI, Spring Boot on own port |
|
|
| 8 | **Concurrency** | Scaling via process model | Horizontal Pod Autoscaler (K8s), EC2 Auto Scaling |
|
|
| 9 | **Disposability** | Fast startup and graceful shutdown | Health checks, SIGTERM handling, preStop hooks |
|
|
| 10 | **Dev/Prod parity** | Minimal difference between environments | Docker, IaC (Terraform), same backing services |
|
|
| 11 | **Logs** | Logs as event streams | stdout/stderr → CloudWatch, ELK, Datadog |
|
|
| 12 | **Admin processes** | Admin tasks as one-off processes | DB migrations, data backfill — run in isolation |
|
|
|
|
### Multi-cloud Extensions (Multi-Cloud Handbook for Developers)
|
|
- **API-first design** — consistent API interfaces across clouds (REST, gRPC)
|
|
- **Domain-Driven Design (DDD)** — bounded contexts mapped to cloud services
|
|
- **Service Mesh** — Istio, Linkerd for observability, traffic management and security across clouds
|
|
- **GitOps** — declarative deployment with ArgoCD/Flux across Kubernetes clusters in different clouds
|
|
|
|
## Azure Cloud Native Architecture (Map Book)
|
|
|
|
Based on **The Azure Cloud Native Architecture Mapbook (2nd ed.)** (Eyskens, 2025) — 40+ architectural maps across domains:
|
|
|
|
### Domains of Architectural Maps
|
|
|
|
| Domain | Key Azure Services | Architectural Patterns |
|
|
|--------|-------------------|----------------------|
|
|
| **Infrastructure** | VNet, Azure Firewall, ExpressRoute, VPN Gateway | Hub-and-spoke, Virtual WAN, Private Link |
|
|
| **Applications** | App Service, API Management, Service Bus, Functions | Event-driven, Strangler Fig, Backend for Frontend |
|
|
| **Data** | Cosmos DB, SQL Database, Synapse, Data Lake | CQRS, Event Sourcing, Polyglot Persistence |
|
|
| **Container Orchestrators** | AKS, Azure Container Apps, ACA | Sidecar, Ambassador, Adapter (service mesh) |
|
|
| **AI** | Azure OpenAI, Cognitive Services, ML Studio | RAG, model fine-tuning, MLOps |
|
|
| **Security** | Entra ID, Defender for Cloud, Key Vault, Sentinel | Zero Trust, Defense in depth, JIT Access |
|
|
|
|
### Cloud Adoption Framework on Azure
|
|
- **Strategy** — business case, application catalog, portfolio rationalization
|
|
- **Plan** — landing zone design, governance baseline, subscription taxonomy
|
|
- **Ready** — landing zone implementation (ALZ), Azure Policy, Networking, Identity
|
|
- **Migrate** — assessment (Azure Migrate), rehost/replatform, test and cutover
|
|
- **Govern** — cost management, policy enforcement, compliance monitoring
|
|
|
|
## Cloud Provider Comparison
|
|
|
|
Based on **Cloud Computing: AWS, Azure, Google Cloud** (Sario, 2025):
|
|
|
|
| Area | AWS | Azure | GCP |
|
|
|------|-----|-------|-----|
|
|
| **Compute** | EC2, Lambda, ECS/EKS | VMs, Functions, AKS | GCE, Cloud Functions, GKE |
|
|
| **Storage** | S3, EBS, EFS | Blob, Disk, Files | Cloud Storage, Persistent Disk, Filestore |
|
|
| **Relational DB** | RDS (MySQL, PG, SQL Server, Oracle, MariaDB) | SQL Database, MySQL/PostgreSQL | Cloud SQL (MySQL, PG, SQL Server) |
|
|
| **NoSQL DB** | DynamoDB, ElastiCache | Cosmos DB, Redis Cache | Firestore, Bigtable, Memorystore |
|
|
| **Message queue** | SQS, SNS | Service Bus, Queue Storage | Pub/Sub, Tasks |
|
|
| **Observability** | CloudWatch, X-Ray | Monitor, Application Insights | Cloud Monitoring, Cloud Trace |
|
|
| **AI/ML** | SageMaker, Bedrock | Azure ML, OpenAI | Vertex AI, AutoML |
|
|
| **Pricing (compute)** | On-demand, Reserved, Spot, Savings Plan | Pay-as-you-go, Reserved, Spot | On-demand, Committed Use, Spot |
|
|
|
|
## OpenStack as Private Cloud
|
|
|
|
OpenStack is the dominant open-source platform for building private clouds (IaaS). It provides compute (Nova), networking (Neutron), and storage services (Cinder/Swift/Manila) with a unified API.
|
|
|
|
### Advantages over Commercial Solutions
|
|
|
|
- **Vendor-neutral API** — avoids lock-in (VMware, Hyper-V)
|
|
- **Multi-tenancy** — Keystone identity, RBAC, projects, quotas
|
|
- **Hybrid cloud ready** — federation with AWS/Azure/GCP, Terraform provisioning
|
|
- **Ecosystem** — hundreds of services (Heat orchestration, Magnum containers, Designate DNS)
|
|
|
|
### Suitable Scenarios
|
|
|
|
| Scenario | Key Services |
|
|
|----------|--------------|
|
|
| Data center with multi-tenancy and self-service | Nova, Neutron, Cinder, Horizon |
|
|
| Telco / NFVI / MEC | Neutron (DPDK, SR-IOV), Nova (NUMA pinning) |
|
|
| Science and HPC | Cyborg (GPU), Manila (NAS), Ironic (bare metal) |
|
|
| Academic clouds | Keystone federation, Trove (DBaaS) |
|
|
|
|
### Challenges
|
|
|
|
- Significant deployment and operations complexity
|
|
- Frequent API breaking changes between releases (cycle per year)
|
|
- Limited enterprise support outside commercial distributions (Red Hat, Canonical, Mirantis)
|
|
|
|
## Best Practices
|
|
|
|
- Use **infrastructure as code** (Terraform, Pulumi, CDK)
|
|
- Design for **failure** — every component can fail
|
|
- Implement **defense in depth** — security at every layer
|
|
- Monitor **costs** — tagging, budget alerts, anomaly detection
|
|
- Use **managed services** where it makes sense (less operations)
|
|
- **Least privilege** for all IAM roles and policies
|
|
|
|
## Resources
|
|
|
|
Links, books and standards: [sources/cloud/sources.md](sources/cloud/sources.md)
|
|
- **Cost tagging** — assign tags for chargeback/showback (Environment, Team, Cost Center, Application)
|
|
- **Automated compliance** — AWS Config, Azure Policy, GCP Org Policies for guardrails
|
|
- **Multi-account strategy** — AWS Control Tower, Azure Landing Zones, GCP Resource Hierarchy
|
|
|
|
### Recommended Reading
|
|
|
|
| Book | Authors | ISBN | Description |
|
|
|------|---------|------|-------------|
|
|
| The AI Cloud Infrastructure Blueprint | Thummarakoti, Vududala, Madupati, Kaushik | 978-1-041-16642-9 | End-to-end guide to designing, deploying, and managing AI systems on cloud platforms. Covers public/private/hybrid/multi-cloud models for AI, infrastructure for ML training and inference, MLOps. Target audience: architects, data scientists, DevOps. |
|
|
| AWS for Solutions Architects (3rd ed.) | Shrivastava, Srivastav, Thakur | 978-1-83664-193-3 | Practical guide to AWS architecture — compute (EC2, Lambda), storage (S3, EBS), databases (RDS, DynamoDB), networking, security, Well-Architected Framework, migration, cost optimization. Suitable for AWS Solutions Architect certification preparation. |
|
|
|
|
*Last revised: 2026-06-03*
|