The New CTO's AWS Infrastructure Audit: What to Check in Week One

Before the audit phases, get clear on what you are trying to find out. A useful framing is four questions, each with a distinct time horizon and audience:

Three forces make the first 30 days the best window for this kind of audit.

Political capital. You have more permission to ask naive-sounding questions in week one than you will in month six. “Walk me through how this is deployed” is a natural question for a new CTO. The same question six months in signals that you have not been paying attention. Use the window.

Baseline establishment. The value of an audit is not just the findings — it is the reference point it creates. “When I arrived, GuardDuty was not enabled in three accounts and we had 14 IAM users with active static access keys. We are down to two users pending OIDC migration.” That is a narrative your board can follow. Without the baseline, you cannot show progress.

Credibility sequencing. Engineering teams watch new leadership carefully. Arriving with questions before opinions — and publishing a structured assessment before proposing changes — signals that you are making evidence-based decisions. That credibility compounds over the next 90 days when you do start making changes.

The first question is: what does Terraform manage? Everything in state is visible, reviewable, and auditable. Everything not in state was created manually — and is invisible to any Terraform-based audit tooling. The gap between the two is the first meaningful risk signal you will find.

Ask for access to the Terraform repository and remote state location. Then run:

Single-account AWS environments are common at early-stage companies and represent a structural risk: every service, every developer, and every CI pipeline shares the same account boundary. If one IAM credential is compromised, the blast radius is the entire account. AWS Organizations — with separate accounts for production, staging, security tooling, and billing — is the well-architected pattern for multi-environment isolation.

Before you decide what security tooling to add, you need to know what is already running. This avoids duplicating spend and tells you what signals are already available if something goes wrong today.

Phase 1 tells you what exists. Phase 2 tells you whether what exists is configured correctly for the workload it serves. The standard for “correctly” here is the AWS Well-Architected Framework — specifically the four pillars most relevant to an operational audit: Security, Reliability, Cost Optimization, and Operational Excellence.

For Terraform-managed infrastructure, a linter (Checkov, tfsec, or Trivy) gives you a baseline misconfiguration count quickly. Run one against the Terraform repository and note the finding count and the proportion of High findings. This is your linter baseline — useful, but incomplete. Linters check individual resource configurations; they do not evaluate blast radius, cross-service dependencies, or whether the architecture is appropriate for a production workload. For that, you need an architectural review against the WAF pillars — covered in detail in the Terraform Architecture Review guide.

IAM is the highest-priority area in the Security pillar because it determines the blast radius of every other security failure. The three highest-signal IAM signals in an inherited environment:

• 1.IAM users with static access keys — count them. Each is a long-lived credential that does not expire. The question is not whether they exist; the question is whether each one has a justification and a rotation policy.
• 2.Roles with wildcard actions or Resource: "*" — search for Action: "*" and Resource: "*" in aws_iam_role_policy and aws_iam_user_policy resources. These represent maximum-blast-radius permissions that linters may not fully catch.
• 3.EC2 instances without IMDSv2 enforcement — any EC2 instance without http_tokens = "required" in its metadata_options block is a SSRF risk. This is a well-known pattern; see the IAM breach pattern analysis for the incident context.

For S3: check that every bucket has server-side encryption configured and public access blocked at the bucket level. The Checkov rule CKV_AWS_19 covers encryption, but the Well-Architected Security pillar additionally requires that encryption uses a customer-managed KMS key for any bucket containing sensitive data. For network: security groups with 0.0.0.0/0 ingress on ports 22 or 3389 are an immediate finding regardless of context.

The Reliability pillar asks: what happens when a component fails? The minimum standard for a production environment is that no single component failure should result in complete service unavailability. In Terraform terms, the highest-signal reliability checks are:

• 1.RDS instances: multi_az = true for any database serving production traffic. A single-AZ RDS instance has a maintenance window that causes downtime and no automatic failover if the underlying hardware fails.
• 2.RDS backup_retention_period: should be at least 7 days for production. A value of 0 means automated backups are disabled.
• 3.Auto Scaling Groups: min_size ≥ 2 for production-serving ASGs, across at least two availability zones. A single-instance EC2 serving prod traffic has no failover.
• 4.ALB: subnets list should include at least two AZs. An ALB configured in one AZ fails if that AZ has an AWS-side event.

An inherited AWS environment often has cost visibility problems before it has cost efficiency problems. If resources are not tagged with environment, service, and team, you cannot attribute spend — which means you cannot have a productive conversation about what to cut.

Open the AWS Cost Explorer and look at the 90-day cost trend. Three questions:

• 1.Is the trend flat, growing proportionally with usage, or growing faster than usage? Faster-than-usage growth typically means infrastructure is being added without corresponding review.
• 2.What is the top-five cost by service? EC2, RDS, and data transfer are common large lines — but NAT Gateway often appears unexpectedly high because VPC endpoints are cheaper for most S3 and DynamoDB traffic.
• 3.How much spend is untagged? Open the Tag Editor and look for aws_instance, aws_db_instance, and aws_s3_bucket resources without Name and Environment tags. Untagged spend cannot be attributed and will make future cost discussions impossible.

The Operational Excellence pillar asks: can the team operate this system at midnight when something goes wrong? The signals are:

• 1.CloudWatch log groups: do they exist for every Lambda, ECS task, and application? Are retention periods set — or are logs retained indefinitely (creating growing cost and compliance exposure)?
• 2.Alarms: are there CloudWatch alarms on error rates, latency, CPU, and custom business metrics? Who receives them — a PagerDuty integration, an SNS topic, an email address that a former employee owned?
• 3.Runbooks: ask the on-call engineer "what do you do when the API latency alarm fires?" If the answer is "we ssh in and look around," that is a process finding, not an infrastructure finding.
• 4.Deployment process: how does code go from a merged PR to production? Is it automated (CI/CD), semi-automated (manual approval gate), or manual? Manual deployments to production are a reliability and audit risk.

Phase 2 gives you a list of findings. Phase 3 orders them by priority so your engineering team can act on them without asking “what should we fix first?” every sprint.

Prioritisation in an AWS infrastructure context has two axes: severity (what is the potential impact if this is exploited or fails) and likelihood (how likely is it that this specific finding leads to an incident in the next 90 days). High severity and high likelihood get fixed in the next sprint. Low severity and low likelihood go on the backlog.

A useful heuristic for the severity axis: think in terms of blast radius. An IAM role that, if compromised, gives an attacker access to one Lambda function is less severe than a role that gives access to all S3 buckets in the account. Both might pass a linter check. The architectural review tells you the blast radius; the linter does not.

Your first board report on inherited AWS infrastructure should be readable in five minutes by a non-technical board member. Keep the technical detail in an appendix. The body should contain four sections: