The gap
AWS moved Service Catalog AppRegistry and the myApplications console dashboard into maintenance mode on 2026-07-30, closed to any account that had not already used them. myApplications was the one free AWS surface that put cost, alarms, and security findings for a single application on one page.
AWS's named replacements are tagging, Resource Groups, Resource Explorer, and (paid) CloudWatch Application Signals. None of them reproduce the single pane. After the transition an operator asking "how is product X doing" visits three places:
| Question |
Where it lives now |
| What does it cost |
Cost Explorer, grouped by tag |
| What is alarming |
CloudWatch alarms |
| What exists / blast radius |
Resource Groups and Resource Explorer |
That reassembly is manual, repeated, and exactly the kind of context-gathering Glance already exists to collapse.
Why this fits Glance specifically
The README frames the direction as "surface what needs attention first" and "make next-step operator actions fast", with Findings as the operator-centric home. An application-scoped view is the same idea with a different axis: instead of slicing by service, slice by the tag that says what the resources are for.
Glance already fetches per-service inventory, cost data, and CloudWatch state. The missing piece is not data collection, it is a grouping key.
Proposed feature
An Application view: pick a tag key (default something like Application), and Glance renders one row per distinct value with cost, alarm state, and resource count rolled up, drilling into the resources behind it.
Sketch:
- Config option for the grouping tag key, since AWS mandates no standard one. Common conventions are
Application, project, workload. awsApplication should work too, for accounts that used AppRegistry before the cutoff.
- Roll up per tag value: month-to-date cost (Cost Explorer supports
GroupBy on a tag key), count of alarms in ALARM, resource count by service.
- Drill down into the resources carrying that tag value, reusing the existing per-service views.
- Optionally seed the list from Resource Groups (
resource-groups:ListGroups plus ListGroupResources), since many accounts will already have tag-based groups defined. That gives named groupings without Glance having to infer them.
- Surface untagged resources as their own bucket. That doubles as a tagging-hygiene finding, which fits the Findings direction: an untagged resource is invisible to every cost and grouping tool, so it is genuinely worth flagging.
Prior art to point at
fells-code/seamless-iac now standardizes six tag keys across every stack (Application, Component, Plan, Environment, ManagedBy, Repo) and builds Resource Groups per component, plan, and application. See ADR 0007 in that repo. It is a concrete account to develop against, and the Component key in particular maps a resource back to the Terraform root module that owns it, which is useful context to show in a drill-down.
Not proposing
Reimplementing Application Signals. This is tag-based rollup of data Glance already reads, not tracing or dependency mapping.
The gap
AWS moved Service Catalog AppRegistry and the myApplications console dashboard into maintenance mode on 2026-07-30, closed to any account that had not already used them. myApplications was the one free AWS surface that put cost, alarms, and security findings for a single application on one page.
AWS's named replacements are tagging, Resource Groups, Resource Explorer, and (paid) CloudWatch Application Signals. None of them reproduce the single pane. After the transition an operator asking "how is product X doing" visits three places:
That reassembly is manual, repeated, and exactly the kind of context-gathering Glance already exists to collapse.
Why this fits Glance specifically
The README frames the direction as "surface what needs attention first" and "make next-step operator actions fast", with Findings as the operator-centric home. An application-scoped view is the same idea with a different axis: instead of slicing by service, slice by the tag that says what the resources are for.
Glance already fetches per-service inventory, cost data, and CloudWatch state. The missing piece is not data collection, it is a grouping key.
Proposed feature
An Application view: pick a tag key (default something like
Application), and Glance renders one row per distinct value with cost, alarm state, and resource count rolled up, drilling into the resources behind it.Sketch:
Application,project,workload.awsApplicationshould work too, for accounts that used AppRegistry before the cutoff.GroupByon a tag key), count of alarms in ALARM, resource count by service.resource-groups:ListGroupsplusListGroupResources), since many accounts will already have tag-based groups defined. That gives named groupings without Glance having to infer them.Prior art to point at
fells-code/seamless-iacnow standardizes six tag keys across every stack (Application,Component,Plan,Environment,ManagedBy,Repo) and builds Resource Groups per component, plan, and application. See ADR 0007 in that repo. It is a concrete account to develop against, and theComponentkey in particular maps a resource back to the Terraform root module that owns it, which is useful context to show in a drill-down.Not proposing
Reimplementing Application Signals. This is tag-based rollup of data Glance already reads, not tracing or dependency mapping.