Self-serve CloudWatch metric explorer for non-AWS users

Build me a self-serve Amazon CloudWatch metric explorer: an app that people who do not have an AWS login can open to answer their own infrastructure questions. The audience is support leads, finance, product managers, and junior ops, so the app has to be usable by someone who does not know AWS naming conventions. CloudWatch metric data is region scoped, so the app connects to a single AWS region and should show which region is connected in a persistent header or banner, and every view should be understood as showing that one region only.

The main view is a metric browser backed by List Metrics. Let people drill from namespace, to metric name, to the dimension sets available for that metric, so they can find something without knowing what it is called up front. Put a search box over metric names above the tree, and a namespace filter so the team can narrow to the handful of services they actually care about, with the default filter set configurable. List Metrics is paginated with NextToken and an account can have a lot of metrics, so the handler should page through fully and cache the catalogue rather than refetching the whole tree on every keystroke; the search box should filter the cached catalogue client side.

Add a second way in: a dashboard import panel that calls List Dashboards to show existing CloudWatch dashboards, and Get Dashboard when one is picked. Parse the returned DashboardBody, which is a JSON string, and extract the metrics referenced by its widgets so the user gets a ready made starting selection instead of building a view from scratch. Treat CloudWatch dashboards strictly as read-only inputs. Do not write anything back to CloudWatch, and do not attempt to create or update a dashboard there. Everything the user saves stays in the app's own storage.

Selecting one or more metrics charts them together using Get Metric Statistics. That operation returns one metric per call, so a multi-metric chart means the handler fans out one call per selected metric and merges the returned datapoints into a single series set aligned on timestamp, sorting each series by time because CloudWatch does not guarantee datapoint order. Give the user a time range picker, a statistic picker offering Average, Sum, and Maximum plus p95, and a period granularity control. Note that p95 is a percentile and has to be requested through the ExtendedStatistics parameter rather than Statistics, so the handler should route the selection to the right parameter.

Bake in CloudWatch's retention and granularity rules so long ranges do not silently return an empty chart: fine grained data ages out, and older windows require a coarser period. Auto-suggest a sensible period for the chosen time range, and if the user picks a combination CloudWatch will not serve, say so in the UI instead of rendering a blank graph.

Add a compare to previous period toggle. When it is on, the handler runs the same fan-out a second time against the immediately preceding window of equal length, and the chart overlays that prior window in a visually secondary style such as a dashed or muted line, aligned so the two periods sit on top of each other by relative offset rather than absolute timestamp. The purpose is to let someone see whether today is actually unusual, so make the comparison easy to read at a glance.

For whichever metric is currently selected, call Describe Alarms For Metric and show whether anything is alarming on it, including the alarm name, threshold, and current state. Make the empty result a first class, visible outcome rather than a blank space: if no alarms exist for that metric, say clearly that nothing is watching it. Finding the metrics the team monitors by eye but never alerts on is one of the main reasons this app exists, so consider surfacing an unwatched indicator directly in the browse tree as well.

Any chart a person builds can be saved as a named view in the app's own storage, capturing the selected metrics and their dimensions, the time range, statistic, period, and the compare toggle, so the same question is one click next time. Saved views should be listed on the app's home screen, and let the setup decide whether views are private per user or shared across everyone using the app.

Add an export action on any chart that writes the underlying numbers to a tab in Google Sheets using Append Values, with a header row plus one row per timestamp and a column per selected metric, and a column noting the AWS region and statistic used. Let the user pick the target spreadsheet and tab. This is for finance or leadership who want to chart infrastructure numbers next to business numbers in a tool they already have open, so it is an occasional deliberate action rather than a background sync.

Scope boundaries: read-only IAM on the AWS side is sufficient for everything this app does, which is worth stating in the app's own setup or help text because it lowers the bar for granting access. CloudWatch Logs is a separate API and is not part of this integration, so do not include any log search anywhere in the app. The app performs no writes against AWS at all; the only write in the whole app is the Google Sheets export.