After a Big Outage: How to Catalog Your Cloud Ops Footprint - and Check for Cross-Cloud Resilience
The AWS incident on Monday, October 20th, 2025, made one thing painfully clear: most companies don’t just “run on a cloud”; they run on multiple clouds and SaaS—many of which sit on the same underlying provider. If you want real resilience, you first need a comprehensive, up-to-date catalog of every cloud service supporting production, and then you need to determine whether each of those services is diversified across competing providers.
Here’s a practical, field‑tested approach you can implement now.
1. Define the scope: “everything that keeps prod running”
Don’t limit your inventory to compute and databases. Include:
- Core IaaS/PaaS: compute, storage, databases, message queues, caches, serverless, container platforms.
- Edge & networking: DNS, CDN, WAF, DDoS protection, certificate management.
- Identity & access: IdP/SSO, MFA, secrets managers, key management, PAM.
- Delivery & platform: CI/CD, artifact registries, container registries, feature flags, config stores.
- Observability, Monitoring & reliability: metrics, logs, tracing, error tracking, paging/incident response, status page.
- Security & IT ops: vulnerability scanners, EDR/MDM, posture management, ticketing, chat/collab, email/SMS/voice providers.
- Data & integration: ETL/ELT, analytics, event streaming, third‑party webhooks.
If losing the service would slow or stop your response to a production incident, it belongs in the catalog.
2. Discover services from multiple evidence sources
Relying on one source (say, cloud bills) misses critical SaaS. Combine these:
- Cloud billing & inventory: AWS CUR, Azure Cost Management exports, GCP billing data; AWS Config/Resource Explorer, Azure Resource Graph, GCP Asset Inventory. Pull account/project, region, tags.
- Infrastructure-as-Code & clusters: Parse Terraform state, CloudFormation stacks, Helm releases, and Kubernetes manifests to list managed services, add-ons, and external dependencies.
- CI/CD & repos: enumerate GitHub/GitLab/Jenkins integrations, runners, artifact/registry endpoints referenced in pipelines.
- Identity provider logs: Okta/Azure AD/Entra sign-ins and app assignments reveal “shadow” SaaS used by engineers.
- Endpoint & egress logs: MDM/EDR agents and outbound firewall/DNS logs surface tools the platform team installed or calls at runtime.
- Finance & procurement: AP/vendor records catch paid SaaS that hasn’t been integrated with SSO (yet).
Automate these pulls and deduplicate by canonical service name.
3. Normalize into a service catalog (system of record)
Choose a home - Backstage, ServiceNow, Jira CMDB, or even a spreadsheet to start - but standardize fields so the catalog is useful for risk decisions. Recommended fields:
- Service name & purpose (one sentence)
- Business & technical owners (with on-call rotation)
- Environment coverage (prod/non-prod)
- Criticality (tier), RTO/RPO, data classification
- Primary vendor, product, SKU/plan
- Declared hosting provider(s) (from vendor docs)
- Verified hosting indicator (DNS/ASN check; see §4)
- Region/zone usage (for self-run services)
- Upstream dependencies (IdP, DNS, CDN, registry, queue, email/SMS)
- Failover mechanism (active-active, warm standby, manual)
- Last DR test date and runbook link
- Contract/SLA (SLOs, support plan, renewal date)
Keep this catalog versioned and visible to engineering and leadership.
4. Identify whether each service spans competing providers
You need both attestation and technical hints:
Ask and verify (attestation):
- Vendor trust center/status page/data residency docs often state the underlying cloud(s) and regions.
- Sub-processor lists (common for GDPR/SOC 2) reveal where data flows (e.g., storage, email, SMS).
- Send a short resilience questionnaire: Are you single-cloud or multi-cloud? Which regions? What’s your failover strategy? How often do you test? What are your control-plane dependencies (DNS, IdP, messaging, artifact registry)?
Cross-check (technical hints):
- DNS lookups (dig, nslookup) and CNAME chains often expose patterns:
- ...elb.amazonaws.com, …cloudfront.net, s3.amazonaws.com → AWS
- ...azurewebsites.net, …trafficmanager.net → Azure
- ...appspot.com, …googleusercontent.com → Google Cloud
- WHOIS/ASN on resolved IPs can indicate Amazon/Microsoft/Google/Cloudflare/Fastly/Akamai ownership.
- HTTP headers/TLS SANs sometimes reveal CDNs or proxies.
Caveat: CDNs and WAFs can mask origins; treat technical signals as indicators, not proof. Always pair with vendor attestation.
Record your findings in the catalog: Declared provider(s) vs. Observed indicator(s), and mark mismatches for follow-up.
5. Score concentration risk and highlight single points of failure
Adopt a simple 0–4 score for each service:
- 0: Single region on a single provider; no documented failover.
- 1: Multi-AZ or multi-zone on a single region.
- 2: Multi-region on one provider with tested failover.
- 3: Hot/warm standby across two providers or provider-agnostic deployment (portable data + automation).
- 4: Active-active across providers; control-plane independence (DNS/IdP not a shared bottleneck).
Identify critical hotspots that often cause failures: DNS, IdP/SSO, artifact/container registries, observability/paging, secrets management, status page, inbound webhooks (payments, email, SMS, chat). List the current vendor, underlying provider, score, and owner for each hotspot.
6. Apply practical mitigations (quick wins first)
- Dual DNS: Maintain secondary DNS with an independent provider; pre‑publish records and health checks.
- Break‑glass identity: Local admin accounts, cached credentials, hardware OTP, and documented IdP‑down runbooks.
- Out‑of‑band comms & status: Host incident comms and status page off your primary provider.
- Registry and package mirrors: Replicate artifacts/images to a second registry and test pull‑through.
- Off‑cloud backups: Immutable backups with periodic restore tests; track RPO/RTO in the catalog.
- Multi‑provider comms: Configure at least two channels/providers (email/SMS/voice/push) for critical notifications.
- Portable deployments: Containerize, externalize config, pin IaC to providers behind a thin abstraction, and store Terraform/state + secrets in locations that don’t vanish when your primary cloud is not available.
Tie each mitigation to a catalog field (e.g., “Failover mechanism,” “Last DR test”).
7. Keep it alive: automate and rehearse
- Continuous updates: Nightly imports from billing/asset inventories, weekly SSO log diffs, and monthly IaC scans. Alert owners when new dependencies appear.
- Intake guardrails: New SaaS must be registered in the catalog with hosting attestation before access is granted.
- GameDay’s/Chaos Drills: Simulate the loss of IdP, DNS, primary region, artifact registry, and paging provider. After-the action items are completed, update the catalog and runbooks.
The Multi-Level Dependency Chain
To turn the inventory into action, the Multi-Level Dependency Chain table below lays out each production-critical service against the layers it leans on - identity/SSO, DNS/CDN, networking, CI/CD and registries, observability/paging, data stores, and external webhooks - making upstream vendors, underlying clouds, and failover posture visible at a glance. It complements your service catalog by exposing concentration hotspots (e.g., DNS, IdP, artifact registries) and the likely cascade path of a region or control-plane failure, so you can sequence mitigations (dual DNS, break-glass identity, off-cloud status/comm channels, secondary registries, off-cloud backups) and assign owners with test dates. Read left-to-right for dependency depth and top-to-bottom for blast radius; update after every change so this becomes a living, testable map of resilience.
About KendraCyber
KendraCyber blends deep business acumen with cutting-edge AI to deliver precise, scalable cybersecurity solutions. From strategy to execution, the company helps enterprises navigate the evolving landscape of AI Governance, Risk, and Compliance (GRC) with confidence and clarity.