Regions, availability zones, and autoscaling

Two important questions remain about cloud resources: where in the world are they running? Who decides how many of them should be running?

These questions sound like infrastructure details, but their answers affect product speed, legal obligations, reliability, and cost.

Cloud providers organize their physical infrastructure into regions and availability zones, and they also provide autoscaling, which allows systems to increase or decrease computing capacity as demand changes.

What is a cloud region?

A regionConcept · lights on your mapregionA geographic area in which a cloud provider operates infrastructure: us-east-1 (Northern Virginia), eu-west-1 (Ireland). Choosing one affects latency, data residency and law, resilience, and cost: a product decision wearing a dropdown. is a geographic area in which a cloud provider operates infrastructure.

Each region is identified by a name or code. AWS uses names such as us-east-1 for its Northern Virginia region and eu-west-1 for its Ireland region.

Other providers use their own naming systems.

A region is not one server or one building. It contains several isolated infrastructure locations, commonly organized as availability zones.

When a team creates a cloud resource, it often chooses the region in which that resource should run.

That choice affects several parts of the product.

Region choice affects latency

In Module 4, you learned that network communication involves physical travel, and even though information moves extremely quickly, distance still matters.

If a user in Sydney sends a request to a server in Northern Virginia, the request must cross a large geographic distance before the server can process it. Then the response must travel back.

This adds latency.

A request might travel:

So running the application closer to the user can reduce that round-trip time.

This is especially important for products involving interactive applications, real-time communication, online games, video or audio, financial trading, repeated API requests, or mobile users on slower networks.

A small delay in one request may seem harmless, but if a page requires many sequential requests, the delays can accumulate into a noticeably slower experience.

Region choice is a product decision

If most of the coffee application’s customers live in the eastern United States, running the backend in Northern Virginia may provide acceptable performance for those users.

If the product expands to Australia, the company must decide whether to continue serving Australian users from Virginia or operate infrastructure closer to them.

That decision affects user experience, infrastructure complexity, database design, data synchronization, cost, operational support, and legal and contractual requirements.

Selecting a cloud region therefore reaches beyond server placement. It can become a product and business decision.

Data residency

Data residency refers to requirements or decisions about the geographic location where data is stored or processed.

A company might need to keep certain information in a particular country or region because of local laws, industry regulations, government contracts, customer agreements, internal risk policies, or data-sovereignty concerns.

For example, an enterprise customer may require its information to remain within the European Union.

Choosing a European cloud region can help the product satisfy that requirement.

However, privacy law is more nuanced than: “European data must always stay in Europe.”

The GDPR can permit certain international data transfers when appropriate legal protections and mechanisms are in place.

The specific requirement depends on the data, countries, contract, organization, and applicable law.

The useful technical lesson is: where data is stored and processed can have legal and contractual consequences.

Data residency involves more than the database

A company cannot satisfy a residency requirement merely by placing its primary database in the correct region. That is because copies of the information may also appear in backups, logs, analytics systems, caches, search indexes, monitoring tools, customer-support platforms, third-party services, and disaster-recovery environments.

The company must understand the complete data flow. For example:

If one downstream system transfers the data elsewhere, the overall design may no longer satisfy the intended residency policy.

Data location is therefore a system-wide concern.

Regions and failure boundaries

Regions are also used as failure boundaries. A failure domain is an area of infrastructure that can be affected by the same problem.

A severe regional incident might involve major network disruption, power-system failures, control-system problems, natural disasters, software configuration errors, or provider-wide service failures within the region.

Running everything in one region means that a sufficiently large regional failure can affect the entire product.

Protection against failure starts at a smaller scale, inside the region itself.

What is an availability zone?

An availability zoneConcept · lights on your mapavailability zoneAn isolated infrastructure location within a region (an AZ), with separate power, cooling, facilities, and networking, connected to sibling zones by fast links. Running components across two or more AZs is the standard redundancy move against one location’s bad day., commonly shortened to AZ, is an isolated infrastructure location within a cloud region.

An availability zone may consist of one or more physical data centers.

Availability zones within the same region are designed to have separation in areas such as power, cooling, physical facilities, and networking infrastructure.

They are also connected through high-speed networks so applications can communicate across them with relatively low latency.

A simplified region might look like:

The exact internal design is controlled by the provider and can be more complex than this diagram.

Why availability zones exist

Imagine that the coffee backend runs only in one facility. If that location loses power or network connectivity, the entire application may become unavailable.

Instead, the company could run backend instances across two availability zones:

• Availability Zone A → coffee backend instance 1
• Availability Zone B → coffee backend instance 2

If one zone experiences a failure, the system may continue serving requests through the other.

This is redundancy: maintaining additional resources so one failure does not remove the entire capability.

The design reduces reliance on one location as a single point of failure, and you will examine these reliability concepts more deeply in Module 10.

Multi-AZ design

A system that uses resources in more than one availability zone is commonly described as multi-AZ.

A multi-AZ application might contain backend instances in two or more zones, a load balancer distributing traffic across them, and a database with a standby copy in another zone. It might also contain replicated queues or managed services, along with network connections designed to survive one-zone failure.

A simplified architecture might look like:

If the backend instance in Zone A fails, the load balancer can send new traffic to the healthy instance in Zone B.

Not everything must be duplicated identically

Running critical components across multiple zones is a common reliability practice, but the exact design depends on the workload.

A temporary development environment may not need multi-AZ redundancy.

A production payment system probably needs stronger protection.

Some managed cloud services are already designed to use several availability zones behind the scenes, while others require the customer to configure redundancy explicitly.

Teams should ask:

• How important is this component?
• How long can it be unavailable?
• Can it be recreated?
• Does it contain authoritative state?
• What would multi-AZ operation cost?
• Does the provider already manage redundancy?

The correct answer depends on the product’s reliability requirements.

Availability zones reduce risk, not eliminate it

Availability zones are designed to limit shared infrastructure failures, but they should not be imagined as perfectly independent universes.

Several zones can still be affected by regional network problems, shared cloud control systems, software bugs, customer configuration mistakes, large natural disasters, dependencies deployed in only one zone, or incorrect failover procedures.

Multi-AZ design reduces the impact of many local failures, but it does not guarantee that the product can survive every possible incident.

What is blast radius?

The blast radius is the amount of a system affected when something fails or goes wrong.

If every backend instance and database lives in one availability zone, a zone failure has a large blast radius, while if the product is distributed across zones, the same local failure may affect only part of the capacity.

The concept also applies outside geography.

A configuration mistake applied to every region simultaneously can create a larger blast radius than a hardware failure limited to one building.

Reliability design often asks: how can we prevent one failure from affecting everything?

Regions and availability zones provide physical and geographic tools for limiting that impact.

When one region is not enough

A multi-AZ design still leaves the region itself as a shared failure domain. Some organizations therefore operate their most important systems across more than one region, perhaps with Northern Virginia as the primary region and Ohio as the recovery region.

If the primary region becomes unavailable, the company may attempt to move traffic to the recovery region.

This is called a multi-region design.

Running in multiple regions can improve resilience and user performance, but it introduces complexity.

The team may need to decide:

• Which region accepts writes?
• How is data copied between regions?
• What happens if the copies disagree?
• How quickly can traffic move?
• Are both regions active all the time?
• What happens to sessions?
• Can third-party dependencies operate in both places?
• How will failover be tested?
• How much does the additional infrastructure cost?

A second region does not automatically create a reliable disaster-recovery system. The application, databases, networking, and operational procedures must all support the design.

This is why many systems remain in one region, relying on availability zones for resilience within it.

Choosing the right geographic design

Cloud geography exists on several levels:

Each level provides a different kind of boundary.

A product might run near its users for speed, in a required jurisdiction for compliance, across several zones for availability, across several regions for disaster recovery, and at edge locations for static content.

The complete design balances latency, reliability, cost, data residency, and operational complexity.

There is no single correct region strategy for every application.

The second question: how many machines?

Choosing where machines run solves only part of the infrastructure problem. The company must also decide how many instances or containers should run.

Suppose the coffee backend normally receives 500 requests per minute. One instance might be sufficient.

During the morning commute, traffic may rise to 5,000 requests per minute, and one instance may become overloaded.

The team could permanently run ten instances, but most of that capacity might sit unused overnight, which is why cloud platforms provide autoscaling to adjust capacity as demand changes.

What is autoscaling?

AutoscalingConcept · lights on your mapautoscalingAutomatic adjustment of computing capacity according to configured rules or signals: a minimum, maximum, and desired count, scaled out when demand rises and in when it falls. The team defines the rules; the platform adjusts the fleet. automatically increases or decreases computing capacity according to configured rules or signals.

Instead of manually deciding “run exactly five instances forever,” the team defines boundaries, a minimum, a maximum, and a desired number of instances, and the system adjusts the active count within them.

A useful mental model is: the team defines the rules. The platform adjusts the fleet.

Minimum, maximum, and desired capacity

An autoscaling configuration commonly includes three numbers.

Minimum capacity

The smallest number of resources that should remain running: minimum: 2 can ensure that at least two backend instances remain available, potentially across different availability zones.

Maximum capacity

The largest number the system may create automatically.

For example, maximum: 40 prevents the platform from scaling without limit and creating an unexpectedly large bill or overwhelming downstream systems.

Desired capacity

The number of resources the system currently attempts to maintain.

For example, desired: 6. Autoscaling may adjust this number as demand rises or falls, while respecting the configured minimum and maximum.

Scaling out and scaling in

When the platform adds more instances, it is scaling out: 3 instances → 6 instances

When it removes instances, it is scaling in: 6 instances → 3 instances

You may also hear horizontal scaling for adding more machines.

A different approach is vertical scaling, which means making one machine larger: 4 CPUs and 16 GB RAM → 16 CPUs and 64 GB RAM

Cloud systems can use both approaches.

Autoscaling commonly refers to horizontal scaling, although some services can automatically adjust other resource dimensions as well.

Which signals trigger autoscaling?

Autoscaling does not need to rely only on CPU usage.

The platform might scale according to:

• CPU utilization
• Memory use
• Number of incoming requests
• Request latency
• Queue depth
• Number of active users
• Scheduled periods
• Custom business metrics

For example:

• If average CPU remains above 70%: add more instances.
• If average CPU remains below 30%: remove some instances.

A queue-processing system might instead use: if more than 10,000 jobs are waiting, add more workers.

A restaurant-order system might scale on a schedule before the expected dinner rush. The correct signal depends on what represents real pressure on the workload.

Autoscaling during the dinner rush

Imagine that the coffee application begins the evening with two backend instances:

• Zone A → instance 1
• Zone B → instance 2

Traffic increases rapidly during a promotion.

The monitoring system detects that request volume and CPU utilization have crossed the configured threshold, and autoscaling creates additional instances:

• Zone A → instances 1, 3, 5
• Zone B → instances 2, 4, 6

A load balancer begins sending requests to the new healthy instances.

Later, when traffic declines, autoscaling removes unnecessary capacity while preserving the minimum number of instances, so the product gains more capacity when it needs it and avoids paying for the full peak fleet at all times.

Autoscaling needs a way for traffic to reach new instances

Adding instances is useful only if traffic can reach them.

A load balancer receives incoming requests and distributes them among available backend instances.

A simplified flow is:

When autoscaling creates a new instance, the platform can register it with the load balancer after it becomes healthy, and when an instance is removed or fails, the load balancer stops sending it new requests.

The load balancer presents one stable destination while the machines behind it change, and you will explore load balancing more deeply in Modules 9 and 10.

Autoscaling needs health checks

Before sending traffic to a new instance, the platform needs to know whether it is ready, and a health check is a test used to determine whether a resource is functioning correctly.

The load balancer might ask: GET /health

A healthy backend may return: 200 OK

If the application crashes or cannot respond, the health check fails.

The platform can then stop sending traffic to the unhealthy instance, terminate it, create a replacement, and alert the engineering team.

Autoscaling therefore does more than react to traffic. It can also help maintain the desired number of healthy resources.

Stateless applications scale more easily

Autoscaling works best when backend instances are interchangeable.

Suppose Erik’s shopping cart exists only in the memory of instance 1.

His next request might be sent to instance 4, which knows nothing about the cart. This creates a problem.

Instead, important shared state should usually live in a system accessible to every instance, such as a database, a shared cache, object storage, or a session store.

Then any healthy backend instance can process Erik’s next request.

This is why temporary compute and persistent state are separated.

A useful principle is: replaceable machines scale easily when important state does not depend on one particular machine.

Stateful systems scale differently

Not every system is stateless. Databases, queues, and storage systems contain important state. Adding and removing them requires careful coordination so data is not lost or contradicted.

A frontend or API service may be able to scale from two containers to twenty relatively easily.

A database may require replication, partitioning, leader election, storage coordination, data migration, and consistency management.

Autoscaling therefore does not mean that every part of an architecture expands and contracts in the same way. Compute workers are often easier to scale than authoritative stateful systems.

What autoscaling cannot promise

Autoscaling earns its place in most architectures. It also has limits that teams plan around.

New capacity is not instant

Before new capacity becomes useful, the platform may need to:

1. Select physical capacity.
2. Create a VM or container.
3. Start the operating environment.
4. Download the application image.
5. Start the application.
6. Connect it to dependencies.
7. Pass health checks.
8. Register it with the load balancer.

During a sudden traffic spike, the existing instances may become overloaded before the new instances are ready.

Teams reduce this risk with techniques such as keeping minimum spare capacity, scaling before expected events, using faster-starting containers or functions, and responding to early warning signals. Rate limits, queues, and improvements to application efficiency can also help.

Autoscaling is powerful, but it cannot create usable capacity before the system detects or predicts the need.

Policies need stability

If a system adds and removes instances too aggressively, capacity can fluctuate constantly. For example:

• CPU rises slightly → add instances
• CPU falls slightly → remove instances
• CPU rises again → add them back

This repeated movement is inefficient and unstable.

Autoscaling policies therefore commonly use thresholds sustained for a period, cooldown periods, separate rules for scaling out and scaling in, minimum running durations, and predictive or scheduled scaling.

Teams often scale out quickly to protect performance and scale in more cautiously to avoid removing capacity too soon.

Cost still exists

Autoscaling can reduce compute spending by removing unnecessary resources when demand falls, but the entire cloud bill does not disappear when instances scale in.

The company may continue paying for databases, stored objects, persistent disks, backups, and networking. Load balancers, monitoring, minimum instances, reserved capacity, and other managed services may also stay on the bill.

Autoscaling adjusts selected resources. It is not an automatic guarantee of the lowest possible cloud cost.

Poor scaling rules can also increase costs by creating too many resources or reacting to noisy metrics.

Dependencies feel the pressure

Suppose the backend automatically scales from five instances to fifty.

Each instance opens connections to the same database.

The backend now has more compute capacity, but the database may receive ten times as many connections and queries. The bottleneck has moved.

Similarly, rapidly scaling workers may overwhelm a payment API, an email provider, a queue, a database, or a downstream internal service.

This connects back to Module 6’s rate limits and Module 2’s resource constraints.

A system scales only as well as the components it depends on.

Seeing the complete cloud design

Imagine that the coffee application serves customers across the eastern United States, so the team chooses the Northern Virginia region to reduce latency for most users.

Inside that region, it runs backend instances in at least two availability zones.

A load balancer distributes requests among healthy instances.

The autoscaling policy maintains at least two instances, allows up to forty, and adds capacity when request volume or CPU usage rises.

The application keeps lasting state out of any particular backend instance, storing it in a managed multi-AZ database.

The architecture might look like:

During the dinner rush, autoscaling adds more backend instances across the zones, and overnight it removes excess instances while preserving the minimum capacity.

The product’s geography supports latency and reliability, and its scaling rules respond to demand.

The mental model to remember

A region is a geographic area in which a cloud provider operates infrastructure.

Region choice affects latency, legal and contractual requirements, resilience, and cost.

Data residency concerns where information is stored or processed.

An availability zone, or AZ, is an isolated infrastructure location within a region.

A multi-AZ design distributes important components across availability zones to reduce dependence on one location.

A failure domain is an area that can be affected by one shared failure.

Blast radius describes how much of the system a failure affects.

Autoscaling automatically adjusts computing capacity according to configured rules or signals.

Scaling out adds more resources. Scaling in removes them.

A load balancer distributes incoming traffic among healthy resources.

A health check determines whether a resource is ready to receive traffic.

Autoscaling works most easily when compute instances are replaceable and important state lives in shared persistent systems.

You should now understand how cloud systems decide both where resources run and how much capacity should be active.

Geography creates boundaries for speed, law, and failure.

Autoscaling replaces fixed guesses with controlled rules.