Choosing a Region

Every AWS resource that is not global lives in a Region, so the first design decision for Cascade Ridge is which Region, or Regions, to use. Mateo assumed the answer was obvious: pick the closest one. Gwen agrees that distance matters, but she makes him work through the four factors AWS itself recommends, because sometimes the closest Region is not the right one, and the exam likes questions where one factor overrides the others.

Factor 1: compliance and data governance

Some organizations are required, by law, contract or their own policy, to keep certain data inside a particular country or jurisdiction. Because AWS does not move data out of a Region unless the customer does, choosing a Region in the right place is the main tool for meeting such a requirement. Where a legal requirement exists, it overrides every other factor: there is no point choosing a fast, cheap Region the organization is not allowed to use.

Hannah reviews Cascade Ridge's obligations. There is no single federal privacy law that covers a veterinary group's client records, but state privacy laws such as the Colorado Privacy Act apply to some businesses depending on their size and activity, payment card data falls under the PCI DSS standard wherever it is stored, and some contracts with partner clinics ask for data to stay in the United States. The board has therefore decided that client data will stay in US Regions. That one decision rules out every Region outside the country.

Hannah notes a detail she wants in writing: keeping data in a Region is a design choice the customer makes and keeps. If someone later configures replication to a Region outside the country, or uses a global service that stores copies elsewhere, the data could leave. AWS-102 shows how policies can stop resources from being created in unapproved Regions at all.

Factor 2: proximity and latency

Latency is the delay for data to travel between two points, usually measured in milliseconds as a round trip. It grows with physical distance and with the number of network hops. Applications that staff click through all day, such as VetLedger, feel sluggish when latency is high, especially if each screen makes many small requests to the server. Placing resources in a Region close to most users keeps latency low.

Gwen asks Mateo to measure rather than guess. He runs a simple network test from the emergency hospital to endpoints in several Regions. The illustrative numbers below are typical of what such a test shows, and the code turns them into a comparison.

# Illustrative round-trip times (milliseconds) from the head office to each Region,
# and how many server round trips one VetLedger screen makes.
rtt = {"ca-west-1": 6, "ca-central-1": 48, "us-west-2": 31, "us-east-2": 44}
round_trips_per_screen = 12
for region, ms in sorted(rtt.items(), key=lambda kv: kv[1]):
    wait = ms * round_trips_per_screen
    print(f"{region:13} {ms:3} ms per trip -> about {wait:4} ms of network wait per screen")

ca-west-1       6 ms per trip -> about   72 ms of network wait per screen
us-west-2      31 ms per trip -> about  372 ms of network wait per screen
us-east-2      44 ms per trip -> about  528 ms of network wait per screen
ca-central-1   48 ms per trip -> about  576 ms of network wait per screen

The test shows why latency matters more than it first seems: one screen that makes twelve round trips multiplies a small delay twelve times. A designer can reduce the effect by choosing a closer Region, by caching, or by changing how the application talks to its server, but the Region is the simplest lever.

For Cascade Ridge there is no Region in Colorado. US West (Oregon) and US East (Ohio) are both usable from Denver, and the test favors Oregon slightly.

Factor 3: service availability

Not every AWS service, and not every feature or instance type, is available in every Region. New services usually launch in a few large Regions first and spread to others over months or years. Smaller or newer Regions may lack some services entirely. Before choosing a Region, a team should confirm that every service it plans to use is offered there, using the AWS list of services by Region.

Gwen walks Mateo through Cascade Ridge's list: Amazon EC2 with Windows Server, Amazon RDS for SQL Server with Multi-AZ, Amazon S3, AWS Backup, Elastic Load Balancing, Amazon CloudFront and AWS Lambda for phase 2. All of them are available in both US West (Oregon) and US East (Ohio), which are large, long-established Regions with a very wide range of services.

Factor 4: pricing

Prices for the same service differ from Region to Region, because land, power, taxes and other costs differ. The difference can be noticeable for large workloads. AWS publishes prices for each Region, and the AWS Pricing Calculator lets a team compare a design's estimated cost in several Regions before choosing. AWS-104 covers pricing and the calculator in depth.

Mateo's estimate shows that Oregon and Ohio are close in price for Cascade Ridge's design, and both are cheaper than some other US Regions. Because latency also favors Oregon slightly, Oregon becomes the primary choice.

Putting the factors together

Gwen's method is a sequence rather than a weighted vote. First, discard every Region that compliance rules out. Second, among the remaining Regions, discard any that lack a required service. Third, compare latency and price among those left, and weigh them according to how the system is used. A system that staff click through all day leans on latency; a large overnight batch job leans on price.

Gwen adds a fifth consideration that the exam does not list but real teams do: a second Region for recovery should be far enough away that one regional disaster cannot affect both, and both should satisfy the compliance rule. Oregon and Ohio are separated by most of the country, which more than satisfies that test.

Setting the Region in practice

Choosing a Region on paper is half the work; making sure everyone actually uses it is the other half. In the console, the Region selector sits at the top right, and every Regional resource is created in whatever Region is selected. The AWS CLI and SDKs use a default Region from configuration, which can be overridden per command. Gwen asks Mateo to set the default once and to check it whenever something seems missing.

aws configure set region us-west-2
aws configure get region
aws s3 ls --region us-east-2

When the factors conflict

Gwen gives Mateo three short scenarios from other clients to show how the factors interact, and asks him to choose a Region for each before she gives her answer.

• A research group with no data rules wants the cheapest place to run large overnight calculations whose results are emailed in the morning. Latency hardly matters because nobody waits for each step, so price leads, provided the needed instance types exist in the cheaper Region.
• An online game studio has players concentrated in one city and wants the fastest possible response. Proximity leads, and a Local Zone in that city might serve better than any Region.
• A provincial or state agency must keep records in its own jurisdiction. Compliance decides first; among the allowed Regions, service availability and latency decide next, and price is a minor factor.

In each case the order is the same: rule out what is not allowed, rule out what lacks required services, then weigh the rest according to how the system is used. Mateo notices that the exam questions he has seen follow this pattern too: they usually give one strong clue, such as a legal requirement, a latency-sensitive user base or a cost-sensitive batch workload, and the answer follows that clue.

Data residency is more than storage

Hannah raises a point that goes beyond where data is stored. Data can leave a Region in other ways: through logs sent to a central account, through support cases where someone attaches a database export, through an analytics tool that copies data elsewhere, or through a backup copied to the wrong Region. A residency requirement therefore needs a short checklist, not just a Region choice. Cascade Ridge's checklist covers primary data, backups and copies, logs, exports and test data, and assigns each to an owner.

Test data deserves particular care. Developers often want realistic data to test with, and copying a production database into a test account is the quickest way to get it. Hannah's rule is that test environments use either synthetic data or production data with names, addresses and payment details removed, and that test accounts follow the same Region rules as production. The rule costs Kwame some convenience, but it removes a common way for personal information to end up where it should not be.

Revisiting the choice

A Region decision is not permanent. New Regions open, services spread to more Regions, prices change and businesses grow into new places. Gwen records the date and the reasons for Cascade Ridge's choice and schedules a review every two years, or sooner if the business opens clinics in a new area or a required service is missing. Moving between Regions later is possible but takes work, which is another reason to choose carefully the first time.

Mateo writes the review date into the decision record and adds a line for each factor, so that whoever reviews the choice in two years can see which facts have changed. If a new Region opens closer to the clinics, or a needed service appears only elsewhere, the record shows exactly which part of the reasoning to revisit, and the team can decide quickly whether a move is worth the effort.

Mateo's notebook now has a short decision record: the two chosen Regions, the four factors, and one sentence from Hannah that he copies word for word: residency is a setting we choose, so it is a setting we must keep. Lesson 6 introduces the framework Gwen will use to review the whole design.