What is the difference between horizontal and vertical scaling?
Vertical scaling makes a single instance bigger by adding CPU, memory, or faster storage, while horizontal scaling adds more instances and spreads load across them behind a load balancer. Vertical scaling is simple and needs no code changes but hits a hardware ceiling and leaves a single point of failure; horizontal scaling has effectively no ceiling and tolerates instance loss, but requires the workload to be stateless or to keep state in an external store. Cloud-native designs default to horizontal scaling and treat vertical scaling as a quick early step.
When should I use containers versus virtual machines?
Use containers when you want fast startup, high density, and portable, immutable application packaging, especially for microservices and horizontally scaled stateless services that share the host kernel. Use virtual machines when you need strong isolation, a different or full operating system, kernel-level control, or to run legacy software that assumes a complete OS. Many real architectures combine both, running containers on top of VM-based worker nodes.
What is the difference between IaaS, PaaS, and serverless?
IaaS gives you raw virtual machines, storage, and networking, leaving the OS, runtime, and application as your responsibility, which maximises control and portability. PaaS provides a managed platform that builds, deploys, scales, and routes your code so you skip server management, at the cost of following the platform's conventions. Serverless goes further still: the provider runs your code per event, scales it to zero when idle and out under load, and bills per invocation and execution time, shifting all capacity planning and patching to the provider.
How do I choose a cloud region?
Pick a region by weighing latency to your users, data-residency and compliance requirements, the cost of compute and egress in that region, and which services are actually available there, since service catalogues differ by region. For most applications, latency to the primary user base and legal residency dominate the decision. If you serve a global audience, combine a primary region with a CDN and consider multi-region only when latency or availability targets genuinely require it.
What is Infrastructure as Code and why does it matter?
Infrastructure as Code defines your cloud resources in version-controlled definition files and provisions them automatically, instead of clicking through a console. It matters because it makes environments reproducible, reviewable in pull requests, and auditable, and it lets you stamp out identical staging and production environments and recover them after disasters. Declarative tools such as Terraform converge resources to a desired state, so re-running the same definition is safe and idempotent.
How can I control and reduce my cloud bill?
Start with visibility: tag every resource and attribute spend to teams or products so cost becomes an engineering metric rather than a surprise invoice. Then optimise - right-size over-provisioned instances, delete idle resources, commit to reserved instances or savings plans for steady baseline load, use spot instances for interruptible work, and watch data-egress charges, which often dominate. This continuous practice of cost accountability across engineering and finance is known as FinOps.
What is the difference between high availability and disaster recovery?
High availability is about surviving routine component failures within a region through redundancy and automatic failover, so individual server, zone, or replica failures cause little or no downtime. Disaster recovery is about restoring service after a large-scale event, such as a whole region becoming unavailable, and is defined by a recovery time objective and a recovery point objective. HA reduces the frequency of downtime; DR limits the impact when something major still goes wrong despite HA.
How do I keep my backend resources off the public internet?
Place backend services and databases in private subnets within a VPC, where instances have no public IP and no inbound route from the internet, and expose only a load balancer or API gateway in a public subnet. Outbound access for updates and third-party APIs goes through a NAT gateway, which lets private instances initiate connections without being reachable from outside. Combine this with tight security groups, least-privilege IAM, and a web application firewall at the edge.
What are availability zones and how should I use them?
Availability zones are isolated data centres within a region, each with independent power, cooling, and networking, connected by low-latency links. You use them by spreading your instances, replicas, and database standbys across at least two zones so the loss of one zone does not take down your workload. Multi-AZ deployment is the baseline for high availability and is usually far cheaper and simpler than going multi-region.
What is the difference between blue-green and canary deployments?
Blue-green deployment keeps two full production environments and switches all traffic from the old to the new version at once after verification, giving instant rollback by switching back. Canary deployment instead shifts a small slice of traffic to the new version, watches error rate and latency, and ramps up gradually only if metrics stay healthy. Blue-green optimises for instant, all-or-nothing cutover; canary optimises for limiting the blast radius and catching problems before full exposure.
Why is my cloud egress bill so high?
Egress - data leaving the provider's network toward the internet or another region - is billed per gigabyte, whereas inbound traffic is usually free, so data-heavy or chatty cross-region designs accumulate charges quickly. Common culprits are cross-region replication, CDN cache misses pulling repeatedly from the origin, and APIs returning large payloads to many users. You reduce it by serving cacheable content through a CDN, keeping traffic within a region, compressing responses, and avoiding unnecessary cross-region data movement.
When do I actually need Kubernetes?
You need Kubernetes when you are running many containerised services that require automated scheduling, self-healing, rolling updates, service discovery, and horizontal autoscaling across a cluster, and you have the operational maturity to run it. For a small number of services, a managed container platform or a PaaS often delivers the same outcome with far less complexity. Adopt Kubernetes when its abstractions solve real problems you have, not pre-emptively, and prefer a managed control plane to avoid operating the cluster's brain yourself.
What is the difference between RTO and RPO?
The recovery time objective (RTO) is how quickly you must restore service after an outage, and the recovery point objective (RPO) is how much data loss, measured in time, you can tolerate. A tight RTO pushes you toward warm-standby or active-active architectures that are always ready, while a tight RPO requires frequent or synchronous replication. Both are business decisions: you set them by weighing the cost of the architecture against the cost of downtime and data loss.
Should I use spot instances in production?
Spot instances are spare capacity at a steep discount that the provider can reclaim on short notice, so they belong on fault-tolerant, interruptible workloads such as batch jobs, CI runners, and stateless web tiers fronted by a queue or load balancer. They are unsuitable for stateful or latency-critical services that cannot tolerate sudden eviction. You can run a large share of suitable workloads on spot to cut cost dramatically, provided you diversify instance types and handle interruption gracefully.
What is a service mesh and do I need one?
A service mesh is an infrastructure layer, usually implemented as sidecar proxies, that handles service-to-service networking - load balancing, retries, mutual TLS, and telemetry - transparently to your application code. It gives uniform security and observability across many microservices without each team re-implementing them. You need one when you have enough services that consistent traffic management, encryption, and tracing become a real burden; for a handful of services its added latency and operational overhead rarely pay off.
How should I manage secrets in cloud infrastructure?
Never hardcode secrets in code, images, or Infrastructure-as-Code files; store them in a dedicated secrets manager and inject them at runtime through environment variables or mounted volumes with tightly scoped access. Use short-lived, automatically rotated credentials and workload identities (such as instance roles or service accounts) instead of long-lived static keys wherever possible. Audit access, encrypt secrets at rest and in transit, and keep Terraform state - which can contain secrets - in a secured, access-controlled backend.
What is zero trust in a cloud context?
Zero trust is a security model that grants no implicit trust based on network location and instead verifies the identity, device, and context of every request before granting least-privilege access. In the cloud it replaces the old "trusted internal network" perimeter with strong identity, mutual TLS between services, and policy enforced per request. It limits lateral movement: even an attacker who breaches one component cannot freely reach others, because each interaction is independently authenticated and authorised.