StackScopes
StackScopes derives cloud relationships that no single inventory or architecture diagram can provide. The Dependency Inference Engine combines explicit configuration, infrastructure-as-code, identity and network context, runtime observations where available, ownership data, and human review. Each inferred edge explains why it exists and how certain the available evidence makes it.
Problem
Some AWS dependencies are explicit. A load balancer listener names a target group, or a Lambda event-source mapping names a queue. Other paths are distributed across systems:
- An application retrieves a database endpoint from a secret.
- A task role permits access to several resources but uses only one.
- Workloads communicate through a proxy or VPC endpoint.
- A queue producer does not name its consumers.
- A DNS record resolves to an external API.
- A deployment module creates resources under generated names.
- A monthly workflow is absent from a short tracing window.
Configuration can show that access is possible without proving it is used. Runtime traffic can show communication without proving it is required. Tags and naming can suggest ownership while remaining inconsistent. Any inference engine that collapses these distinctions creates false confidence.
The challenge is to assemble useful paths while showing uncertainty, freshness, and disagreement.
What We Built
We built a rule-driven inference layer on top of the normalized StackScopes graph. It accepts evidence from approved sources, resolves observations to stable resource identities, proposes typed relationships, and assigns explainable confidence based on the strength and agreement of evidence.
The engine distinguishes relationship meanings such as:
- Configured to use
- Observed calling
- Can access
- Routes through
- Reads from
- Writes to
- Triggered by
- Owned by
- Deployed from
- Potentially depends on
This vocabulary prevents an IAM permission from being presented as observed use, or a network flow from automatically becoming a critical application dependency.
Inferences retain their ingredients. A user can inspect the resource reference, trace span, network correlation, policy statement, deployment mapping, or reviewed annotation behind the edge.
How It Works
Begin with explicit facts
Provider configuration and direct references form the strongest baseline. StackScopes extracts resource identifiers from supported fields and creates typed edges with the source path and observation time.
Infrastructure-as-code adds declared intent. Terraform references, state mappings, CloudFormation resources, stack outputs, and change metadata can connect logical definitions to deployed identities. Declared deployment ordering remains distinguishable from runtime dependency.
Correlate runtime evidence
Where enabled and approved, traces can reveal service-to-service paths and remote endpoints. Network observations can support communication between interfaces or services. CloudTrail may provide resource-access context for supported events.
Runtime evidence is associated with an observation window. Its absence does not prove a dependency is absent, particularly for rare, seasonal, failover, or administrative paths.
Model identity and access separately
IAM policies, trust relationships, resource policies, and grants can create potential access paths. StackScopes models capability—what a principal may do—separately from observed use and operational requirement.
This distinction supports both dependency review and security-path analysis. A broad permission may be a risk even if it is not a production dependency.
Resolve endpoints and network context
Endpoints, DNS, subnets, routes, security groups, network interfaces, gateways, and proxies can connect application observations to infrastructure. Resolution remains time-aware because addresses and targets change.
A flow is classified cautiously. Health checks, scans, backups, and administrative actions can create traffic that is not customer-path dependency.
Combine evidence
Confidence follows explainable rules rather than an unexplained percentage. A direct configuration reference may be confirmed. Repeated traces plus matching configuration may be strong. Recurrent network evidence with identity correlation may be moderate. Naming similarity alone remains weak.
When sources disagree, the engine preserves the discrepancy. Declared infrastructure might reference one queue while observed configuration uses another; that can indicate drift rather than an edge to average away.
Invite human validation
Owners can confirm or reject inferred dependencies, classify them as required or optional, describe fallback, and add review notes. The system records who reviewed the relationship and when, while retaining the original evidence.
Output and Evidence
The engine provides:
- Typed dependency edges
- Evidence sources and observation windows
- Confidence level and explanation
- Required, optional, fallback, or unknown behavior
- First-seen and last-observed timestamps
- Staleness indicators
- Conflicting-source warnings
- Ownership and review state
- Coverage gaps
Illustrative scenario: An application trace shows repeated calls to a private address. Network-interface correlation resolves it to a shared proxy. Route and security-group configuration confirms the path, while no Terraform reference exists in the application repository. StackScopes creates an observed network dependency with strong supporting evidence and flags that the relationship is absent from declared infrastructure. An owner can confirm that the proxy is required for two external APIs.
The output does not merely draw a line. It answers: which signal suggested the edge, how the endpoint was resolved, how recently it was observed, which configuration supports it, and whether an engineer validated its behavior.
The engine also exposes the lifecycle of an inference. First-seen and last-observed times show whether a path is persistent, new, or quiet. Evidence-specific freshness prevents a monthly batch dependency from being handled like a high-frequency request path. A removed configuration reference can close an edge historically, while old runtime traffic can remain visible without continuing to appear current.
Relationship behavior is kept separate from topology confidence. The system may be highly confident that two services communicate while still not knowing whether the caller can degrade gracefully. That distinction gives workload owners a precise review task: validate whether the path is required, buffered, optional, or backed by an alternative.
Why It Matters
Hidden dependencies are a common source of surprise during changes and incidents. A shared endpoint policy, DNS zone, queue, secret, or security group can affect workloads that do not appear together in a repository or diagram.
Inference makes those paths reviewable before failure. Change-impact analysis can show likely dependents of a proposed rule update. Failure simulation can include runtime-discovered paths. Incident responders can begin with a broader evidence set instead of manually correlating five consoles.
Explainability is central. Engineers are more likely to trust and correct a model when it shows evidence rather than an opaque recommendation. Corrections then improve later simulation and recovery planning.
The engine is not intended to claim omniscience. Its purpose is to convert fragmented observations into explicit, challengeable hypotheses.
Operational Guardrails
Runtime collection is optional and bounded by customer-approved sources. Logs, traces, and network evidence can contain sensitive context, so StackScopes applies minimization, tenant-aware access, retention controls, and masking principles.
Secret contents are not required. IAM permissions remain separate from actual use. Weak naming or tag similarity never becomes a high-confidence technical dependency on its own.
Inferences expire or become stale according to evidence type. Configuration remains valid until a later observation changes it; runtime evidence is tied to a window; human assertions require review dates.
AI assistance can summarize evidence but does not create production truth by assertion. Production-impacting remediation remains separate, policy-bound, auditable, and subject to human approval.
Inference rules are versioned and testable. A rule change can affect many relationships, so its output should be compared with prior results before promotion. This prevents an apparently small correlation update from silently changing blast-radius or security conclusions across an environment.
FAQ
Can the engine find every application dependency?
No. Missing telemetry, dynamic code, external services, rare paths, and insufficient permissions can leave gaps. StackScopes displays coverage and uncertainty.
Is an IAM permission treated as a dependency?
It is modeled as a potential access path. Observed use and operational requirement are separate relationship states.
How is confidence determined?
Confidence is based on explainable evidence rules, such as direct configuration references, matched declared state, repeated runtime observations, and human review. Users can inspect the supporting sources.
What happens when an engineer rejects an edge?
The review decision is stored with its reason and time. Raw evidence remains available, and later contradictory evidence can request revalidation.
Related StackScopes links
StackScopes keeps operational evidence, timestamps, assumptions, and confidence visible. Production-impacting recovery remains subject to policy and human approval.