StackScopes
Problem
Most cloud inventories answer a present-tense question: what exists now? That is useful for operations, but incidents and architecture decisions are usually about change. What was connected before the outage? Which policy changed? Did a dependency disappear before or after the first alert? Was a deleted resource still part of the topology when customer impact began?
Current state can erase the evidence. A replaced instance receives a new identifier. A DNS record points to a new target. A security-group rule is removed. A queue subscription disappears. If the model keeps only the latest snapshot, the previous architecture becomes difficult to reconstruct.
Infrastructure-as-code history helps but is not sufficient. Declared state can differ from actual cloud configuration, and runtime evidence can reveal relationships that neither source describes. Cloud events offer precise context for some changes but can be missing, delayed, or outside retention.
Teams need a timeline that preserves what StackScopes observed, where that observation came from, and how topology changed without inventing precision that the sources do not provide.
What We Built
StackScopes Infrastructure Timeline and Drift Explorer adds a time dimension to the cloud digital twin. It stores lifecycle and change context for resources, configuration fields, relationships, ownership, and evidence.
The explorer supports:
- Point-in-time resource views
- Point-in-time dependency topology
- Before-and-after comparison
- New, changed, and deleted resources
- Added, removed, and redirected relationships
- Configuration-event context
- Declared-versus-actual state
- Actual-versus-observed behavior
- Incident-window reconstruction
- Drift prioritization through downstream impact
The model distinguishes observation time from event time. A snapshot comparison can prove that a value differed between two collections, but the exact change may have happened at any point between them. A CloudTrail event can narrow the time when its configured coverage includes the relevant API. This distinction remains visible.
Deleted resources are not immediately erased from historical topology. Their lifecycle closes according to authoritative evidence and retention policy so prior incidents can still reference them.
How It Works
Capture versioned observations
Read-only discovery produces normalized observations with resource identity, account, Region, type, selected configuration, relationships, source, and collection time. Service adapters identify fields that carry operational meaning rather than retaining every response property without purpose.
Each successful scoped collection creates a version or set of changes. Failed scopes preserve the previous known state and become stale; they do not imply that every resource disappeared.
Add event context
Where authorized and configured, CloudTrail or deployment events can provide actor, action, target, and event time. Infrastructure plan and apply records connect intention to resulting state. Events become evidence linked to topology, not an unquestioned replacement for state discovery.
Late, duplicate, or out-of-order events are handled idempotently. An event can trigger a scoped refresh to confirm actual state.
Preserve lifecycle
Canonical identity uses account, Region or global scope, resource type, and provider identifier. Names and tags remain mutable attributes. Replacement with a new native identifier usually creates a new lifecycle even if the friendly name remains the same.
Deletion is inferred only from an authoritative complete listing or reliable event. A throttled or denied scan cannot close resource lifecycles.
Compare states
Users select two times or an incident window. StackScopes calculates field-level and graph-level differences:
- Resource added, removed, or replaced
- Configuration changed
- Relationship created, removed, or redirected
- Ownership changed
- Declared and actual state diverged
- Observed runtime path appeared or disappeared
Changes can be filtered by account, Region, environment, workload, owner, resource type, evidence, and downstream impact.
Evaluate drift in context
Not every difference is equally important. The explorer follows dependencies from a drifted resource to affected workloads and shared controls. A security-group drift on an isolated test resource differs from one attached to production database paths.
Output and Evidence
The timeline presents events and observed state transitions in one navigable view. A user can select an item to inspect:
- Resource identifier and lifecycle
- Before and after values
- Observation or event time
- Actor where supported
- Collection source
- Related plan, stack, or deployment
- Relationship changes
- Evidence confidence
- Affected topology
- Ownership
- Collection gaps
A point-in-time graph renders the topology known at the selected moment. The interface states whether relationships came from explicit configuration, policy reachability, runtime observation, or human validation.
Drift views separate three concepts:
- Declared state: what infrastructure definitions intend.
- Actual state: what cloud control-plane APIs report.
- Observed state: selected behavior seen through approved telemetry.
A difference between them is evidence to investigate, not automatically an error. Emergency changes can be intentional; dynamic services can produce expected variation; telemetry can be incomplete.
Incident-window mode narrows the timeline around first symptoms and relevant dependencies. It helps investigators ask which topology changes preceded the incident without claiming chronology alone proves causation.
Historical simulation and comparison
A selected historical state can also become the baseline for a model-based failure scenario. Investigators can ask whether removing a node from the topology known at that time produces an impact path similar to the incident. Differences between simulated and observed behavior reveal missing dependencies, incorrect assumptions, or application semantics the graph does not capture.
Historical simulation remains analytical. It does not reproduce production traffic, concurrency, data corruption, or third-party behavior. Its value is in testing the explanatory model and identifying which evidence should be added.
For architecture review, teams can compare two points and group changes by capability. This makes a large migration easier to understand: which dependencies moved, which shared controls remained, and which recovery paths now cross a new account or Region.
Why It Matters
Temporal context turns infrastructure inventory into operational memory. Incident investigators can reconstruct the architecture that existed before remediation changed it. Change reviewers can compare proposed, expected, and actual outcomes. Platform teams can see relationships drifting, not just fields. Security teams can inspect how access paths evolved.
The timeline also strengthens failure simulation. Teams can simulate against a historical topology to test whether a dependency model explains a past impact pattern. The result remains model-based and should be compared with incident evidence.
Prioritizing drift by topology makes remediation more useful. Teams can focus on differences connected to critical capabilities, shared controls, or weak recovery paths instead of treating every mutable field as equally urgent.
Operational Guardrails
- Discovery uses approved read-only access.
- Failed collection never becomes mass deletion.
- Event time and observation time remain distinct.
- History respects tenant retention and deletion policies.
- Sensitive configuration and event content is minimized.
- Actor information follows role-based authorization.
- Chronology is not presented as proof of causality.
- Runtime gaps are visible.
- Drift rules are versioned and explainable.
- Historical views retain evidence provenance.
FAQ
How is the exact change time determined?
An event can provide a precise timestamp when coverage includes the action. Snapshot comparison provides an interval between observations. StackScopes preserves that distinction instead of guessing.
Are deleted resources kept forever?
No. Historical lifecycle follows the configured retention and deletion policy. The product can preserve deleted resources for point-in-time analysis only within those boundaries.
Is every difference considered drift?
No. Some differences are expected or intentionally introduced. StackScopes shows the source, scope, and dependency impact so owners can classify and prioritize them.
Can a timeline prove the root cause of an incident?
It can identify relevant changes and dependency paths, but temporal proximity alone does not prove causation. Investigators must correlate configuration, telemetry, application behavior, and validation.
Related StackScopes links
StackScopes keeps operational evidence, timestamps, assumptions, and confidence visible. Production-impacting recovery remains subject to policy and human approval.