Choose a Region for the workload
Start with your users, required services, data requirements and operating costs. A nearby Region can reduce network latency, but proximity alone is not the complete decision.
Before a lab, check the Region selector. A resource created in one Region may not appear when the console is showing another. Record the Region alongside resource names.
Use Zones as a design boundary
Availability Zones give you separate locations within a Region. A resilient design can place components across multiple Zones rather than relying on one location.
Selecting AWS does not automatically make every application highly available. You must choose service configurations and application behaviour that support your recovery goals.
Distinguish location from recovery
A second instance is useful only when the rest of the system can use it. Consider traffic routing, database availability, shared state and how failures are detected.
For a learning website, draw the application and data components. Mark which failures each component can survive. This reveals gaps more clearly than a diagram containing only cloud icons.
Try it yourself
Draw a two-Zone website. Explain how traffic reaches the remaining application instance if one Zone becomes unavailable and where the application data lives.
A common question
Should I always deploy in multiple Regions?
No. Multiple Regions add operational complexity. Start with requirements and assess whether a suitable multi-Zone design meets them.
References & video notes
An original CloudFolks companion guide to the topic. Older video interfaces and offers may differ from current services. Use the current documentation for implementation details.
Keep learning
- Public, private and hybrid cloud explained
- IaaS vs PaaS vs SaaS: who manages what?
- Getting comfortable with the AWS Management Console