Cloud-Infrastructure

Overview Single-region deployments run all infrastructure and data in one geographic location, keeping operations simple but exposing the system to regional outages and higher latency for distant users. Multi-region deployments replicate infrastructure and data across multiple geographic locations, trading operational simplicity for resilience and locality. The right choice depends on your availability targets, compliance needs, and how much complexity your team can absorb. Comparison Diagram Single-RegionMulti-Regionus-east-1Load BalancerApp ServersPrimary DatabaseRegion outage = full downtimeeu-west-1App ServersDB Replicaap-south-1App ServersDB ReplicaGlobal Routerdata syncOne region fails, others serve traffic Comparison Table Aspect Single-Region Multi-Region Request entry point Single DNS/load balancer target in one region Global load balancer or DNS routing to nearest healthy region Data placement One primary datastore, one location Data replicated or partitioned across regions Consistency model Straightforward strong consistency within one datastore Trade-offs between strong and eventual consistency across replicas Latency for global users High latency for users far from the region Low latency via routing to the closest region Failure blast radius Regional outage takes down the entire system Regional outage degrades capacity but other regions keep serving Deployment and rollout complexity Single pipeline, single environment to manage Coordinated rollouts, versioning, and config across regions Cost profile Lower infrastructure and data transfer cost Higher cost from duplicated infrastructure and cross-region transfer Compliance and data residency Limited to rules of the single region Can satisfy data residency laws by keeping data in-region Key Differences Single-region has one failure domain; multi-region isolates failures so an outage in one region doesn’t take the whole system down Multi-region requires solving data replication and consistency across distant datastores, which single-region avoids entirely Multi-region cuts latency for geographically dispersed users by serving requests from the nearest region Multi-region needs a global router or DNS-based traffic manager, adding a layer absent in single-region setups Operational and infrastructure cost scales up sharply with each additional region When to Use Each Single-Region ...

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 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 Declarative IaC (e.g. Terraform, CloudFormation) has you specify the desired end state of infrastructure and lets an engine figure out how to get there. Imperative IaC (e.g. shell scripts, Chef recipes, raw CLI calls) has you write the exact sequence of commands to execute. The distinction matters because it determines who — you or the tool — is responsible for ordering, idempotency, and reconciling drift. Comparison Diagram DeclarativeDesired State"3 servers, 1 LB"Engine Computes Diffplan + dependency graphInfrastructureconverges to match stateEngine decides how & in what orderImperativeStep 1: Create VPCStep 2: Launch ServersStep 3: Attach LBInfrastructureAuthor decides exact steps & order Comparison Table Aspect Declarative Imperative Authoring model Write a desired-state spec Write an ordered command list Execution engine Resolves a dependency graph Runs a sequential interpreter State tracking Maintains a state file Stateless execution Applying changes Single apply command Run the script/playbook Ordering & dependencies Auto-resolved by engine Manually sequenced by author Idempotency Guaranteed by design Developer-enforced Drift detection Built-in plan diff Not built-in Failure handling Partial apply, replan Manual rollback Key Differences Declarative code answers ‘what’, imperative code answers ‘how’. Declarative tools rely on a state file to know current vs. desired infrastructure; imperative scripts have no memory of prior runs. Idempotent re-runs are automatic in declarative tools but must be hand-coded (checks, conditionals) in imperative scripts. Declarative engines build a dependency graph to order operations; imperative code hardcodes that order line by line. Drift correction in declarative IaC is a matter of re-running plan/apply; imperative approaches require re-running or rewriting the exact script. When to Use Each Declarative ...