Architecture and Resource Mapping
Associate AWS resources and legacy assets with the workloads they support.
Architecture mapping connects resources to application/workload context, enabling cost allocation and migration decisions that make sense to owners rather than only cloud administrators.
What can be mapped
Supported AWS discovery covers selected Tier-1 resources (EC2, EBS, RDS/Aurora, NAT Gateway, ELB/ALB/NLB, Lambda); legacy import supplies additional source assets. A resource can have current metadata and historical cost facts with different tags or ownership at different dates.
Mapping evidence
Suggestions may derive from tags, resource attributes or existing links. A suggestion should expose its source and confidence; confirmation is an authorized action. An unmatched resource stays unmapped and its cost can remain unallocated.
Recommended workflow
- 1
Review the inventory and unmapped resources list
Find resources without business context in the Architecture view.
- 2
Filter by account, resource type or context
Use available filters to narrow the list to high-cost or high-priority resources.
- 3
Identify the target workload, application and environment
Confirm ownership before assigning.
- 4
Confirm the assignment or apply an approved rule
An authorized actor must approve mapping decisions.
- 5
Re-run allocation and confirm the financial rollup changed
Verify the previously unallocated cost now appears under the correct workload.
Historical guardrail
A mapping change today must not silently rewrite previously published allocation history. Historical labels are preserved as calculated, while current metadata remains useful for operational context.
Important