AWS Cloud Practitioner Study Notes · Part 5
Six Benefits of AWS Global Infrastructure
AWS Cloud Practitioner study notes on high availability, fault tolerance, low latency, global reach, disaster recovery, and data residency.
AWS Global Infrastructure is not only a map of Regions and Availability Zones. It is the foundation for decisions about availability, performance, resilience, reach, and data location.
This is Part 5 of the AWS Cloud Practitioner Study Notes series. Part 4 explains the infrastructure components; this note focuses on the benefits those components enable and the exam clues that help you choose between them.
The six benefits at a glance
| Benefit | Typical AWS choice | Exam clue |
|---|---|---|
| High availability | Multiple Availability Zones, load balancing, automatic scaling | Keep serving users when one AZ fails |
| Fault tolerance | Isolated failure domains and redundant components | Continue operating despite infrastructure failure |
| Low latency | A nearby Region, CloudFront, Local Zones, or Wavelength Zones | Reduce the distance between users and workloads |
| Global reach | Multiple Regions and edge locations | Serve users in different countries or continents |
| Disaster recovery | Backups, replication, and a recovery environment in another Region | Recover after a Region-level disruption |
| Compliance and data residency | Select an appropriate Region and control data movement | Keep data in a required country or jurisdiction |
These are architectural outcomes, not automatic guarantees. AWS provides resilient building blocks, but your workload must use them correctly.
1. High availability
High availability means keeping an application accessible and reducing downtime when a component or location becomes unavailable. A common pattern is to run EC2 instances in multiple Availability Zones behind a load balancer. If one AZ has a problem, traffic can be sent to healthy instances in another AZ.
Other building blocks can support this design:
- Elastic Load Balancing distributes requests across healthy targets.
- EC2 Auto Scaling replaces unhealthy instances and adjusts capacity.
- Amazon RDS Multi-AZ maintains a standby database in another AZ for supported configurations.
- Amazon ECS or Amazon EKS can schedule application capacity across more than one AZ.
Multiple AZs do not make an application highly available by themselves. The application, database, networking, deployment process, and dependencies must all tolerate the failure pattern being planned for.
Exam clue: “The application should continue operating if one data centre or Availability Zone fails” usually points to a multi-AZ design.
2. Fault tolerance
Fault tolerance is the ability of a system to continue operating when a component or infrastructure location fails. AWS Availability Zones are separate locations with independent infrastructure, so placing redundant components across AZs limits the blast radius of some failures.
High availability and fault tolerance are related but not identical:
- High availability focuses on minimising downtime and restoring service quickly.
- Fault tolerance focuses on continuing service despite a failure.
For example, a standby database that takes time to become active may support high availability, while a system with enough redundant capacity to keep serving traffic immediately is closer to fault tolerant for that failure mode. The exact result depends on the architecture and the failure being considered.
3. Low latency
Network distance affects response time. Choosing a Region close to the majority of users can reduce the time required for requests to travel to the application and back. For users in Malaysia, Singapore may be a sensible starting point, but measured latency, service availability, cost, and compliance requirements still matter.
Different AWS services address different latency problems:
- Amazon CloudFront caches and delivers content from edge locations close to viewers.
- AWS Local Zones place selected AWS resources closer to a metropolitan area.
- AWS Wavelength Zones place selected infrastructure at telecommunications providers’ 5G edge for suitable mobile applications.
- AWS Global Accelerator uses the AWS global network to improve the path to regional application endpoints.
CloudFront is usually the exam answer for delivering static content globally with lower viewer latency. A nearby Region is more relevant when the application itself and its data need to run closer to users.
4. Global reach
AWS Regions and edge locations allow an organisation to serve users across countries and continents. A workload can run in one or more Regions, while CloudFront distributes cacheable content through its global edge network.
A multi-Region design can help an organisation:
- Place applications nearer to users in different geographies
- Provide a recovery location away from the primary Region
- Meet requirements about where data is processed or stored
- Reduce dependence on one geographic area
Not every AWS service or feature is available in every Region, and resources do not automatically appear in another Region. A global design therefore requires explicit decisions about deployment, replication, routing, operations, and cost.
5. Disaster recovery
Disaster recovery (DR) is the ability to restore or continue workloads after a serious disruption. The recovery strategy should define its recovery time objective (RTO) and recovery point objective (RPO):
- RTO: how long the service can be unavailable.
- RPO: how much recent data loss is acceptable.
Multi-AZ architecture primarily addresses failures within a Region. If the requirement is to recover after an entire Region becomes unavailable, the design may need backups or replicas in another Region, together with a tested failover or restoration process.
Examples of supporting services include:
- Amazon S3 Cross-Region Replication for suitable object-replication requirements
- Amazon RDS cross-Region read replicas for supported engines and configurations
- Amazon Route 53 health checks and routing policies for DNS-based failover patterns
- AWS Backup for centrally managed backup policies where supported
Cross-Region DR normally increases cost and operational complexity. Replication is not the same as a tested recovery plan; teams should regularly verify that backups, permissions, infrastructure, application configuration, and runbooks can restore the service.
Exam clue: “Recover if the primary Region is unavailable” points to a multi-Region recovery design, not only multiple AZs in the same Region.
6. Compliance and data residency
Some organisations must keep data in a particular country, region, or legal jurisdiction. Choosing an AWS Region can help satisfy a data-residency requirement—for example, selecting a Frankfurt Region for a workload that must store data in Germany—subject to the organisation’s specific legal and compliance obligations.
Region selection is only one part of compliance. You must also consider:
- Which services store or process the data
- Cross-Region replication and backup destinations
- Data transfer between services and countries
- Encryption, access control, logging, and retention
- Contractual and regulatory requirements
AWS Regions can support compliance strategies, but choosing a Region alone is not a blanket compliance guarantee.
Putting the benefits together
Consider a customer-facing application for users across Asia:
- CloudFront serves cacheable static assets from edge locations close to viewers.
- The application runs on EC2 or containers across two Availability Zones in the Singapore Region.
- A load balancer sends traffic only to healthy application targets.
- RDS runs with a Multi-AZ configuration for database resilience within Singapore.
- Backups or selected replicas are stored in another Region for disaster recovery.
- Data placement and replication are reviewed against the organisation’s residency requirements.
This design combines low latency, high availability, fault isolation, and recovery planning. It also shows why no single AWS service represents all six benefits.
Exam-ready memory aid
- One AZ fails: use multiple AZs.
- An entire Region fails: plan recovery in another Region.
- Users are worldwide and content is cacheable: consider CloudFront.
- Users are far from the application: choose a closer Region or an appropriate edge service.
- Data must stay in a jurisdiction: select the correct Region and review replication and transfers.
- The system must continue despite a failure: design redundant components and remove single points of failure.
Conclusion
AWS Global Infrastructure helps you design systems that are available, fault tolerant, responsive, globally accessible, recoverable, and aligned with data-location requirements. For the Cloud Practitioner exam, first identify the failure scope or user requirement, then choose the infrastructure level that matches it: Availability Zones for local resilience, Regions for geographic separation, and edge services for proximity and delivery.