Cloud Compute Glossary

Accelerated compute uses specialized processors alongside or instead of conventional CPUs to execute particular classes of workloads more efficiently. In cloud environments, accelerators can include GPUs, TPUs, FPGAs, and other specialized processors designed for parallel computation, AI, scientific workloads, graphics, or high-throughput data processing. The objective is not simply to replace CPU compute, but to match the processor architecture to workloads that can benefit from massive parallelism or specialized hardware. Example: An AI inference workload that takes several seconds on a CPU may execute in milliseconds on a suitably configured GPU instance.

An admission controller evaluates requests to create or modify workloads before those workloads are accepted by a container orchestration platform. In cloud compute, it can enforce policies such as approved images, required security settings, resource limits, trusted registries, or restrictions on privileged workloads before they reach the compute nodes. This creates a preventive security and governance layer: instead of discovering that an insecure workload has already been deployed, the platform can reject it before it consumes compute resources. Example: An admission controller blocks a container deployment that attempts to run with privileged host access or uses an unapproved image.

AI/ML compute refers to computing infrastructure configured to support machine-learning workloads such as model training, fine-tuning, inference, evaluation, and data processing. Cloud AI/ML compute can combine CPUs, GPUs or other accelerators, high-capacity memory, fast storage, and high-bandwidth networking depending on the workload and scale. The optimal configuration varies significantly between training and inference: training often prioritizes accelerator capacity and distributed communication, while inference may prioritize latency, concurrency, model-memory fit, and cost per prediction. Example: A company uses multi-GPU compute for model training but deploys a smaller, latency-optimized GPU configuration for production inference.

AllReduce is a distributed computing operation that combines values from multiple workers and makes the resulting value available to all of them. In distributed machine-learning training, it is commonly used to aggregate gradients produced independently by different GPUs or compute nodes so that each worker can update the model consistently. The efficiency of AllReduce can become a major determinant of training scalability because every additional worker increases the amount of synchronization and communication required. Example: Eight GPUs independently calculate gradients for different batches and use AllReduce to combine those gradients before updating the shared model.

Autoscaling automatically adjusts the amount of compute capacity allocated to a workload based on changing demand or predefined conditions. In cloud environments, it can add or remove VM instances, containers, pods, or other compute resources to maintain application performance while avoiding the cost of permanently running resources for peak demand. Effective autoscaling depends on choosing meaningful scaling signals, defining appropriate thresholds, and accounting for the time required to provision and initialize new capacity. Example: A web application automatically adds compute instances when request volume remains above its configured threshold and removes them as demand falls.

A bare metal server provides physical compute resources directly to a customer without placing conventional customer workloads inside a shared VM environment. Cloud providers offer bare metal when applications require dedicated hardware, predictable performance, specialized hardware access, licensing requirements, or workloads that do not virtualize efficiently. The customer gains greater control over the physical environment but gives up some of the flexibility and resource abstraction associated with virtual machines. Example: An enterprise running a specialized workload that requires direct hardware access may choose a bare-metal cloud server instead of a VM.

Benchmarking is the controlled measurement of workload performance under defined compute configurations and operating conditions. In cloud environments, benchmarking helps compare instance types, processor generations, accelerators, resource configurations, and scaling strategies using metrics that matter to the actual workload rather than relying solely on provider specifications. Good benchmarking also accounts for sustained performance, concurrency, workload size, and cost, because the fastest configuration is not necessarily the most economical one. Example: A company benchmarks its inference workload across three GPU instance types and compares predictions per second and cost per million predictions before selecting the production configuration.

A boot volume is the storage volume from which a VM loads its operating system and starts its execution environment. In cloud compute, separating the boot volume from the underlying physical server allows a VM to be stopped, recreated, moved, or recovered without tying the operating system to a specific physical machine. Boot-volume performance can also influence startup time and application initialization, particularly when the VM performs substantial work during boot. Example: When a VM is recreated on another host, its boot volume provides the operating system and configuration needed to start the instance.

Cloud bursting allows a workload that normally runs in a private or on-premises environment to temporarily use additional public-cloud compute capacity when local resources become insufficient. It can help organizations handle short-lived demand spikes without maintaining enough private infrastructure for maximum capacity year-round, but it requires compatible application architecture, connectivity, identity, data access, and deployment processes. The economics also depend heavily on the cost and latency of moving data or traffic across the environment boundary. Example: An enterprise runs its normal analytics workloads on private infrastructure but sends excess batch jobs to public-cloud compute during monthly processing peaks.

Cloud compute refers to the processing capacity delivered as an on-demand service through cloud infrastructure, allowing applications and workloads to run without the customer owning or managing the underlying physical servers. It can include virtual machines, containers, serverless runtimes, bare-metal systems, and specialized accelerators such as GPUs, with resources provisioned according to workload requirements. The fundamental shift is from treating compute as fixed physical infrastructure to treating it as an elastic, programmable resource that can be allocated, scaled, and released as demand changes. Example: An organization can provision additional compute capacity during a traffic spike and release it once demand returns to normal, rather than maintaining enough physical servers for peak demand year-round.

A Cluster Autoscaler adjusts the number of compute nodes available in a container cluster according to whether workloads can be scheduled with the existing capacity. Unlike application-level autoscaling, which changes the number of workload instances, cluster autoscaling changes the underlying compute capacity on which those workloads run. In cloud environments, this often means adding or removing VM-backed nodes or node pools as Kubernetes workloads require additional resources. Example: When pending pods cannot be scheduled because the cluster has insufficient CPU capacity, the Cluster Autoscaler adds another compute node.

Compute architecture describes how physical processing infrastructure is abstracted, pooled, allocated, scheduled, isolated, and exposed to workloads as usable compute capacity. In a cloud environment, this architecture can include physical servers, virtualization, container runtimes, schedulers, networking, storage, orchestration, and management systems working together to deliver compute as a service. The architecture determines how efficiently resources can be shared, how quickly workloads can be provisioned, how they scale, and what level of isolation and performance they receive. Example: A cloud provider can pool thousands of physical servers and use virtualization and automated scheduling to present customers with independently managed compute instances.

Compute as a Service refers to consuming processing capacity as a cloud-delivered service rather than acquiring and maintaining dedicated physical infrastructure for every workload. The model encompasses different forms of compute—from virtual machines and bare-metal servers to containers and serverless execution—with varying levels of abstraction and provider management. What changes is not simply where the server is located, but how compute becomes a programmable resource that can be requested, configured, scaled, monitored, and released through service interfaces. Example: A business can request additional compute capacity through a cloud API when a new application environment is required and release it when the environment is no longer needed.

Compute capacity is the amount of processing capability available to run workloads, usually represented through resources such as vCPUs, physical CPU cores, memory, GPUs, or other accelerators. In cloud environments, capacity exists both as resources already provisioned to workloads and as additional capacity that can be made available when demand increases. Capacity planning therefore involves more than estimating peak CPU usage; it also considers workload growth, scaling speed, availability requirements, resource constraints, and the capacity required for failure recovery. Example: An application may normally consume 200 vCPUs but require enough additional capacity to handle a sudden traffic surge or the loss of an availability zone.

Compute capacity planning is the process of estimating how much compute infrastructure a workload or organization will need over time and ensuring that sufficient capacity is available without excessive overprovisioning. In cloud environments, planning considers historical utilization, workload growth, seasonal demand, scaling behavior, failure scenarios, resource quotas, and the time required to obtain additional capacity. Although cloud reduces the need to forecast hardware purchases years in advance, capacity planning remains important because scaling is not always instantaneous and critical workloads may require guaranteed or reserved capacity. Example: An enterprise forecasts seasonal demand and reserves baseline compute capacity while using autoscaling for short-term peaks.

A compute cluster is a coordinated group of compute nodes that collectively provide capacity for running applications, distributed services, batch jobs, or other workloads. Clustering allows workloads to be distributed across multiple machines for scalability, higher utilization, parallel processing, or resilience rather than relying on a single server. Cloud clusters can be dynamically expanded or reduced, but their effectiveness depends on scheduling, workload distribution, networking, storage, and the ability of the application to operate across multiple nodes. Example: A machine-learning training workload can distribute computation across a cluster of GPU-enabled nodes to reduce training time.

Compute cost optimization is the process of reducing the cost of running cloud workloads while maintaining required performance, availability, and business outcomes. It involves decisions such as right-sizing instances, removing idle resources, selecting appropriate pricing models, improving utilization, scheduling non-production workloads, and choosing the right compute architecture for the workload. Effective optimization looks at the cost of useful work, rather than simply trying to minimize the number or price of compute instances. Example: An organization identifies that its development VMs are idle overnight, schedules them to stop outside working hours, and uses the savings to fund additional production capacity.

Compute elasticity describes how effectively a compute environment can adjust available capacity to match changes in workload demand. It involves both scaling out or up when more resources are required and scaling back when they are no longer needed, making it a key characteristic of cloud’s consumption model. High elasticity can improve cost efficiency and responsiveness, but it is not unlimited: provisioning delays, service quotas, application architecture, workload startup time, and available infrastructure capacity can all constrain how quickly the environment responds. Example: A workload that can add 50 compute instances within minutes and remove them when demand falls has greater practical elasticity than one requiring manual infrastructure changes.

A compute instance is an allocated, isolated unit of cloud compute capacity on which a workload can execute. An instance commonly represents a virtual machine with a defined combination of CPU, memory, networking, and storage characteristics, although some cloud services also use the term for dedicated or specialized compute resources. Instance selection is therefore not simply about choosing a larger machine; the instance’s CPU architecture, memory ratio, network capability, accelerator availability, and expected workload behavior all influence the appropriate choice. Example: A general-purpose instance may be suitable for an application server, while a compute-optimized instance is selected for a CPU-intensive batch workload.

A compute node is a physical or virtual machine that contributes processing resources to a larger compute environment or cluster. In containerized and distributed cloud platforms, nodes provide the CPU, memory, and other resources onto which workloads are scheduled, while a control or orchestration layer determines where those workloads should run. A node therefore represents an execution resource within a larger pool rather than necessarily being a complete application environment by itself. Example: A Kubernetes cluster uses multiple compute nodes, with the scheduler placing application pods on nodes that have sufficient available CPU and memory.

Compute performance describes how effectively a cloud compute environment executes a workload within its required time, throughput, and resource constraints. It depends not only on the number of vCPUs or amount of memory allocated, but also on processor architecture, clock behavior, memory bandwidth, CPU scheduling, storage and network performance, workload parallelism, and resource contention. In cloud environments, performance must therefore be evaluated against the actual workload rather than inferred solely from the nominal size or price of an instance. Example: Two instances with the same vCPU count can deliver different application performance because they use different processor generations or have different memory and network characteristics.

A compute pool is a shared collection of processing resources from which workloads can be allocated capacity dynamically. In cloud environments, pools can be organized around characteristics such as CPU architecture, instance family, GPU type, availability zone, tenancy, or performance level, allowing workloads to consume appropriate resources without being tied permanently to individual physical servers. Pooling is fundamental to cloud economics because it allows infrastructure to be shared across workloads and allocated according to demand rather than dedicated permanently to one application. Example: Multiple applications can draw VM capacity from a shared pool of general-purpose servers while the cloud platform handles placement and resource allocation.

Compute profiling is the process of examining how an application consumes CPU, memory, threads, and other compute resources to identify where execution time and resources are actually being spent. Profiling can expose issues such as inefficient code paths, excessive synchronization, unnecessary CPU consumption, poor parallelism, memory pressure, or functions that dominate execution time. In cloud environments, profiling helps determine whether scaling the infrastructure will solve the problem or whether the workload itself needs optimization. Example: A profile shows that an application spends most of its CPU time serializing data, leading engineers to optimize the serialization path rather than simply moving to a larger VM.

A compute resource is a unit of processing capacity made available to execute a workload, typically comprising CPU or accelerator capacity, memory, and access to networking and storage. In cloud environments, these resources are abstracted and packaged into different consumption models such as VM instances, containers, serverless execution environments, or dedicated physical servers. The amount and characteristics of compute resources assigned to a workload directly affect its performance, scalability, availability, and cost. Example: A CPU-intensive application may require more vCPUs, while an AI workload may require fewer CPUs but substantial GPU and memory capacity.

A compute service is a cloud offering through which customers consume processing capacity without directly managing the physical infrastructure that provides it. Compute services exist at different levels of abstraction: IaaS provides relatively direct control over virtual machines, while containers and serverless services shift more responsibility for operating systems, runtimes, scaling, and infrastructure management to the provider. Choosing a compute service is therefore largely a decision about the balance between control, operational responsibility, portability, and convenience. Example: A team may choose VMs when it needs operating-system control but use a serverless compute service when it wants the provider to manage scaling and the execution environment.

Compute utilization measures how much of the provisioned processing capacity is actually being used by workloads over time. In cloud environments, utilization is an important economic signal because paying for significantly more CPU, memory, or accelerator capacity than a workload consumes can result in unnecessary expenditure; however, low utilization is not automatically waste because spare capacity may be intentionally maintained for bursts, high availability, or recovery. Cost optimization therefore requires interpreting utilization alongside performance requirements, scaling behavior, and resilience objectives. Example: A VM consistently using 15% of its allocated CPU may be a candidate for right-sizing, unless the remaining capacity is intentionally reserved for predictable traffic spikes.

A compute workload is an application, service, job, or processing task that consumes computing resources to perform a specific function. Workloads differ substantially in how they consume CPU, memory, storage, network bandwidth, and accelerators: an interactive web application may be latency-sensitive, a batch job may prioritize throughput, and an AI training workload may depend heavily on GPU capacity and high-speed interconnects. Understanding these characteristics is essential for choosing the right compute model, resource configuration, placement strategy, and scaling approach. Example: A recommendation engine running real-time inference has very different compute requirements from a batch workload that retrains the underlying model overnight.

A container is an isolated execution environment that packages an application together with the libraries, dependencies, and configuration it needs to run. Unlike a traditional VM, a container generally shares the host operating-system kernel with other containers, making it lighter and faster to start while still providing process and resource isolation. In cloud compute, containers allow applications to be packaged consistently and scheduled across pools of compute resources without requiring a separate full operating system for every application component. Example: A company packages its API and dependencies into a container and runs multiple copies across cloud compute nodes as application demand increases.

A container image is an immutable package containing the application code, runtime components, libraries, configuration defaults, and filesystem layers required to create a container. In cloud compute, images provide a standardized unit for deploying workloads across different hosts and environments, making them central to repeatable deployments and automated scaling. Because the same image may be instantiated hundreds or thousands of times, image contents, provenance, vulnerabilities, and update practices directly affect the security and consistency of the compute fleet. Example: A platform team builds a versioned application image, scans it for vulnerabilities, and uses the approved image to launch containers across multiple compute nodes.

A container runtime is the software responsible for creating, starting, stopping, and managing containers on a compute host. It handles the low-level interaction between the container workload and the host operating system, including filesystem, process, networking, and resource-isolation mechanisms. In cloud and Kubernetes environments, the runtime forms an important part of the execution stack, but applications generally interact with the orchestration platform rather than directly managing the runtime. Example: A container runtime on a cloud compute node starts the application container requested by the cluster scheduler.

Container sandboxing adds stronger isolation mechanisms around containers to reduce the impact of a compromised or malicious workload escaping its normal container boundaries. Standard containers share the host kernel, so sandboxed runtimes can introduce additional isolation through techniques such as lightweight virtual machines or restricted system-call interfaces. In multi-tenant cloud compute, this can provide a stronger security boundary for workloads that cannot be treated as fully trusted. Example: A cloud platform runs untrusted workloads using a sandboxed container runtime to reduce their ability to interact directly with the host system.

Cordon and drain are node-maintenance operations used to safely remove workloads from a compute node before the node is taken out of service. Cordon prevents new workloads from being scheduled onto the node, while drain attempts to evict existing workloads according to the platform’s disruption and scheduling rules. In cloud compute, this process is important for controlled maintenance, node replacement, scaling, and infrastructure lifecycle operations without unnecessarily disrupting running services. Example: Before replacing an unhealthy Kubernetes node, an operator cordons it to stop new workloads from arriving and drains its existing pods so they can be rescheduled elsewhere.

CPU pinning or CPU affinity associates a workload or virtual CPU with specific physical CPU cores or processor groups instead of allowing the scheduler to place it freely across available cores. In cloud compute, this can improve performance predictability for latency-sensitive or high-performance workloads by reducing unnecessary CPU migration and improving cache locality, although it also reduces scheduling flexibility and can make resource utilization less efficient. It is most useful when predictable CPU behavior matters more than maximizing general-purpose resource sharing. Example: A latency-sensitive workload may be pinned to dedicated CPU cores to reduce scheduling variability and contention.

CPU steal time represents the amount of time a virtual machine wanted to execute on a virtual CPU but the underlying hypervisor was using the physical processor capacity for another workload. It is primarily relevant in virtualized environments where physical compute resources are shared and can help identify contention that is not visible through ordinary application-level CPU utilization. Elevated steal time can indicate that a workload is receiving less effective CPU capacity than its vCPU allocation might suggest. Example: A VM reports high CPU steal time even though its application is not using all available vCPU capacity, indicating contention at the underlying host level.

CPU utilization represents how much of the available processor capacity a workload is actively consuming over a period of time. In cloud compute, sustained high utilization can indicate that a workload needs additional capacity, while consistently low utilization can indicate overprovisioning—but neither metric should be interpreted in isolation. A workload may show moderate CPU utilization while being constrained by memory, I/O, synchronization, or a single saturated processing thread. Example: A VM consistently operating at 85–90% CPU utilization during peak traffic may require additional capacity, provided CPU is actually the workload’s limiting resource.

A CronJob schedules Kubernetes Jobs to run according to a recurring time-based schedule. It is useful for periodic compute tasks such as backups, data processing, maintenance, report generation, or model-refresh operations without requiring a continuously running application instance. In cloud environments, scheduled execution can also reduce cost because compute is consumed only when the scheduled task actually runs. Example: A CronJob starts a data-processing workload every night at 2 a.m. and the compute resources are released after the job completes.

A DaemonSet ensures that a specified pod runs on every eligible node, or on a defined subset of nodes, in a Kubernetes cluster. In cloud compute, this is useful for node-level functions that need to operate alongside the compute infrastructure, such as monitoring agents, logging collectors, security agents, or networking components. As nodes are added or removed, the DaemonSet automatically adjusts the workload placement to maintain the required node-level coverage. Example: A monitoring agent is deployed as a DaemonSet so every compute node automatically runs an instance of the agent.

Data locality refers to keeping compute resources physically or logically close to the data they process so that less data needs to travel across networks. In cloud compute, locality can significantly affect latency, throughput, data-transfer costs, and overall application performance, particularly for analytics, AI, databases, and distributed processing workloads. The optimal placement is therefore often determined not simply by where compute capacity is available, but by where the workload’s data and dependent services reside. Example: An analytics workload processes data in the same cloud region as its object storage rather than repeatedly transferring large datasets across regions.

Elastic compute is the ability to dynamically increase or decrease computing resources in response to changing workload requirements. Unlike fixed-capacity infrastructure, elastic compute allows organizations to accommodate demand spikes without permanently maintaining peak capacity and to release resources when demand falls. The practical benefit depends on how quickly additional resources can be provisioned, how efficiently workloads can use them, and whether the application’s architecture supports dynamic scaling. Example: An online retailer automatically increases its compute fleet during a major sale and reduces capacity after traffic returns to normal.

An Elastic Network Interface (ENI) is a virtual network interface that can be attached to a cloud compute instance and provides connectivity through one or more IP addresses, security policies, and network configurations. Separating the network interface from the compute instance allows certain networking attributes to persist or move independently of the underlying VM lifecycle, depending on the cloud platform. ENIs are particularly useful when applications require multiple network identities, controlled traffic paths, or the ability to move network configuration between compute resources. Example: An application can retain a secondary network interface and its associated private IP configuration when a replacement VM is provisioned.

Enhanced networking refers to cloud infrastructure capabilities that provide higher network throughput, lower latency, and reduced CPU overhead compared with conventional virtualized networking paths. These capabilities typically rely on optimized network interfaces, specialized virtualization mechanisms, or direct hardware assistance to move packets more efficiently between compute instances and the underlying network. For high-performance cloud workloads, network performance can become as important as CPU capacity because distributed applications may spend significant time moving data between compute nodes or services. Example: A distributed analytics workload uses enhanced networking to exchange large volumes of data between compute instances without making network processing a major CPU bottleneck.

Ephemeral storage provides temporary storage associated with a compute instance or the physical host on which it runs, with data potentially being lost when the instance is terminated, migrated, or otherwise recreated depending on the platform. In cloud compute, it is useful for temporary files, caches, scratch data, intermediate processing, and workloads where persistence is not required. It should not be confused with persistent cloud storage because the lifecycle of ephemeral data is tied more closely to the compute resource itself. Example: A batch-processing VM uses ephemeral storage for temporary intermediate files and writes the final results to persistent object or block storage.

An execution environment is the combination of compute resources, operating-system or runtime components, libraries, configuration, networking, storage, and security controls required for a workload to execute. In cloud compute, the execution environment can be a VM, container, serverless runtime, or specialized accelerator environment, and differences between environments can affect application behavior even when the application code remains unchanged. Defining the execution environment clearly is therefore important for portability, reproducibility, performance, and troubleshooting. Example: The same application image may behave differently if its CPU architecture, runtime version, available memory, or security configuration changes between environments.

A GPU instance is a cloud compute configuration that combines conventional CPU and memory resources with one or more GPUs. GPUs are particularly effective for workloads that can divide large numbers of similar calculations into parallel operations, making them widely used for machine-learning training and inference, scientific computing, simulation, rendering, and other accelerated workloads. Selecting a GPU instance involves more than counting GPUs; GPU memory, interconnect bandwidth, CPU-to-GPU communication, network performance, and workload parallelism can all determine actual performance. Example: A machine-learning team uses a multi-GPU cloud instance to train a large neural network that would take substantially longer on CPU-only infrastructure.

GPU memory is the high-speed memory directly accessible to a GPU for storing model parameters, intermediate tensors, input data, and other information required during computation. In cloud AI compute, available GPU memory can be as important as raw GPU processing capability because a model or batch that does not fit within accelerator memory may require smaller batches, model partitioning, offloading, or multiple GPUs. This makes GPU memory capacity and bandwidth important selection criteria when choosing an accelerator instance. Example: A large language model may require multiple GPUs because its model weights and intermediate activations cannot fit within the memory of a single GPU.

GPU passthrough provides a virtual machine with direct access to a physical GPU rather than exposing only an abstracted virtual GPU interface. In cloud compute, this can provide workloads with near-native access to accelerator capabilities and is useful when applications require specific GPU functionality or high performance. The trade-off is that directly assigned hardware is less flexible to share and migrate than conventional virtualized resources, so GPU passthrough can influence scheduling, availability, and VM mobility. Example: A cloud VM is assigned an entire physical GPU through passthrough so an AI workload can access the accelerator directly.

GPU utilization indicates how actively an accelerator is being used during workload execution, but the metric needs to be interpreted carefully because high utilization does not automatically mean the workload is efficiently using the GPU. A GPU can remain busy while waiting on memory, data movement, CPU preprocessing, or network synchronization, and a low utilization rate can indicate that the workload is input-bound rather than compute-bound. In cloud environments, GPU utilization is therefore useful for capacity planning and cost optimization when combined with memory usage, workload throughput, and application-level performance metrics. Example: A GPU shows only 45% utilization because CPU-based data preprocessing cannot supply batches quickly enough to keep the accelerator busy.

Hardware-assisted virtualization uses processor capabilities designed to help the hypervisor efficiently execute virtual-machine workloads while maintaining isolation between guest environments. Modern CPUs provide virtualization extensions that allow privileged guest operations to be handled more efficiently than purely software-based virtualization approaches. In cloud compute, hardware-assisted virtualization forms part of the foundation that allows VMs to achieve performance much closer to physical machines while retaining the management and isolation benefits of virtualization. Example: A cloud VM uses CPU virtualization extensions so its guest operating system can execute efficiently without direct control of the physical processor.

Horizontal scaling, or scale-out, increases compute capacity by adding more instances, nodes, containers, or other parallel execution units rather than making an individual resource larger. It is particularly effective for workloads that can distribute requests or processing across multiple independent instances and is a foundation of many cloud-native architectures. The benefit is greater aggregate capacity and potentially better resilience, but the application must be designed to distribute work effectively across the additional resources. Example: Instead of upgrading one application server from 8 to 32 vCPUs, a service adds four additional 8-vCPU instances behind a load balancer.

HugePages are larger-than-default memory pages that allow applications to manage memory with fewer page-table entries. In cloud compute, they can reduce translation overhead and improve memory-management efficiency for workloads that use large amounts of memory or require high-performance memory access, such as databases, virtualized networking, and certain HPC applications. They require deliberate configuration and are not automatically beneficial for every workload because allocating large pages can reduce memory-management flexibility. Example: A high-performance database configured to use HugePages can reduce page-table overhead when managing a large memory footprint.

A hypervisor is the virtualization layer that creates and manages virtual machines by allocating physical CPU, memory, networking, and other hardware resources to them. In cloud compute, the hypervisor provides isolation between tenants while allowing the provider to consolidate multiple VMs onto shared physical infrastructure and dynamically manage their resources. Its design influences VM performance, isolation, hardware access, migration capabilities, and the extent to which physical resources can be shared or overcommitted. Example: A cloud provider’s hypervisor can run multiple customer VMs on the same physical server while keeping their operating environments logically isolated.

Idle resource detection identifies compute resources that are consistently unused or significantly underutilized so they can be resized, stopped, scheduled, or removed. In cloud environments, this is particularly valuable because unused compute still generates cost when instances, nodes, or other capacity remain provisioned. Effective detection needs to distinguish genuinely unnecessary resources from intentionally underutilized capacity reserved for bursts, high availability, failover, or predictable future demand. Example: A monitoring system identifies development VMs that have had negligible CPU and network activity for several weeks and recommends shutting them down outside working hours.

Image scanning examines VM or container images for known vulnerabilities, outdated packages, malicious components, misconfigurations, or other security issues before those images are used to launch compute workloads. In cloud compute, this is especially important because an image is often replicated across many instances, meaning a vulnerability embedded in a widely used image can propagate rapidly across an entire compute environment. Scanning is therefore most effective when integrated into the image-build and deployment pipeline rather than performed only after workloads are already running. Example: A platform team scans a new VM image for vulnerable operating-system packages before approving it as the organization’s production image.

InfiniBand is a high-performance networking technology designed for low-latency, high-throughput communication between compute systems and devices. In cloud compute, it is commonly associated with HPC and large-scale AI environments where distributed applications need extremely fast communication between GPUs or compute nodes. Its importance increases as workloads scale across multiple machines because inter-node communication can otherwise become the bottleneck that prevents additional GPUs from translating into proportional performance gains. Example: A multi-node AI training cluster uses InfiniBand to provide high-speed communication between GPU servers.

Infrastructure as a Service (IaaS) provides fundamental infrastructure resources such as virtual machines, networking, and storage through cloud APIs rather than requiring customers to purchase and operate the underlying physical hardware. With IaaS compute, the provider generally manages the physical servers, facilities, and virtualization infrastructure, while the customer remains responsible for the operating system, applications, and much of the workload configuration. This model offers substantial infrastructure control but also leaves the customer with more operational responsibility than higher-level managed compute services. Example: An enterprise provisions cloud VMs, installs its preferred operating system and application stack, and manages patching and configuration while the provider operates the underlying physical infrastructure.

An instance type defines a particular combination of compute resources offered for a cloud workload, while an instance family groups configurations optimized for common workload characteristics such as general-purpose computing, CPU-intensive processing, memory-intensive applications, storage performance, or accelerated computing. Choosing an instance therefore involves more than selecting the number of vCPUs; memory-to-CPU ratio, network bandwidth, storage capability, processor architecture, and accelerator availability can materially affect workload performance and cost. Example: A memory-optimized instance may be preferable for an in-memory database even when a similarly priced general-purpose instance provides the same number of vCPUs.

A Job represents a Kubernetes workload that runs a task to completion rather than continuously serving requests. In cloud compute, Jobs are useful for batch processing, data transformation, testing, report generation, and other finite workloads where the desired outcome is successful completion rather than a continuously running service. Kubernetes can create the required pods, track their completion, and retry failed execution according to configured behavior. Example: A cloud compute cluster launches a Job to process a large batch of files and terminates the workload after all files have been processed successfully.

Jumbo frames are network packets larger than the conventional Ethernet frame size, while MTU (Maximum Transmission Unit) defines the largest packet size that can be transmitted over a network interface without fragmentation. In cloud compute, increasing the MTU can reduce packet-processing overhead and improve efficiency for workloads that transfer large volumes of data, but the configured MTU must be supported consistently across the relevant network path. An MTU mismatch can instead cause fragmentation, dropped packets, or connectivity problems. Example: A high-throughput data-processing cluster uses a larger MTU across compatible network interfaces to reduce networking overhead between compute nodes.

The kubelet is the Kubernetes node-level agent responsible for ensuring that the containers assigned to a node are running according to the desired state provided by the control plane. It works with the container runtime and reports node and workload status back to Kubernetes, making it a critical part of the path between cluster-level scheduling decisions and actual workload execution. In cloud compute, understanding the kubelet helps explain how a high-level request to run a container ultimately becomes an executing process on a specific compute node. Example: After Kubernetes schedules a pod to a node, the kubelet instructs the container runtime to create and maintain the required containers.

Latency is the time taken for a compute operation, request, or interaction to complete, and is particularly important for workloads that require fast responses. In cloud compute, latency can be introduced at several layers—including CPU processing, memory access, storage operations, network communication, and application dependencies—so reducing compute latency often requires identifying the actual source of delay rather than simply adding CPU capacity. For distributed applications, the physical and network location of compute resources can also materially affect latency. Example: A real-time inference service may need to return a prediction within tens of milliseconds, making both compute processing time and network latency important.

Limit ranges define default or allowable CPU and memory requests and limits for workloads within a Kubernetes namespace. In cloud compute, they help prevent individual containers from requesting unreasonable amounts of capacity or running without appropriate resource boundaries, which can affect scheduling and overall cluster utilization. Unlike a resource quota, which generally limits aggregate consumption, a limit range controls resource allocation at the individual workload or container level. Example: A platform sets a default CPU request for containers and prevents a single container from requesting more memory than the namespace is intended to support.

Live migration moves a running virtual machine from one physical host to another with little or no visible interruption to the workload. Cloud platforms use live migration to perform hardware maintenance, balance infrastructure resources, address host failures proactively, or optimize infrastructure utilization without requiring every VM to be manually stopped. The ability to migrate a VM depends on factors such as workload memory behavior, storage architecture, networking, device passthrough, and the virtualization platform. Example: A cloud provider moves a running VM to another physical host during planned hardware maintenance while keeping the application available to users.

Multi-GPU training distributes machine-learning training workloads across multiple GPUs so that a model can process more data or perform computation faster than it could on a single accelerator. In cloud compute, this can involve multiple GPUs within one server or GPUs distributed across several compute nodes, with the latter requiring high-performance networking and efficient communication between accelerators. Scaling beyond one GPU therefore depends not only on GPU capacity but also on synchronization overhead, GPU memory, network bandwidth, and the parallelism strategy used by the training framework. Example: A training job uses eight GPUs to process batches in parallel and synchronizes model updates across them after each training step.

NCCL (NVIDIA Collective Communications Library) is a communication library optimized for collective operations between GPUs, such as broadcasting data, reducing results, and synchronizing information across multiple accelerators. In cloud AI compute, NCCL is an important component of distributed GPU workloads because the efficiency of GPU-to-GPU communication can significantly affect overall training performance. It works particularly closely with high-speed GPU interconnects and networking technologies, making the software communication layer as important as the underlying GPU hardware when scaling training workloads. Example: A distributed training framework uses NCCL to coordinate gradient communication across eight GPUs during each training iteration.

A node is a compute machine that provides the CPU, memory, networking, and other resources on which containerized workloads execute. In a cloud environment, a node may itself be a VM or a bare-metal server, with a container runtime and node-level management components installed on it. Kubernetes and similar orchestration systems treat nodes as schedulable compute capacity and place workloads according to available resources, policies, constraints, and workload requirements. Example: A Kubernetes cluster contains ten cloud VM nodes, and application pods are distributed across them according to resource availability and scheduling rules.

A node pool is a group of compute nodes with a common configuration or purpose that can be managed and scaled as a unit. In cloud compute, node pools allow organizations to match different workloads with appropriate compute characteristics—for example, general-purpose CPU nodes, memory-optimized nodes, or GPU-enabled nodes—within the same container platform. This provides more control over workload placement while avoiding the need to operate every node as a completely independent resource. Example: A Kubernetes cluster may use one node pool for general applications and another containing GPU-enabled nodes for machine-learning workloads.

NUMA is a server architecture in which processors have different access costs to different regions of physical memory, with memory located closer to a processor generally being accessed faster than memory attached to another processor. In cloud compute, NUMA topology can affect the performance of large VMs, databases, analytics workloads, and high-performance applications, particularly when their CPU and memory resources span multiple NUMA nodes. Workload placement and resource allocation that respect NUMA boundaries can therefore reduce memory-access latency and improve predictable performance. Example: A large memory-intensive VM can perform better when its CPU and memory are allocated in a NUMA-aware configuration rather than being spread inefficiently across processor sockets.

On-demand compute allows organizations to provision computing resources when required without making a long-term commitment to a specific amount of capacity. It is particularly useful for unpredictable workloads, development environments, temporary processing, and applications whose capacity requirements change frequently, although the flexibility generally comes with a higher effective unit price than committed consumption models. The value is therefore not simply lower infrastructure ownership cost but the ability to align capacity more closely with when it is actually required. Example: A media company temporarily provisions hundreds of compute instances to process a large batch of video files and releases them after processing is complete.

On-demand pricing charges for compute resources based on the capacity actually provisioned and the duration for which it is consumed, without requiring a long-term usage commitment. It provides the greatest flexibility for unpredictable workloads, temporary environments, and applications whose capacity requirements change frequently, but the effective price per unit of compute is typically higher than committed or interruptible pricing models. For cloud compute, its primary value is the ability to obtain capacity without accepting the financial risk of paying for resources that may not be needed later. Example: A development team runs a set of VMs on an on-demand basis during testing and terminates them once the environment is no longer required.

Paravirtualization is a virtualization approach in which the guest operating system or its drivers are designed to cooperate with the hypervisor rather than behaving entirely as though they were running on physical hardware. In cloud compute, paravirtualized drivers can reduce virtualization overhead for operations such as storage and networking by providing more direct communication between the guest and virtualization layer. Modern cloud platforms often use optimized virtual drivers or paravirtualized interfaces even when the underlying VM uses hardware-assisted virtualization. Example: A cloud VM uses an optimized virtual network driver to reduce the overhead of moving packets between the guest operating system and the underlying physical network interface.

Per-second billing charges for compute consumption in increments of seconds rather than larger fixed billing intervals, where supported by the provider and service. This can make short-lived workloads more economically efficient because customers pay more closely for the actual duration of compute consumption instead of rounding usage into larger time blocks. The benefit is most noticeable for bursty, batch, testing, and automated workloads that start and terminate frequently, although billing granularity alone does not guarantee that a workload is cost-efficient. Example: A batch job that runs for 47 minutes and 20 seconds can be billed according to its actual eligible runtime rather than being rounded to a full hour.

Persistent block storage provides a durable storage volume that remains available independently of the lifecycle of the compute instance using it. In cloud compute, this allows applications to retain operating data when a VM is stopped, restarted, replaced, or moved to another physical host, separating data persistence from compute lifecycle. The performance characteristics of the volume—such as IOPS, throughput, and latency—can also influence the overall performance of compute workloads. Example: A database running on a VM stores its data on persistent block storage so replacing the VM does not automatically remove the database files.

A pod is the smallest deployable unit in Kubernetes and represents one or more containers that are scheduled and managed together on the same compute node. Containers within a pod share certain resources and networking characteristics and are intended to operate as a closely related unit rather than as independently scheduled workloads. In cloud compute, the pod abstraction allows Kubernetes to schedule application workloads onto available compute nodes while treating their required CPU, memory, and other resources as a single scheduling unit. Example: A Kubernetes pod may contain an application container alongside a tightly coupled sidecar container that provides supporting functionality.

A Pod Disruption Budget (PDB) specifies how much voluntary disruption a Kubernetes workload can tolerate at a given time. In cloud compute, this helps protect application availability during planned operations such as node maintenance, cluster upgrades, or node scaling by preventing too many replicas from being voluntarily removed simultaneously. It does not protect against every type of failure; unexpected hardware or infrastructure failures can still cause more disruption than the budget allows. Example: A service with ten replicas may define a PDB requiring at least eight to remain available during planned node maintenance.

Pod Priority and Preemption allow Kubernetes to rank workloads according to their importance and, when necessary, remove lower-priority pods to make compute capacity available for higher-priority workloads. In cloud compute, this provides a mechanism for ensuring that critical workloads can obtain scarce resources when a cluster is under pressure. However, preemption can disrupt lower-priority applications, so priorities need to reflect genuine business or operational importance rather than simply giving every workload a high priority. Example: A production service with high priority can displace a lower-priority batch workload when the cluster has insufficient CPU capacity.

Predictive scaling uses historical patterns, forecasting, or other predictive signals to increase or decrease compute capacity before demand actually changes. It is useful for workloads with recognizable patterns where reactive autoscaling may respond too late—for example, applications that experience predictable traffic increases every morning. The challenge is balancing forecast accuracy against the cost of provisioning resources that may not ultimately be needed. Example: A retail platform increases compute capacity shortly before an expected evening traffic surge based on historical demand patterns.

Remote Direct Memory Access (RDMA) allows one system to access memory or exchange data with another system with significantly less CPU involvement than conventional networking approaches. In cloud accelerated compute, RDMA is particularly valuable for distributed AI and HPC workloads where GPUs or other accelerators need to exchange large amounts of data quickly and consistently across compute nodes. By reducing communication overhead and latency, RDMA can help distributed workloads spend more time performing useful computation and less time waiting for synchronization. Example: A distributed AI training job uses RDMA networking to exchange gradients between GPU-equipped nodes with low communication overhead.

Reserved or committed-use pricing provides a lower effective cost in exchange for committing to consume a defined amount of compute capacity or spend over a specified period. It is suited to workloads with relatively predictable baseline demand, where the organization can confidently forecast that the resources will be needed for the duration of the commitment. The trade-off is reduced flexibility: committing too much capacity can create unused spend, while committing too little may leave the organization paying higher on-demand rates for additional capacity. Example: An enterprise expects to maintain a baseline of 500 vCPUs throughout the year and uses a compute commitment to reduce the cost of that predictable capacity.

Resource quotas place defined limits on the amount of compute or other infrastructure resources that a user, project, namespace, team, or account can consume. In cloud compute, quotas protect shared capacity from uncontrolled consumption and can also support governance, cost management, and fair resource allocation between workloads. A quota can become an operational constraint during scaling or disaster recovery, so capacity planning needs to account for both the workload’s requirements and the platform’s permitted resource limits. Example: A development environment is limited to a maximum number of vCPUs so a test workload cannot consume the compute capacity allocated to production services.

Right-sizing is the process of selecting compute resources that closely match a workload’s actual performance and capacity requirements rather than simply allocating more resources than necessary. In cloud environments, right-sizing considers CPU, memory, network, storage, accelerator requirements, utilization patterns, workload variability, and performance objectives. The goal is not to minimize resource allocation at all costs, but to find the smallest practical configuration that consistently meets workload requirements without creating performance or availability risks. Example: Monitoring reveals that a workload consistently uses 20% of its allocated CPU but nearly all of its memory, leading the team to choose a memory-optimized but smaller compute instance.

RuntimeClass allows Kubernetes workloads to specify which container runtime configuration or runtime handler should be used when they are executed. This becomes relevant in cloud compute when different workloads require different execution characteristics, such as stronger isolation, specialized sandboxing, or alternative runtime behavior. It allows the same cluster to support multiple execution approaches rather than forcing every workload to use identical runtime characteristics. Example: A security-sensitive workload can be scheduled using a sandboxed runtime while ordinary workloads use the cluster’s standard runtime.

Scheduled scaling changes compute capacity according to a predefined timetable rather than waiting for real-time demand signals. It works well when workload demand is predictable, such as scheduled business-hour applications, nightly batch processing, or known event periods. In cloud environments, combining scheduled scaling with reactive autoscaling can provide baseline capacity ahead of expected demand while still allowing the platform to respond to unexpected changes. Example: A business application scales from five instances to twenty every weekday morning and returns to five instances overnight.

Secrets management provides a controlled way to store, access, rotate, and audit sensitive values such as passwords, API keys, certificates, and application credentials used by compute workloads. In cloud environments, keeping secrets outside VM images, source code, container images, and configuration files reduces the risk of credentials being replicated across instances or exposed through application artifacts. Secure access policies and automated rotation are particularly important when workloads scale dynamically because newly created compute resources need access to credentials without embedding permanent secrets into their images. Example: An application running on cloud VMs retrieves its database credentials from a managed secrets system at runtime rather than storing the password inside the VM image.

Secure Boot is a mechanism that verifies the authenticity and integrity of software components involved in starting a compute system before allowing them to execute. In cloud compute, this helps establish a trusted boot chain by preventing unauthorized or modified bootloaders, kernels, or other startup components from being loaded. It is particularly valuable for protecting compute instances against persistent attacks that attempt to compromise the system before the operating system’s normal security controls become active. Example: A cloud VM uses Secure Boot to verify that its boot components are signed and trusted before loading the operating system.

A Shielded VM is a virtual machine configured with additional protections designed to defend the VM’s boot process, firmware, and operating environment against unauthorized modification or tampering. In cloud compute, shielded-VM capabilities can combine mechanisms such as Secure Boot, virtualized hardware roots of trust, and integrity monitoring to strengthen the boundary around a virtual machine. The objective is to protect not only the application running inside the VM but also the integrity of the environment from which that application starts. Example: A security-sensitive workload runs on a shielded VM so unauthorized changes to its boot configuration can be detected or prevented.

Single Root I/O Virtualization (SR-IOV) is a hardware-assisted virtualization technology that allows a physical network device to expose multiple virtual interfaces that can be assigned to different virtual machines. In cloud compute, this can provide workloads with a more direct path to network hardware, reducing virtualization overhead and improving throughput and latency compared with fully software-mediated networking. The trade-off is that workloads using direct hardware-oriented networking capabilities can have additional constraints around portability, migration, and infrastructure management. Example: A latency-sensitive VM uses an SR-IOV virtual function to achieve higher network performance with less CPU overhead.

Spot or preemptible instances provide access to spare cloud compute capacity at a significantly lower price than standard on-demand resources, with the understanding that the provider may reclaim the capacity when it is needed elsewhere. They are well suited to workloads that can tolerate interruption and restart, such as batch processing, distributed data processing, testing, rendering, and some fault-tolerant AI workloads. The cost advantage comes with operational requirements: applications need checkpointing, retry mechanisms, workload redistribution, or other strategies to avoid losing significant work when compute is interrupted. Example: A batch-processing platform uses spot instances for non-urgent jobs and automatically retries interrupted tasks on available capacity.

A StatefulSet is a Kubernetes workload controller designed for applications that require stable identities, predictable ordering, or persistent storage across their instances. This is important in cloud compute because not every workload is stateless: databases, distributed data systems, and other stateful services often need predictable relationships between compute instances and their persistent data. StatefulSets therefore provide a mechanism for running stateful workloads while still benefiting from container orchestration. Example: A distributed database can use a StatefulSet so each database instance retains a stable identity and its associated persistent storage.

A subnet is a logical subdivision of a virtual cloud network that provides a defined IP address range for compute resources and influences how those resources communicate within the network. Subnets are commonly associated with particular availability zones or network segments and can be used to separate workloads according to their connectivity, security, or routing requirements. In cloud compute, subnet placement can therefore affect both the reachability of an instance and the network path available to its traffic. Example: An enterprise places application instances in private subnets while keeping internet-facing load-balancing components in public-facing subnets.

Tail latency describes the slower end of a workload’s latency distribution rather than its average response time. Metrics such as p95 and p99 indicate the latency below which 95% or 99% of requests complete, helping teams identify occasional but significant slowdowns that an average can hide. This matters in cloud compute because resource contention, noisy neighbors, cold starts, network variability, garbage collection, and downstream dependencies can disproportionately affect a small percentage of requests. Example: An API may have an average latency of 40 ms but a p99 latency of 300 ms, meaning one in every hundred requests takes substantially longer.

Tenant isolation is the set of technical controls that prevent workloads belonging to different customers, teams, or security domains from accessing one another’s compute resources or data. This is particularly important in cloud environments where physical infrastructure may be shared, even though workloads are logically separated through virtualization, access controls, networking, and other isolation mechanisms. The strength of isolation depends on the underlying architecture and the security boundaries implemented between tenants; it is therefore a fundamental consideration when evaluating shared cloud compute. Example: Two customers may run VMs on the same physical server while the hypervisor and associated controls prevent one VM from directly accessing the other’s memory or storage.

Throughput measures how much work a compute environment can complete within a given period, such as requests per second, transactions per second, jobs per hour, or data processed per second. In cloud compute, throughput depends on the combined capabilities of CPU, memory, storage, networking, parallelism, and application architecture rather than on CPU capacity alone. It is particularly important for batch, analytics, media-processing, AI, and other workloads where the objective is to maximize completed work rather than minimize the latency of an individual request. Example: A video-processing workload may be evaluated by how many videos it can process per hour rather than by the response time of a single processing request.

TPUs, IPUs, and FPGAs are examples of specialized accelerators designed for particular classes of computational workloads rather than general-purpose processing. In cloud compute, they can provide better performance, efficiency, or cost characteristics for workloads that align closely with their architecture, but they generally require more specialized software support than conventional CPU workloads. Choosing among them involves evaluating workload compatibility, programming frameworks, performance requirements, availability, and portability—not simply selecting the accelerator with the highest theoretical performance. Example: A workload designed for a particular tensor-processing architecture may achieve better performance on a TPU than on a general-purpose GPU.

A Type 1 hypervisor, or bare-metal hypervisor, runs directly on the physical server rather than on top of a conventional host operating system. This architecture is widely used in cloud and enterprise data centers because the virtualization layer can directly manage hardware resources and provide controlled isolation for multiple virtual machines. It also allows the provider to build additional capabilities such as scheduling, resource management, and VM migration around the virtualization layer. Example: A cloud provider runs a Type 1 hypervisor directly on physical servers and uses it to allocate CPU and memory to customer VMs.

A Type 2 hypervisor runs as an application on top of a conventional host operating system and creates virtual machines within that host environment. It is commonly used for development, testing, desktop virtualization, and laboratory environments rather than large-scale cloud infrastructure because the additional host operating-system layer introduces another level of resource management. Understanding the distinction helps explain why the virtualization architecture used by a developer’s laptop can differ from the infrastructure underneath a public-cloud VM. Example: A developer runs a Linux VM on a Windows workstation using a Type 2 hypervisor to test an application.

A vCPU (virtual CPU) is a virtualized processing unit assigned to a cloud VM and presented to the guest operating system as a CPU that can execute workload instructions. The relationship between a vCPU and a physical CPU core is implementation-dependent; a vCPU does not universally mean one dedicated physical core because cloud providers may use techniques such as simultaneous multithreading and resource scheduling. Therefore, comparing instances solely by vCPU count can be misleading without considering processor generation, architecture, frequency, workload characteristics, and whether CPU resources are shared. Example: Two VM types may both offer eight vCPUs but deliver different performance because they use different processor generations or resource-allocation models.

Vertical Pod Autoscaler (VPA) adjusts the CPU and memory resource requests or limits of Kubernetes workloads based on observed or configured resource requirements. In cloud compute, this can help workloads move toward more appropriate resource allocations rather than relying on manually chosen values that may lead to overprovisioning or resource starvation. Depending on its configuration, applying a new recommendation may require a pod to be restarted, so VPA involves a trade-off between resource optimization and workload disruption. Example: A service consistently using more memory than originally requested receives a higher memory recommendation so its pods can be allocated more appropriate compute capacity.

Vertical scaling, or scale-up, increases the capacity of an existing compute resource by assigning it more CPU, memory, or other resources. It can be simpler than distributing a workload across multiple instances and is useful for applications that are difficult to parallelize or that benefit from a larger single execution environment. However, vertical scaling eventually encounters hardware or instance-size limits and may require downtime or workload movement depending on the platform. Example: A memory-intensive application is moved from a VM with 64 GB of RAM to one with 256 GB rather than being distributed across multiple smaller VMs.

A virtual machine (VM) is a software-defined computing environment that behaves like an independent computer, with its own virtual CPU, memory, networking, storage interfaces, and operating system. In cloud compute, VMs allow a physical server to host multiple isolated workloads while presenting each customer with a controllable compute environment. The cloud provider manages the underlying physical infrastructure and virtualization layer, while the customer typically manages the guest operating system and applications. Example: An enterprise can provision a Linux VM with a defined number of vCPUs and memory without knowing which physical server will host it.

A virtual network, commonly exposed as a Virtual Private Cloud (VPC), is an isolated logical network in which cloud compute resources are deployed and connected. It provides the networking boundary around instances and other workloads, allowing organizations to control IP addressing, routing, traffic flow, and connectivity to other cloud or on-premises environments. For compute workloads, the VPC is effectively the network environment that determines how instances communicate with applications, databases, users, and external services while remaining subject to defined security and routing policies. Example: An organization places its application VMs and internal services inside a VPC and restricts direct inbound access from the public internet.

A VM image is a packaged representation of the operating system and software configuration used as the starting point for creating virtual machines. In cloud compute, images make VM provisioning repeatable by allowing organizations to standardize operating-system versions, security configurations, drivers, and preinstalled software rather than configuring every VM manually. Images can also become part of an organization’s deployment pipeline, where approved versions are built, scanned, tested, and promoted for production use. Example: A platform team maintains a hardened Linux image with approved patches and monitoring agents and uses it as the standard base for application VMs.

A VM snapshot captures the state or storage associated with a virtual machine at a particular point in time so it can later be used for recovery, cloning, testing, or creating another VM. In cloud compute, snapshots can simplify operational tasks such as creating a recoverable copy before a major configuration change, but they should not automatically be treated as a complete application-consistent backup. Snapshot behavior varies by platform, particularly around memory state, attached volumes, transactional consistency, and how incremental changes are tracked. Example: An administrator takes a snapshot of a VM’s boot volume before performing a major operating-system upgrade so the previous state can be recovered if the upgrade fails.

A virtual Trusted Platform Module (vTPM) is a software- or hardware-backed virtual representation of a TPM provided to a virtual machine so that the VM can use hardware-rooted or measured-trust capabilities without requiring a dedicated physical TPM for every instance. In cloud compute, vTPMs can support functions such as secure boot, key protection, measured boot, and integrity verification while maintaining the isolation of individual virtual machines. They are particularly useful when organizations need stronger assurance that a VM has started from an expected and trusted state. Example: A cloud VM uses a vTPM to securely store measurements of its boot process and support integrity verification.

Workload placement is the process of deciding where a compute workload should run based on factors such as available resources, performance requirements, availability, hardware characteristics, network topology, and organizational policies. In cloud environments, placement can determine which physical host, availability zone, region, node pool, or accelerator-equipped infrastructure executes the workload. Good placement can improve performance and resilience, while poor placement can introduce latency, resource contention, or correlated failure risk. Example: A GPU workload is placed on an accelerator-enabled node in the same availability zone as the storage and services it accesses most frequently.

Workload scheduling is the process of deciding which available compute resource should execute a workload based on its resource requirements, constraints, policies, and the current state of the infrastructure. In cloud compute, schedulers may consider CPU and memory availability, accelerator requirements, affinity rules, availability zones, data locality, workload priority, and resource policies when making placement decisions. Good scheduling improves utilization and performance while reducing contention and ensuring that workloads are placed on infrastructure capable of meeting their requirements. Example: A scheduler places a GPU-dependent workload on a node with available GPUs instead of assigning it to a general-purpose CPU node.