Cloud Infrastructure Explained: Compute, Storage, Networks, and Identity

Follow one job through the cloud

A daily order job reads files, checks customer references, transforms rows, and publishes a validated result. Saying that it “runs in the cloud” does not tell us which machine executes it, where its state survives, how its requests travel, or what it is allowed to access. Those are four different questions: compute, storage, networks, and identity.

We will use a fictional batch job with 100 GiB of input and a 30-minute completion target after the source batch is ready. Input files are retained in object storage, a managed database holds customer reference data, and workers write a new output version before it is published. The example is an infrastructure map and two local calculations, not a cloud deployment or a measured performance result. Basic Python is needed only for the calculations; DE-P2, P6, and P7 supply the networking, transaction, and validation background.

Management path
  deployment identity -> cloud control APIs -> job configuration, network, permissions
  scheduler -> starts workers using an assigned workload identity

Data path (logical connections, not physical placement)
  retained input objects --read--> workers --write--> candidate output version
                                   |                       |
                                   | read                  | validation succeeds
                                   v                       v
                           customer reference DB     published version -> consumers

  workers -> logs and metrics; audit events -> operational evidence

Each data-path arrow needs a route, a supported protocol, and effective permission.
Object storage is a managed API service; the diagram does not put a bucket in a subnet.

The control plane creates and configures resources: starting a job, changing a route, or granting a role. The data plane carries the workload: reading an object or querying a table. A deployment identity may be able to create a worker while the worker’s own identity cannot read its input. Conversely, an existing worker can sometimes keep serving data while a control-plane operation is unavailable. The exact dependencies belong to the chosen service.

Where resources live and where failures spread

An account, project, or subscription groups resources for administration, billing, and policy. These terms are provider-specific rather than interchangeable implementations. Separate development and production boundaries can reduce accidental impact, but shared credentials, networks, and organization policies can still connect them. A region is a geographic deployment area. Availability zones are separate failure domains within a region; a zone can include one or more facilities.

Choose location from source and consumer distance, permitted data locations, available services, and recovery needs. Two workers in one zone still share a zone failure. Two zones still share regional dependencies. A resource described as regional does not imply that every tier or storage class automatically survives a zone outage; inspect the service’s replication and failover configuration. A second region adds data movement, consistency, and recovery work, so it should answer a stated requirement.

Compute: what runs the code

A worker needs CPU for parsing and transformation, RAM for in-flight data, and enough network and storage throughput to feed it. A GPU helps only workloads with suitable parallel operations and supporting software; it does not accelerate every data job. Distinguish total input size from the working set: a streaming job can process a large input in bounded memory, while a global sort or join can need memory, spill space, or distributed exchange.

Execution choice	What you choose or operate	What to verify
Virtual machine	An OS image, CPU/RAM capacity, software, and service process	Guest OS updates, startup, disks, shutdown behavior
Container on a cluster	An image and resource requests; the cluster schedules it	Who operates the nodes, image updates, limits, restarts
Managed container job or function	Code/image and service configuration	Runtime limits, concurrency, networking, retries, temporary storage

A container packages an application and its dependencies; it is not a promise of a dedicated machine or persistent storage. Containers commonly share a host kernel, while some managed offerings add stronger isolation boundaries. “Serverless” means the service manages more of the server lifecycle, not that there are no servers, no configuration, or no cost. The appropriate execution model follows runtime, isolation, operations, and workload needs.

Scaling up gives one worker more resources. Scaling out adds workers and requires partitionable work plus coordination. Autoscaling reacts to configured signals and takes time; quotas or unavailable capacity can prevent the desired scale. More workers can also exhaust database connections or saturate a shared link. Interruption-tolerant capacity can suit restartable tasks when input and checkpoints survive elsewhere, but the restart protocol must handle partial output and repeated work.

Storage: what survives after the worker disappears

Storage interface	Typical use	Boundary to remember
Object: bucket + key + API	Input files, versioned outputs, backups	An object key is not automatically a POSIX file path
Block: a volume exposed as blocks	A filesystem or database on attached storage	Attachment scope, persistence, throughput, and backup are separate settings
File: shared filesystem interface	Software that needs directories and shared file access	Locking, metadata performance, and supported access semantics matter
Managed database	Queries, indexes, transactions, controlled concurrent updates	Engine guarantees and configured recovery remain relevant

For our job, retained source objects and validated output versions are durable state. A worker’s local scratch files are replaceable. “The disk survived a restart” is not enough to infer it survives worker deletion or a zone failure. Check whether storage is ephemeral or persistent, its deletion policy, and which failure it is designed to tolerate. Persistent storage can still be deleted or corrupted.

Object storage is useful for large immutable files, but a prefix that looks like a directory does not automatically provide directory rename, file append, locking, or a multi-object transaction. Guarantees differ by service and interface. Amazon S3 documents strong consistency for object writes and deletes; that does not turn a set of objects into one database transaction. Write a new output version, validate all its parts, then publish a manifest or catalog reference using a supported conditional or transactional update. Readers must follow that reference, and old versions need a retention policy.

Reference: Amazon S3 storage and consistency model.

Durability concerns retaining data; availability concerns accessing the service when needed. Replication can improve resilience to hardware failure yet also propagate a mistaken deletion. Backups or retained versions provide recovery points, subject to their own retention and access controls. Encryption at rest protects stored data under its key model; it does not decide which application is authorized to read it. Losing or disabling a required encryption key can make otherwise intact data inaccessible.

Networks: the route is part of the application

A virtual network defines address space and connectivity boundaries; a subnet allocates part of that space. A route table selects a next hop for a destination. Firewall rules determine which traffic is allowed. DNS resolves names to addresses, while TLS authenticates the server endpoint and encrypts the connection when correctly configured. Each does a different job. A DNS answer does not prove the port is reachable, and an open port does not grant database or object permissions.

For a concrete AWS example, a VPC spans one region and a subnet belongs to one availability zone. A public subnet has a direct route to an internet gateway; public IPv4 access for an instance also needs suitable addressing and security rules. A private IPv4 worker can use an explicitly configured NAT path for outbound internet access. A NAT device is not an IAM permission, a general traffic-inspection system, or free connectivity. Other providers can give virtual networks and subnets different scopes.

Reference: AWS subnet placement, routing, and security.

A supported private endpoint or service endpoint can connect a worker to a managed service without using its normal public internet path. It does not move the managed storage service into your subnet, and it does not remove service authorization. Check endpoint type, DNS behavior, route configuration, endpoint policies, and charges. A private worker may still need access to an image registry, identity endpoint, log service, or external source before the first input file is read.

Trace both the request and its response. In AWS, security groups are stateful, while network ACLs are stateless and can require explicit return-path allowance; do not copy one rule model into the other. Connectivity across accounts, virtual networks, or an on-premises VPN also needs nonconflicting routes and name resolution. A load balancer distributes requests among eligible backends and uses health checks; it does not make a shared database or a broken business calculation healthy.

Reference: AWS network ACLs and security-group comparison.

Identity: who asks for which operation

An identity names a human or workload principal. Authentication establishes the caller’s identity using credentials or a trusted federation flow. Authorization evaluates whether that caller may perform an action on a resource under the request’s conditions. A deployment role, a runtime role, and a dashboard user have different jobs. The runtime job does not need permission to redesign the network merely because deployment does.

Principal in the example	Required access	Access to keep separate
Deployment identity	Create or update approved job infrastructure; assign approved runtime identity	Unrestricted access to all input and output data
Batch workload identity	Read assigned input and references; write candidate output; send operational logs	Administrator access, changing policies, deleting retained backups
Publisher identity or tightly scoped publication step	Validate the selected version and update its publication reference	Unrelated raw data or organization settings
Consumer identity	Read the published version or approved query view	Write candidate output or change publication pointers

This table is a permission design, not a deployable IAM policy. Map each operation to the service’s exact action and resource scope. Reading known object keys, listing a bucket prefix, decrypting with a customer-managed key, and assuming a role can require distinct permissions. Permission to assign a powerful runtime role is itself sensitive. Use workload identities and short-lived credentials where supported, and verify who is trusted to obtain them; never assume the role name alone establishes that trust.

Reference: AWS IAM identities, temporary credentials, and least privilege.

Effective access is evaluated across the applicable policy types. In AWS, an applicable explicit deny overrides an allow; identity and resource policies, organization controls, permissions boundaries, and session context can all matter. It is not always “one allow in the role is enough,” nor does every policy combine through the same intersection rule. Inspect the actual principal, action, resource, and denial context before widening a role. A network endpoint policy or a key policy can be part of the explanation.

Reference: AWS policy evaluation logic.

A secret manager stores and controls retrieval of secrets; it does not remove the need for a valid workload identity or a rotation plan. Prefer not to distribute long-lived keys in images, source files, or notebooks. TLS, storage encryption, network filtering, and authorization solve different parts of protection. Verify the complete request path, including allowed requests and a small set of deliberately denied operations in an isolated test environment.

Managed services change the responsibility boundary

With a virtual machine, a team typically maintains its guest OS and application. A managed database provider takes over more of the engine and underlying infrastructure operation, according to the service contract. Your team still owns the data model, queries, access choices, integration, and whether the configured backup and recovery meet its needs. Automatic backups are useful only if retention, keys, permissions, and restoration procedures support the required recovery.

Name the operator and decision owner for each layer: cloud provider, platform team, workload team, and data owner. A provider can restore healthy infrastructure while the application still publishes the wrong partition. Conversely, a correct transform cannot repair a missing route by changing its business logic. Define escalation and evidence across the boundary instead of assigning every failure to “the cloud.”

Reference: AWS shared responsibility model.

Availability and recovery need the whole path

A retry can replace a failed worker if its inputs remain available and unfinished output is not treated as published. The scheduler must avoid uncontrolled duplicate publication, and the database, network path, credentials, and output reference must still work. Two workers improve little if both rely on one failing component. For a batch job, recovery may mean safely resuming before the deadline rather than keeping every worker continuously alive.

RPO, recovery point objective, states how much data loss measured in time is acceptable. RTO, recovery time objective, states how long service restoration may take after interruption. A retained recovery point from 09:50 at a 10:00 outage represents a ten-minute recovery-point gap; restoration at 10:40 takes forty minutes. These observations meet an RPO of fifteen minutes and an RTO of one hour for that exercise, but do not prove future incidents will. Check source completeness and all dependent state, not just the backup timestamp.

Reference: Recovery point and recovery time objectives.

A recovery exercise should restore into an isolated destination, verify data and application behavior, and include credentials, encryption keys, configuration, and routing. Keep a versioned definition of the infrastructure, review planned changes, and detect configuration drift. Infrastructure as code helps reproduce intended configuration; it does not reconstruct lost data or guarantee a successful rollback. Resource deletion and schema changes may need a forward repair or retained snapshot.

Estimate the bottleneck before adding workers

Suppose each worker can read at 25 MiB/s, the shared path can sustain 100 MiB/s in total, and non-overlapping setup, transformation, and publication work adds 300 seconds. We assume the input splits evenly and throughput stays constant. Transfer time is input size divided by the smaller of aggregate worker throughput and shared-path throughput. The model then adds the 300 seconds. This deliberately simple estimate omits contention, skew, failures, and measurement uncertainty.

from math import ceil

def estimate(workers, *, input_mib=100 * 1024, per_worker_mib_s=25,
             shared_mib_s=100, other_seconds=300,
             connections_per_worker=4, connection_budget=24, deadline_seconds=1800):
    if type(workers) is not int or workers <= 0:
        raise ValueError("workers must be a positive integer")
    if input_mib < 0 or other_seconds < 0:
        raise ValueError("sizes and durations must not be negative")
    if per_worker_mib_s <= 0 or shared_mib_s <= 0:
        raise ValueError("throughput must be positive")
    throughput = min(workers * per_worker_mib_s, shared_mib_s)
    seconds = ceil(input_mib / throughput) + other_seconds
    connections = workers * connections_per_worker
    fits = seconds <= deadline_seconds and connections <= connection_budget
    return seconds, connections, fits

for workers in (1, 2, 4, 8):
    seconds, connections, fits = estimate(workers)
    print(f"workers={workers} seconds={seconds} connections={connections} fits={fits}")
# workers=1 seconds=4396 connections=4 fits=False
# workers=2 seconds=2348 connections=8 fits=False
# workers=4 seconds=1324 connections=16 fits=True
# workers=8 seconds=1324 connections=32 fits=False
assert estimate(4) == (1324, 16, True)
assert estimate(8)[0] == estimate(4)[0]

Four workers fit the model’s deadline and 24-connection budget, which is the allowance for this job after other clients are reserved. Eight have the same modeled duration because the link is already saturated, and they exceed the connection allowance. This identifies a candidate to benchmark rather than an instance count to deploy blindly. If the actual transform is CPU-bound or the input cannot split evenly, the model must change. The 100 GiB input uses 102,400 MiB; mixing decimal GB with binary MiB would change the calculation.

Cost follows lifetime, retained data, and traffic

Compute time is only part of a bill. Include retained storage and versions, requests, database capacity, logging, and billable network paths such as internet egress or particular cross-zone, cross-region, NAT, or endpoint usage. Which paths are charged depends on the service and agreement. Turning off a worker need not remove its disks, snapshots, addresses, or standing services. Budget alerts report a threshold; they are not necessarily a spending cap.

The following monthly worksheet uses invented USD rates, no provider price list. Assume 30 runs, four workers billed for 23 minutes each per run, an average of 1,000 GiB retained all month, 300 GiB of billable transfer, 300,000 object operations, and 50 GiB of log ingestion. The 23 minutes is an illustrative rounded allowance around the earlier 1,324-second estimate, not a real billing rule. The subtotal excludes database capacity, standing network services, retries, taxes, and discounts.

from decimal import Decimal

costs = {
    "compute": Decimal(30 * 4 * 23) / 60 * Decimal("0.12"),
    "storage": Decimal(1000) * Decimal("0.02"),
    "transfer": Decimal(300) * Decimal("0.05"),
    "object_operations": Decimal(300000) / 1000 * Decimal("0.004"),
    "log_ingestion": Decimal(50) * Decimal("0.10"),
}
# Rates: USD/worker-hour, USD/GiB-month, USD/GiB transferred,
# USD/1000 operations, and USD/GiB logs, respectively; all fictional.
for name, value in costs.items():
    print(f"{name}: USD {value:.2f}")
# compute: USD 5.52
# storage: USD 20.00
# transfer: USD 15.00
# object_operations: USD 1.20
# log_ingestion: USD 5.00
subtotal = sum(costs.values(), Decimal(0))
print(f"modeled subtotal: USD {subtotal:.2f}")
# modeled subtotal: USD 46.72
assert subtotal == Decimal("46.72")

Here transfer costs more than compute, so halving worker runtime would not halve the subtotal. The omitted database or a standing network service could dominate a real bill. Record units, resource lifetime, route, and retention before comparing alternatives. Replace every invented rate with a dated rate for the chosen service, region, and commercial terms when making a purchase decision.

Read an incident by following the request

Observation	First evidence to inspect	What it does not prove
Worker never starts	Scheduler events, image pull, capacity/quota, runtime identity	The transformation code is wrong
Name resolves, connection times out	Destination, route, firewall, return path, service availability	Adding an IAM allow will repair connectivity
Service responds with access denied	Actual caller, action/resource, policy and key context	All traffic took the intended private route
More workers but no speed gain	CPU, memory/spill, shared throughput, DB waits, skew	The cloud needs a bigger machine in every case
Job succeeds but output is stale	Input version, validation, publication pointer, consumer cache	Healthy infrastructure guarantees fresh business data

Correlate scheduler events, application logs, service request IDs, metrics, and audit records using the same run identity and time window. Metrics show quantities such as queue age or throughput; logs explain events; traces connect supported request spans; audit records identify control or data actions where logging is enabled. None automatically contains every failure. Avoid logging credentials or sensitive payloads, and make sure the operator has access to the evidence before an incident.

Exercises: explain the boundary before changing it

1. A worker restarts halfway through a batch. It used local scratch files, wrote three candidate objects, and had not published the manifest. Describe what a replacement worker needs and what consumers should see.

The replacement needs the retained input version, code/configuration, runtime identity, and a known restart or checkpoint protocol. Consumers should continue following the last validated publication reference. Candidate objects may be reused only if the protocol validates them; otherwise regenerate or clean them up later. If consumers list a candidate prefix directly, the publication boundary is already broken. This is a design exercise, not an executed failure injection.

2. A private endpoint exists, but reading an encrypted object returns access denied. List the next checks without granting administrator access.

Identify the actual responding service and request ID, runtime principal, exact object action/key, and applicable identity/resource/endpoint policies. If a customer-managed encryption key is involved, inspect its authorization too. Verify that DNS and routing selected the intended endpoint; receiving an error does not establish the intended route. Distinguish a denied object read from a denied listing operation. Then test the smallest corrected permission in an isolated environment.

3. Double the input to 200 GiB in the capacity model. Does adding eight workers meet the original deadline? What would have to change?

Four and eight workers both model 2,348 seconds at the 100 MiB/s shared limit, beyond 1,800 seconds; eight also exceed the connection allowance. Reducing input, increasing measured shared throughput, or revising the deadline are different options. A faster path alone does not remove the database connection constraint. Recalculate and benchmark the complete path before selecting an option.

4. Replicas are healthy, but a bad release overwrote the published data. Explain why adding a replica is insufficient and what a recovery exercise must establish.

Replication may have copied the bad change. Find an approved prior data version or replayable input and compatible code, restore with working keys and permissions, validate the result, then switch the publication reference through its supported procedure. Measure the usable recovery point and time to restored service against RPO/RTO. Also fix the validation or publication defect so the same release cannot repeat the damage.

You should be able to draw the compute location, persistent state, network path, and principal for every request in this job, then explain who acts when one fails.