AWS Global Infrastructure

1. Why make a global application?

A global application is an application deployed in multiple geographies. On AWS, this could be Regions and / or Edge Locations. The reasons:

• Decreased latency. Latency is the time it takes for a network packet to reach a server. It takes time for a packet from Asia to reach the US. Deploying your applications closer to your users decreases latency and gives a better experience.
• Disaster Recovery (DR). If an AWS Region goes down (earthquake, storms, power shutdown, politics), you can fail over to another Region and have your application still working. A DR plan is important to increase the availability of your application.
• Attack protection. A distributed global infrastructure is harder to attack.

The three building blocks

• Regions — for deploying applications and infrastructure
• Availability Zones — made of multiple data centers
• Edge Locations (Points of Presence) — for content delivery as close as possible to users

The four services that make an application global:

• Global DNS: Route 53 — routes users to the closest deployment with the least latency, and is great for disaster recovery strategies
• Global Content Delivery Network (CDN): CloudFront — replicates part of your application to AWS Edge Locations to decrease latency, and caches common requests
• S3 Transfer Acceleration — accelerates global uploads & downloads into Amazon S3
• AWS Global Accelerator — improves global application availability and performance using the AWS global network

2. Amazon Route 53

Route 53 is a managed DNS (Domain Name System). DNS is a collection of rules and records which help clients understand how to reach a server through URLs.

The most common record types in AWS:

Record	Meaning	Example
A	hostname to IPv4	www.google.com → 12.34.56.78
AAAA	hostname to IPv6	www.google.com → 2001:0db8:85a3:0000:0000:8a2e:0370:7334
CNAME	hostname to hostname	search.google.com → www.google.com
Alias	hostname to an AWS resource	example.com → ELB, CloudFront, S3, RDS…

The A-record flow from the slide: the web browser sends a DNS request for myapp.mydomain.com, Route 53 sends back the IP 32.45.67.85 (an A record — hostname to IP), the browser then makes an HTTP request to that IP with Host: myapp.mydomain.com, and the application server returns the HTTP response.

Routing policies

You need to know these at a high level for the Cloud Practitioner exam.

• Simple Routing Policy — returns a single record, no health checks. foo.example.com → A: 11.22.33.44.
• Weighted Routing Policy — splits traffic by weight across records; with weights of 70, 20 and 10 the traffic goes 70% / 20% / 10%.
• Latency Routing Policy — sends the user to the deployment with the lowest latency.
• Failover Routing Policy — a health check on the primary; if it fails, traffic goes to the failover record. This is the disaster recovery policy.

Exam tip

Match the keyword to the policy: “split traffic for a canary release” → Weighted; “best performance for users worldwide” → Latency; “switch to the standby site when the primary is unhealthy” → Failover; “just one record, nothing clever” → Simple (and remember Simple has no health checks).

3. Amazon CloudFront

CloudFront is a Content Delivery Network (CDN).

• Improves read performance — content is cached at the edge
• Improves the user experience
• Hundreds of Points of Presence globally (edge locations, caches)
• DDoS protection (because it is worldwide), with integration with AWS Shield and the AWS Web Application Firewall

Origins

• S3 bucket — for distributing files and caching them at the edge, and for uploading files to S3 through CloudFront. Secured using Origin Access Control (OAC).
• VPC Origin — for applications hosted in VPC private subnets: Application Load Balancer / Network Load Balancer / EC2 instances.
• Custom Origin (HTTP) — an S3 website (the bucket must first be enabled as a static S3 website), or any public HTTP backend you want.

How it works

A client sends a request such as GET /beach.jpg?size=300x300 to the nearest CloudFront Edge Location. The edge location checks its local cache; on a miss it forwards the request to your origin (S3 over HTTP, or another origin), caches the response and serves it.

With S3 as an origin, edge locations in Los Angeles, Mumbai, Melbourne, São Paulo and elsewhere serve the public web, while the link back to the S3 bucket travels over the private AWS network, locked down by Origin Access Control + an S3 bucket policy.

CloudFront vs S3 Cross Region Replication

CloudFront	S3 Cross Region Replication
Global edge network	Must be set up for each Region you want replication to happen
Files are cached for a TTL (maybe a day)	Files are updated in near real-time
—	Read only
Great for static content that must be available everywhere	Great for dynamic content that needs to be available at low latency in a few Regions

Real-world example

A product catalogue’s images belong behind CloudFront — they change rarely and every region wants them. The catalogue’s frequently updated price file, needed with fresh data in three specific Regions, is a better fit for S3 Cross Region Replication.

4. S3 Transfer Acceleration

S3 Transfer Acceleration increases transfer speed by transferring the file to an AWS edge location, which then forwards the data to the S3 bucket in the target Region.

In the slide’s example, a file in the USA is uploaded to a bucket in Australia: the first hop goes over the public www to a USA edge location (fast), and the long leg to the Australian bucket travels over the private AWS network (fast).

5. AWS Global Accelerator

Global Accelerator improves global application availability and performance using the AWS global network.

• Leverages the AWS internal network to optimize the route to your application (60% improvement)
• 2 Anycast IP addresses are created for your application, and traffic is sent through Edge Locations
• The edge locations send the traffic to your application

Users in America, Australia, Europe and India all reach the nearest edge location over the public internet, and the traffic then crosses the private AWS network to your public ALB.

Global Accelerator vs CloudFront

They both use the AWS global network and its edge locations around the world, and both integrate with AWS Shield for DDoS protection.

CloudFront — Content Delivery Network

• Improves performance for your cacheable content (such as images and videos)
• Content is served at the edge

Global Accelerator

• No caching — it proxies packets at the edge to applications running in one or more AWS Regions
• Improves performance for a wide range of applications over TCP or UDP
• Good for HTTP use cases that require static IP addresses
• Good for HTTP use cases that require deterministic, fast regional failover

Exam tip

The two keywords that decide this question: caching → CloudFront; static IP addresses or non-HTTP (TCP/UDP) traffic → Global Accelerator.

6. AWS Outposts

Hybrid Cloud describes businesses that keep an on-premises infrastructure alongside a cloud infrastructure — which means two ways of dealing with IT systems: one for the AWS cloud (console, CLI, AWS APIs) and one for their on-premises infrastructure.

AWS Outposts are “server racks” that offer the same AWS infrastructure, services, APIs & tools so you can build your own applications on-premises just as in the cloud.

• AWS will set up and manage “Outposts Racks” within your on-premises infrastructure, and you can start leveraging AWS services on-premises
• You are responsible for the Outposts Rack physical security

Benefits:

• Low-latency access to on-premises systems
• Local data processing
• Data residency
• Easier migration from on-premises to the cloud
• Fully managed service

Some services that work on Outposts: Amazon EC2, Amazon EBS, Amazon S3, Amazon EKS, Amazon ECS, Amazon RDS, Amazon EMR.

Exam tip

Outposts is the answer when a question combines “must stay in our own data center” (data residency, low latency to on-prem systems) with “but we want AWS APIs and services”. Note the shared responsibility twist: the physical security of the rack is yours.

7. AWS WaveLength

WaveLength Zones are infrastructure deployments embedded within the telecommunications providers’ datacenters at the edge of the 5G networks.

• Brings AWS services to the edge of the 5G networks — for example EC2, EBS, VPC
• Ultra-low latency applications through 5G networks
• Traffic doesn’t leave the Communication Service Provider’s (CSP) network
• High-bandwidth and secure connection to the parent AWS Region
• No additional charges or service agreements
• Use cases: Smart Cities, ML-assisted diagnostics, Connected Vehicles, Interactive Live Video Streams, AR/VR, Real-time Gaming

Architecturally, a WaveLength Zone sits beside the Region’s Availability Zones, reached from the telecom carrier’s 5G network through a Carrier Gateway.

8. AWS Local Zones

Local Zones place AWS compute, storage, database, and other selected AWS services closer to end users to run latency-sensitive applications.

• Extend your VPC to more locations — an “extension of an AWS Region”
• Compatible with EC2, RDS, ECS, EBS, ElastiCache, Direct Connect
• Example: AWS Region N. Virginia (us-east-1) with AWS Local Zones in Boston, Chicago, Dallas, Houston, Miami…

In the diagram, the VPC spans the Region’s Availability Zones and the Boston Local Zone, with private subnets in each.

Real-world example

A video-editing SaaS whose Region is us-east-1 but whose customers are studios in Boston can put the latency-sensitive editing instances in the Boston Local Zone — same VPC, same tooling, a few milliseconds away from the users.

9. Global application architectures

The deck grades four shapes by difficulty:

Architecture	High availability	Global latency
Single Region, Single AZ — one EC2 instance in one AZ	No	Poor
Single Region, Multi AZ — EC2 instances in AZ-A and AZ-B	Yes	Poor
Multi Region, Active-Passive — an Active instance in Region A, a Passive one in Region B; users read/write to the active Region and read from the passive one	Yes	Good for global reads’ latency, poor for global writes’ latency
Multi Region, Active-Active — Active instances in both Regions, users read/write to either	Yes	Good for both reads’ and writes’ latency

Difficulty increases as you move down the list.

Exam tip

Multi-Region Active-Passive improves read latency globally but writes still travel to the active Region. Only Active-Active fixes write latency — and it is the hardest to build.

Quick recap

Concept	What to remember for the exam
Why go global	Decreased latency, disaster recovery, attack protection
Infrastructure blocks	Regions (deploy), Availability Zones (data centers), Edge Locations (content delivery)
Route 53	Managed DNS; A, AAAA, CNAME and Alias records; routes users to the closest deployment and supports DR
Routing policies	Simple (no health checks), Weighted, Latency, Failover (DR)
CloudFront	CDN caching content at hundreds of Points of Presence; DDoS protection with Shield and WAF
CloudFront origins	S3 bucket (secured with OAC), VPC Origin (ALB/NLB/EC2), Custom HTTP origin
CloudFront vs CRR	CDN cached for a TTL, global, static content — vs per-Region, near real-time, read-only, dynamic content
S3 Transfer Acceleration	Upload/download via an edge location, then over the AWS network to the bucket’s Region
Global Accelerator	2 Anycast IPs, no caching, proxies TCP/UDP over the AWS network, ~60% route improvement
Accelerator vs CloudFront	Caching → CloudFront; static IPs, TCP/UDP or fast regional failover → Global Accelerator
Outposts	AWS-managed racks in your own data center; you own the rack’s physical security
WaveLength	AWS services inside telecom 5G datacenters, ultra-low latency, no additional charges
Local Zones	Extension of a Region closer to users, extends your VPC, for latency-sensitive apps
Global architectures	Single AZ → Multi AZ → Multi Region Active-Passive → Active-Active, in increasing difficulty