Security at Scale: Lessons From Launching Services at AWS and Why Most Companies Can’t Replicate It
Chaochen shows that building secure software is hard for large companies, and why most smaller companies struggle to achieve the same level of security.
Why Building Secure Software is Hard Even at AWS
Security is supposed to be a foundational pillar of modern application, mentioned in the same breath as availability, durability, and scalability. But while everyone agrees security is important, very few teams know how to actually achieve it. Here’s the uncomfortable truth most people don’t realize:
Even companies like AWS, with deep pockets and dedicated AppSec/security expertise, struggle to scale secure software development. Now imagine the odds for a 20-person startup, a mid-market engineering org, or a team shipping features every week with no resident security expert on staff. Most teams aren’t failing because they don’t care about security. They fail because the system is stacked against them:
They don’t know what “good” looks like.
They don’t know what to prioritize.
They don’t have trained AppSec/security engineers to guide decisions.
And they lack the time and context to analyze every feature deeply.
This article is about what it really took to build secure services at AWS and why the rest of the world needs a new model.
Bringing AppSec Into Every Release and What It Actually Looked Like at AWS
I was fortunate to work on the launch and decade-long evolution of Amazon Data Firehose, serving hundreds of thousands of customers. Within AWS, a single security bug can cause catastrophic customer impact and irreversible trust loss. That pressure is real.
To prevent this, AWS enforces a mandatory security review (called an AppSec review) when:
launching a new service
adding a new API
modifying an existing API
Nothing ships without AppSec sign-off. This creates a robust security culture but also reveals why the traditional model doesn’t scale.
The Pain Points Nobody Talks About
Here’s what the process actually entailed:
AppSec teams were always overbooked. You’d often wait weeks for a single consult.
They lacked deep context on the specific service, which meant debates, escalations, and multi-week back-and-forth cycles.
Security became the pacing item for many projects, not because security was wrong, but because the process was fundamentally human-limited.
If AWS struggles with bandwidth, expertise, and alignment across teams, how should a smaller company with no AppSec team ship secure software?
Threat Modeling: Powerful but Fragile Even for the Most Senior Engineers
Threat modeling is the backbone of AWS AppSec reviews. It’s a systematic, collaborative process designed to surface what can go wrong and how to address it. Done well, it serves as an asynchronous review mechanism that helps bridge the knowledge gap between engineering and AppSec teams. The workflow starts with defining trust boundaries and data flows, then walks teams through potential threats to each component and the possible mitigations. Multiple stakeholders contribute to produce a clear, executable plan.
Here’s the typical workflow my team followed at AWS:
The engineering team gathers project context: architecture overviews, trust boundaries, data flows, processes, data stores, and external dependencies.
For each system component, the team performs threat analysis to identify attack scenarios and assess impact, severity, and likelihood.
For each identified threat, the team proposes architectural or code changes, controls, or guardrails, along with estimated effort and mitigation effectiveness.
Engineering and AppSec jointly review the threat list and proposed controls.
After incorporating feedback, engineering and product teams align on an execution plan, prioritizing some mitigations and explicitly accepting certain risks.
Engineering implements the plan, updates code or policies, and validates changes with tests.
The AppSec reviewer validates those tests and policy updates and, if satisfied, approves the release.
Every step in this process requires deep expertise, accurate shared context, and significant coordination. And this was at AWS, an environment with dedicated AppSec teams, strong processes, and a mature security culture. Most companies simply don’t operate with anything close to this level of support.
Challenges at Scale
As a tech lead, I could usually piece together enough understanding to evaluate my service from a security perspective. Documenting context upfront also made reviews with AppSec far more productive. But doing this once is very different from doing it continuously across multiple features, parallel workstreams, and frequent releases. At scale, several challenges become unavoidable.
Context Gathering
Accurate context is the foundation of any meaningful threat model. But gathering and maintaining it is extremely difficult, especially when the responsibility falls on a single engineer. This often leads to gaps that weaken the entire security assessment.
Two issues show up repeatedly:
Insufficient context: System architecture, data flows, user interactions, and operational processes all need to be captured by someone who understands the entire system end-to-end. In large, long-lived systems like Amazon Data Firehose, that’s unrealistic; many original contributors are long gone, and tribal knowledge fades.
Validating context: Even when engineers do their best to document everything, it’s hard to know whether diagrams and flows are accurate or current. Much of the review depends on good intentions, not verified truth, and discrepancies often surface too late.
Long Pole
Threat modeling often becomes the long pole of a project for several reasons:
Security reviewers are overloaded, and it can take weeks to get feedback or close a single decision.
Threat modeling requires a fully documented architecture, which means work can’t start until designs are mature and detailed.
Feedback can trigger architectural changes, forcing teams to pause development, redo designs, and re-align on schedules.
I experienced this firsthand on one project where the review began mid-development. AppSec required us to move in-memory data processing into an isolated, containerized microservice. We had to discard what we’d already built, redesign the architecture, and reopen the review—adding weeks of churn during which the project barely moved forward.
Coordination Between Stakeholders
Stakeholders often view risk through different lenses. Security teams aim to uphold the highest bar and call out every concern. Engineering teams must balance those asks against limited resources and committed timelines. Product teams weigh risk against user experience, cost, and delivery targets. Aligning these perspectives frequently led to long, open-ended meetings and debates, making it difficult to reach decisions and keep the project moving.
Tracking of Changes
Team churn adds another layer of complexity. Reviewers or engineers who created the original threat model often move to new projects, and their successors may interpret risks or mitigation plans differently. Without meticulous documentation, this turnover can create conflicting guidance and significantly disrupt the project timeline.
Validation of Mitigation
Security reviewers often require full test coverage for the mitigation plan, but validating those tests is difficult in practice:
Reviewers rarely have deep knowledge of the service’s business logic, making it hard to assess whether tests truly cover the intended scenarios.
Each engineering team uses its own testing framework, outside the reviewer’s control. Tests may not run as frequently as expected, and failures can slip through after approval with no enforcement.
Some attack scenarios are extremely complex to simulate, creating tension between what reviewers want and what engineering can realistically test.
I saw this firsthand on a feature involving cross-account access restricted to specific principals. We built end-to-end tests and showed successful results, but confirming that the test logic was correct was far harder. Months after release, we discovered some of those tests had been accidentally disabled, and no one noticed!
(Lack of) Continuous Threat Modeling
Threat models age quickly. New vulnerabilities, attack patterns, and exploitation techniques emerge constantly, meaning a system that passed review years ago may no longer meet today’s standards. Once a service launches, the excitement fades, but the security posture still needs ongoing monitoring, something most teams aren’t staffed or structured to do.
This gap also creates friction when developing new features. Components considered “safe” in the existing system may no longer be acceptable under updated threat knowledge. I often saw debates like: “This workflow has been running for five years and isn’t part of my change, why is it blocking my release?” The underlying issue is that without continuous threat modeling, outdated assumptions surface as last-minute surprises that no team wants to absorb in the middle of development.
Opportunities Ahead
After years of building, scaling and evolving secure services like Amazon Data Firehose at AWS, I came to a clear conclusion: the traditional AppSec model simply doesn’t scale. Even inside AWS, with dedicated security teams, strong processes, and a culture that truly values security, the process was constantly strained and fragile. Engineers like me spent significant time piecing together fragmented system context, coordinating with overextended AppSec reviewers, and navigating long cycles of back-and-forth to align on priorities and mitigation plans. The work was necessary, but incredibly manual and often fragile, easily disrupted by reviewer changes, missing documentation, or shifting project timelines.
If AWS struggles with this level of overhead, most teams outside big tech have almost no chance of achieving similar security rigor. Smaller companies don’t have full-time AppSec engineers, detailed architectural history, or the bandwidth to run multi-week security reviews for every release. Yet the expectation is that every engineering team should somehow meet the same standard. That gap between expectation and capability is what pushed me to rethink how AppSec should work.
This is why I’m excited about what we’re working on at Trent AI. The tools we’re building directly address the pain points I lived every day at AWS. For the first time, it feels possible to give every engineering team the level of security support only the largest companies could afford and to deliver it in a way that’s more scalable, reliable, and integrated than the processes I depended on at AWS.
