StackScopes
StackScopes converts service-specific cloud resources into a consistent graph without flattening away the details that make each service operationally meaningful. The Normalized Resource Graph connects infrastructure, identity, networking, data, workloads, ownership, and changes through typed, directed, evidence-backed relationships.
Problem
AWS exposes rich configuration through many service APIs, but those services use different resource identifiers, response shapes, scopes, and relationship conventions. A load balancer listener forwards to a target group. A Lambda function has event-source mappings. An IAM role trusts principals and permits actions. A route table directs prefixes through targets. A KMS key encrypts resources under policies and grants.
A flat inventory can store each resource as a row, yet it cannot naturally answer:
- Which workloads depend on this endpoint?
- Which security groups sit on a database path?
- Which customer capability uses this queue?
- Which resources share one KMS key?
- What changed along the affected path before an incident?
Naive graphs introduce their own problems. If every connection is labeled “depends on,” analysis loses direction and behavior. If names are treated as identity, similarly named resources across accounts can be merged. If service details are discarded during normalization, later investigation cannot verify why an edge exists.
The graph must create consistency without manufacturing certainty.
What We Built
We built a canonical resource-and-relationship model designed for operational traversal. It represents provider resources as nodes with stable identity, typed configuration, boundaries, lifecycle, and source evidence.
Relationships are first-class records. Each edge can include:
- Source and target
- Semantic type
- Direction
- Account and Region context
- Observation or validity time
- Provenance
- Confidence
- Required, optional, fallback, or unknown behavior
- Supporting configuration field or runtime evidence
The graph also supports higher-level nodes for workloads, services, teams, environments, customer capabilities, and controlled tenant groups. These provide business and ownership context without pretending they are AWS resources.
Normalization adds shared structure while preserving the original service-specific evidence. A database node can participate in general dependency traversal while still exposing engine, endpoints, subnet group, security groups, encryption configuration, and availability design where collected.
How It Works
Resolve stable identity
Identity uses provider scope rather than display name. Partition, account ID, Region, service, type, ARN, and service identifier are combined according to resource semantics. Global, regional, and zonal resources remain distinct.
A Terraform address or CloudFormation logical ID represents declared infrastructure, not the provider resource itself. StackScopes links these identities using state, stack metadata, tags, or deployment evidence and retains the reason for the match.
Normalize common attributes
Common fields include resource type, lifecycle, account, Region, Availability Zone, environment, tags, ownership context, and observation time. Service-specific configuration remains attached as structured evidence.
Normalization rules are versioned because provider APIs and relationship semantics evolve. Changes to a rule can be reviewed and reprocessed without hiding how earlier conclusions were produced.
Extract typed edges
Direct configuration creates high-confidence relationships. Examples include:
- Listener forwards to target group
- Service uses task definition
- Task definition uses IAM role
- Resource is encrypted by KMS key
- Function is triggered by queue
- Subnet uses route table
- DNS record resolves to endpoint
Declared infrastructure and runtime sources can add evidence. “Can access” from IAM policy is modeled separately from “observed accessing.” Network traffic is not automatically labeled a required application dependency.
Preserve boundaries
Cross-account and cross-Region edges are explicit. A central event bus or shared VPC can connect resources while authorization continues to respect tenant and account scope. The graph does not erase isolation to simplify visualization.
Add time and provenance
Nodes and edges retain first-seen, last-observed, and validity context. When a relationship disappears, it can close historically rather than vanish. Every important edge can point to configuration, infrastructure-as-code, runtime observation, or reviewed human context.
Support scoped traversal
Users can explore one workload, critical path, owner, account, Region, or change window rather than loading every node. Aggregation can group ephemeral instances beneath a stable service while preserving drill-down.
Output and Evidence
The graph supports:
- Live infrastructure topology
- Inbound and outbound dependency views
- Multi-hop path queries
- Shared-dependency detection
- Change-impact traversal
- Blast-radius analysis
- Security and IAM path analysis
- Point-in-time topology
- Ownership and capability mapping
- Evidence review
Illustrative scenario: An ECS service appears redundant across two Availability Zones. The graph shows both task groups depend on the same Secrets Manager VPC endpoint and the same KMS key. The compute layer has multiple instances, but two shared edges create a common path. Selecting either edge reveals its configuration evidence, observation time, and affected workload context.
An edge is never just a line. Its detail view explains the relationship type, direction, evidence source, freshness, and confidence. When sources disagree—for example, declared infrastructure references one target while observed configuration uses another—the graph preserves both and identifies potential drift.
Why It Matters
Operational decisions are about systems, not resource lists. A graph makes it possible to move from one alerting node to affected workloads, from a proposed configuration change to dependent paths, or from a customer capability toward its infrastructure prerequisites.
Normalization enables consistent queries across AWS services. Preserved service detail keeps those queries explainable. Typed edges allow simulations to distinguish a synchronous database requirement from an optional analytics event or an IAM permission path.
The graph also provides a foundation for AI-assisted investigation. An assistant can summarize a path or compare changes, but its statements remain grounded in inspectable nodes, edges, timestamps, and evidence.
The goal is not to display the largest possible graph. It is to provide the smallest useful view for the operational question while retaining a connected source of context.
The same model creates consistency across product workflows. Live topology, security-path review, change impact, failure simulation, and recovery planning do not need separate, contradictory inventories. Each workflow can select the edge semantics and time window it needs while referring back to the same identities and evidence. When an engineer validates that a cache is optional or that a proxy is required, that reviewed context becomes available to later analysis without rewriting the underlying provider observation.
Graph quality can also be inspected as an operational concern. Unknown owners, unresolved identities, stale evidence, and low-confidence edges can be grouped into a review queue. This turns gaps into visible work instead of allowing a complete-looking diagram to hide them.
Operational Guardrails
Resource identity and tenant boundaries are enforced during ingestion, storage, traversal, and export. Cross-account edges do not grant cross-account data access.
Sensitive values are not required for topology. StackScopes can model that a workload references a secret without collecting its contents. Evidence fragments should be minimized to the fields needed for explanation.
Inferred edges show confidence and provenance. Users can confirm, reject, or annotate an inference without overwriting raw observations. Stale runtime evidence does not remain active indefinitely without a freshness indicator.
Graph results do not guarantee production behavior. Missing permissions, external services, application code, and telemetry gaps can leave unknown paths. Coverage remains visible, especially during high-risk simulation or change review.
Visualization is also bounded deliberately. Dense environments are filtered and aggregated by workload, account, Region, owner, or path. Aggregation preserves access to the underlying resources and does not conceal a shared dependency merely to make the screen cleaner.
FAQ
Why use a graph instead of relational inventory tables?
Inventory tables are useful for filtering assets. A graph makes multi-hop, path, shared-dependency, and impact queries more natural. StackScopes can still use multiple storage patterns internally; the operational model is graph-oriented.
Does normalization remove AWS-specific details?
No. Common identity and relationship fields are normalized while relevant service configuration remains available as source evidence.
Are all graph edges equally reliable?
No. Explicit provider references, declared relationships, runtime evidence, and human context have different strengths. Each inferred edge carries provenance, time, and confidence.
Can the graph represent resources outside AWS?
The current product scope is AWS-first. The model is designed to represent controlled external or custom concepts, but support should only be claimed for integrations that are actually implemented and verified.
Related StackScopes links
StackScopes keeps operational evidence, timestamps, assumptions, and confidence visible. Production-impacting recovery remains subject to policy and human approval.