TCP #126: Architecture decisions are risk decisions. Most teams forget that.
How to evaluate AWS architecture choices on what they cost you in 18 months, not what they save you this sprint.
Every AWS architecture decision is made under deadline pressure. The product team needs the feature. The team picks the design that ships fastest. The work goes out, the feature performs, and the decision is logged as a success.
Eighteen months later, the same architecture is the reason a migration is delayed, an audit stalls, an incident takes four hours to recover from, or a tenant cannot be onboarded without manual intervention.
The decision was not wrong on the day it was made. It was made against the wrong frame.
Architecture choices are not feature decisions. They are risk decisions. The team that treats them as feature decisions ships faster in the short term and pays interest forever. The team that treats them as risk decisions ships almost as fast and stops paying interest after the first iteration.
Why the Risk Frame Gets Lost
Engineering organizations frame architecture as a delivery problem because delivery is the visible bottleneck.
The roadmap is fixed. The deadline is fixed.
The team is asked: Which AWS service can we use to ship this on time? The conversation is dominated by what the design enables today, not what it constrains tomorrow.
This produces predictable failure patterns. The team picks Lambda for a workload that grows into a six-figure monthly bill. The team picks DynamoDB for a workload that turns out to need transactional integrity across tables. The team selects a single-account deployment, which prevents a future move to a multi-tenant platform. The team picks a managed service in a region that does not meet the next compliance scope.
None of these decisions is bad in isolation. Each one solves the immediate problem. The cost is not visible at the time of decision. It surfaces during an event the team did not plan for: a migration, an incident, an audit, a customer in a regulated industry, or a competitor that built the same product more cheaply.
By that point, the architecture is load-bearing. Changing it is expensive enough that the team continues to pay the interest rather than refinance.
The Three Categories of Future Risk
Every AWS architecture decision implicates three categories of future risk. The team that names them at decision time makes different choices than the team that does not.
