Step 3 — Continuous Improvement

Every architecture you’ve designed so far in this track was greenfield — a blank canvas. Most of the real work of a Professional-level architect happens after that canvas already has three years of production traffic on it, a backlog of “we’ll fix that later” decisions, and a team that’s afraid to touch half of it. This step is about that harder, messier job: looking at something that already works and deciding what to change, in what order, without breaking it.

The Well-Architected Framework as a Diagnostic Tool, Not a Checklist

You met the six pillars early in the Associate track. At Professional level, the pillars stop being something you memorize and start being something you apply as a structured interrogation of an existing system. AWS formalizes this with the Well-Architected Tool and, for deeper engagements, Well-Architected Reviews run against workload-specific and industry lenses (Serverless Lens, SaaS Lens, Data Analytics Lens) layered on top of the general framework.

A review produces two buckets of findings, and the exam consistently distinguishes them:

HIGH RISK ISSUE (HRI)                    │  MEDIUM RISK ISSUE (MRI)
──────────────────────────────────────────┼─────────────────────────────
Single points of failure in prod          │  Missing tags on non-critical resources
No tested backup/restore process          │  Slightly oversized instances
Hardcoded credentials in application code │  Missing CloudWatch dashboards
Public database with no encryption        │  No lifecycle policy on log bucket

The Professional exam does not ask you to fix everything found in a review simultaneously — it asks you to prioritize. High-risk issues that threaten data loss, security exposure, or total outage get remediated first, generally regardless of remediation cost, because the downside is asymmetric. This prioritization logic — impact and likelihood before cost — is the actual skill being tested, more than familiarity with any specific pillar.

Finding the Bottleneck Before You Fix It

A recurring failure mode in real reviews (and in exam distractor answers) is treating a symptom as the root cause. A system that’s “slow” gets more compute thrown at it, when the actual constraint was a database connection pool, a synchronous downstream call, or a single-threaded queue consumer. Professional-level troubleshooting starts by tracing the request path end-to-end and instrumenting each hop.

Client ──▶ CloudFront ──▶ ALB ──▶ ECS Service ──▶ RDS (single AZ, db.m5.large)
                                        │
                                        └──▶ External payment API (synchronous call, 800ms p99)

In this shape, the ECS service can autoscale all day and the p99 latency won’t improve, because every request blocks on an 800ms synchronous call to a third party. The fix isn’t more compute — it’s decoupling: accept the order, return quickly, and process the payment confirmation asynchronously via a queue and webhook or polling. X-Ray is the tool that actually reveals this in production rather than in theory — its service map shows you exactly where time is spent across a distributed request, and Professional-level scenario questions frequently describe symptoms (“high latency, low CPU utilization across the fleet”) that only make sense once you recognize the bottleneck is I/O-bound waiting, not compute-bound processing.

CloudWatch Application Insights and Compute Optimizer round out the instrumentation picture — Application Insights automatically surfaces anomalies for common application frameworks without hand-built dashboards, and Compute Optimizer recommends resource right-sizing based on actual utilization history rather than guesswork, which matters when a review finds instances provisioned for a peak load that happens twice a year.

Automating Operational Excellence: Self-Healing Systems

The Operational Excellence pillar’s most testable idea is this: humans responding to alarms manually does not scale, and it introduces the exact delay and error rate you’re trying to design out. A mature architecture treats common failure classes as automatable, not escalatable.

Failure Signal	Manual Response (avoid)	Automated Response (prefer)
EC2 instance fails health check	On-call engineer investigates and reboots	Auto Scaling replaces the instance automatically
Lambda function throwing errors	Engineer reads logs, redeploys	CloudWatch Alarm triggers rollback via CodeDeploy
Disk approaching capacity	Ticket filed to increase volume	EventBridge rule triggers Lambda to expand EBS volume
Unusual account activity	SOC analyst manually investigates	GuardDuty finding triggers automated Lambda remediation (isolate instance, revoke credentials)

Systems Manager Automation documents and runbooks let you codify the remediation steps once and trigger them from EventBridge rules or CloudWatch Alarms, turning “the wiki page says to do these seven steps” into “this runs automatically at 3 a.m. without waking anyone up.” The exam frequently frames this as “reduce mean time to recovery without increasing headcount” — that phrasing is a strong signal the expected answer involves EventBridge plus Systems Manager Automation or a Lambda-based remediation, not a bigger on-call rotation.

AWS Fault Injection Simulator (FIS) pushes this further, into chaos engineering: rather than waiting for production to fail and finding out whether your self-healing actually works, FIS deliberately injects failure — terminating instances, throttling API calls, introducing latency, simulating an AZ outage — inside guardrails you define (stop conditions tied to CloudWatch Alarms so an experiment aborts if it causes real customer impact). A well-run continuous improvement program schedules these experiments regularly rather than treating resilience as something you built once and can assume still works after eighteen months of unrelated changes.

Modernization: Monolith to Microservices, Without a Big Bang

Rewriting a monolith from scratch is the answer nobody should give and the exam consistently rejects it as a distractor. The tested pattern is the strangler fig: build the new service alongside the old monolith, route a slice of traffic to it, and only decommission the corresponding monolith code once the new path is proven.

                         ┌────────────────────┐
   Client ───▶ API GW ──▶│  Routing Rule       │
                         └──────────┬──────────┘
                     ┌──────────────┴───────────────┐
                     │                               │
             ┌───────▼────────┐           ┌──────────▼─────────┐
             │  Legacy Monolith │          │  New Microservice   │
             │  (still handles  │          │  (handles the       │
             │  everything else)│          │  "checkout" path)   │
             └──────────────────┘          └─────────────────────┘

API Gateway (or an ALB with path-based routing) sits in front of both, and the routing rule moves traffic incrementally — 5%, then 25%, then 100% — to the new service as confidence builds. This is the same mechanism as a canary deployment, applied at the architecture level instead of the deployment level, and recognizing that overlap is worth internalizing: modernization and safe deployment are the same underlying technique used at different time scales.

Database Modernization

Databases resist the strangler pattern more than application code does, because data has gravity — you can’t easily run “half” a database. The common professional-level path is a staged one: first move off a commercial engine onto a compatible open-source-based engine (commonly using DMS with schema conversion tooling to handle the engine translation), then only afterward consider decomposing a single large relational database into per-service databases as part of a broader microservices effort.

Trying to do both simultaneously — engine migration and schema decomposition in one step — is a common exam distractor precisely because it maximizes risk in a single cutover. The tested best practice sequences these efforts:

Assess and convert schema/application compatibility issues (schema conversion tooling flags stored procedures, proprietary functions, and other engine-specific dependencies)
Migrate data with continuous replication so cutover downtime is minimal
Validate functional and performance parity against the source engine
Only then, as a separate initiative, evaluate decomposing shared tables into per-service ownership if a broader microservices migration is underway

Exam Focus: What Questions Test From This Step

Well-Architected review output: distinguishing High Risk Issues from Medium Risk Issues and prioritizing by impact/likelihood, not remediation cost alone
Recognizing symptoms of a bottleneck (high latency, low CPU) as evidence of I/O-bound waits rather than needing more compute
X-Ray service maps as the tool for locating the actual bottleneck in a distributed request path
EventBridge plus Systems Manager Automation (or Lambda) as the pattern for automated remediation, replacing manual on-call response
AWS Fault Injection Simulator for proactive chaos engineering, including the role of stop conditions
Strangler fig pattern for monolith modernization, including API Gateway/ALB incremental routing
Sequencing database modernization: engine migration and compatibility validation before schema decomposition, not simultaneously
Rejecting “rewrite from scratch” and “big bang cutover” as high-risk distractor answers