How I Review AWS Architectures: Risks, Trade-Offs, and Decisions

An AWS architecture review can become a checklist exercise: examine infrastructure, compare it to AWS Well-Architected best practices, identify gaps, and list recommendations. While this may produce a technically accurate report with many findings, it doesn't always help the business make better decisions.

In my experience, identifying architectural imperfections is straightforward. Determining which ones matter is much harder.

Not every deviation from best practices poses a meaningful risk. A single-region deployment is not always problematic. Migrating from Amazon ECS to Kubernetes does not guarantee architectural improvement. Adding redundancy, automation, or managed services can sometimes increase complexity without delivering proportional value.

The AWS Well-Architected Framework is an excellent foundation for evaluating cloud architectures. I use its principles to structure reviews across reliability, security, operational excellence, performance, cost, and sustainability. However, I do not treat the framework as a pass-or-fail checklist. I evaluate architectural decisions against business requirements, operational capabilities, technical constraints, and the cost of change.

Over the years, I have encountered situations where the best recommendation was to leave the existing architecture largely unchanged. In other cases, seemingly healthy AWS infrastructure concealed serious problems that only became apparent when examining component interactions under real workloads.

The goal of an architecture review isn’t to produce the longest possible list of improvements. It’s to identify meaningful risks, understand the trade-offs, and decide which changes are worth making.

In this article, I explain my approach to AWS architecture reviews, using examples from my consulting experience to illustrate how I evaluate risks, challenge assumptions, and turn technical findings into actionable decisions.

Start With Business Requirements, Not AWS Services

Before reviewing an AWS architecture, I want to understand what the system is expected to deliver and what happens when it fails.

How critical is the application to the business? What level of downtime and data loss is acceptable? What are the expected growth and performance requirements? Equally important, what are the budget and operational constraints?

Without these answers, distinguishing an architectural risk from an intentional trade-off is difficult.

A Real-World Example: Do We Really Need Multi-Region?

In one of my architecture reviews, I evaluated a production application running on Amazon ECS Fargate with Aurora PostgreSQL, Application Load Balancer, and other AWS services. The infrastructure spanned multiple Availability Zones but operated within a single AWS Region.

One proposed improvement was to add a second AWS Region to increase resilience.

From a purely technical perspective, the reasoning was understandable. A Multi-AZ deployment protects against certain infrastructure and Availability Zone failures, but it doesn’t provide continuity if an entire AWS Region becomes unavailable.

A Multi-Region architecture could reduce that risk. However, it would also add costs and operational complexity: cross-region data replication, failover procedures, infrastructure synchronization, and ongoing recovery testing.

Before recommending such a change, I wanted to understand whether the business actually needed it.

The key questions were straightforward: What would a regional outage mean for the business? What recovery time and data loss would be acceptable? And would the benefits of faster recovery justify the additional infrastructure and operational costs?

The review showed that the business could tolerate a longer recovery period in the event of a regional disaster. Continuous operation across Regions wasn’t a requirement.

I recommended keeping the existing single-Region architecture rather than introducing an expensive Multi-Region deployment.

Instead, we focused on recovery readiness: appropriate backup protection, documented recovery procedures, and the ability to restore the application within the agreed business objectives. The remaining risk of a regional outage had to be understood and explicitly accepted.

This didn’t make the architecture immune to regional failures. It meant choosing a recovery strategy proportionate to the actual business requirements.

For a payment platform with stringent recovery objectives or a system subject to specific continuity requirements, the conclusion could have been entirely different.

The Architecture Must Fit the Business

This example illustrates an important principle: a technically stronger architecture is not always the best business decision.

AWS provides multiple disaster recovery strategies, from backup and restore to active-active multi-region deployments. Each offers different recovery capabilities, costs, and operational requirements.

The architect’s role is not to select the most sophisticated option, but to determine which option satisfies business objectives with acceptable risk and complexity.

This is why I begin every architecture review with business context. Without it, even technically correct recommendations can result in unnecessary investments or leave important risks unaddressed.

Understand How the System Actually Works

Once I understand the business requirements, I examine how the architecture behaves in practice.

Architecture diagrams, Infrastructure as Code, and AWS configurations provide a useful starting point. They show how a system is designed and how its components are configured. But they don’t necessarily tell us how the system behaves under real workloads.

A service can be configured correctly yet still contribute to a serious architectural problem. Sometimes the issue lies not within individual components, but in how those components interact.

When Autoscaling Makes Things Worse

In one of my projects, I worked with an application running on Amazon ECS Fargate, behind an Application Load Balancer, with Aurora PostgreSQL as its database.

The application used ECS Service Auto Scaling to increase the number of running tasks as CPU utilization increased. The scaling policies were configured correctly, and new tasks were launched as expected.

However, during periods of high traffic, the application experienced increased response times and database connection errors. Adding more application instances wasn’t improving overall throughput as expected.

The issue was not ECS autoscaling itself, but the relationship between application capacity and database capacity.

Each ECS task maintained its own database connection pool. As the number of tasks increased, so did the potential number of concurrent database connections. Eventually, the application approached the database’s connection limits.

Scaling the application tier introduced additional pressure on the database instead of removing the bottleneck.

From the perspective of individual AWS services, much of the infrastructure appeared to function as configured. ECS added capacity, and the load balancer saw healthy application targets. However, the system as a whole was becoming less reliable.

Look Beyond Individual Services

This is why I do not evaluate scalability by reviewing autoscaling policies alone.

I seek to understand the entire request path and identify where capacity constraints exist. In this case, that meant examining the relationship between ECS task count, application concurrency, database connection pools, and Aurora’s capacity.

CloudWatch metrics such as ECS CPU utilization, ALB response times, and Aurora Database Connections can help reveal these relationships. Database load and application-level errors provide additional context.

The key question is not simply whether the application can scale horizontally, but whether its dependencies can handle the additional workload.

Our approach was to align ECS scaling limits with database capacity, reconsider connection pool configuration, and control application concurrency. Backpressure and connection management were more relevant than simply increasing the maximum number of ECS tasks.

Amazon RDS Proxy can also be useful in this situation, but connection pooling and multiplexing behavior must be evaluated against the application’s transaction patterns. Introducing another AWS service is not always the right solution.

Configuration Is Not Operational Evidence

This example illustrates a distinction I consider fundamental to architecture reviews: a correctly configured component does not guarantee a correctly functioning system.

An autoscaling policy can be working exactly as designed while the application fails to meet its performance objectives. A database can be available while applications can't obtain connections. Healthy load balancer targets don’t necessarily mean that users can complete their transactions.

That’s why I look beyond architecture diagrams and configuration settings. I examine production metrics, incidents, application behavior, and the interactions between critical dependencies.

The goal is to understand not only how the system was designed to work, but how it actually behaves, particularly under load, during failures, and when operating conditions change.

Separate Risks From Imperfections

One of the most important parts of an architecture review is distinguishing genuine architectural risks from technical imperfections.

The AWS Well-Architected Framework provides comprehensive best practices, but not every deviation represents a significant risk. Some are deliberate design decisions, while others are optimization opportunities that may not justify the cost of implementation.

For example, running an application on an older EC2 instance generation might indicate an opportunity to improve price-performance. But if the application meets its requirements, operates reliably, and the potential savings are insignificant, replacing those instances may not be a priority.

An architectural imperfection becomes a meaningful risk when it can plausibly affect a business objective.

Findings Need Context

When I identify a potential issue, I try to answer three questions:

• What is actually wrong? Is there a confirmed configuration problem, a missing control, or simply a deviation from a recommended practice?
• What could happen? Under what circumstances could the issue lead to an outage, security incident, data loss, performance degradation, or unnecessary expense?
• Why does it matter? What would be the consequences for the business, and how likely is the scenario given the existing safeguards?

Consider a database with automated backups enabled but no evidence of successful restoration testing.

The backup configuration may be correct, and AWS may report successful backup operations. However, this does not confirm that the application can be restored within its required Recovery Time Objective (RTO), or that the recovered data will be consistent and usable.

At the same time, the absence of restoration tests does not prove that recovery will fail.

What we have is a confirmed gap in recovery validation and uncertainty about actual recovery capability. The potential business impact depends on the application's criticality, the acceptable recovery time, and the consequences of data loss.

For a critical production system, that uncertainty may pose a significant risk that requires prompt investigation. For a disposable development environment, the consequences might be negligible.

The technical observation is similar, but the architectural assessment is different.

Evidence Matters More Than Assumptions

This is why I rely on evidence rather than configuration reviews alone.

AWS Config, CloudTrail, CloudWatch, and service-specific metrics provide valuable information about deployed resources, changes, and operational behavior. Incident reports, deployment histories, performance tests, and recovery exercises help establish whether architectural assumptions hold in practice.

I also distinguish between what has been verified and what remains uncertain.

A configured failover mechanism is not the same as a successfully tested failover. An enabled security control does not necessarily mean it protects every relevant resource. The absence of recorded incidents does not prove that a system is resilient.

When evidence is incomplete, I document the limitation rather than assume the architecture is safe or unsafe. Sometimes the most valuable recommendation is not an infrastructure change, but a targeted investigation or test.

Evaluate Business Impact, Not Just Technical Severity

Technical findings should ultimately be evaluated based on their potential business consequences.

I consider the likely failure scenario, its impact on critical business processes, its likelihood, and the effectiveness of existing controls. I also look at how far the failure could propagate and how quickly the organization could recover.

An issue affecting a non-critical internal application may be far less significant than the same issue affecting a revenue-generating production service.

Similarly, a finding classified as high severity by an automated security or architecture assessment tool does not automatically become the highest business priority. Its context, exposure, and consequences must still be understood.

This does not mean dismissing best practices or minimizing security and reliability concerns. It means making recommendations proportionate to demonstrated or credibly estimated risks.

An architecture review aims not to prove that every component follows an ideal design, but to identify where the current architecture exposes the business to unacceptable consequences.

Once those risks are understood, the next challenge is evaluating the available solutions and the trade-offs they introduce.

Evaluate Architectural Trade-offs

Every architectural decision involves trade-offs. Improving one aspect of a system can increase costs, introduce operational complexity, or create new risks elsewhere.

This is especially important when evaluating proposals to modernize an existing architecture. Newer technologies and more sophisticated platforms may offer additional capabilities, but adopting them does not necessarily improve the system. When reviewing a proposed change, I look beyond its technical advantages. I want to understand what problem it solves, what benefits it delivers, and what the organization must give up to implement and maintain it.

When Moving from ECS to Kubernetes Didn’t Make Sense

In one of my architecture reviews, I evaluated a proposal to migrate an existing application from Amazon ECS Fargate to Amazon EKS.

The application consisted of several containerized services integrated with AWS messaging and database services. ECS handled deployments and scaling, and the infrastructure was operating reliably.

The proposed migration aimed to standardize on Kubernetes, improve portability, and access its broader ecosystem.

These were reasonable arguments. Kubernetes offers extensive orchestration capabilities, a mature ecosystem, and a standardized API for managing containerized workloads. For organizations operating across multiple environments or requiring Kubernetes-specific capabilities, EKS can be an excellent choice.

However, the review revealed a fundamental issue with the proposal: we could not identify a significant limitation in the existing ECS architecture that Kubernetes would resolve.

The application already met its operational and performance requirements. There was no demonstrated need for Kubernetes-specific features, and multi-cloud portability was not an established business requirement.

At the same time, migrating to EKS would require changes to deployment pipelines, infrastructure definitions, monitoring, and operational procedures. The engineering team would also need to maintain the skills and processes required to operate the new environment.

Although managed Kubernetes offerings such as EKS Auto Mode can reduce infrastructure management overhead, adopting Kubernetes still introduces a different operational model.

The expected benefits did not justify the migration effort and additional complexity.

My recommendation was to keep ECS Fargate and invest engineering effort in improvements with clearer business value.

This was not a decision against Kubernetes. It was a decision against introducing a technology without a sufficiently strong reason to adopt it.

Consider the Cost of Change

When evaluating architectural alternatives, I consider factors beyond infrastructure pricing.

A migration has implementation costs, but it also introduces transition risks, changes operational responsibilities, and may require ongoing investment in skills and tooling.

The relevant comparison is between the current architecture and realistic alternatives, including the option to make no change.

For significant decisions, I consider several factors:

• Business value: What measurable problem will the change solve?
• Technical benefits: Will it improve reliability, security, scalability, or performance?
• Implementation risk: What could go wrong during migration, and can we safely reverse the change?
• Operational complexity: What additional responsibilities will the team take on?
• Total cost: Do the expected benefits justify both the implementation effort and ongoing expenses?

An architecture that is theoretically more flexible or sophisticated may still be a poor choice if the organization does not need that flexibility or cannot operate it efficiently.

The Best Decision Isn’t Always a Change

Sometimes an architecture review confirms that the existing technical choices remain appropriate.

This is a valuable outcome. It prevents unnecessary migrations, reduces the risk of introducing new problems, and allows engineering resources to be directed toward more important work.

A good architecture review should be just as capable of justifying an existing design as recommending a new one.

The goal is not to maximize technological sophistication, but to make deliberate architectural decisions that balance business value, technical requirements, cost, and operational risk.

Decide What Not to Fix

An architecture review often produces more findings than an engineering team can reasonably address. Some represent serious risks that require immediate attention. Others identify weaknesses that may become relevant in the future, while some are simply opportunities for improvement.

There is a temptation to turn every finding into a remediation task. However, this approach can create an expensive backlog of changes without necessarily improving the system in meaningful ways.

Not every architectural weakness needs to be eliminated. Some risks can be mitigated, some can be accepted, and some improvements may not justify the investment.

The challenge is knowing the difference.

Risk Acceptance Is an Architectural Decision

Accepting a risk does not mean ignoring it.

It means understanding what could go wrong, evaluating the potential consequences, and making a deliberate decision to retain that exposure.

Consider the single-region architecture discussed earlier. The lack of multi-region failover is a genuine limitation: a regional outage could keep the application unavailable for an extended period.

However, if the business understands this scenario, can tolerate the potential disruption, and considers the cost of multi-region deployment unjustified, retaining the existing architecture is a reasonable decision.

The important distinction is between a risk that has been consciously accepted and one that has been overlooked.

In my reviews, I expect significant accepted risks to have a clear business owner, documented reasoning, and defined conditions for reconsideration. Changes in business criticality, traffic, customer expectations, or regulatory requirements may invalidate an earlier decision.

Risk acceptance also has limits. Internal decisions cannot override mandatory legal, regulatory, or contractual obligations.

Consider the Risk of Making Changes

Fixing an architectural weakness is not always risk-free.

A database migration can introduce data integrity problems. Replacing a deployment platform can disrupt established operational processes. Changing network architecture may introduce new connectivity failures.

Even straightforward infrastructure modifications can have unexpected consequences when dependencies are not well understood.

That’s why I evaluate the risks introduced by a proposed solution alongside the risks it is intended to address.

For example, replacing a stable database architecture with a more sophisticated solution might improve theoretical scalability. But if the existing database comfortably meets current and foreseeable requirements, the migration may create more immediate risk than it removes.

Implementation effort is also important. Engineering time spent on a low-value migration cannot be invested in improving security, reducing operational incidents, or delivering business functionality.

The cost of remediation includes more than the AWS bill. It also includes engineering effort, operational complexity, migration risk, and the opportunity cost of not pursuing other priorities.

Choose the Appropriate Response

Not every finding requires the same response.

Sometimes the right approach is to eliminate the underlying problem. Sometimes a smaller change can reduce the risk to an acceptable level without redesigning the system.

In some situations, the most valuable next step is to collect additional evidence. If the severity or existence of a problem is uncertain, a targeted test or investigation may be more useful than immediately implementing a solution.

Sometimes the appropriate decision is to retain the current design, document the trade-off, and revisit it when circumstances change.

Deferring a decision differs from accepting a risk. When remediation is postponed, the remaining exposure still needs an owner, appropriate safeguards, and a clear point for reconsideration.

An Architecture Review Is Not a Remediation Mandate

I do not consider the number of resolved findings a useful measure of architecture review quality.

A review that recommends twenty changes is not necessarily better than one that identifies five important risks and explains why the remaining findings do not justify immediate action.

What matters is whether the organization understands its exposure and makes informed decisions about where to invest.

A successful architecture review should identify not only what needs to change, but also what should remain unchanged and why.

Once these decisions are made, the remaining task is to determine the right order of implementation. That requires distinguishing the severity of an architectural risk from the priority of the action intended to address it.

Prioritize Improvements

Identifying architectural risks and improvement opportunities is only part of an architecture review. The next challenge is deciding what to address first.

Most organizations have limited engineering capacity, budgets, and time. Even when several recommendations are technically valid, implementing them all at once may not be practical or beneficial.

I distinguish between the severity of a finding and the priority of the action needed to address it. A serious architectural risk may require immediate mitigation but a longer-term redesign. Conversely, a minor issue may deserve early attention if fixing it is inexpensive and delivers measurable value.

Prioritization is not simply about fixing the most severe problems first. It is about choosing improvements that deliver the greatest value, at the right time, with acceptable implementation risk.

Why Rightsizing Should Come Before Savings Plans

In one of my AWS cost optimization projects, I reviewed an environment running multiple applications on Amazon EC2 and ECS.

A significant portion of the compute usage was billed at On-Demand rates, making AWS Savings Plans an attractive opportunity to reduce costs. Cost Explorer recommendations suggested that committing to a longer-term usage level could provide meaningful discounts.

At first glance, purchasing Savings Plans appeared to be an obvious improvement.

However, a closer examination of the infrastructure revealed other optimization opportunities. Some EC2 instances were oversized relative to their actual workloads. Certain non-production environments ran continuously even though they weren't needed around the clock. There were also planned infrastructure changes that could affect future compute requirements.

Purchasing a large Savings Plan based on current consumption would have been premature.

Savings Plans provide discounted pricing in exchange for a one- or three-year hourly spending commitment. Compute Savings Plans are flexible across eligible compute services and configurations, but the financial commitment remains even if actual usage decreases.

In other words, committing to the current level of spending before eliminating unnecessary consumption could diminish the value of the optimization.

My recommendation was to change the implementation order.

First, identify and right-size overprovisioned resources using actual utilization and performance requirements. Next, eliminate unnecessary running hours in environments that don’t require continuous availability. Then, account for planned architectural changes and establish a realistic baseline of future compute usage.

Only after that would I recommend purchasing Savings Plans against the stable portion of the remaining demand.

The goal was not to avoid Savings Plans. They are an effective cost optimization mechanism when applied appropriately. The objective was to avoid making a long-term financial commitment based on infrastructure that was about to change.

Dependencies Matter as Much as Individual Recommendations

This example shows why you can't always evaluate improvement recommendations independently.

Rightsizing and Savings Plans may both be valid cost optimization opportunities, but their benefits depend on implementation order.

The same principle applies beyond cost optimization.

Improving observability may be a prerequisite for safely changing autoscaling behavior. Validating backup recovery may be more urgent than redesigning a database. Fixing an application bottleneck may eliminate the need for additional compute capacity.

When building an improvement roadmap, I consider expected business benefit, urgency, implementation effort, dependencies, and the risk each change introduces.

I also distinguish immediate actions from longer-term improvements. A critical weakness may justify temporary mitigation while the team plans a more comprehensive solution. This does not eliminate the underlying risk, but it can reduce exposure without requiring a rushed architectural redesign.

From Findings to an Actionable Roadmap

A prioritized list of recommendations is useful, but it is not the final outcome of an architecture review.

The real value comes when technical findings translate into decisions that business and engineering stakeholders can understand, evaluate, and act on.

An architecture review may identify dozens of issues across security, reliability, performance, and cost. However, presenting all findings with equal emphasis can overwhelm stakeholders and obscure where attention is most needed.

The final report should help decision-makers understand what matters, why it matters, and what actions are required.

Translate Technical Findings Into Business Consequences

Technical findings need to be connected to their potential business impact.

For example, reporting that an Aurora database is approaching its connection limit describes a technical condition. Explaining that additional ECS tasks may overwhelm the database during peak traffic and cause failed customer transactions makes the risk clear to business stakeholders.

Similarly, identifying a single-region deployment is less useful than explaining the potential consequences of a regional outage and whether the current recovery strategy meets the business’s expectations.

I structure significant findings around a few essential elements:

• Observation: What did the review establish, and what evidence supports it?
• Risk: What could go wrong, under which conditions, and what would be the business impact?
• Recommendation: What options are available, and what are their trade-offs?
• Decision: Should the organization fix, mitigate, accept, defer, or investigate the issue?
• Next steps: Who is responsible, when should action be taken, and how will success be measured?

This approach keeps the discussion focused on outcomes rather than individual AWS configurations.

It also makes uncertainty visible. If a risk cannot be assessed confidently due to missing operational evidence, that limitation should be explicit. The appropriate next step may be a recovery test, performance assessment, or further investigation rather than an immediate infrastructure change.

Separate Recommendations From Decisions

As an architect, my responsibility is to evaluate alternatives, explain their consequences, and recommend an appropriate course of action.

However, not every decision belongs to the architect.

The business owner must ultimately determine which risks are acceptable and which investments are justified, with input from engineering, security, operations, and other relevant stakeholders.

Consider the multi-region example discussed earlier. I can explain the added resilience, costs, operational complexity, and remaining failure scenarios for different recovery strategies. I can recommend retaining a single-region architecture when it satisfies the business requirements.

Accepting the residual risk of a regional outage is a business decision. It should be made by someone with the authority to accept its consequences.

This distinction is particularly important when recommendations compete for the same engineering budget.

A technically valid improvement may still be postponed in favor of another initiative with greater business value. The key is to make that choice explicitly, with a clear understanding of the trade-offs.

Make the Roadmap Realistic

Once decisions are agreed upon, I translate them into an improvement roadmap.

The roadmap should reflect dependencies, available engineering capacity, implementation risks, and business deadlines. It should distinguish immediate risk reduction from structural changes that require additional planning.

For example, resolving a database connection bottleneck might involve short-term limits on application concurrency followed by improvements to connection management. These actions have different implementation efforts and may need to be delivered in stages.

Likewise, cost optimization initiatives need appropriate sequencing. Rightsizing resources before purchasing Savings Plans can prevent long-term financial commitments based on unnecessary capacity.

I prefer a roadmap that identifies near-term actions, planned improvements, and items that can reasonably remain in the backlog. It should also make accepted risks and unresolved investigations visible, rather than treating them as completed work.

Each significant action needs an owner, an expected outcome, and a way to validate that the intended improvement was achieved.

Without these elements, even a well-prioritized roadmap can become another document that is not acted upon.

Measure Outcomes, Not Completed Tasks

An architectural recommendation is not successful simply because it has been implemented.

If the objective was to improve reliability, demonstrate the result through appropriate recovery or failure testing. If the goal was to improve scalability, the system should meet its performance objectives under representative demand. If the recommendation concerned cost optimization, compare expected savings with actual spending after the change.

These measurements help determine whether the original assumptions were correct and whether further action is necessary.

They also create a feedback loop for future architecture reviews. As the workload evolves, business requirements change, and new evidence becomes available, teams may need to reconsider earlier decisions.

The best outcome of an architecture review is not a perfect architecture diagram or a long list of resolved findings. It is a set of informed decisions, supported by evidence, that leads to measurable improvements.

This is what transforms an architecture review from a technical assessment into a practical tool for managing business risk and guiding technology investment.

Conclusion

An AWS architecture review should do more than identify deviations from best practices. It should help an organization determine whether its existing architecture meets business requirements, where meaningful risks exist, and which improvements justify the investment.

The AWS Well-Architected Framework provides a valuable foundation for this work. However, applying its principles effectively requires more than reviewing configurations and answering questions. It requires understanding how the system behaves, validating assumptions with evidence, and evaluating architectural choices in their business context.

Throughout my experience, some of the most valuable architectural decisions have involved not making a change, such as keeping a single-region deployment, retaining ECS instead of migrating to Kubernetes, or postponing a long-term compute commitment until unnecessary capacity had been eliminated.

Other reviews have revealed risks that were not apparent from infrastructure configurations alone, such as autoscaling behavior that overwhelmed a shared database.

These experiences have reinforced a simple principle: good architecture is not about maximizing the number of best practices implemented. It is about making deliberate trade-offs that support the business.

A successful review should leave stakeholders with a clear understanding of their risks, the reasoning behind recommended changes, and a realistic roadmap for improvement. Just as importantly, it should explain which parts of the architecture are already fit for purpose and why they do not need to change.

Ultimately, the value of an architecture review is measured not by the number of findings it produces, but by the quality of the decisions it enables.