How to Understand an AWS Environment You Didn't Build

How Do You Understand an AWS Environment You Didn’t Build?

An unfamiliar AWS account rarely explains itself. Resource names may be inconsistent, diagrams may be stale, and a list of services tells you very little about how the system actually works.

The goal of a first architecture review is not to redesign it. It is to build an evidence-based picture of what exists, how requests and events move, where the trust boundaries are, and which questions need answers.

Don’t start with the resource list

An inventory is useful, but architecture is mostly about relationships. A Lambda function matters because of what invokes it, what it can access, where failures go, and which data it changes.

So start at the edges and trace inward. Find the public entry points: Route 53 records, CloudFront distributions, API Gateway APIs, load balancers, or other externally reachable endpoints. Then follow requests toward compute and data stores. Separately trace asynchronous paths through services such as EventBridge, SNS, SQS, and Lambda.

This gives you a working system map rather than a service catalog.

Use four passes before drawing conclusions

Trying to understand everything at once creates noise. I would break the review into four passes.

1. Inventory — What exists? Identify accounts, regions, VPCs, entry points, compute, data stores, queues, event buses, storage, IAM roles, secrets, and monitoring resources. Infrastructure-as-code repositories and tags can add useful context, but verify them against deployed resources.

2. Relationships — What talks to what? Trace synchronous requests, event sources, queue consumers, IAM permissions, security-group paths, database clients, bucket access, and cross-account relationships. This is where an architecture begins to emerge.

3. Controls — How is it protected? Look at public exposure, IAM scope, encryption, secret handling, backup and recovery settings, network boundaries, and failure handling. Record what you can prove separately from what you still need to ask.

4. Operations — How does it behave? Configuration shows intended structure; metrics and logs show runtime behavior. Look for errors, throttling, queue depth, latency, database pressure, scaling behavior, and alarms relevant to the paths you identified.

The output should be a current architecture map, prioritized risks, and questions that require human context.

Example: the Lambda that looks wrong

Suppose you find a Lambda function inside a VPC connecting to an Aurora cluster. It has a 15-minute timeout, no obvious dead-letter queue, and broad access to several resources.

It would be easy to label all three as defects. That would be premature.

Trace the function first. Perhaps API Gateway invokes it synchronously, in which case a dead-letter queue on the Lambda function is not the relevant failure mechanism. The long timeout may be unnecessary, or it may support a specific background path. Broad permissions may be excessive, but you need to identify which APIs the code and runtime actually depend on before proposing a narrower policy.

Then examine operational evidence. Does the function approach its timeout? Is Aurora showing connection pressure when it scales? Are failures visible to operators?

The important distinction is observation versus conclusion. “Timeout is configured to 900 seconds” is an observation. “This timeout is unsafe” is a conclusion that needs context.

Make findings explainable

For every issue, keep the evidence close to the finding. A useful record contains the affected resource, observed configuration, why it matters, severity, and a remediation direction. That makes the review debuggable: another engineer can inspect the same evidence and challenge the conclusion.

Automation can collect evidence and deterministic rules can flag known conditions, but business intent often lives outside AWS.

Common mistakes and trade-offs

The biggest mistake is changing resources while you are still discovering them. An odd-looking queue, security rule, or scheduled job may support a dependency you have not found yet.

Another mistake is treating configuration as proof of usage. A resource graph can show that a Lambda can reach a database; it does not prove which queries execute in production or whether the path is business-critical. Logs, metrics, code, infrastructure definitions, and conversations with the team fill different gaps.

Finally, read-only discovery reduces the need for write permissions, but it still needs deliberate scope. Too little visibility produces an incomplete model; unnecessarily broad visibility exposes information the assessment does not need. Define supported services and required read permissions explicitly.

Build the map before proposing the destination

When inheriting an AWS environment, resist the urge to start with best practices. First establish what exists, trace the important paths, validate controls and runtime behavior, and separate facts from assumptions. Then your recommendations have an architectural reason behind them.

If you want to automate part of that first assessment, ArchNube.com addresses this exact problem. Archnube Assess connects through a narrow, customer-controlled read-only IAM role, discovers the AWS resources it supports, and applies deterministic rules to produce explainable findings about risks, weaknesses, inefficiencies, and questionable configurations. It does not require write access to the AWS account. The useful next step is the same either way: establish a trustworthy baseline before deciding what to change.