knowledge-base/CLOUD.md

☁️ Cloud architektura

Poskytovatelé

• AWS — největší tržní podíl, nejširší portfolio
• Azure — silná integrace s Microsoft ekosystémem
• GCP — Kubernetes (GKE), data & ML, síťová konektivita

Modely nasazení

Model	Popis
Public cloud	Sdílená infrastruktura poskytovatele
Private cloud	Vyhrazená infrastruktura (on-prem nebo hosted)
Hybrid cloud	Propojení public + private
Multi-cloud	Více veřejných poskytovatelů

Multi-cloud strategie

Důvody pro multi-cloud

• Vendor lock-in prevence — diverzifikace rizika
• Regulatorní požadavky — data residency v konkrétních regionech
• Best-of-breed — každý provider má silné stránky (AWS networking, Azure enterprise, GCP data/ML)
• Akviziční scénáře — merge & acquisition sjednocení

Multi-cloud connectivity

Metoda	Latence	Propustnost	Náklady
Site-to-Site VPN	Střední	Omezená	Nízké
Private interconnect (Direct Connect / ExpressRoute / Dedicated Interconnect)	Nízká	Vysoká	Vysoké
Cloud-to-cloud VPN	Střední	Střední	Střední
SD-WAN	Nízká	Vysoká	Střední

Výzvy

• Síťová komplexita — rozdílné VPC/VNet koncepty, security modely
• IAM federace — jednotné identity napříč cloudy (SSO, SAML, OIDC)
• Data gravitace — pohyb dat mezi cloudy je drahý a pomalý
• Monitoring — jeden pane of glass napříč cloudy (Grafana, Datadog)

Cloud Adoption Frameworks (CAF)

Každý hlavní poskytovatel má vlastní Cloud Adoption Framework pro strukturovaný přístup k adopci cloudu:

Poskytovatel	Rámec	Zaměření
AWS	AWS CAF	6 perspektiv: Business, People, Governance, Platform, Security, Operations
Azure	Microsoft CAF	8 metodik: Strategy, Plan, Ready, Migrate, Innovate, Govern, Manage, Secure
GCP	Google CAF	4 pilíře: Learn, Scale, Modernize, Operate

Multi-Cloud Administration Guide (Mulder, 2024) doporučuje kombinovat CAF rámce napříč poskytovateli pro jednotné governanční modely, zejména v oblastech:

• Interoperabilita — standardizace API a IaC napříč cloudy (Terraform, Pulumi)
• Data governance — jednotná politika pro data residency a životní cyklus dat
• Compliance automation — automatizované audity napříč cloudy (AWS Config, Azure Policy, GCP Org Policies)
• Access management — federace identit a centralizované RBAC

Migrační strategie — 6 Rs

Strategie	Popis	Náročnost	Typický scénář
Rehost (Lift & Shift)	Přesun VM/as-is bez změn	Nízká	Rychlá migrace, datacentrum exit, minimální riziko
Replatform (Lift & Reshape)	Migrace s drobnými úpravami (např. RDS místo self-managed DB)	Střední	Optimalizace bez přepisování aplikace
Refactor (Re-architect)	Přepis aplikace na cloud-native (microservices, serverless)	Vysoká	Maximalizace cloudu, dlouhodobá strategie
Repurchase	Přechod na SaaS (např. Salesforce, Workday)	Nízká	Aplikace je zastaralá, existuje SaaS alternativa
Retire	Vypnutí nepotřebných aplikací	Nízká	Aplikace již není používaná, decommission
Retain	Ponechání on-prem	Žádná	Regulatorní důvody, příliš vysoké riziko migrace

Decision framework pro 6 Rs

Start: Je aplikace potřebná?
  ├── Ne → Retire
  └── Ano → Existuje SaaS alternativa?
       ├── Ano → Repurchase
       └── Ne → Vyplatí se refactoring?
            ├── Ano → Refactor
            └── Ne → Stačí změna platformy?
                 ├── Ano → Replatform
                 └── Ne → Rehost

Well-Architected Framework (AWS)

1. Operational Excellence — automace, monitoring, dokumentace
2. Security — IAM, encryption, compliance
3. Reliability — recovery, škálování, záložní plány
4. Performance Efficiency — right-sizing, výběr správných služeb
5. Cost Optimization — FinOps, reserved instances, spot instances
6. Sustainability (od 2022) — carbon footprint, energy efficiency

Obdoby: Azure Well-Architected Framework, GCP Architecture Framework

Klíčové otázky z Well-Architected Review (~60 otázek)

Operational Excellence (12 otázek)

• Jak jsou změny řízeny a automatizovány?
• Jak jsou operace dokumentovány a sdíleny v týmu?
• Jak jsou očekávané a neočekávané události reflektovány v operacích?
• Jaké runbooky existují pro běžné provozní scénáře?
• Jak probíhá incident management a postmortem proces?

Security (12 otázek)

• Jak je implementováno identity & access management?
• Jak jsou chráněna data v klidu a při přenosu?
• Jak je zajištěna detekce bezpečnostních incidentů?
• Jaké jsou postupy pro patch management a vulnerability remediation?
• Jak jsou řízeny infrastrukturní kredenciály a secrets?

Reliability (12 otázek)

• Jak je zajištěna dostupnost služby při výpadku komponenty?
• Jak je implementováno backup a disaster recovery?
• Jak service limity (quotas, throttling) ovlivňují spolehlivost?
• Jak probíhá automatické škálování při změně zátěže?
• Jaké jsou SLI/SLO metriky a jak jsou monitorovány?

Performance Efficiency (12 otázek)

• Jak je vybrán správný typ a velikost compute/ storage?
• Jak je optimalizována databázová vrstva (indexy, dotazy, caching)?
• Jak je monitoring využit k identifikaci úzkých hrdel?
• Jak je implementováno škálování (vertikální vs horizontální)?

Cost Optimization (12 otázek)

• Jak jsou náklady alokovány na týmy/projekty (chargeback/showback)?
• Jaké nástroje se používají pro analýzu nákladů?
• Jak jsou identifikovány a eliminovány nevyužité zdroje?
• Jak je optimalizováno licencování (BYOL, hybrid benefit)?

Klíčové komponenty

Výpočetní vrstva

• VM / instance — EC2, Azure VMs, GCE
• Container orchestrace — EKS, AKS, GKE
• Serverless — Lambda, Azure Functions, Cloud Functions
• PaaS — App Engine, Elastic Beanstalk, Azure App Service

Compute comparison matrix (AWS EC2)

Rodina	Typ	vCPU:Memory	Use case	Příklady cen (on-demand, us-east-1)
General purpose	M7g, m7i	1:4	Web servery, 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 až 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

Viz GPU.md pro detail GPU modelů a konfigurací.

Úložiště

• 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

Třída	Dostupnost	Retrieval time	Cena / GB / měsíc	Use case
S3 Standard	99.99 %	milisekundy	~$0.023	Aktivní data, častý přístup
S3 Intelligent-Tiering	99.9 %	milisekundy	~$0.023 + monitoring fee	Neznámý / proměnlivý přístup
S3 Standard-IA	99.9 %	milisekundy	~$0.0125	Méně častý přístup, ale rychlý
S3 One Zone-IA	99.5 %	milisekundy	~$0.01	Znovu vytvořitelná data
S3 Glacier Instant	99.9 %	milisekundy	~$0.004	Archiv s občasným přístupem
S3 Glacier Flexible	99.99 %	1-5 min (expedite) / 3-5 h (standard)	~$0.0036	Dlouhodobý archiv
S3 Glacier Deep Archive	99.99 %	12 h (standard) / 48 h (bulk)	~$0.00099	Nejlevnější, compliance archívy

Multi-AZ a Multi-Region architektura

Region ┌──────────────────────────────┐
       │  AZ-1       AZ-2       AZ-3  │
       │  ┌───┐      ┌───┐      ┌───┐ │
       │  │APP│──────│APP│──────│APP│ │
       │  └─┬─┘      └─┬─┘      └─┬─┘ │
       │    │          │          │    │
       │  ┌─▼──────────▼──────────▼─┐ │
       │  │      Load Balancer      │ │
       │  └────────────┬────────────┘ │
       │               │              │
       │  ┌────────────▼────────────┐ │
       │  │  Database (Primary)     │ │
       │  │  + Read Replica         │ │
       │  └─────────────────────────┘ │
       └──────────────────────────────┘

Disaster Recovery strategie

DR strategie na AWS (od nejméně po nejvíce připravené)

Strategie	RTO	RPO	Náklady	Popis
Backup & Restore	hodiny	24 h	Nízké	Pravidelné zálohy dat do S3/Glacier, obnova v DR regionu
Pilot Light	desítky minut	minuty	Střední	Minimální běžící kopie (DB, core služby), škálování při failover
Warm Standby	minuty	sekundy	Vysoké	Běží zmenšená kopie produkce, škálování při failover
Active-Active (Multi-Region)	sekundy	< 1 s	Velmi vysoké	Plně aktivní ve více regionech, traffic routing (Route53, Global Accelerator)

Klíčové knihy k tématu:

• Engineering Resilient Systems on AWS (Schwarz, Moran, Bachmeier, 2024) — praktické laby pro resilience vzory: back off and retry, multi-Region failover, circuit breaker, chaos engineering pomocí AWS Fault Injection Simulator
• Building Resilient Architectures on AWS (2025) — data security, backup strategie, automace recovery plánů

Chaos Engineering

Cílené vnášení poruch do systému pro ověření odolnosti:

• AWS Fault Injection Simulator (FIS) — spravované fault injection pro EC2, ECS, EKS, RDS
• Nástroje: Chaos Mesh (Kubernetes), Gremlin, Litmus
• Postup: definice hypotézy → provedení experimentu → měření dopadu → zlepšení systému
• Bezpečnost: experimenty v izolovaném prostředí, safety controls, automatic rollback

Cloud design patterns

Strangler Fig

Postupné nahrazování částí monolitické aplikace microservices.

• Legacy funkcionalita se postupně přesměrovává na nové služby
• Strangler Fig proxy (route hlavičky, feature flagy) řídí přesun trafficu
• Výhoda: průběžné dodávání hodnoty bez big-bang přepisu

Circuit Breaker

Zabránění kaskádovým selháním při výpadku závislé služby.

• Tři stavy: Closed (normální provoz), Open (requesty okamžitě failují), Half-Open (testovací request po timeoutu)
• Parametry: failure threshold, timeout (reset timeout), half-open max requests
• Implementace: resilience4j, Hystrix (legacy), Istio (envoy), AWS App Mesh

Saga

Distribuovaná transakce napříč microservices — řada lokálních transakcí s kompenzačními akcemi.

• Choreography — každá služba publikuje událost, další služba reaguje (Kafka, EventBridge)
• Orchestration — centrální orchestrátor řídí kroky (Step Functions, Temporal, Camunda)

CQRS (Command Query Responsibility Segregation)

Oddělení zápisových (Command) a čtecích (Query) modelů.

• Command model: optimalizovaný pro zápis (normalizovaný, transactionální)
• Query model: optimalizovaný pro čtení (denormalizovaný, read-optimized views)
• Eventual consistency mezi modely (event bus propaguje změny)
• Use case: reporting, audit logy, high-throughput systémy

Event Sourcing

Ukládání stavu jako sekvence událostí (eventů), ne aktuálního stavu.

• Každá změna je append-only event v event store
• Současný stav = fold všech událostí
• Výhody: audit trail, time travel, CQRS kompatibilita
• Implementace: EventStoreDB, Kafka (log), DynamoDB + CDC

Další cloudové patterny (Wilder — Cloud Architecture Patterns)

Pattern	Kategorie	Popis
Horizontally Scaling Compute	Škálovatelnost	Přidávání/odebírání instancí dle zátěže, elasticita
Queue-Centric Workflow	Škálovatelnost	Decoupling komponent přes fronty (SQS, RabbitMQ), zpracování asynchronně
Auto-Scaling	Škálovatelnost	Automatické škálování na základě metrik (CPU, memory, request count)
MapReduce	Big Data	Distribuované zpracování dat (Hadoop, EMR, BigQuery)
Database Sharding	Big Data	Horizontální partition dat napříč databázemi
Busy Signal	Failure Handling	Graceful degradace při přetížení (HTTP 503, throttling, backpressure)
Node Failure	Failure Handling	Detekce a automatické zotavení z výpadku výpočetního uzlu
Colocation	Distribuovaní uživatelé	Umístění compute blízko datům pro snížení latence
Valet Key	Distribuovaní uživatelé	Delegovaný přístup ke storage (SAS tokeny, S3 presigned URLs)
Multi-Site Deployment	Distribuovaní uživatelé	Aktivní nasazení ve více geografických lokalitách

Evolutionary Architecture

Definice (Ford, Parsons, Kua, 2022): Evoluční architektura podporuje řízenou, inkrementální změnu napříč více dimenzemi.

Fitness Functions

Automatizované kontroly architektonických charakteristik — obdoba testů pro architekturu:

Typ	Popis	Příklad
Atomic	Kontroluje jednu metriku	Cyclomatic complexity < 10
Holistic	Kontroluje celkový systém	Latence end-to-end < 200 ms
Triggered	Spouštěná událostí (CI/CD commit, deployment)	Ověření API kontraktu
Continous	Běží nepřetržitě v produkci	Monitoring dependency freshness
Static	Analýza kódu bez běhu	SonarQube, ESLint
Dynamic	Analýza za běhu	Load testy, chaos experimenty

Principy evoluční architektury

1. Inkrementální změna — malé, bezpečné změny díky CI/CD, deployment pipelines, zralému DevOps
2. Fitness funkce — automatizovaná ochrana architektonických charakteristik (škálovatelnost, performance, bezpečnost)
3. Správa couplingů — vědomá práce s propojením komponent (affinity, volatility, cykly)
4. Evoluční data — databázové migrace jako first-class občan (evoluční schemata, expand-contract pattern)

Antipatterny

• Big Design Up Front (BDUF) — snaha navrhnout vše předem, ignoruje změny
• No Design at All — absence architektonického myšlení, čistě emergentní design
• Premature Standardization — zavedení standardů dříve, než je známe domény

Hybrid cloud konektivita

Viz také: NETWORKING.md — síťová architektura (VPN, BGP, VPC design).

• Site-to-Site VPN — IPSec tunel přes internet
• Direct Connect / ExpressRoute / Dedicated Interconnect — privátní fyzické propojení
• Cloud VPN / Transit Gateway — hub-and-spoke topologie

Cost optimization detail

Savings Plans vs Reserved Instances

Vlastnost	Compute Savings Plan	EC2 Instance Savings Plan	Reserved Instances
Flexibilita	Instance family, region, OS	Instance family + region	Specifická instance
Termín	1 nebo 3 roky	1 nebo 3 roky	1 nebo 3 roky
Sleva (typicky)	~30-50 %	~40-60 %	~40-60 %
Změna instance	Ano (libovolná)	Ano (v rámci rodiny)	Ne
Změna regionu	Ano	Ne	Ne
Payment options	All Upfront / Partial / No Upfront	All Upfront / Partial / No Upfront	All Upfront / Partial / No Upfront

Spot instance best practices

• Diverzifikace — používejte mix instance typů (spot fleet) pro vyšší dostupnost
• Graceful handling — aplikace musí zvládnout termination notice (2 minuty varování)
• Checkpointing — pravidelné ukládání stavu pro restart po spot přerušení
• Spot block (AWS) — ochrana na 1-6 h (omezená dostupnost)
• Použití: batch processing, CI/CD runners, stateless microservices, ML training
• Vyhnout se: stateful workloads, databáze (bez speciálního designu)

Organizace a 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 → jednotlivé dev accounts
│   ├── Staging OU → staging accounts
│   └── Prod OU → production accounts
└── Sandbox OU → izolované experimentální účty

• SCP (Service Control Policies) — whitelist/blacklist služeb na OU úrovni
• Tag policies — enforcement tagování napříč účty
• AI services opt-out — kontrola použití dat v AWS AI službách

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 a custom policies (podobné SCP)
• Management Group hierarchy — až 6 úrovní hloubky
• Subscription limits — max 10 000 subscriptions na 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: [aplikace]-dev
│   ├── Folder: Staging
│   │   └── Project: [aplikace]-staging
│   └── Folder: Prod
│       └── Project: [aplikace]-prod
└── Folder: Sandbox
    └── Project: [user]-sandbox

• Organization policies — constrainty na úrovni organizace/folderu
• Resource Manager — hierarchie: Organization → Folder → Project → Resources
• Project limits — max 30 projektů (lze navýšit), resources per project 10k

12-Factor App metodologie

Metodologie pro building cloud-native aplikací (Heroku, 2011), rozšířená knihou Multi-Cloud Handbook for Developers (Natarajan, Jacob, 2024).

#	Faktor	Popis	Cloudová implementace
1	Codebase	Jeden repozitář, mnoho deploymentů	Git + CI/CD pipeline
2	Dependencies	Explicitní deklarace závislostí	package.json, requirements.txt, Docker image
3	Config	Konfigurace v proměnných prostředí	Secrets Manager, Parameter Store, env vars
4	Backing services	Závislé služby jako připojené zdroje	RDS, S3, Redis — připojení přes connection string
5	Build, release, run	Striktní oddělení fází sestavení	CI/CD pipeline (GitHub Actions, GitLab CI)
6	Processes	Aplikace jako bezstavové procesy	Horizontální škálování, session v Redis
7	Port binding	Služba exportuje port, není vložena do serveru	Express, FastAPI, Spring Boot na vlastním portu
8	Concurrency	Škálování pomocí procesního modelu	Horizontal Pod Autoscaler (K8s), EC2 Auto Scaling
9	Disposability	Rychlý start a graceful shutdown	Health checks, SIGTERM handling, preStop hooks
10	Dev/Prod parity	Co nejmenší rozdíl mezi prostředími	Docker, IaC (Terraform), stejné backing services
11	Logs	Logy jako event streamy	stdout/stderr → CloudWatch, ELK, Datadog
12	Admin processes	Administrativní úlohy jako one-off procesy	DB migrace, data backfill — spuštěno v izolaci

Rozšíření pro multi-cloud (Multi-Cloud Handbook for Developers)

• API-first design — konzistentní API rozhraní napříč cloudy (REST, gRPC)
• Domain-Driven Design (DDD) — ohraničené kontexty mapované na cloudové služby
• Service Mesh — Istio, Linkerd pro observabilitu, traffic management a security napříč cloudy
• GitOps — declarativní deployment s ArgoCD/Flux napříč Kubernetes clustery v různých cloudech

Azure Cloud Native Architecture (mapová příručka)

Na základě The Azure Cloud Native Architecture Mapbook (2nd ed.) (Eyskens, 2025) — 40+ architektonických map napříč doménami:

Domény architektonických map

Doména	Klíčové služby Azure	Architektonické vzory
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

Využití Cloud Adoption Framework na Azure

• Strategy — business case, katalog aplikací, racionalizace portfolia
• Plan — landing zone design, governance baseline, subscription taxonomy
• Ready — implementace landing zones (ALZ), Azure Policy, Networking, Identity
• Migrate — assessment (Azure Migrate), rehost/replatform, test a cutover
• Govern — cost management, policy enforcement, compliance monitoring

Srovnání cloudových poskytovatelů

Na základě Cloud Computing: AWS, Azure, Google Cloud (Sario, 2025):

Oblast	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
Databáze relační	RDS (MySQL, PG, SQL Server, Oracle, MariaDB)	SQL Database, MySQL/PostgreSQL	Cloud SQL (MySQL, PG, SQL Server)
Databáze NoSQL	DynamoDB, ElastiCache	Cosmos DB, Redis Cache	Firestore, Bigtable, Memorystore
Message queue	SQS, SNS	Service Bus, Queue Storage	Pub/Sub, Tasks
Observabilita	CloudWatch, X-Ray	Monitor, Application Insights	Cloud Monitoring, Cloud Trace
AI/ML	SageMaker, Bedrock	Azure ML, OpenAI	Vertex AI, AutoML
Cena (compute)	On-demand, Reserved, Spot, Savings Plan	Pay-as-you-go, Reserved, Spot	On-demand, Committed Use, Spot

OpenStack jako Private Cloud

OpenStack je dominantní open-source platforma pro budování private cloudu (IaaS). Poskytuje výpočetní (Nova), síťové (Neutron) a storage služby (Cinder/Swift/Manila) s jednotným API.

Výhody oproti komerčním řešením

• Vendor-neutral API — vyhne se lock-in (VMware, Hyper-V)
• Multi-tenancy — Keystone identity, RBAC, projekty, quoty
• Hybrid cloud ready — federation s AWS/Azure/GCP, Terraform provisioning
• Ekosystém — stovky služeb (Heat orchestrace, Magnum containers, Designate DNS)

Vhodné scénáře

Scénář	Klíčové služby
Datacentrum s multi-tenancy a self-service	Nova, Neutron, Cinder, Horizon
Telco / NFVI / MEC	Neutron (DPDK, SR-IOV), Nova (NUMA pinning)
Věda a HPC	Cyborg (GPU), Manila (NAS), Ironic (bare metal)
Akademické cloudy	Keystone federation, Trove (DBaaS)

Výzvy

• Významná komplexita nasazení a provozu
• Časté API breaking changes mezi releasy (cycle per year)
• Omezená enterprise podpora mimo komerční distribuce (Red Hat, Canonical, Mirantis)

Best practices

• Používejte infrastructure as code (Terraform, Pulumi, CDK)
• Designujte pro failure — každá komponenta může spadnout
• Implementujte defense in depth — security na každé vrstvě
• Monitorujte náklady — taggování, budget alerts, anomaly detection
• Používejte managed services kde to dává smysl (méně operací)
• Least privilege pro všechny IAM role a politiky

Zdroje

Odkazy, knihy a standardy: sources/cloud/sources.md

• Cost tagging — assign tags pro chargeback/showback (Environment, Team, Cost Center, Application)
• Automated compliance — AWS Config, Azure Policy, GCP Org Policies pro guardrails
• Multi-account strategie — AWS Control Tower, Azure Landing Zones, GCP Resource Hierarchy

Doporučená literatura

Kniha	Autoři	ISBN	Popis
The AI Cloud Infrastructure Blueprint	Thummarakoti, Vududala, Madupati, Kaushik	978-1-041-16642-9	End-to-end průvodce návrhem, deploymentem a správou AI systémů na cloudových platformách. Pokrývá public/private/hybrid/multi-cloud modely pro AI, infrastrukturu pro ML trénování a inferenci, MLOps. Cílová skupina: architekti, data scientists, DevOps.
AWS for Solutions Architects (3rd ed.)	Shrivastava, Srivastav, Thakur	978-1-83664-193-3	Praktický průvodce AWS architekturou — compute (EC2, Lambda), storage (S3, EBS), databáze (RDS, DynamoDB), networking, security, Well-Architected Framework, migrace, cost optimization. Vhodné pro přípravu na AWS Solutions Architect certifikaci.

Poslední revize: 2026-06-03