AWS

The operational problem

Information from AWS is valuable, but it becomes more useful when it can be connected to applications, owners, changes, dependencies, and potential impact.

Cloud systems rarely fail along the boundaries presented by a single provider console. The relevant question is how resource state, access, data flow, ownership, and recovery assumptions interact. StackScopes keeps those relationships visible so the result can be reviewed rather than accepted as a black box.

How the connection is modeled

The StackScopes integration model uses AWS context as evidence within the infrastructure graph and temporal model. It preserves source and scope so users can understand where a relationship or change originated.

The design favors explicit scope, durable resource identity, visible provenance, and explainable relationships. This allows a finding to participate in multiple workflows without losing the evidence or assumptions that produced it.

How it works

Connections should use the least access required for the selected workflow. Data is normalized, associated with the correct tenant, account, Region, and resource identity, and then used by topology, investigation, simulation, or reporting features.

Core considerations

• Scoped access
• Source provenance
• Tenant boundaries
• Resource matching
• Temporal context
• Operational evidence

What the output looks like

Teams can review AWS information in the operational context of the resources and paths it describes, while retaining clear source visibility.

Outputs are structured for investigation, review, simulation, reporting, or recovery planning. Illustrative environments are labeled as examples and are not presented as customer deployments.

Design decisions

Preserve uncertainty

A relationship derived from an explicit resource reference is different from one inferred from supporting context. StackScopes preserves that difference with confidence and evidence rather than flattening every edge into an absolute fact.

Keep collection separate from execution

Read-only infrastructure discovery remains distinct from any restricted execution capability. This separation supports least privilege and makes the authority required for a recovery action easier to review.

Make time part of the model

Cloud state changes continuously. Timestamps, configuration history, deleted resources, and relationship evolution provide the context required to reconstruct incidents and review proposed changes against the right state.

Why it matters

Integration is valuable when it reduces context switching without hiding provenance or implying a relationship that the evidence does not support.

The goal is not to replace provider documentation, observability, security tooling, or engineering judgment. It is to connect their evidence into a model that explains how the cloud environment behaves as a system.

Connection scope

The AWS integration is configured for the accounts, Regions, projects, repositories, signals, or resource types explicitly approved for the workspace. StackScopes keeps source identity and collection time so a user can distinguish provider configuration from declared or observed context.

What enters the model

• Scoped access
• Source provenance
• Tenant boundaries
• Resource matching
• Temporal context
• Operational evidence

Only information required for the selected operational workflows should be collected. Unsupported entities, denied permissions, throttling, incomplete history, and stale observations are represented as coverage information rather than silently converted into absence.

How teams use the integration

Evidence from AWS can support topology, dependency review, infrastructure history, change analysis, incident investigation, failure simulation, or reporting where the evidence is relevant. The integration does not replace the source system or imply support for every feature that source provides.

Security and lifecycle

Connections should use least privilege, explicit tenant and environment boundaries, secure credential handling, auditable configuration, and a documented offboarding path. Removing an integration stops future collection; retention and deletion of previously collected records follow workspace settings and contractual requirements.