CxO End-to-End Walkthrough¶
For the enterprise board: Follow a CEO/CTO/CFO/CDO/CSO through a single autonomous orchestration loop. Every stage is driven by a REAL runbooks CLI command, backed by proven ADLC agents and governed by enterprise controls. No slides — pure operational evidence.
The Journey: 6 Stages, One Doctrine¶
flowchart LR
A["🛡️ Business Continuity<br/>(CEO/CSO)<br/>Can we recover<br/>every account?"] -->
B["⚙️ Operations<br/>(CTO)<br/>Patch baseline<br/>org-wide?"] -->
C["💰 Finance<br/>(CFO)<br/>Who owns<br/>this spend?"] -->
D["📋 Governance<br/>(CDO)<br/>SCP inheritance<br/>automatic?"] -->
E["🔒 Security<br/>(CSO)<br/>Threat detection<br/>complete?"] -->
F["🌐 Infrastructure<br/>(VP-Infra)<br/>Network drift<br/>detected?"]
style A fill:#e8f5e9
style B fill:#fff3e0
style C fill:#e3f2fd
style D fill:#f3e5f5
style E fill:#ffebee
style F fill:#e0f2f1Why This Matters to You¶
| Role | Your Hook |
|---|---|
| CEO | See the whole cloud estate as one governed system — continuity first, every layer protecting the business — and know the board's hardest questions already have evidence behind them. |
| CTO | Watch a single command apply an operations and patch baseline across every account, so a zero-day is contained by design and the architecture proves itself, not the slideware. |
| CFO | Follow unattributed spend become permanent showback clarity in one pass — every business unit owning the dollars it spends, with optimisation that was previously invisible now in reach. |
| CDO | See guardrails inherited at the organisational boundary, so governance is a continuous design property — policy-and-detect on every change, not audit-and-remediate after the fact. |
| CSO | Confirm threat detection and recoverability cover every account from one delegated view — no silent blind spots — so the next audit is a confirmation, not a discovery. |
The Platform at a Glance¶
╭────────────────────────────────────────────────────────────────────────────────╮
│ runbooks v1.5.0 Enterprise AWS Automation Platform │
│ │
│ Cost ↓ Risk ↓ Time-to-Value ↑ · 88 resource types · 50+ accounts · │
│ SOC2/ISO27001 baselines │
╰────────────────────────────────────────────────────────────────────────────────╯
Available Command Groups
├── 💰 Cost & FinOps
│ └── 💰 finops → validate Turn cloud spend into intelligence —
│ rightsizing, orphan detection, RI/SP
│ optimization
│ 💰 workspaces ← inventory Right-size your WorkSpaces estate —
│ idle desktops, decommission tiers
├── 🔍 Discovery & Inventory
│ └── 🔍 inventory → finops Complete visibility across your
│ Landing Zone — 88 resource types, org
│ governance
│ ✅ cfat → security Score your Cloud Foundations maturity
│ — Well-Architected assessment with
│ remediation
├── 🔒 Security & Compliance
│ └── ✅ security ← cfat Automate SOC2/ISO27001 baseline checks
│ — detect misconfigurations
│ continuously
│ ⚙️ remediation ← security Close security findings in minutes —
│ IAM, S3, CloudTrail, encryption fixes
│ ✅ cert Never miss a certificate expiry —
│ discover and monitor TLS/SSL across
│ all accounts
├── 🌐 Network & Infrastructure
│ └── ⚙️ vpc ← inventory Map and validate your network
│ architecture — TGW routes, NAT costs,
│ flow logs
└── 🔄 Operations & Integration
└── 📌 operate Execute AWS resource operations — EC2
lifecycle, S3 provisioning, IaC
deployment
⚙️ itsm Connect AWS operations to ITSM
workflow — change records, PIRs,
incident tickets
✅ validation ← finops Validate data accuracy before acting —
4-way cross-validation, ≥99.5% gate
Run runbooks GROUP --help for group-specific commands
Stage 1: Business Continuity — Org-Wide Backup Coverage¶
Owner: CEO / CSO
The Question: If a region fails or ransomware hits tonight, can every account be recovered — or are we gambling account-by-account?
The Commands (org-wide discovery, every account):
# Assess current backup posture across the organization
runbooks inventory collect --all-profile $AWS_OPERATIONS_PROFILE [A1-Discovery]
# Check backup vault status by account
runbooks cfat assess --all-profile $AWS_MANAGEMENT_PROFILE [A2-Inventory]
What Happens Autonomously: The discovery agent enumerates backup posture org-wide via the Resource Explorer aggregator, then the assessment agent scores recoverability against the Well-Architected baseline — one pass, every account.
What You Get: One org-wide backup policy turns recoverability from an account-by-account gamble into a design guarantee — every new and migrated account inherits a vault automatically, so the board's first question always has an answer.
Stage 2: Operations — Patch Manager Baseline¶
Owner: CTO
The Question: Could a single unpatched instance let a zero-day spread across the whole organisation before anyone notices?
The Commands (patch compliance, per-instance investigation):
# Check patch compliance across all accounts
runbooks inventory enrich-ec2 --all-profile $AWS_OPERATIONS_PROFILE [A1-Discovery]
# Get SSM agent health per instance
runbooks inventory ssm-status --instance-id <id> --profile $AWS_PROFILE [A1-Investigate]
What Happens Autonomously: The enrichment agent overlays patch and SSM-agent health onto every instance org-wide, then the investigation agent confirms a single host's baseline on demand — containment by default, exceptions by exception.
What You Get: A patch and operations baseline applied at the organisation boundary means a zero-day on any single account cannot spread uncontained — operational risk is managed by default, with exceptions handled by exception.
Enrichment Output (real command panel):
Runbooks Inventory - Multi-account AWS resource discovery
📋 Command Categories (40 operations across 9 categories):
1️⃣ Discovery: resource-explorer (88 AWS resource types)
2️⃣ Organizations: org-*, accounts-* (multi-account management)
3️⃣ VPC/Network: vpc-*, nat-*, elb-* (network architecture)
4️⃣ CloudFormation: cfn-*, stack-* (IaC drift detection)
5️⃣ Activity/Scoring: enrich-*, score-* (decommission analysis)
6️⃣ Security/Compliance: security-*, audit-*, check-*
7️⃣ Workflows: workflow-*, pipeline-* (automated pipelines)
8️⃣ Validation: validate-*, verify-* (MCP cross-validation)
9️⃣ Utilities: export-*, clean-*, show-* (helper commands)
Inventory Commands (59 commands)
├── 🔍 Multi-Account Discovery (6 commands)
│ └── Command Description
│ collect Multi-account resource discovery
│ via Resource Explorer
│ resource-explorer Discover resources by friendly
│ alias (88 types)
│ resource-types List all 88 supported resource
│ types
│ discover-rds RDS database discovery
│ discover-lambda Lambda function discovery
│ collect-containers Container discovery (ECS
│ clusters, tasks, services)
├── 🏢 Organizations (14 commands)
│ └── Command Description
│ list-org-accounts List AWS accounts in organization
│ list-org-users List IAM users across
│ organization
│ draw-org Visualize organization hierarchy
│ check-landingzone Validate Landing Zone
│ configuration
[... more commands ...]
Stage 3: Finance — Tag-Enforcement for Cost Attribution¶
Owner: CFO
The Question: Which business unit owns this month's cloud spend — and how much of it can no one account for?
The Commands (tag coverage, finops dashboard, tag compliance):
# Check tag coverage across the organization
runbooks inventory tag-coverage --all-profile $AWS_OPERATIONS_PROFILE [A1-Discovery]
# Show cost breakdown by service (with tag context)
runbooks finops dashboard --all-profile $AWS_BILLING_PROFILE [A3-FinOps]
# Validate cost-allocation tags for completeness
runbooks finops check-config-compliance --all-profile $AWS_MANAGEMENT_PROFILE [A2-Inventory]
What Happens Autonomously: The tag-coverage agent measures cost-allocation completeness org-wide, the FinOps agent renders cross-account spend through Cost Explorer with cross-validation, and the compliance agent confirms tag enforcement — attribution becomes continuous, not a quarterly hunt.
What You Get: Cost-allocation tag enforcement converts unattributed spend into permanent showback clarity — every business unit sees the dollars it owns, unlocking the optimisation that was previously invisible.
FinOps Dashboard (real command panel):
FinOps Commands (23 commands, AWS + Azure)
├── 💰 Cost Analysis (5 commands)
│ └── Command Description
│ dashboard Multi-account cost visibility
│ with MCP validation
│ analyze-ec2 EC2 cost analysis with 4-way
│ enrichment
│ (Discovery→Orgs→Cost→Activity)
│ analyze-workspaces WorkSpaces cost analysis with
│ decommission tier scoring
│ lambda-analysis Lambda cost and activity
│ analysis
│ detect-rds-idle RDS idle instance detector ($50K
│ annual savings, 5 signals)
├── ☁️ Azure FinOps (4 commands)
│ └── Command Description
│ azure daily Daily Azure costs by service
│ (FOCUS 1.3 aligned)
│ azure monthly Monthly Azure cost summary
│ azure anomaly Azure cost anomaly detection
│ (7-day rolling average)
│ azure validate Ground truth validation (±$0.01)
├── ⚙️ Infrastructure Optimization (10 commands)
│ └── Command Description
│ infrastructure Comprehensive infrastructure
│ analysis
│ ebs EBS volume cost optimizer
│ (GP2→GP3 conversion, orphan
│ cleanup, $1.5M+ savings)
│ ec2-snapshots EC2 snapshot cost optimization
│ optimize General cost optimization
│ recommendations
│ optimize-savings-plans Hybrid Savings Plans optimizer
│ (60/30/10 strategy, $500K+
│ target)
│ optimize-s3-lifecycle S3 Lifecycle automation ($180K
│ target, Epic 3)
│ optimize-cloudwatch-costs CloudWatch log retention
│ optimization ($10K-$50K annual
│ savings)
│ detect-orphans Unified orphan detection
│ (EBS/EIP/NAT/LB, $50K-$200K
│ savings)
│ analyze-s3-storage-lens S3 Storage Lens cost
│ intelligence ($30K-$150K
│ savings)
│ check-config-compliance AWS Config compliance-cost
│ correlation ($20K-$80K savings)
[... more commands ...]
Stage 4: Governance — OU-Level SCP Inheritance¶
Owner: CDO
The Question: When a new account is created, do our guardrails apply automatically — or does someone have to remember to re-apply them every time?
The Commands (Well-Architected assessment, Landing Zone validation):
# Assess current Config compliance and SCP effectiveness
runbooks cfat assess --all-profile $AWS_MANAGEMENT_PROFILE [A2-Inventory]
# Check SCP coverage and OU attachment strategy
runbooks inventory check-landingzone --all-profile $AWS_MANAGEMENT_PROFILE [A2-Inventory]
What Happens Autonomously: The assessment agent scores Config and SCP effectiveness, then the Landing Zone agent validates that guardrails are inherited at the organisational-unit boundary — governance shifts from audit-and-remediate to policy-and-detect.
What You Get: Guardrails inherited at the organisational-unit boundary move governance from reactive audit-and-remediate to continuous policy-and-detect — drift on every change is eliminated by design, not chased after the fact.
Stage 5: Security — Threat Detection & Compliance Baseline¶
Owner: CSO
The Question: At the next audit, can we prove threat detection covers every single account — with no silent blind spots?
The Commands (GuardDuty coverage, security assessment, enrollment):
# Enumerate GuardDuty detector coverage gaps org-wide
runbooks inventory list-guardduty-detectors --all-profile $AWS_MANAGEMENT_PROFILE [A2-Inventory]
# Score security posture across SOC2/ISO27001/PCI/HIPAA
runbooks security assess --all-profile $AWS_MANAGEMENT_PROFILE [A2-Inventory]
# Enroll missing accounts into GuardDuty (delegated security view)
runbooks security deploy-guardduty --all-profile $AWS_MANAGEMENT_PROFILE [HITL-gate: write/operate verb]
What Happens Autonomously (first two steps): The detector agent enumerates GuardDuty coverage gaps org-wide, the security agent scores posture across SOC2/ISO27001/PCI/HIPAA, and the enrollment step (HITL-approved, since it writes) closes the gaps from one delegated security view.
HITL Approval Gate:
The deploy-guardduty command carries a [HITL-gate] flag because it is a write/operate verb (security_cli.py:428, --execute). The detector enumeration and posture scoring are autonomous READONLY. Only the enrollment step requires human approval per Principle I.
What You Get: Threat detection enrolled across every account with a single delegated security view closes the coverage blind spots — security signals are comprehensive and actionable from one pane, proving the foundation is sound.
Security Assessment (real command panel):
Security Commands (6 commands)
├── 🔒 Security Assessment (2 commands)
│ └── Command Description
│ assess Multi-framework compliance assessment (SOC2,
│ PCI-DSS, HIPAA, ISO27001)
│ baseline Security baseline validation with remediation
│ recommendations
├── 📋 Compliance Reporting (1 commands)
│ └── Command Description
│ report Generate compliance reports (PDF, HTML,
│ Markdown, JSON)
├── 🛡️ Security Hub & GuardDuty (2 commands)
│ └── Command Description
│ remediate-findings Remediate Security Hub findings across
│ multi-account organization (FIN-63/62/61)
│ deploy-guardduty Deploy GuardDuty organization-wide with
│ delegated admin configuration (FIN-64)
└── 🔐 Certificate Management (1 commands)
└── Command Description
cert-inventory Multi-cloud certificate inventory (ACM, IAM,
Key Vault) with expiry dashboard
Stage 6: Infrastructure — Network Baseline & Drift Detection¶
Owner: VP-Infra / CTO
The Question: Is every new account a hand-built network risk — or a templated, drift-detected instantiation that takes seconds?
The Commands (VPC topology, CloudFormation drift):
# Map topology and cost across accounts
runbooks vpc analyze --all-profile $AWS_OPERATIONS_PROFILE [A1-Discovery]
# Discover network topology and visualize dependencies
runbooks vpc topology --all-profile $AWS_OPERATIONS_PROFILE [A1-Discovery]
# Compare live infrastructure against versioned template
runbooks inventory find-cfn-drift --all-profile $AWS_OPERATIONS_PROFILE [A1-Discovery]
What Happens Autonomously: The network agent maps topology and cost across accounts, then the drift agent compares live infrastructure against its versioned template — hygiene is assured last because the five layers above already protect the business.
What You Get: Network baselines templated as versioned, drift-detected infrastructure turn each new account from a hand-built risk into a seconds-long instantiation — hygiene is assured last because the layers above already protect the business.
The Autonomous Orchestration Behind Every Command¶
flowchart LR
A["CLI Command<br/>(runbooks)"] -->|invokes| B["ADLC /command<br/>(Orchestrator)"]
B -->|loads| C["Skill<br/>(Domain Logic)"]
C -->|calls| D["MCP Server<br/>(AWS APIs)"]
D -->|returns data| E["Agent Role<br/>(Reviews & Approves)"]
E -->|delivers evidence| F["CxO Report<br/>(Board-Ready)"]
style A fill:#f3e5f5
style B fill:#e3f2fd
style C fill:#fff3e0
style D fill:#e8f5e9
style E fill:#ffebee
style F fill:#f5f5f5
A -.->|Example: finops dashboard| G["(cost-intelligence skill)"]
G -.->|Cost Explorer MCP| H["(finops-engineer agent)"]Each stage above follows the same pattern:
1. CLI Command — the user types one line (e.g., runbooks finops dashboard)
2. ADLC /command — the enterprise orchestrator routes to the right specialist
3. Skill — domain logic (cost analysis, compliance scoring, network mapping) runs
4. MCP Server — AWS APIs (Cost Explorer, Organizations, CloudFormation, etc.) supply the data
5. Agent Role — human (cloud-architect, finops-engineer, infrastructure-engineer) reviews and approves
6. CxO Report — actionable intelligence reaches the board
This is the core differentiator: behind one command sits an autonomous, governed agent team — not a single script or CLI tool.
Next Steps¶
Ready to act? Follow this three-part path:
- CxO End-to-End Walkthrough (this page) — narrative journey through 6 business domains
- Cloud Foundations Catalog — copy-paste commands, agent delegation prompts, and business value per stage
- CLI Commands Reference — detailed command reference by functional area (board-risk indexed)
Each functional area in Cloud Foundations maps to one stage above. CLI Reference provides the detailed command documentation for every group.
For framework details, see the ADLC Agent Coordination Guide in the main documentation.
Version: 1.0.0 · Last Updated: 2026-06-21 · Scope: runbooks v1.5.0 enterprise platform