AWS / Basic: cloud scope and core boundaries / Lesson 1
Cloud boundaries, Regions, and accounts
Identify resource scope, failure domains, and customer responsibilities before selecting an AWS service or drawing an architecture.
On this page
Lesson goals
- Explain the assumptions, responsibilities, and trade-offs of cloud boundaries, regions, and accounts.
- Interpret both examples and distinguish declared intent from verified evidence.
- Diagnose the listed failures and justify the worked decisions without using a real AWS account, credential, or service.
Start with an application outcome
AWS supplies managed infrastructure and services, while the customer chooses an architecture and configures how it is used. A service name does not establish availability, security, or cost for a particular application. Begin with the user journey, data classification, recovery needs, and permitted locations. The course uses commercial AWS concepts and synthetic records, not a real account. Other partitions, specialized offerings, and newly introduced features can have different identifiers or availability. No console, CLI, SDK, credential, or cloud endpoint is accessed by the examples; official documentation provides the reference boundary.
Separate Region and Availability Zone
A Region is a geographic service location containing Availability Zones. An AZ is a failure-domain building block, not a synonym for Region or one guaranteed building. Many resources are regional, some are zonal, and some services have broader scope. Deploying instances in two AZs can reduce a particular local failure exposure but does not protect against every shared dependency or regional event. The first synthetic record distinguishes a regional application boundary from its AZ placement. Confirm service and feature support in the selected Region, and do not assume AWS replicates customer data across Regions automatically.
workload: synthetic-booking
partition_assumption: commercial-aws
resource_scope: one-approved-Region
placement: multiple-reviewed-AZs
cross_region_copy: separately-designed
account_reference: lab-production-reference
The record distinguishes scopes and states that cross-Region copying is a separate design. Its labels are fictional references, not resource identifiers or deployment instructions.
Use accounts as governance boundaries
An account contains resources, identities, billing relationships, and policy scope. Separate development and production accounts can reduce accidental cross-environment change, but account separation still needs controlled access and organization policy. Region choice is another independent dimension; the right account in the wrong Region can yield an empty inventory or an unintended resource. Record account reference, partition, Region, resource identity, owner, and time in approved operational evidence. Never place real account credentials in a teaching configuration. A friendly environment label is not proof of the authenticated principal or the target resource scope.
Verify assumptions before real authorization
Document the selected service mode, Region, supported features, customer controls, and recovery evidence. Treat quotas, capacity, dependencies, and pricing dimensions as separate checks rather than guarantees inferred from the cloud label. Use the Well-Architected questions to compare trade-offs, not as a score proving safety. A regional service can still require a multi-AZ or backup configuration chosen by the customer. All records here are illustrative and non-runnable. Their purpose is to make a later authorized design review precise; they do not provision resilience, assess a real account, or promise free usage.
Common errors and fixes
Multiple AZs are called cross-Region recovery
- Why it happens
- Two different failure boundaries were conflated.
- How to fix it
- Define regional recovery and copying explicitly.
- Prevent it next time
- Record scope for each availability and backup claim.
A managed service is treated as no responsibility
- Why it happens
- Provider operation was confused with application ownership.
- How to fix it
- Assign data, identity, configuration, and recovery owners.
- Prevent it next time
- Review the responsibility split for each service mode.
An empty inventory is assumed to mean no resource
- Why it happens
- Account, Region, or permissions may differ.
- How to fix it
- Compare approved target context before any creation.
- Prevent it next time
- Include scope and principal in diagnostic evidence.
Check your understanding
1. An application runs in two AZs but has no cross-Region data copy. What claim is justified?
Show worked solution
It may reduce selected AZ-level exposure under its actual configuration, but regional recovery is not established. Examine shared dependencies and surviving capacity as well. Do not turn a placement fact into a promise about every failure or recoverable historical data.
2. Moving from EC2 to RDS changes which responsibilities?
Show worked solution
AWS takes on selected managed database infrastructure and maintenance duties according to the offering, while the customer still owns data access, schema, queries, configuration choices, and recovery verification. Identify the exact engine and deployment mode instead of claiming all database work disappears.
Key takeaways
- AWS supplies managed infrastructure and services, while the customer chooses an architecture and configures how it is used.
- An account contains resources, identities, billing relationships, and policy scope.
- Document the selected service mode, Region, supported features, customer controls, and recovery evidence.