Investor Due Diligence for a Series A AWS Startup: What Gets Flagged

Three changes have made infrastructure review a standard part of Series A DD over the past three to four years.

Cloud breaches are now common enough to be a known risk category. Infrastructure misconfiguration appears in a growing share of disclosed security incidents, and investors are aware of this. An environment with unresolved High-severity findings is a contingent liability. Investors who are buying equity are also implicitly buying that liability — and sophisticated ones price it in.

Compliance requirements have moved earlier in the company lifecycle. SOC 2 Type II, ISO 27001, and HIPAA BAAs are now common requirements at Series A customers rather than Series B. If your infrastructure does not meet the preconditions for these certifications — encryption at rest, audit logging, access controls — your ability to close enterprise deals is constrained. That is a revenue risk, and revenue risk shows up in DD.

Terraform and IaC have made infrastructure reviewable at scale. If your environment is defined in Terraform, a technical DD firm can run a structured assessment in hours rather than days. This has lowered the cost of infrastructure DD to the point where it is now standard — not exceptional — for deals above $5M.

A typical infrastructure DD review covers five areas. The first two — IAM and encryption — carry the most weight because they represent current risk. The remaining three — cost, observability, and IaC maturity — represent operational risk that affects scalability and investor confidence in the team.

IAM is the first area reviewed and the most consequential. The reason is straightforward: IAM misconfiguration determines the blast radius of any other security failure. An attacker who gains access to an overly-permissive role does not just compromise one service — they compromise everything that role can access.

DD reviewers look for four IAM signals:

• 1.Static access keys on IAM users — every key is a long-lived credential that can be phished, leaked via source control, or extracted from a compromised CI/CD system. Each key is a named finding.
• 2.Wildcard permissions — any role policy with Action: "*" or Resource: "*". These exist in many startup environments as a "we'll lock it down later" shortcut that never gets addressed. They are the single most common blocker in infrastructure DD.
• 3.IMDSv1 on EC2 instances — the absence of http_tokens = "required" in Terraform metadata_options. This is the pattern behind the most well-documented AWS infrastructure breach of the last decade and is trivial to find in Terraform.
• 4.No MFA enforcement — IAM users with console access and no MFA requirement. For a company that stores customer data, this is a direct compliance gap.

Encryption findings carry weight proportional to what the affected storage contains. An unencrypted S3 bucket that holds static marketing assets is a lower-severity finding than an unencrypted RDS instance that holds customer PII. DD reviewers assess both the configuration and the data classification — and if you cannot answer “what data is in this bucket” during DD, that is itself a finding.

The minimum acceptable encryption posture for a Series A startup handling customer data: S3 buckets with server-side encryption enabled (SSE-KMS for any bucket containing PII or regulated data), public access blocks at the bucket level, RDS with StorageEncrypted = true, EBS volumes encrypted, and no secrets stored in Terraform variables. The S3 encryption guide covers the distinction between SSE-S3, SSE-KMS, and what the Well-Architected Security pillar requires for each data classification tier.

Cost structure matters to investors for two reasons. First, it is a proxy for operational discipline — an environment with tagged resources and a predictable cost trend signals that the team understands what they are running and why. Second, it is a forward-looking risk: a cost structure that cannot be attributed to services and environments will not scale cleanly and will create surprises at the post-close financial review.

The specific signals DD reviewers look at:

• 1.Tagging coverage — what percentage of EC2, RDS, and S3 resources have Name and Environment tags. Resources without Environment tags cannot be attributed to prod vs. staging cost, which makes the cost model opaque.
• 2.Cost trend — the 90-day AWS Cost Explorer trend. Is it flat, growing proportionally with revenue/usage, or growing faster than either? Faster-than-usage growth without explanation is flagged.
• 3.NAT Gateway spend — this appears unexpectedly large in many startup environments because most S3 and DynamoDB traffic routes through a NAT Gateway instead of VPC endpoints. It is a cost efficiency finding, not a security finding, but it signals infrastructure that was not designed for cost awareness.
• 4.Reserved Instance or Savings Plan coverage — for a company at Series A run rate, 0% RI coverage on baseline EC2 and RDS is a missed optimisation that implies the infrastructure has not been reviewed from a cost perspective.

Investors ask one implicit question about observability: if something goes wrong at 2am on a Sunday, will the team know within 15 minutes? The infrastructure signals that answer that question:

• 1.GuardDuty enabled in every account and region with workloads — this is the baseline runtime threat detection signal. An environment without GuardDuty has no automated detection for credential abuse, unusual API patterns, or instance compromise.
• 2.CloudTrail enabled as a multi-region trail — every API call recorded, logs stored in a centralised bucket, not the same account as the workloads.
• 3.CloudWatch alarms on critical services — error rate, latency P95, CPU. Alarms that go to an SNS topic connected to PagerDuty or Opsgenie, not to a Slack channel that no one monitors at night.
• 4.Log retention policy — CloudWatch log groups should have a retention period set. Indefinite retention is both a cost problem and a signal that the team has not thought about what logs are for.

Infrastructure defined in Terraform is reviewable, auditable, and reproducible. Infrastructure created manually through the AWS console is none of those things — and DD reviewers will note the proportion of your environment that falls outside Terraform state. Console-created resources are an operational risk (no version control, no review process, no reproducibility in a disaster recovery scenario) and a governance risk (no record of who created what and when).

The IaC maturity signals DD reviewers assess:

• 1.Coverage — what percentage of production resources are in Terraform state. Everything outside state is invisible to any automated review tool.
• 2.Module structure — monolithic modules with mixed environments (prod, staging, dev in one state file) are a blast-radius risk and a signal of infrastructure that grew without architectural review.
• 3.CI integration — whether Checkov, tfsec, or Trivy is integrated into the CI pipeline and blocking deployments on High findings. Advisory-only integration (fails don't block) is a weaker signal.
• 4.State storage — whether state is in S3 with DynamoDB locking or stored locally. Local state means the last developer to run terraform apply owns the truth about production infrastructure.

The single most common finding in Series A infrastructure DD is an IAM role policy with wildcard permissions. It appears in Terraform as Action: "*", it passes many linter checks, and it represents a maximum blast-radius condition that is usually a shortcut from early-stage development that was never revisited.

The fix is straightforward — but the remediation requires understanding what each role actually needs access to, which is often undocumented. That work takes time. Running this review 60 to 90 days before DD gives you the time to do it properly.

Not all infrastructure findings are equal in DD. Some are noted and remediated post-close. Others affect deal terms directly.

The most effective pre-DD approach is a structured Well-Architected review against the four pillars most relevant to a technical DD assessment: Security, Reliability, Cost Optimization, and Operational Excellence. Conducted 60 to 90 days before you expect to enter DD, it gives you:

• 1.A complete findings list you own before the investor does — no surprises.
• 2.Time to remediate the highest-severity findings before DD begins.
• 3.A before/after narrative: "We identified N findings in our Q1 review. X are remediated; Y are scheduled in Q3." This is materially more credible than a clean scan run the week before DD.
• 4.Documentation that satisfies the DD requirement without requiring an investor-side technical review team to generate the findings themselves — which compresses the DD timeline.

The Terraform Architecture Review guide covers the full six-step process for conducting a review yourself — including how to evaluate each WAF pillar and produce a stakeholder-ready report. If you need a structured external assessment to put in your data room, ArchGuard produces a PDF report that maps findings to WAF pillars with severity ratings and HCL remediation examples — the format that DD reviewers expect to see.