Who is responsible—and what can fail?

Before choosing an AWS service, ask two questions. First: who is responsible for this part of the system—AWS or your team? Second: what failure must the system survive—one server, one Availability Zone, or an entire Region?

The first question is about ownership. For example, AWS secures the physical server, but your team decides who may sign in to your application. The second question is about failure boundaries. Two servers help only when they do not depend on the same thing that failed.

Keep the questions separate. Adding another server may improve availability, but it does not repair an overly powerful user role. Tightening permissions may reduce security risk, but it does not keep an application online when its only location fails. A sound design names both the owner and the failure it covers.

AWS calls this split the shared responsibility model. AWS is responsible for security “of” the cloud: its data centres, physical equipment, and the infrastructure that runs AWS services. You do not need to build a fence around an AWS data centre or replace a failed physical disk.

You remain responsible for security “in” the cloud. Your team classifies its data, grants access, configures the network, and decides what the application allows each person to do. On Amazon EC2, you also maintain the guest operating system and your application software.

A managed service can move more operating work to AWS. That is useful, but “managed” does not mean “AWS handles everything.” AWS may patch the service platform while you still control the data, identities, permissions, and recovery plan. For every important control, write down whether AWS or your team owns it and how you will verify that it works.

An AWS account is an ownership, permissions, and billing container. It is not a physical location. Inside an account, you choose a Region for Regional resources. A Region is a geographic AWS service area, such as Singapore or Sydney.

Each Region contains multiple Availability Zones, usually shortened to AZs. An AZ is an isolated location with independent infrastructure. A subnet belongs to exactly one AZ, so choosing a subnet also chooses the AZ where a resource is placed.

Imagine an application in one Region. It has one subnet in AZ A and another subnet in AZ B. If both application servers are in AZ A, adding a second server can cover one server failure, but AZ A is still a shared failure boundary. Placing capacity in both AZs can cover an AZ failure only when the entry path, application, data, dependencies, and remaining capacity also survive there.

Service-specific scope still matters. A resource may be global, Regional, or tied to one AZ. Check the documentation instead of assuming that every managed service spans multiple locations automatically.

High availability and disaster recovery are related, but they are not the same claim. A design spread across two AZs in one Region may continue through one AZ failure. It does not prove that the application can recover when the entire Region is unavailable.

To claim Regional disaster recovery, the design needs a tested recovery path in another Region. That usually means copying the required data and dependencies, preparing enough capacity, directing traffic to the recovery location, and practising the recovery procedure. If policy allows only one Region, say plainly that a Regional outage is outside the design.

Security has a different failure boundary. Two application servers can improve availability, but they do not limit a deployment role that can also administer the database. Use narrowly scoped roles to contain credential compromise, and test those permissions separately from infrastructure failures.

Finish each architecture statement with evidence. Health checks show whether components are serving. Access tests show whether permissions enforce the intended boundary. Recovery exercises show whether the application can meet its stated recovery scope. A precise, smaller claim is more useful than a broad claim the design has never proved.