AWS Architecture Guide

Cloud Architecture Responsibilities in AWS

What This Chapter Is About

Explain AWS at a business and architecture level before service selection begins.

This chapter is for readers who know some cloud vocabulary but want AWS to feel like a coherent operating model rather than a long catalog of product names. The focus is not to memorize services. The focus is to understand how AWS helps teams place responsibility for infrastructure, identity, networking, workload services, security, cost, and operations.

Keep one durable idea in view:

Service names help you translate; responsibilities help you design.

Sections

  1. Responsibilities Before Services

  2. Shared Responsibility and Service Models

  3. AWS Operating Boundaries

  4. Service Selection as an Architecture Decision

  5. Customer-Facing Application Scenario

How the Chapter Develops

The chapter develops in this order:

  1. Start with AWS as a platform for placing cloud responsibilities, not only selecting products.

  2. Explain shared responsibility and service models as responsibility shifts.

  3. Introduce AWS operating boundaries such as accounts, Regions, Availability Zones, IAM, VPCs, services, and operations.

  4. Show how service selection follows workload shape, ownership, risk, and operations.

  5. Apply the model to a customer-facing application migration scenario.

What You Will Be Able to Do

By the end of this chapter, the reader should be able to:

  • Explain AWS at a high level without listing random services.

  • Describe why cloud architecture starts with responsibilities, constraints, and ownership.

  • Explain shared responsibility and why customer responsibility changes by service choice.

  • Identify the first AWS boundaries that matter: account, Region, Availability Zone, IAM, VPC, workload service, data, and operations.

  • Reframe "Which AWS services should we use?" into a better architecture conversation.

Key Ideas

  • AWS is a cloud platform and an operating model for building, securing, connecting, and operating workloads.

  • Shared responsibility means AWS manages some layers while the customer remains responsible for workload decisions, configuration, data, access, and operations.

  • IaaS, managed services, and serverless shift responsibility but do not remove architecture decisions.

  • AWS service names are useful vocabulary, but service selection should follow business outcome, workload shape, risk, security, cost, and operating model.

  • Strong AWS architecture conversations start with context, constraints, options, trade-offs, recommendation, risks, and next steps.