aws-networking-audit

What this skill does

# AWS VPC Networking Security Audit

Cloud resource audit for AWS Virtual Private Cloud (VPC) architecture,
security posture, and connectivity. This skill evaluates provider-specific
AWS networking constructs — VPC design, Security Groups, NACLs, Transit
Gateway topologies, VPC Flow Logs, Route Tables, and ENI placement — not
generic cloud networking advice.

Scope covers VPC-layer networking: CIDR planning, subnet tier layout,
security filtering, inter-VPC connectivity, and traffic observability.
Out of scope: CloudFront distributions, WAF rules, application-layer
load balancing (ALB content routing), and DNS (Route 53) configuration.
Reference `references/cli-reference.md` for read-only AWS CLI commands
organized by audit step, and `references/vpc-architecture.md` for the
VPC packet flow model, Security Group vs NACL evaluation order, and
Transit Gateway routing architecture.

## When to Use

- VPC architecture design review — validating CIDR allocation, subnet tier layout, and AZ distribution before or after deployment
- Post-migration networking audit — verifying VPC connectivity, Security Group rules, and Route Table entries after workload migration
- Security assessment — identifying overly permissive Security Group rules, default NACL exposure, and missing VPC Flow Log coverage
- Connectivity troubleshooting — diagnosing Transit Gateway route propagation failures, VPC peering asymmetric routing, or black-hole routes
- Compliance preparation — documenting VPC segmentation, Security Group justification, and Flow Log retention for auditors
- Cost optimization review — identifying unused Elastic Network Interfaces (ENIs), unattached Elastic IPs (EIPs), and cross-AZ traffic patterns

## Prerequisites

- **AWS CLI v2** configured with valid credentials (`aws sts get-caller-identity` succeeds)
- **IAM permissions** — minimum read-only policy covering: `ec2:DescribeVpcs`, `ec2:DescribeSubnets`, `ec2:DescribeSecurityGroups`, `ec2:DescribeNetworkAcls`, `ec2:DescribeTransitGateways`, `ec2:DescribeTransitGatewayRouteTables`, `ec2:DescribeRouteTables`, `ec2:DescribeFlowLogs`, `ec2:DescribeNetworkInterfaces`, `ec2:DescribeVpcPeeringConnections`, `ec2:DescribeVpcEndpoints`, `ec2:DescribeAddresses`, `logs:FilterLogEvents`, `logs:DescribeLogGroups`
- **Target scope identified** — specific VPC ID(s), AWS account, and region. Multi-account audits require cross-account IAM roles or AWS Organizations access
- **VPC Flow Logs enabled** — Step 4 requires active Flow Logs publishing to CloudWatch Logs or S3. If Flow Logs are not enabled, document this as a Critical finding

## Procedure

Follow these six steps sequentially. Each step builds on prior findings,
moving from inventory through security analysis to optimization.

### Step 1: VPC Inventory and Design Assessment

Enumerate all VPCs in the target region and assess architectural design.

```
aws ec2 describe-vpcs --region <region> --output table
aws ec2 describe-subnets --filters "Name=vpc-id,Values=<vpc-id>" --output table
```

For each VPC, evaluate:

- **CIDR block allocation:** Primary and secondary CIDR blocks. Check for RFC 1918 compliance, overlapping CIDRs across VPCs (blocks peering), and sufficient address space for growth. VPCs support up to 5 CIDR blocks.
- **Subnet tier layout:** Identify public subnets (Route Table routes to Internet Gateway), private subnets (Route Table routes to NAT Gateway), and isolated subnets (no internet route). Verify each tier exists and workloads are placed in the correct tier.
- **Availability Zone distribution:** Subnets should span at least 2 AZs for resilience. Single-AZ VPC designs are a High finding.
- **DNS settings:** Verify `enableDnsSupport` and `enableDnsHostnames` are enabled — required for VPC endpoints and private DNS resolution.
- **Tenancy:** Default vs dedicated. Dedicated tenancy has significant cost implications; verify it is intentional.

### Step 2: Security Group and NACL Analysis

Audit stateful Security Group rules and stateless NACL rules for overly permissive access.

**Security Group analysis:**

```
aws ec2 describe-security-groups --filters "Name=vpc-id,Values=<vpc-id>"
```

For each Security Group, evaluate inbound and outbound rules:

- **0.0.0.0/0 inbound rules:** Any Security Group rule permitting inbound from `0.0.0.0/0` (or `::/0`) is a finding. Severity depends on port: SSH/RDP from 0.0.0.0/0 is Critical; HTTPS from 0.0.0.0/0 on a public ALB may be acceptable.
- **SG-to-ENI mapping on public subnets:** Cross-reference Security Groups with ENIs on public subnets. An overly permissive Security Group attached to an ENI in a public subnet with a public IP is higher risk than the same Security Group on a private subnet.
- **Default Security Group:** The VPC default Security Group allows all inbound from itself and all outbound. If any ENI uses the default Security Group, flag as Medium — workloads should use purpose-specific Security Groups.
- **Unused Security Groups:** Security Groups with no associated ENIs are cleanup candidates.

**NACL analysis:**

```
aws ec2 describe-network-acls --filters "Name=vpc-id,Values=<vpc-id>"
```

NACLs are stateless — evaluate both inbound and outbound rule sets:

- **Rule ordering:** NACLs evaluate rules by rule number (lowest first). A broad permit at rule 100 cannot be overridden by a deny at rule 200. Verify deny rules are numbered lower than corresponding permits.
- **Default NACL:** Allows all inbound and outbound traffic. Subnets using the default NACL have no network-layer filtering beyond Security Groups. Flag as Medium if used on production subnets.
- **Ephemeral port range:** Outbound NACLs must permit ephemeral ports (1024–65535) for return traffic. Missing ephemeral port rules break TCP connections.

### Step 3: Transit Gateway and Connectivity Assessment

Evaluate inter-VPC and hybrid connectivity through Transit Gateway (TGW), VPC Peering, and VPC Endpoints.

**Transit Gateway:**

```
aws ec2 describe-transit-gateways
aws ec2 describe-transit-gateway-route-tables --transit-gateway-id <tgw-id>
aws ec2 search-transit-gateway-routes --transit-gateway-route-table-id <tgw-rt-id> --filters "Name=state,Values=active"
```

- **TGW route table associations:** Each VPC attachment should be associated with the correct TGW Route Table. Misassociations cause traffic to route to wrong VPCs.
- **Route propagation:** Verify propagation is enabled for VPC attachments that need dynamic routing. Disabled propagation requires manual static routes — check for stale entries.
- **TGW peering:** For multi-region Transit Gateway peering, verify routes are propagated across regions and CIDR blocks don't overlap.

**VPC Peering:**

```
aws ec2 describe-vpc-peering-connections --filters "Name=status-code,Values=active"
```

- **Route validation:** VPC peering is non-transitive. Verify Route Tables in both VPCs contain routes pointing to the peering connection for the peer CIDR. Missing routes cause silent packet drops.
- **DNS resolution:** Check `AllowDnsResolutionFromRemoteVpc` for cross-VPC private DNS.

**VPC Endpoints:**

```
aws ec2 describe-vpc-endpoints --filters "Name=vpc-id,Values=<vpc-id>"
```

- **Gateway endpoints:** S3 and DynamoDB. Verify Route Table entries exist for gateway endpoint prefix lists.
- **Interface endpoints (PrivateLink):** Verify ENI placement in appropriate subnets and Security Group rules permit traffic from workloads.

### Step 4: VPC Flow Log Analysis

Analyze VPC Flow Logs for security events and traffic patterns.

```
aws ec2 describe-flow-logs --filter "Name=resource-id,Values=<vpc-id>"
```

Verify Flow Logs are enabled at the VPC level (not just subnet or ENI level) with REJECT and ACCEPT capture. If Flow Logs are not enabled, document as Critical and recommend enabling before further analysis.

For active Flow Logs, query CloudWatch Logs:

```
aws logs filter-log-events --log-group-name <flow-log-group> --filter-pattern "REJECT"
```

Analyze patterns:

- **Reject patterns:*