The Slack message that changes everything

It usually starts the same way. A deploy fails on a Friday afternoon. Someone asks who set up the production VPC, and the answer comes back: the engineer who built it left eight months ago. Nobody documented the architecture. The CI/CD pipeline runs on a machine under someone's old desk — or worse, on an EC2 instance nobody can identify. The IAM policies are a tangle of inline permissions granted during late-night firefights that were never cleaned up.

If you are a CTO, engineering lead, or founder staring at an inherited AWS environment you did not design and do not fully understand, you are not alone. This is one of the most common — and most quietly dangerous — situations growing companies face. The infrastructure works until it does not, and nobody on the current team has the context to explain why it was built this way or how to fix it safely.

This is the soil work that determines whether your next phase of growth has solid ground or a sinkhole underneath it. Here is a grounded, week-by-week plan to take back control in 30 days.

Week 1: See what you actually have

Before you change anything, you need a truthful inventory. The goal this week is not to fix — it is to map.

Run a full resource audit

Start with AWS Config or a tool like Steampipe to enumerate every resource across every region in every account. Most inherited environments have resources running in regions nobody expected, often left behind from a proof-of-concept that became quietly permanent. Check all regions, not just the ones your team uses intentionally.

Catalog at minimum: EC2 instances (including stopped ones still attached to EBS volumes), RDS databases, S3 buckets, Lambda functions, load balancers, VPCs and their peering connections, IAM users, roles, and policies. Tag everything you identify with an owner if known, or mark it unknown-owner. That tag becomes your working list.

Map the network topology

Draw the VPC architecture. How many VPCs exist? Are they peered? Is there a transit gateway, or are connections stitched together ad hoc? Where does traffic ingress and egress? This is where undocumented cloud infrastructure creates the most risk — security groups and NACLs that were opened temporarily and never closed, public subnets hosting resources that should be private.

You do not need a polished diagram yet. A whiteboard sketch that accurately reflects reality is more valuable than a beautiful but outdated Lucidchart from two years ago.

Identify the billing gravity

Pull your AWS Cost Explorer data for the last 90 days. Sort by service, then by resource. You will almost certainly find spend you cannot explain — a NAT gateway in a region with no active workloads, an oversized RDS Multi-AZ instance backing a staging database nobody uses, data transfer charges between poorly placed services. Do not optimize yet. Just flag the top five line items you cannot account for.

Week 2: Understand the deployment path

Knowing what exists is necessary but not sufficient. You need to understand how things get deployed — or do not.

Trace the CI/CD pipeline (if one exists)

Follow a code change from commit to production. Where does the build run? What tests execute? How does the artifact reach the target environment? In many inherited setups, the answer is uncomfortable: someone SSHs into a server and runs a script, or a Jenkins instance that has not been updated in two years handles deploys with credentials baked into environment variables.

Document what you find without judgment. The engineer who built this was probably solving real problems under real constraints. Your job is to see clearly, not to assign blame.

Check for Infrastructure as Code — or its absence

Search for Terraform state files, CloudFormation stacks, or CDK projects. If they exist, compare the declared state against what is actually running. Drift is nearly universal in undocumented environments. Resources get created through the console during an outage and never backported into code. The infrastructure-as-code repository says one thing; AWS says another.

If no IaC exists at all, that is actually a cleaner starting point than partially drifted code. You know you are building from scratch rather than trusting a false source of truth.

Catalog secrets and credentials

Where are database passwords stored? How do services authenticate to each other? Check for hardcoded credentials in application code, environment variables on EC2 instances, and secrets in SSM Parameter Store or Secrets Manager. This is often the most alarming part of an infrastructure audit checklist — credentials that have never been rotated, shared across environments, or stored in plaintext in a Git repository's history.

Week 3: Stabilize and secure

Now you know what exists and how it is connected. This week is about reducing risk without breaking what works.

Lock down IAM

Audit every IAM user, role, and policy. Look for users with console access who no longer work at the company. Look for roles with AdministratorAccess attached that were created for a one-time migration and never scoped down. Implement least-privilege policies for the resources you now understand. This is not optional — it is the single highest-impact security action you can take in an inherited AWS environment.

Enable MFA for every human user. If root account credentials exist without MFA, fix that before you do anything else on this list.

Establish observability

You cannot manage what you cannot see. Set up a baseline observability stack: CloudWatch alarms on CPU, memory, disk, and error rates for production workloads. If budget and complexity allow, integrate a tracing tool to understand request flows across services. The goal is not a perfect monitoring dashboard — it is ensuring that when something breaks at 2 AM, you know which component failed and have enough context to respond.

This is where many teams realize the inherited environment has been silently failing for weeks. Log groups full of errors nobody was watching. Health checks that were never configured. Alerts that fire into a Slack channel nobody reads.

Rotate every credential you found

Every secret you cataloged in Week 2 gets rotated this week. Database passwords, API keys, service account tokens — all of them. Move anything hardcoded into Secrets Manager or your vault of choice. Yes, this is tedious. Yes, some things will break when you rotate them, which is exactly why you do it now while you are paying close attention, rather than after a breach forces your hand.

Week 4: Build the foundation forward

The first three weeks were about understanding and stabilizing. This final week is about making sure you never end up here again.

Begin codifying infrastructure

Pick the most critical production workload and declare it in Terraform, Pulumi, or your IaC tool of choice. Import existing resources rather than recreating them — you want to bring reality under code control, not rebuild from scratch under pressure. This first workload becomes your template: module structure, state management, CI integration. Every subsequent workload follows the same pattern.

This is the foundational work that separates environments that scale from environments that collapse. Declarative, version-controlled, reproducible infrastructure means the next engineer who inherits this environment finds a codebase, not a mystery.

Design the deployment pipeline you actually need

Based on what you learned in Week 2, architect a CI/CD pipeline that fits your team's real workflow. Automated testing in a staging environment that mirrors production. Zero-downtime deploys using blue-green or rolling strategies. Rollback procedures that are documented and tested, not theoretical.

The pipeline does not need to be perfect on day 30. It needs to exist, be understood by the team, and be the only way code reaches production. No more SSH-and-pray deployments.

Write the documentation that did not exist

Document three things at minimum: an architecture overview (what runs where, how services connect), a runbook for common operational tasks (deploying, rolling back, scaling, responding to alerts), and a decision log explaining why the architecture is shaped the way it is now. That decision log is the piece most teams skip, and it is the piece that saves the most time for the next person.

The trade-off nobody talks about

Here is the honest part. Thirty days is enough to go from blind to grounded — from reacting to incidents you do not understand to operating an environment you can reason about. It is not enough to fully modernize a complex inherited AWS environment. Multi-account architecture, container orchestration, cost optimization at scale — those are longer arcs that build on this foundation.

The real trade-off is between doing this work with your existing team and bringing in experienced help. Your engineers are shipping features. Pulling them into a month of infrastructure archaeology means those features do not ship. A fractional DevOps engagement — bringing in principal-level infrastructure judgment without a full-time senior hire — lets you run this audit and remediation in parallel with product work.

That is not a pitch disguised as a blog post. It is a genuine structural decision every scaling startup faces: build the internal competency over six months, or bring in someone who has done this across dozens of environments and compress the timeline. Both paths are valid. The wrong choice is doing neither and hoping the inherited infrastructure holds.

Your infrastructure should grow with you, not against you

An undocumented cloud environment is not a failure — it is a natural consequence of building fast with a small team. The engineer who set it up was probably doing their best with the information and constraints they had. But the environment they left behind was designed for the company you were, not the company you are becoming.

The soil work matters. Roots that go deep enough support growth that reaches further. If you are staring at an inherited AWS environment and feeling the weight of everything you do not know about it, that awareness is the starting point — not the problem.

At Figtree Development, we start every infrastructure engagement with a Discovery and Strategy process — a clear-eyed assessment of where you are, what is at risk, and what to build next. No assumptions, no generic playbooks. Just experienced judgment applied to your specific environment.

Book a free 20-minute discovery call and walk us through what you are dealing with. We will help you see what you have, understand what it needs, and build the kind of foundation that does not crack under pressure.