# HCA Log Archival — IaC Deployment Plan

## Phase 1 — Foundation

Bucket naming standard has been set to follow the pattern `hca-archival-usw2-<source>`. This follows kebab-case source token, no account ID as all buckets are in the same Log Archival account.

- Current trail inventory (per source doc §2.9) shows no digest validation column populated for any trail. Confirm this is actually off today before treating it as a change.
- Create 6 new S3 buckets, namely:
  - `hca-archival-usw2-vpc-flow`
  - `hca-archival-usw2-tgw-flow`
  - `hca-archival-usw2-guardduty`
  - `hca-archival-usw2-waf`
  - `hca-archival-usw2-route53`
  - `hca-archival-usw2-elb`
- Enable these on each bucket: delete-deny bucket policy, Object Lock (compliance mode), SSE-KMS, versioning, lifecycle rule (S3 Standard to Glacier Flexible Retrieval at 90 days, expire at 366 days).
- No need to rename existing buckets for CloudTrail/Config as both are already centralized in `aws-controltower-logs-095509168441-us-west-2` (Control Tower managed).
- Enable log file integrity validation (digest files) on CloudTrail trails not currently covered by Control Tower defaults.

## Phase 2 — VPC Flow, TGW, Route 53 second-feed delivery

- Add a second VPC Flow Log delivery, targeting `hca-archival-usw2-vpc-flow`, on all VPCs currently logging to CloudWatch. Existing CloudWatch flow log groups are left untouched.
- Add a second Transit Gateway Flow Log delivery, targeting `hca-archival-usw2-tgw-flow`. Existing `HCA-TGW-LogGroup` is left untouched.
- Stand up a new Route 53 Resolver query logging config, targeting `hca-archival-usw2-route53`.
  - Note: current Route 53 configs (`dns-poc-logs`, `LogGroup_NewDev`) are POC/Dev-labeled in the source doc. Decide whether this new config replaces or productionizes those two, or stands up alongside them.
- No changes to existing CloudWatch feeds or any alerting built on them in this phase.

## Phase 3 — GuardDuty findings export + WAF S3 delivery

- Enable GuardDuty publishing destination on each account (HCA-Non-Prod-Dev, HCA-Non-Prod-QA, HCA-Prod, HCA-Non-Prod), targeting `hca-archival-usw2-guardduty`, with a KMS key policy allowing GuardDuty write access.
  - Note: this covers S3-side retention only. The live CloudWatch log group (`/aws/guardduty/malware-scan-events`) stays at 3-month retention, with no change to that in this phase per current direction.
- Stand up a CloudWatch subscription filter to Lambda to S3 delivery path for WAF logs, targeting `hca-archival-usw2-waf`. Existing CloudWatch feed (`aws-waf-logs-step-cognito-userpool`) stays live and untouched.

## Phase 4 — ALB access log repoint

- Repoint access logs on `prod-mobileapp-alb` and `HCA-PROD-Step-Tool-ALB` from their current local S3 destinations to `hca-archival-usw2-elb`.
- Current buckets `prod-mobileapp-alb-logs` and `step-alb-access-logs` are left as-is. New logs land in `hca-archival-usw2-elb`, and old buckets are not touched or cleaned up by this plan.
- Sequence as its own change window, since this touches production load balancers directly.

## Phase 5 — NLB access logging (new capability)

- Enable TLS listener access logging, targeting `hca-archival-usw2-elb`, on the 5 currently-unlogged production NLBs: `NLB-SASVIYA-TO-PROD-SMTP`, `NLB-Redshift-serverless-PROD`, `NLB-SASVIYA-TO-PROD-DB`, `mobile-api-nlb`, `HCA-PROD-Step-Tool-NLB`.
  - Note: this is net-new capability enablement, not a repoint. Confirm listener types on each NLB actually support access logging before rollout, since there is no existing config to fall back on if something is unsupported.
- Prove out the config on one NLB before rolling to all 5, given no existing logging baseline to compare against on failure.

## Phase 6 — Guardrails

- Enforce, per log source, that deployments are blocked when the corresponding logging/export config is absent, disabled, or points to a non-approved destination.
- Sources covered: AWS Config, CloudTrail, VPC Flow Logs, TGW Flow Logs, ELB/ALB access logging, Route 53 Resolver query logging, AWS WAF, GuardDuty. Each source's approved destination is the corresponding `hca-archival-usw2-<source>` bucket, or the existing Control Tower bucket for Config/CloudTrail.
- Sequence last, since this depends on bucket names being live and the delivery paths from Phases 1 through 5 being proven in production.
