Lesson 199 · AWS Learning Path

AWS 199: Architecture: balance security, resilience, performance, operations, and cost

Anil Jalela · Published Jan 10, 2026 · 7 min read

Why this lesson matters

Balance security, resilience, performance, operational excellence, cost, and sustainability by making explicit requirements and trade-offs.

What you will be able to do

By the end, you can:

• explain architecture: balance security, resilience, performance, operations, and cost in plain language;
• locate the current service controls in the AWS Management Console;
• run the matching CloudShell or AWS CLI queries and explain every important field;
• draw the identity, network, data, failure, and monitoring path;
• choose the service from requirements and reject it when those requirements are absent;
• diagnose a failed or misleading result from evidence;
• state the cost owner and prove cleanup or a no-create result.

Before you start

• Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
• CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
• The course example Region is ap-south-1. Global services and services with a required control Region are called out in their commands.
• Run aws sts get-caller-identity privately. Redact the account number before sharing evidence.
• Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
• This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
• Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.

The core model

How the request flows

+-----------------------------------------+
|  Business requirements and constraints  |
+-----------------------------------------+
                    |
                    v
+-----------------------------+
|  Pillar trade-off analysis  |
+-----------------------------+
              |
              v
+-----------------------------------+
|  Approved architecture and risks  |
+-----------------------------------+
                 |
                 v
+-------------------------------------+
|  Measured workload and review loop  |
+-------------------------------------+

Use a decision record, not a service wishlist

Start with measurable requirements: users/locations, transactions, latency percentiles, availability, RTO/RPO, consistency, data classification/residency, change frequency, team skills, budget and growth. Mark each as hard constraint, target or assumption. An architecture cannot be “best” without context.

For every major decision record:

1. State context and decision deadline.
2. List at least two viable alternatives, including “do nothing/simpler.”
3. Evaluate security, reliability, performance, operations, cost and sustainability at equal requirements.
4. Record selected option and why each alternative loses.
5. Identify risks, assumptions, compensating controls and reversibility.
6. Define validation metric/test, owner and review trigger.

Balance common tensions

Security and operational readiness are constraints, not expendable bargaining chips. “Cheapest” means lowest total cost that meets requirements, including people, incidents and migration - not smallest monthly calculator line.

Evaluate the end-to-end request

Trace DNS/edge → network entry → compute identity → queue/cache → data store → logs/alarms → recovery. At every hop identify authentication/authorization, encryption, timeout/retry/idempotency, quota/capacity, failure isolation, data consistency, telemetry, price unit and owner. Hidden synchronous dependencies often dominate availability.

Model normal peak, one-AZ failure, dependency throttling, bad deployment, credential compromise, data corruption and regional disaster. State how graceful degradation changes the user experience. Use load/failure/security/restore tests to replace assumptions.

Present an architect recommendation

Lead with recommendation and requirement fit. Show one diagram, decision matrix, top risks, cost range/sensitivity, migration phases, rollback and unresolved questions. Distinguish facts, measured results and assumptions. Set review triggers such as 2× traffic, new data class, 20% unit-cost change, missed SLO or new Region.

Architecture decision table

AWS Management Console, step by step

Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.

1. Use the Console service search and open Well-Architected workload, Pricing Calculator estimate, security findings, alarms, backup jobs, and service quotas; confirm the account and Region before reading the page.
2. Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
3. Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
4. Return to the resource list, clear filters, and record the final inventory. On the read-only track, do not choose Create, Save, or Delete.

CloudShell and AWS CLI, step by step

Start with a known caller and Region:

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure list

Redact the account part of the ARN in shared evidence. Now run the topic queries:

aws wellarchitected list-workloads --output table
aws cloudwatch describe-alarms --state-value ALARM --output table
aws backup list-backup-jobs --by-state FAILED --max-results 20 --output table
aws service-quotas list-services --query 'Services[].ServiceName' --output text

Expected interpretation

A balanced architecture is not the maximum of every pillar. It meets business targets, records residual risk, defines evidence and owners, and can evolve when requirements change.

Practical work

Write the final P05 ADR. Include user load, SLO, RPO/RTO, data classification, threats, budget, team skills, selected architecture, rejected alternatives, failure tests, cost estimate, improvement backlog, and approval gate.

Diagnose this topic from its own evidence

• “Use service X because it is managed” is incomplete: quantify constraints, failure, quota, cost and operational ownership.
• Alternatives are not comparable: normalize availability, performance, durability and workload demand.
• Diagram has no trust/failure boundaries: add identity, data flow, Regions/AZs and dependencies.
• Decision has no evidence: attach benchmark, game day, policy analysis, restore test and cost model.
• Architecture never changes: define measurable review triggers and reversible migration steps.

Cost and cleanup

Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.

Knowledge check

1. What operational purpose is this lesson solving?

Expected direction: Balance security, resilience, performance, operational excellence, cost, and sustainability by making explicit requirements and trade-offs.

1. Which scope or ownership boundary must be proved first?

Expected direction: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Balanced architecture decision.

1. What evidence is strong enough to accept the result?

Expected direction: Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Balanced architecture decision.

1. Which tempting design or shortcut must be rejected?

Expected direction: Avoid gold-plating, minimizing one pillar in isolation, or leaving assumptions and residual risks ownerless.

1. Which cost dimensions and retained resources need an owner?

Expected direction: Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.

Lesson acceptance

• Produce at least five complete architecture decision records for P09.
• Map every hard requirement to a component, control and verification test.
• Evaluate at least six cross-pillar trade-offs using equal requirements.
• Present normal and failure request/data/evidence paths with top risks.
• Defend cost range, rollback, residual risk and review triggers to an independent reviewer.

Official sources

• Well-Architected Framework
• Architecture decision records