Responsibilities Before Services

Goal

AWS can look overwhelming because there are many service names. A useful architecture conversation starts before those names. It starts with what the workload must do, who owns each decision, what risks matter, and how the system will be operated.

The durable idea is:

Service names help you translate; responsibilities help you design.

The Short Version

AWS is a cloud platform for building and operating workloads at scale. It offers services for compute, storage, databases, analytics, networking, security, developer tools, management, AI, and more. That breadth is powerful, but it can also distract from the first design question:

What responsibility are we trying to place, control, or improve?

A strong AWS design does not start by saying, "Use EC2," "Use Lambda," or "Use S3." Those names matter later. The design starts with the workload's purpose, constraints, ownership, security, data, connectivity, reliability, operations, and cost.

A Practical Responsibility Model

Think about AWS through responsibility layers:

flowchart TB
    A["Business Outcome<br/><small>What should the workload achieve?</small>"]
    B["Ownership & Governance<br/><small>Who owns accounts, cost, risk, and evidence?</small>"]
    C["Identity & Access<br/><small>Who or what can do which actions?</small>"]
    D["Network & Security<br/><small>How do systems connect safely?</small>"]
    E["Workload Services<br/><small>What runs code, data, events, and workflows?</small>"]
    F["Operations<br/><small>How is the workload observed, changed, recovered, and paid for?</small>"]

    A --> B --> C --> D --> E --> F

This is not a deployment order. It is a way to keep the architecture conversation grounded.

AWS service names will appear throughout the book. For now, focus on the job each layer performs.

Business Outcome

The business outcome explains why the workload exists.

Useful questions include:

• What customer or internal problem does the workload solve?

• Which users, teams, or systems depend on it?

• What happens if it is slow, unavailable, wrong, or expensive?

• Which constraints matter most: delivery speed, security, reliability, compliance, cost, latency, or operational simplicity?

• What does success look like after the first release?

This matters because two workloads can use similar services for very different reasons. A public checkout API, an internal reporting tool, and a batch image-processing job may all use compute, storage, networking, and monitoring, but the design priorities are different.

Ownership and Governance

AWS architecture needs clear ownership. In AWS, ownership often shows up through accounts, organizations, tags, cost allocation, logging, security tooling, and operations.

At this point, do not worry about every service name. The responsibility is simple:

• Which team owns the workload?

• Which environment is production?

• Who pays for the resources?

• Which guardrails must be inherited centrally?

• Which evidence do security, compliance, and finance need?

• Which teams can change the workload, network, identity, and data?

Later chapters will explain AWS Organizations, accounts, landing zones, and governance tools. The first mental model is that AWS architecture is usually organized around boundaries that let teams move independently while central functions keep visibility and control.

Identity and Access

Identity answers who or what can act.

In AWS, identity and access are centered around principals, permissions, and policies. A principal might be a human user, a role, an application, an automation pipeline, or another AWS account. Permissions decide which actions are allowed on which resources.

The early design questions are:

• Who needs human access?

• Which workloads need machine access?

• Which actions are administrative, operational, read-only, or dangerous?

• How will production access differ from development access?

• How will temporary access, break-glass access, and access review work?

Identity is not a late security detail. It shapes deployment, operations, incident response, data protection, and automation.

Network and Security

Most AWS workloads need intentional connectivity.

Ask:

• Which traffic must be public?

• Which systems should stay private?

• Which dependencies cross accounts, VPCs, Regions, or on-premises networks?

• Where should routing, filtering, and inspection happen?

• How should secrets, encryption, and data protection be handled?

• Which controls are inherited from AWS, and which remain with the customer?

Later chapters will cover VPCs, subnets, route tables, security groups, private access, transit networking, edge protection, and hybrid connectivity. For now, remember that cloud networking is not simply "can it connect?" It is "should it connect, how, from where, under whose control, and with what evidence?"

Workload Services

Workload services run application code, store data, move events, host APIs, automate operations, and support analytics or AI.

Here is a first vocabulary pass. Do not memorize this table; use it to see the kinds of responsibility AWS can help place.

The service names are vocabulary. The architecture question is why one responsibility should sit in one service rather than another.

Operations

Operations are part of architecture.

Ask:

• How will the workload be monitored?

• Which logs, metrics, traces, and alarms matter?

• Who responds to incidents?

• How will deployments be released and rolled back?

• How will backup, recovery, and disaster recovery work?

• How will cost be measured and controlled?

• How will the architecture improve over time?

AWS gives teams many operational tools, but the service names are not enough. The team still needs ownership, runbooks, alert quality, deployment discipline, cost review, and improvement loops.

Example: Do Not Start With Products

A company says:

We want to move our customer portal to AWS. Which services should we use?

A weak answer starts listing compute options. A stronger answer starts with architecture questions:

• What does the portal do for customers?

• Which parts need to be public?

• What data does it store or read?

• Which identity model is required?

• Which account should own production?

• Which network paths should be private?

• How much downtime is acceptable?

• Who deploys and supports it?

• What cost and scaling pattern is expected?

After those answers, service selection becomes clearer.

Common Mistakes

• Learning AWS service names before understanding the responsibilities they place.

• Treating "managed" as meaning the customer has no architecture responsibility.

• Starting with compute before understanding identity, data, network, operations, and cost.

• Ignoring account and ownership boundaries until the environment is already messy.

• Comparing AWS to Azure or GCP only through service equivalence tables.

If Someone Asks You

What is AWS architecture really about?

A good answer is:

AWS architecture is about placing cloud responsibilities deliberately. Start with the business outcome, constraints, ownership, identity, network, data, security, reliability, operations, and cost. Then choose AWS services that fit those responsibilities. Service names help translate the design, but responsibilities are what make the architecture coherent.

What You Should Remember

Start with responsibility placement before service selection.

Questions to Check Your Understanding

1. Why is AWS more than a list of services?

2. Which responsibility layers should you consider before choosing services?

3. Why can two workloads use similar services but need different architectures?

4. What questions should you ask before recommending a compute service?