Concept and mechanism
Cloud models differ in consumer control. IaaS allows guest-system and application management; PaaS delegates the platform and supports applications within offered capabilities; SaaS delivers a managed application with configuration options. More provider management does not remove data and access responsibilities. In an EC2 example, the customer retains guest-system patching and resource security configuration. Elasticity adjusts capacity to demand by adding and releasing resources. Horizontal scaling changes instance count; vertical scaling changes one instance’s capacity. None of these decisions alone guarantees continuity, performance, or compliance. Examine dependencies, limits, and application behavior.
Guided application
To withstand a zone failure, placing two replicas in the same zone is insufficient. Also examine databases, routing, and surviving capacity. For cost, define ownership, environment, attribution, and review of forgotten resources. An AWS budget with alerts is not an instantaneous cap shutting everything down: actions need configuration, permissions, and a choice between automatic execution and approval. Cost data can also arrive late. In a fictional shared lab, indiscriminate shutdown can interrupt an agreed recovery exercise. FINOPS and operations should identify consumption, choose scope, and document temporary exceptions rather than raising the threshold without understanding the cause.
Two replicas in one failure domain increase count without removing that shared dependency.
Common pitfalls
Cloud as no responsibilities; alert as hard cap; more CPU as zone tolerance.
Related topics: Linux, shell, and permissions · Services, logs, and capacity · Networking and recovery
Relate cost and resilience to resources, owners, and usage conditions.
Reference: NIST definition of cloud computing · LFCA domains and competencies updated2025-09-16; current page confirmed2026-09-30