CCC-A key terms

On-demand delivery of computing resources such as servers, storage, networking, and software over a network, provisioned rapidly with minimal provider interaction and billed according to consumption rather than upfront purchase.

The five defining traits of cloud: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. A solution missing any of these is not truly cloud under the widely used reference definition.

The layer of the technology stack the provider manages. Infrastructure as a Service supplies virtual machines and storage; Platform as a Service supplies runtimes and middleware; Software as a Service supplies finished applications. Responsibility shifts toward the provider as you move up.

How cloud infrastructure is owned and shared: public (multi-tenant, provider-owned), private (dedicated to one organization), hybrid (connected combination), or community (shared by organizations with common concerns). Choice drives cost, control, and compliance trade-offs.

Infrastructure owned and operated by a provider and shared across many customers over the internet. Offers fast provisioning and economies of scale, but limits customer control over the underlying hardware and physical security.

A composition of two or more distinct cloud environments (private, public, or community) joined by technology enabling data and application portability. Commonly used to keep sensitive workloads on-premises while bursting other workloads to public capacity.

Architecture where one instance of software or infrastructure serves multiple customers whose data and configuration are logically isolated. It underpins public cloud economics but makes isolation controls and noisy-neighbor effects critical design concerns.

The ability to automatically acquire and release resources as demand changes, so capacity tracks workload closely. Differs from scalability, which is the capacity to grow; elasticity is the speed and automation of that growth and shrinkage.

The capability of a system to handle growing load by adding resources. Vertical scaling enlarges a single node; horizontal scaling adds nodes. Cloud platforms favor horizontal approaches because they avoid single-machine limits.

Configuration in which a private environment handles baseline demand and overflow traffic is routed to public cloud capacity during peaks. Requires compatible images, networking, and data synchronization between the two environments.

Execution model where the provider allocates and scales compute automatically and bills per invocation or execution time, with no server management by the customer. Cold starts and execution time limits are common design constraints.

A structured justification for an investment comparing costs, benefits, risks, and alternatives over a defined period. For cloud adoption it should quantify migration cost, run-rate change, avoided capital expense, and expected business outcomes.

The full lifetime cost of an asset or service, including acquisition, operations, support, power, facilities, and retirement. Cloud comparisons often fail when on-premises estimates omit staff time, refresh cycles, and idle capacity.

Net benefit divided by cost, expressed as a percentage, used to rank or justify investments. In cloud programs, benefits may be financial (lower run cost) or non-financial (faster delivery, resilience), which complicates single-number reporting.

Capex is upfront purchase of long-lived assets that depreciate; Opex is ongoing usage-based spending. Cloud generally shifts IT spending from capex to opex, changing budgeting, accounting treatment, and financial approval processes.

The study of cost drivers and value in cloud services, including economies of scale, right-sizing, demand aggregation, and the cost of idle capacity. It explains why unit costs can fall while total spend still rises without governance.

Cost advantages gained as volume increases, because fixed costs spread over more units and purchasing improves. Hyperscale providers pass some of this advantage on through lower per-unit prices and frequent service innovation.

A structured set of phases, roles, and guidance an organization uses to plan and execute cloud adoption, typically covering strategy, planning, readiness, migration, governance, and operations. It aligns technical work with business outcomes.

A classification of application migration approaches: rehost, replatform, refactor or re-architect, repurchase, retain, and retire. Choosing per application prevents both reckless rewrites and lift-and-shift sprawl of technical debt.

A cross-functional team that sets cloud standards, builds shared guardrails and reusable assets, and coaches delivery teams. It succeeds when it enables autonomy rather than acting as a central approval bottleneck.

The discipline of tracking whether promised benefits actually materialize after adoption, using defined metrics reviewed on a schedule. Without it, business cases become one-time approval documents disconnected from operational results.

A region is a geographic area containing isolated data centers; availability zones are separate facilities within a region with independent power and networking. Deploying across zones protects against single-facility failure.

A logically isolated network within a provider's cloud where you define address ranges, subnets, routing, and gateways. It is the primary boundary for network segmentation and connectivity to on-premises networks.

A range of IP addresses within a VPC placed in one availability zone. Public subnets route to the internet through a gateway; private subnets do not, and typically host databases and internal application tiers.

Distributing incoming requests across multiple backend instances to improve responsiveness and availability. Health checks remove failing targets, and session handling choices affect whether scaling out actually helps.

Automatically adjusting the number of running instances based on metrics such as CPU, queue depth, or request rate. Requires health checks, warm-up behavior, and stateless design to work reliably.

Storage that keeps data as immutable objects in a flat namespace, addressed by key and accessed over HTTP APIs. Suited to unstructured content and backups; not suited to in-place modification or low-latency block access.

Storage presented as raw volumes attached to a compute instance and formatted with a filesystem. Offers low-latency random access for databases and operating systems, but volumes are tied to a zone and need replication for resilience.

A geographically distributed cache that serves content from locations near users, reducing latency and origin load. Correct cache-control and invalidation strategy determine whether it helps or serves stale data.

The delay between a request and its response, shaped by physical distance, network hops, and processing time. It is a primary reason to place workloads and data close to users rather than in a single central region.

The property that a system continues operating correctly when a component fails, often through redundancy and automatic failover. Stronger than high availability, which permits brief interruption during recovery.

Design that keeps a service accessible for a target percentage of time by eliminating single points of failure and enabling recovery, though short outages may occur. Usually expressed as a service level objective.

Plans and infrastructure for restoring services after a major outage, characterized by recovery time objective and recovery point objective. Cloud enables pilot-light and warm-standby patterns at lower cost than duplicate data centers.

The division of security duties between provider and customer. The provider secures facilities, hardware, and the managed service layer; the customer secures identity, data, configuration, and whatever they build on top.

The system of identities, roles, policies, and authentication mechanisms controlling who can perform which actions on which resources. Least privilege and federation are core practices for reducing credential risk.

Granting only the permissions required for a task, for only as long as needed, and reviewing them regularly. In cloud, over-broad roles and long-lived access keys are among the most common causes of breaches.

Protecting stored data with encryption on disk or in the storage service, and protecting moving data with protocols such as TLS. Key management, rotation, and who can decrypt matter as much as the cipher chosen.

An insecure setting or default in a cloud resource, such as a publicly readable storage bucket or an open management port. It is a leading cause of cloud incidents because customers, not providers, own configuration.

Preventive or detective controls applied across an environment, such as policy constraints, baseline templates, and automated compliance checks. They let teams move fast within safe boundaries rather than seeking per-change approval.

Expressing governance rules in machine-readable form so they can be version-controlled, tested, and enforced automatically in pipelines and at runtime. Makes compliance repeatable and auditable rather than dependent on manual review.

An operating practice that brings finance, engineering, and business together to make cloud spending visible, accountable, and optimized continuously. Typical activities include tagging, budget alerts, showback, and right-sizing reviews.

Reporting cloud costs to the teams that incur them without transferring the actual charge. It builds cost awareness; chargeback goes further by billing internal budgets, which drives stronger accountability but more political friction.

A contractual commitment on measurable service attributes, usually availability, with remedies such as service credits if missed. It defines the provider's obligation, not the customer's end-to-end user experience.

An internal target for a reliability or performance measure, typically stricter than the provider SLA, used to guide engineering decisions. Error budgets derived from SLOs balance release velocity against stability.

Managing infrastructure through declarative definition files stored in version control and applied by tooling. Enables repeatable environments, peer review of changes, and drift detection, but requires discipline to avoid configuration sprawl.

Divergence between the declared or expected state of an environment and its actual state, usually caused by manual changes. It makes environments unreproducible and is detected by comparing live resources against code definitions.

Matching resource size and type to actual measured demand, removing over-provisioned capacity and correcting under-provisioned bottlenecks. It is one of the largest and least risky sources of cloud cost savings.