Infrastructure monitoring

Forge provides baseline infrastructure monitoring for every deployed platform stack using CloudWatch dashboards, CloudWatch alarms, and a central SNS alerts topic. This answers a different operational question than application observability: is the platform itself healthy?

This guide is for architecture review, procurement, and technical diligence. It explains how Forge thinks about infrastructure monitoring — not how to deploy alarms or wire on-call routing. The four-concern operational model is in Observability architecture; application telemetry depth is in Application telemetry.

What problem this solves

Application observability tells you how software behaves. It does not, by itself, tell you:

1. Whether the load balancer is marking targets unhealthy — ECS tasks may still be running while the target group removes them from service.
2. Whether the database or cache is under pressure.
3. Whether edge protection is firing — WAF blocks and CloudFront errors need infrastructure-level signals, not JVM metrics.
4. Whether email reputation is degrading — bounce and complaint rates are infrastructure concerns, not HTTP request counters.

Forge provisions baseline CloudWatch dashboards and alarms so operators inherit sensible monitoring from the first deployment.

Architectural model

Forge deliberately separates infrastructure monitoring from application observability:

  AWS resources (ECS, ALB, RDS, CloudFront, …)
        │
        ▼
  CloudWatch metrics
        ├────────► CloudWatch dashboards   (per-stack operational view)
        │
        └────────► CloudWatch alarms         (threshold breaches)
                      │
                      ▼
               SNS alerts topic
                      │
                      ▼
         operator routing (PagerDuty, email, chat, …)

Each monitored stack receives its own dashboard so operators can narrow investigations to the layer that changed — runtime, datastore, edge, identity, or domain — without a single monolithic “everything” board.

Monitoring is defined alongside the stacks that own each resource. Each stack contributes dashboards and alarms for the infrastructure it provisions, so monitoring evolves with the platform rather than living in a separate, hand-maintained configuration.

How the pieces fit together

Three operational layers complement each other during an incident:

  Health checks (readiness)        →  "Should this task receive traffic?"
  Infrastructure monitoring        →  "Is the surrounding infrastructure failing?"
  Application observability        →  "Which requests, traces, or domain operations broke?"

An operator might see a target-health alarm first, confirm readiness failures in ECS, then use traces and structured logs to find the root cause. None of these replaces the others.

Monitoring coverage

Forge aligns CloudWatch alarms with the CDK stacks that own the resources. The table below describes what classes of infrastructure receive dashboards and alarms, not an exhaustive metric catalogue.

Runtime monitoring covers each deployed Fargate service and its associated load-balancer target group — the same services described in Health checks, but from the infrastructure perspective (target health counts, not dependency probe logic).

Intentionally out of scope

Forge focuses monitoring on Forge-provisioned, operator-actionable resources. The following are deliberately not covered by CloudWatch dashboards and alarms — either because AWS already manages availability, because another concern owns the signal, or because operators typically provide org-wide equivalents:

This is a baseline, not a landing zone. Mature operators extend coverage with AWS Config, GuardDuty, synthetic canaries, composite alarms, and org-wide observability — documented as common operator extensions in Observability architecture.

Infrastructure monitoring deploys with every cloud environment. Managed application observability has different defaults because it introduces additional infrastructure and cost. See Operations for deployment defaults.

Common operator extensions

Forge provisions CloudWatch alarms to SNS; routing and escalation are operator-owned:

Governance evidence (CloudTrail, load-balancer access logs) answers attribution and proof questions — not “page me because CPU is high.” Keep alarm routing separate from evidence archives.

Further reading

• Observability architecture — four-concern model and how infrastructure monitoring relates to application observability and governance evidence
• Application telemetry — metrics, traces, and logs exported to AMP, X-Ray, and CloudWatch Logs
• Health checks — readiness probes used by load balancers
• ADR-0026: Observability backend strategy
• ADR-0027: Governance evidence architecture
• Using Amazon CloudWatch alarms — AWS Documentation
• AWS Well-Architected Framework — Reliability pillar — AWS Documentation