Draw the responsibility line for each service

AWS describes security as shared responsibility: it operates the cloud infrastructure, while customers still control many aspects of what they deploy and configure. The exact split varies by service. A managed database reduces patching work, but it does not decide who can read your data, whether backups meet your recovery goal, or whether application code exposes secrets.

Responsibility chart compares customer and cloud-provider security duties across on-premises, IaaS, PaaS, and SaaS.
Figure. This Google Cloud chart shows how security duties shift by service model. The exact split varies by provider and service. Source: Google Cloud · Shared responsibilities · CC BY 4.0.

Start with the workload, not a service catalogue. Define the data classification, latency, availability, recovery-time and cost targets before choosing managed components.

Walk a small deployment end to end

For a document-processing service on AWS, decide where files land, which identity can read them, where extracted records live, and how jobs resume after failure. Encrypt and scope access; log actions without leaking document content. Test restore from a backup, not only backup creation. Set cost alerts around storage, model calls and retries.

Worked example

A new worker deployment raises processing errors. The team can see queue depth and error rate, roll back the worker, and replay only jobs with safe idempotency keys. The provider keeps the underlying service available; the team owns this application recovery.

Trace the work you still own

For a multi-step service, attach one trace ID to the request and use spans for retrieval, model calls, policy checks and writes. OpenTelemetry's observability primer shows how a waterfall exposes latency and parent-child relationships. It does not, by itself, tell you whether the answer was correct or the action was authorized. Pair the trace with the task's acceptance result and action receipts.

OpenTelemetry trace waterfall showing nested spans over time for a request.
Figure. A trace waterfall makes timing and call relationships visible. Source: OpenTelemetry observability primer · CC BY 4.0 documentation.

A serverless web application has more than one failure boundary. AWS's serverless web application lens is a reference architecture to inspect for identity, API and data responsibilities. Adapt its components to the workload rather than copying every box.

Review the whole workload

The AWS Well-Architected Framework frames operational excellence, security, reliability, performance, cost and sustainability as tradeoffs to revisit. A serverless component may simplify capacity management while making per-request costs or time limits important. A container may give more control at the price of more operations. Choose the smallest arrangement that meets measured requirements.

Read the original sources

Read next: How to prove an agent works