knowledge-base/CLOUD.en.md

# ☁️ 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.en.md](GPU.en.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.en.md](NETWORKING.en.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.en.md](sources/cloud/sources.en.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*