scrivas/docs/full_discovery_plan.md

Scrivas — Full AWS Discovery Plan

Owner: Dasnuve · Prepared: 2026-08-19 · Status: proposed Access: dasnuve-scrivas-louis-impersonation → iam/louis (mgmt acct 716468089330, groups Admin/devops), cross-account OrganizationAccountAccessRole into members.

Context

We have completed a preliminary Organizations assessment (see findings/discovery_report.md). It confirmed a two-account org (o-qfj0pvhhv7: Scrivas Admin + Lazka), workloads running in the management account (EKS/EC2/RDS), an active compliance stack (Intruder, Secureframe, Macie, Config), and one headline gap — no delegated administrators. This document defines the full discovery needed to size and shape the proposal: the complete cloud footprint, its cost, its security posture, and its operational maturity across every account and region.

Goal: a defensible, evidence-backed picture of Scrivas's AWS estate that lets us (a) scope remediation/landing-zone work and (b) quantify value (cost, risk, effort).

Principles: read-only only; scripted + reproducible (everything lands in scripts/ + findings/); per-account and per-region coverage; no changes to client resources; secrets/PII never exfiltrated, only referenced.

---

Phase 0 — Access, scoping & guardrails (½ day)

• Confirm the role/permissions boundary of iam/louis; document what we can and cannot read (iam get-account-authorization-details, simulate key actions).
• Enumerate every account (organizations list-accounts) and confirm an assumable path into each (OrganizationAccountAccessRole / Control Tower exec role). Record any account we cannot reach — that gap is itself a finding.
• Enumerate enabled regions per account (account list-regions / ec2 describe-regions) to bound the scan surface.
• Deliverable: findings/access_matrix.json (account × reachable × role × regions).

Phase 1 — Organization & governance (mostly done)

• Org structure, OUs, SCP inventory and policy contents (organizations list-policies, describe-policy, list-targets-for-policy).
• Delegated admins, trusted access, org resource policy, IAM role trust — ✅ done (scripts/org_assessment.py).
• Account-level metadata: alternate contacts, root MFA/usage, account status (account get-alternate-contact).
• Deliverable: extend org_assessment_report.json with SCP bodies + OU tree.

Phase 2 — Identity & access management (1 day) — per account

• Users, groups, roles, policies (managed + inline); password policy; access-key age & last-used.
• MFA coverage (console users without MFA), root account usage, unused credentials.
• IAM Access Analyzer external-access findings; SSO / Identity Center config if present.
• Deliverable: findings/iam_<account>.json + a consolidated IAM posture summary.

Phase 3 — Resource footprint inventory (2 days) — per account × region

Primary engine: Resource Explorer / Config aggregator / tag:GetResources for a fast cross-service index, then targeted service calls for depth:

Domain	What we enumerate
Compute	EC2 (instances, AMIs, EBS), Lambda, ECS, EKS (clusters, node groups, versions), Batch, Auto Scaling
Storage	S3 (buckets, public-access config, encryption, size via CloudWatch), EBS, EFS, FSx, Backup
Database	RDS/Aurora, DynamoDB, ElastiCache, Redshift, OpenSearch
Networking	VPCs, subnets, route tables, IGW/NAT, TGW, peering, VPN/DX, ELB/ALB/NLB, Route 53, CloudFront, WAF
Serverless/Integration	API Gateway, SQS, SNS, EventBridge, Step Functions
Containers/Registry	ECR repos & image scan status
Edge/DNS	Route 53 zones, ACM certs (expiry), CloudFront distributions

• Deliverable: findings/inventory_<account>.json + a rolled-up resource census (counts by service/region) feeding the dashboard.

Phase 4 — Security posture (1–2 days)

• Detective controls: GuardDuty findings, Security Hub standards + failed controls, Inspector findings, Macie sensitive-data results, Access Analyzer.
• Preventive/config: AWS Config rule compliance, Config recorder coverage per account/region.
• Exposure: public S3, public EBS snapshots/AMIs, security groups open to 0.0.0.0/0, public RDS/ELB, public IPs.
• Logging & audit: CloudTrail org-trail status & coverage, log-file validation, VPC Flow Logs coverage, CloudWatch log retention.
• Data protection: KMS key inventory & rotation, encryption-at-rest coverage, Secrets Manager/SSM Parameter usage.
• Deliverable: findings/security_posture.json + prioritized risk register (severity × exploitability × blast radius).

Phase 5 — Cost & optimization (1 day)

• Cost Explorer: 12-month trend, spend by account/service/region, month-over-month; anomalies.
• Commitment coverage: Savings Plans / Reserved Instances utilization & coverage.
• Waste signals: idle/unattached EBS, unassociated EIPs, idle NAT gateways, oversized instances, old snapshots, Graviton/spot opportunities, gp2→gp3.
• Budgets & Cost Anomaly Detection presence.
• Deliverable: findings/cost_baseline.json + a quantified savings estimate for the proposal.

Phase 6 — Operational & resilience maturity (1 day)

• Backup coverage (AWS Backup plans, RDS/EBS snapshot policies), cross-region/DR posture.
• IaC footprint: CloudFormation stacks, Terraform state hints (S3 backends), drift signals.
• Tagging hygiene & coverage (via tag editor / Config) — needed for cost allocation & governance.
• Service quotas nearing limits; Trusted Advisor checks (needs Business/Enterprise support).
• Patch/SSM managed-instance coverage; EKS/RDS end-of-life versions.
• Deliverable: findings/ops_maturity.json.

Phase 7 — Synthesis & deliverables (1–2 days)

• Consolidate all findings/*.json into a discovery data model.
• Update findings/assessment_dashboard.html into a full multi-section dashboard (footprint census, cost trend, risk register, maturity scorecard).
• Written Discovery Report + Proposal input pack: prioritized roadmap (landing zone / delegated-admin security account / cost optimization / OU + SCP guardrails), effort estimates, and quantified value.

---

Tooling approach

• Primary: scripted boto3 (extend the existing scripts/ pattern — session per account via assume-role, paginated read-only calls, JSON to findings/).
• Accelerators (read-only, optional): Steampipe/aws mods, Prowler (security), or the AWS "Account Assessment for AWS Organizations" solution for cross-account resource-policy scanning. Note any that require deploying resources — prefer client sign-off first.
• Everything reproducible from the repo; no console-only steps in the critical path.

Timeline & effort

Phase	Effort
0 Access & scoping	0.5 d
1 Governance	done + 0.5 d
2 IAM	1 d
3 Resource inventory	2 d
4 Security posture	1.5 d
5 Cost	1 d
6 Ops/resilience	1 d
7 Synthesis & deliverables	1.5 d
Total	~9 working days

Assumptions & risks

• iam/louis retains Admin-level read access and OrganizationAccountAccessRole remains assumable into members.
• Some data needs paid tiers (Trusted Advisor full checks = Business/Enterprise support; Compute Optimizer must be opted in).
• New accounts/regions added mid-engagement expand scope.
• Strictly read-only; any assessment tooling that provisions resources requires explicit client approval.

Out of scope (unless requested)

Application-level code review, penetration testing, non-AWS cloud, and any write/remediation actions.