Overview Auto scaling and manual scaling both change how much compute capacity an application has, but they differ in who — or what — decides when that change happens. Auto scaling relies on an automated feedback loop that watches metrics and reacts on its own, while manual scaling depends on human intervention to notice load and issue the change. That difference in decision-maker drives everything else: reaction speed, cost efficiency, and how much ongoing attention the system needs. ...

Overview Edge computing and cloud computing both run workloads away from the end-user device, but they differ in where that processing physically happens relative to the data source. Edge computing pushes compute to nodes near the device to cut latency, while cloud computing centralizes it in remote data centers for scale and simplicity. The choice shapes latency budgets, bandwidth costs, and how much infrastructure you have to manage yourself. Comparison Diagram Where Processing HappensEdge ComputingDeviceEdgeNode~1-5 ms round tripCloud ComputingDeviceCloudDataCenter~50-150 ms round trip, multiple network hopsSame device, two distances to compute Comparison Table Aspect Edge Computing Cloud Computing Processing location Local nodes, gateways, or on-device hardware near the data source Centralized data centers operated by the provider, often far from the source Latency Single-digit to low double-digit milliseconds due to physical proximity Tens to hundreds of milliseconds depending on distance and network path Network dependency Can operate with intermittent or low-bandwidth connectivity to the core network Requires a stable, sufficiently fast connection to reach the data center Bandwidth usage Filters or pre-processes data locally, sending only summaries upstream Raw data typically travels over the network to be processed centrally Compute and storage capacity Limited by the size and power of local hardware Effectively unlimited, elastic capacity provisioned on demand Data handling and privacy Sensitive data can be processed and stay on-site, reducing exposure Data leaves the local environment and is subject to provider-side controls Scalability and management Scaling means deploying and maintaining more physical nodes across sites Scaling is a configuration change managed by the provider Cost model Upfront hardware and per-site operational costs Pay-as-you-go operating expense with no hardware to own Key Differences Edge computing minimizes latency by keeping processing physically close to the data source Cloud computing offers far greater elastic capacity since it draws on a shared, centralized pool of resources Edge deployments reduce bandwidth costs by filtering data before it ever leaves the site Cloud computing is simpler to manage since there’s no distributed hardware fleet to maintain Edge nodes can keep sensitive data local, while cloud centralization concentrates data in provider infrastructure When to Use Each Edge Computing ...

Overview A load balancer spreads incoming traffic across many identical backend servers so no single machine gets overwhelmed, while a reverse proxy sits in front of one or more servers to mediate, secure, and transform requests on their behalf. The two overlap heavily in practice — most modern reverse proxies (NGINX, Envoy, HAProxy) can also load balance — but the distinction matters when you’re deciding which capability you actually need to configure or scale for. ...

Overview A managed database hands the operating system, patching, backups, and failover to a cloud provider, while a self-hosted database keeps the entire stack under your team’s direct control. The choice trades operational convenience against flexibility, cost structure, and how much low-level tuning you’re allowed to do. Comparison Diagram Managed DatabaseSelf-Hosted DatabaseApplication / QueriesProvider ManagesDB EngineOperating SystemHardware / StorageLess control, less toilYou Manage EverythingApplication / QueriesDB EngineOperating SystemHardware / StorageMore control, more toil Comparison Table Aspect Managed Database Self-Hosted Database Provisioning & setup Spin up via console or API in minutes; provider installs and configures the engine Manually install and configure the OS, storage, and database software yourself Configuration & tuning access Limited to exposed parameters and flags; some engine internals and OS access are locked Full root or admin access to every config file, kernel setting, and storage layout Scaling Resize compute or add read replicas with a click or API call; provider automates the process Provision new hardware and reconfigure sharding or replication topology yourself Backups & recovery Automated snapshots and point-in-time restore built into the service You script, schedule, and test your own backup and restore procedures Patching & upgrades Provider applies OS and engine security patches on a maintenance schedule You plan, test, and execute every patch and major version upgrade High availability & failover Multi-AZ replication and automatic failover configured with a toggle You design, build, and test the replication and failover setup yourself Monitoring & support Built-in dashboards and alerts, plus vendor support tickets for engine-level issues You assemble your own monitoring stack; support is internal or community-based Cost model Higher per-hour price that bundles operational labor into the bill Lower raw infrastructure cost but a hidden cost in engineering time Key Differences Managed services abstract patching and OS maintenance behind a provider SLA. Self-hosted setups grant full root access to tune kernel, storage, and engine internals. Failover and multi-AZ replication are automated in managed offerings but hand-built elsewhere. Cost shifts from engineering hours to a recurring subscription fee with managed databases. Self-hosting permits any custom extension or fork that managed platforms often restrict. When to Use Each Managed Database ...

Overview A snapshot captures a volume’s state using copy-on-write pointers that still depend on the original data, while a backup creates a fully independent copy stored elsewhere. The distinction matters because snapshots are fast and space-efficient for short-term rollback, but only backups protect against loss or corruption of the source system itself. Comparison Diagram Source Volumepointer (COW)full copySnapshotreferences source blocksSame volume, low overheadInvalid if source is lostBackupindependent full copySeparate storage, survives lossSlower, higher storage cost Comparison Table Aspect Snapshot Backup Primary purpose Quick rollback to a prior state Durable copy for disaster recovery and compliance Capture mechanism Copy-on-write or redirect-on-write pointers to existing blocks Full or incremental copy of data written to separate storage Storage location Same storage system or volume as the source Separate system, often offsite or on a different medium Dependency on source Invalidated if the source volume is deleted or corrupted Independent copy, survives loss of the source Creation speed and overhead Near-instant, minimal I/O impact Slower, with higher I/O, network, and storage cost Retention and lifecycle Short-lived, few kept because storage grows with changes Long-term retention on a scheduled rotation policy Recovery scope Instant rollback on the same system or volume Restore to a new or different system, file- or volume-level Failure resilience Vulnerable to the same hardware or storage failure as the source Resilient to source failure or a site-wide disaster Key Differences A snapshot stores pointers to existing blocks; a backup writes a full, separate copy of the data. Snapshots normally live on the same storage as the source; backups are placed on independent, often offsite media. Deleting the source volume can invalidate a snapshot, while a backup remains intact and restorable. Snapshots are created almost instantly with low overhead; backups take longer and consume more storage and bandwidth. Snapshots are typically kept briefly for rollback; backups follow a long-term retention policy for compliance. When to Use Each Snapshot ...

Overview Both connect a VPC to the internet, but they serve opposite purposes: an Internet Gateway lets public-facing resources send and receive traffic directly, while a NAT Gateway lets private resources reach out without ever being reachable from outside. Picking the wrong one either exposes resources you meant to keep private or silently blocks the outbound access your servers need. Comparison Diagram Internet GatewayNAT GatewayInternetInternetno inboundIGWNAT GatewayPublic SubnetInstancehas public IPPrivate SubnetInstanceprivate IP onlybidirectional trafficoutbound only Comparison Table Aspect Internet Gateway NAT Gateway Primary purpose Enables communication between a VPC and the internet in both directions Enables outbound-only internet access for resources without public IPs Traffic direction Bidirectional — accepts inbound connections and sends outbound Outbound only — inbound traffic allowed only as replies to established connections Placement Attaches directly to the VPC as a whole Deployed inside a specific public subnet IP address handling 1:1 NAT between a private IP and an Elastic/public IP Many-to-one PAT — many private IPs share the gateway’s public IP Which resources use it Instances with a public/Elastic IP routed via a public subnet route table Instances with only private IPs routed via a private subnet route table Scaling and availability Managed, horizontally scaled, highly available with no bandwidth cap Bandwidth-bounded per gateway; needs one per AZ for high availability Cost model No hourly charge and no data processing fee Hourly charge plus per-GB data processing fee Failure impact Loss cuts off all direct internet reachability for the public subnet Loss cuts off outbound internet access for the private subnet only Key Differences Internet Gateway provides bidirectional access; NAT Gateway only permits outbound connections. Internet Gateway attaches to the whole VPC; NAT Gateway lives inside a specific subnet. Internet Gateway does 1:1 Elastic IP mapping; NAT Gateway does many-to-one PAT. NAT Gateway bills per GB processed; Internet Gateway is free. When to Use Each Internet Gateway ...

Overview An Availability Zone is one or more physically isolated data centers with independent power, cooling, and networking, while a Region is a broader geographic area made up of multiple such zones connected by low-latency links. The distinction matters because it determines what kind of failure your architecture survives — a single data-center outage versus a region-wide disaster — and what compliance jurisdiction your data falls under. Comparison Diagram Availability ZoneDCDC1+ data centers,independent power & networkRegionAZAZAZMultiple AZs,low-latency links Comparison Table Aspect Availability Zone Region Definition One or more discrete data centers with independent power, cooling, and networking A geographic area containing multiple availability zones Physical composition Typically 1+ physical data center buildings Multiple AZs (often 3 or more) plus regional network backbone Inter-node latency Sub-millisecond to a few milliseconds over private links between AZs Tens to hundreds of milliseconds over public/backbone links between regions Failure isolation Isolates against power, cooling, or single data-center failures Isolates against natural disasters or systemic events affecting an entire geography Redundancy pattern used for High availability within one geographic area Disaster recovery and global latency reduction across geographies Data residency & compliance No effect — all AZs in a region share the same jurisdiction Determines the legal jurisdiction and data residency boundary Data transfer cost Low intra-region rate for traffic between AZs Higher inter-region or egress rate for traffic between regions Key Differences An Availability Zone is one or more data centers, while a Region is the geographic area that groups several AZs together Inter-AZ traffic uses low-latency private links; inter-region traffic crosses public backbone networks with far higher latency Multi-AZ deployments protect against data-center outages; multi-region deployments protect against regional disasters Region choice fixes your data residency and compliance jurisdiction — AZ choice does not Cross-AZ transfer is cheap; cross-region transfer incurs higher egress costs When to Use Each Availability Zone ...

Overview Both are ways to rent compute capacity from a cloud provider, but they trade cost against reliability in opposite directions. Spot Instances tap into unused capacity at steep discounts but can be reclaimed with almost no notice, while On-Demand Instances cost more per hour in exchange for a guaranteed, uninterrupted slot. Comparison Diagram Timeline of a running workloadOn-Demand InstanceReserved for you, no interruptionsRuns continuously until you stop itSpot InstanceRunning!2-min warningthen reclaimedResumes on new capacityUp to 90% cheaper, but availability is never guaranteed Comparison Table Aspect Spot Instances On-Demand Instances Request & provisioning Fulfilled only if provider has spare capacity at your bid price Fulfilled immediately from reserved capacity pools Capacity guarantee None — provider can reclaim the instance at any time Guaranteed for as long as you keep paying Pricing model Variable, set by real-time supply and demand for spare capacity Fixed hourly rate published by the provider Interruption behavior Reclaimed with a short warning (e.g. ~2 minutes on AWS) Never interrupted by the provider; you control shutdown Cost predictability Fluctuates; can spike or be revoked when demand rises Stable and predictable, easy to forecast in a budget Ideal workloads Fault-tolerant, stateless, or checkpointable batch jobs Stateful, latency-sensitive, or continuously running services Termination control Provider-initiated; your app must handle abrupt shutdown User-initiated; you decide exactly when it stops Key Differences Spot pricing floats with market demand and can be up to 90% cheaper than On-Demand rates Spot capacity is reclaimable at any time, typically with only a short warning window On-Demand gives a firm capacity guarantee that Spot never promises Workloads on Spot need to tolerate sudden termination or design for checkpointing On-Demand cost is fixed and predictable, while Spot cost is variable and market-driven When to Use Each Spot Instances ...

Overview In serverless and containerized systems, a cold start happens when a request must wait for a new execution environment to be provisioned and initialized before it can run, while a warm start reuses an already-running instance and skips straight to execution. The gap between the two explains why the same function can respond in 5ms or 2 seconds depending on whether an idle instance was standing by. Comparison Diagram Cold StartReqProvisioncontainerInit runtime+ codeExecutelatency: tens of ms - several secondsWarm Startidle, pre-initialized container waitingReqExecutelatency: sub-ms - low tens of ms Comparison Table Aspect Cold Start Warm Start Trigger condition No idle instance available (scale-to-zero, scale-out, or fresh deploy) Idle, already-initialized instance is available to handle the request Environment state at invocation No running process; container or sandbox must be created from scratch Process is already running in memory from a prior invocation Steps performed Provision compute, load code, initialize runtime and dependencies, run init code, then handle request Skip provisioning and init; execute the handler directly on the existing process Typical latency added Tens of milliseconds to several seconds depending on runtime and package size Sub-millisecond to low tens of milliseconds Resource cost to provider Higher; allocates new compute, memory, and network setup Lower; reuses resources already allocated Frequency of occurrence Rare relative to total traffic but concentrated after idle periods, deploys, or scale-out Common; most requests during steady, active traffic Primary mitigation Provisioned concurrency, smaller packages, lighter runtimes, scheduled pings Sustained traffic, minimum instance counts, connection reuse Key Differences Cold start pays full provisioning overhead; warm start reuses an already-initialized process. The latency gap can span orders of magnitude — low milliseconds versus multiple seconds. Cold starts are triggered by scale-to-zero or scale-out events, not by what the request contains. Whether a start is warm depends on the platform’s idle timeout before it reclaims the instance. Avoiding cold starts usually means paying for reserved capacity to keep instances standing by. When to Use Each Cold Start ...

Overview A CDN is a distributed network of edge servers that caches and delivers content close to users, while the origin server is the single authoritative source where that content is created or stored. The distinction matters for latency, scalability, and resilience, since most requests should never need to reach the origin at all. Comparison Diagram ClientCDNDistributed edge locationsCache: static & edge-computed contentOrigin ServerSingle sourceof truthrequestcached responseon cache missorigin pull & cacheMost requests resolve at the edge; only misses/dynamic content reach the origin Comparison Table Aspect CDN Origin Server Role in request path Intercepts requests at the edge and serves cached content directly Authoritative backend that generates or stores the original content Geographic distribution Many points of presence worldwide, close to end users Typically one or a few fixed data center locations Content served Cached copies of static assets or cacheable API responses Dynamically generated pages or master copies of files Cache miss handling Forwards uncached requests to the origin and stores the response per TTL Processes every request that reaches it; has no caching layer of its own Latency Low, since content is served from the nearest edge node Higher, since every request travels to one fixed location Load on backend Absorbs most traffic, shielding the origin from direct load Only handles cache misses and non-cacheable requests Resilience to outages Can keep serving stale cached content if the origin goes down Site is effectively unavailable for anything not already cached elsewhere Scaling and cost Scales via the CDN provider’s global network, billed per bandwidth/requests Must be scaled and provisioned directly, billed for compute and hosting Key Differences CDN content lives on distributed edge nodes; the origin server is the single source of truth. CDN caching cuts latency for users, but every cache miss still lands on the origin. CDN edge caching gives resilience against origin outages by serving stale content. Origin servers own dynamic content generation; CDNs only store what’s actually cacheable. When to Use Each CDN ...