Tech Stack Audit: A Step-by-Step Framework

Guides to running a tech stack audit mostly build the inventory the same way: interviews with owners, invoices, SSO sign-in reports, and vendor usage exports, collected into a spreadsheet. That is a useful method, but architects also need evidence of what is actually deployed.

The architect’s version starts from the running system. On an AWS estate of any size, the gap between what is documented and what is deployed is the finding, not a nuisance to clean up first. This piece covers the mechanics: deriving an inventory from the system instead of from people, what such a pass cannot see, and what you do with the difference.

What Is a Tech Stack Audit?

A tech stack audit is a structured review of the technology your organization actually runs: applications, infrastructure, data stores, and third-party services. It identifies what is redundant, unowned, undocumented, or no longer delivering value. An architecture audit asks what is running, a spend audit asks what you are paying for, and the two overlap without being the same.

The distinction matters because it changes where the evidence comes from. A spend-side review is elicited: every input passes through a person or a billing relationship, so anything nobody pays for and nobody remembers is invisible. A derived audit reads the cloud account, the infrastructure definitions, the source repositories, and the traffic, none of which depends on anyone remembering.

Neither is complete on its own, so it helps to know which one you are running. The ongoing discipline, including evaluation criteria and who owns the decisions, lives in our guide to tech stack management.

Why Tech Stack Audits Matter for AWS-First Engineering Teams

AWS’s Well-Architected review guidance notes that reviews often help teams understand their actual implementation for the first time. That describes what can happen when a stack grows through many small decisions by different people over several years.

On an AWS-first estate, the mechanism is specific. Managed services get created by a Terraform module or a CloudFormation change; they work, and nobody revisits them. Accounts multiply for good isolation reasons, each with its own defaults, and a replaced service keeps running because nobody’s ticket was to delete it. None of that is dysfunction, and it is why the map in anyone’s head is partial.

The cost is not mainly the idle resources. It is that architecture decisions get made against the partial map: you approve a migration without knowing two internal tools read the database directly, or meet the sixth consumer during cutover. That kind of technical debt sits in the difference between the stack you can describe and the one you have.

Signs It’s Time for a Tech Stack Audit

The best-known triggers are financial: rising spend, license renewals, seats nobody uses. Those still apply, and for an architecture team the signals show up earlier.

• Nobody can answer a blast-radius question quickly. Someone asks what depends on a service, and the honest answer requires manual investigation across several owners and tools.
• An incident review turned up a component nobody claimed. The strongest single signal, worth acting on the same week.
• Engineers spend more time reading the system than changing it, and onboarding takes longer for reasons nobody can name. Both can signal that the running system has diverged from the documented one.
• A migration or acquisition is coming. Any project that assumes a complete picture of the stack needs a pass that produces one.

The Tech Stack Audit Framework: 5 Steps

Steps 1 and 4 are the ones worth automating first, because their output degrades fastest between passes.

1. Derive the inventory from the running system
2. Write down what the discovery pass cannot see
3. Reconcile the derived inventory against the declared one
4. Map dependencies from observed traffic, not from memory
5. Turn the delta into decisions with owners

Plenty of audit guides tell you to discover what is in use rather than define it. The less common question is where the discovery evidence comes from.

Step 1: Derive the Inventory From the Running System

Start from artifacts, not from people. On AWS, that means the resource inventory across every account and region, infrastructure definitions in version control, orchestration state, and source repositories. Each exists independently of anyone’s memory, and what comes out is an architecture inventory rather than recollections.

A first pass assembled by hand into a spreadsheet is legitimate, and for a small stack it may be all you need. Its failure mode is that it describes the system on the day you built it and nothing after. We built Stacks to regenerate the inventory rather than transcribe it once, on a physical-first model anchored in real availability zones. It regenerates the portion of the model your subscribed integrations cover, so completeness is bounded by those sources.

A diagram drawn by hand records what someone believed on the day they drew it, and it starts drifting the moment it is saved. That is the problem we built Stacks to remove. Whichever route you take, record the source for every entry. An inventory line you cannot trace to a specific artifact is a claim rather than a finding.

Step 2: Write Down What the Discovery Pass Cannot See

In an elicited audit, a blind spot announces itself as a question nobody could answer. A derived inventory’s blind spots are silent, because the pass is bounded by the systems it is allowed to read. You control which integrations feed it, and therefore how complete it is. A model missing a whole class of systems does not produce obviously broken recommendations; it produces confident ones with a blind spot.

Make the boundary explicit before you interpret anything. Typical gaps include a cloud account outside the audited organization, SaaS the business bought without engineering, and anything in a colocation or on a workstation. Contractor-owned repositories belong on the list, along with data sharing that exists as a signed agreement rather than a network path. A one-page list of these is the most useful artifact of the audit: it tells every reader how far to trust the rest.

Step 3: Reconcile the Derived Inventory Against the Declared One

Put the two pictures side by side: what the system says it is, and what the architecture record says it should be. Reading source alongside infrastructure is what makes this work. It is why we connect repositories at all: to resolve the gaps between declared architecture and observed behavior.

Three categories come out, and each wants different handling:

• Running but not declared. Something exists that no diagram or ADR mentions. Sometimes it is shadow infrastructure. More often it is a legitimate component whose documentation never happened.
• Declared but not running. A planned service that was canceled, or one replaced without the record catching up. Cheap to fix and worth fixing, since this is what makes the record untrustworthy.
• Running differently than declared. The hardest and most valuable category, and where configuration drift lives. The component is where it should be, and it is not behaving the way the design says.

Step 4: Map Dependencies From Observed Traffic, Not From Memory

Ask an engineer what calls a service, and you get the callers they know about. Traffic evidence gets you further, with its own edges. It reveals the callers observed during the window you chose and within your logging coverage, which is not the same as every caller that exists.

Combine it with source and configuration analysis and with what owners know, so dormant, sampled, uninstrumented, and application-layer dependencies are not mistaken for absent ones. Practical inputs include network flow data, service mesh telemetry, load balancer logs, and database connection sources. Filtering matters as much as collection, which is what the Filter control in our Infrastructure View is for.

Work outward from your highest-criticality components rather than mapping everything at once: a complete dependency map of a large tech stack is unreadable. Label the output with the window and the sources it came from: a map without that label reads as a claim about the present.

Step 5: Turn the Delta Into Decisions With Owners

An audit that produces a document is not finished. Sort every item from steps 2 through 4 into one of four buckets: remove it, adopt and document it, replace it, or accept it with a stated reason and a review date. That last bucket is not a cop-out: accepted risk beats silently carried risk, and the written reason makes the next audit shorter.

Evaluation criteria for those calls, covering criticality, cost, and fit, belong to the management discipline rather than the discovery pass. The questions that decide a bucket, such as who else uses this, should be answered from the live model rather than from recollection. That is what we built Archie for, within the coverage you connected. Every item leaves this step with a name attached, because findings without owners are just a longer list.

Where Derived Tech Stack Audits Go Wrong

Three failure modes show up repeatedly, and the first is specific to derived audits. The procurement and governance ones belong to the tech stack management guide.

Treating the derived inventory as complete. It is more accurate than the spreadsheet and still bounded by what it can read. A partial inventory that knows it is partial is useful, and one that presents as total is worse than the spreadsheet, because people stop checking it.

Reading the delta as an error list. Every gap becomes a ticket, the backlog doubles overnight, and nothing gets done. The delta is evidence about where your architecture record stopped tracking reality: some should change the system, some should change the record.

Stopping at the report. The finding that matters is usually a decision the team has been deferring, not a resource to delete. That is where modernization plans with explicit trade-offs begin, and it separates the audit that gets referenced next quarter from the one that gets filed.

How Often You Should Audit Your Tech Stack

Use a regular review cadence alongside reviews triggered by significant changes. AWS recommends continual architecture review as workloads evolve, with reviews at key product milestones, including early design and before go-live. A live model supplies current evidence; it does not remove the need to review decisions.

In practice, run a full audit on triggers rather than dates: a major re-architecture, a cloud migration, an acquisition, a compliance scope change, or a new architect inheriting the estate. That is the milestone idea applied to an estate rather than a single product.

Between triggers, the goal is to make each audit smaller than the last. If the inventory regenerates from the running system, the annual review becomes a decision meeting about the delta rather than a rediscovery exercise.

Tech Stack Audit Checklist

Use this as a readiness check before you start and a completion test at the end. Every item should be a clear yes.

• Scope is defined by billing and identity boundaries, not by the accounts you remember
• Every inventory entry names the artifact it was derived from
• The list of things the discovery pass could not see is written down and shared
• The declared architecture record has been located, even if it is out of date
• Running-but-not-declared, declared-but-not-running, and running-differently items are separated
• Dependency edges for top-criticality components come from observed traffic, labeled with their window and sources
• Each finding sits in one bucket, has a named owner, and if accepted, a stated reason and a review trigger
• The output is a set of decisions, not only a list of components

Conclusion: From Audit to Aligned Architecture

A tech stack audit is only as good as its source of truth, and that source degrades from the moment you write it down. That is the reason to derive the inventory rather than collect it, and to name the edges of what you derived.

The first four steps sit in the Understand phase of our loop, and the fifth hands off to Decide. Run it once, and you get a good quarter. Build the pass so it regenerates and the next audit starts from the delta instead of from scratch. To see the derived pass against a real AWS estate, book a walkthrough and bring the question you have not been able to answer about your own.