Demo:


This is an example of a page a customer would create and host on their own intranet using LightPane.
Using provided templates and discovery tools, a page like this can be built in two to three hours.


The infrastructure data below is live — discovered from a real AWS account.


Back to the demonstrations homepage

Customer-hosted page — ACME Corp Intranet

ECommerce Web App — Application Status

This page provides a live view of all AWS infrastructure components supporting the ECommerce Web App production environment. It is intended as the first stop during incident response: rather than navigating the AWS console service by service, this page surfaces the operational state of every component in a single view.

Data is retrieved directly from AWS at page load. Each table below reflects the current state of the environment at the time you opened this page. Refresh the page to get an updated view.

Application Profile

Application Information


ApplicationECommerce Web App
EnvironmentProduction
Primary Regioneu-west-2 (London)
ArchitectureThree-tier web application (CDN → ALB → EC2 → DynamoDB)
Critical PathCloudFront → WAF → ELB → EC2 (web/app) → DynamoDB (cart/orders)
Application OwnerPlatform Engineering Team
RunbookSee Section 8 for escalation contacts

The application serves customer-facing retail traffic. The critical user journey runs through the CDN and load balancer to the EC2 application tier, with DynamoDB providing low-latency storage for shopping cart, session, and order data. Lambda functions handle asynchronous workloads including order confirmations, inventory updates, and image processing. S3 and CloudFront together serve all static assets and product media.

Expected Infrastructure Components


The following table defines the expected steady-state for this application. During an incident, compare what is shown in the discovery sections below against these expectations to identify which component may be the source of degradation.

Layer AWS Service Expected Count Region Notes
CDN CloudFront 2 Global Storefront distribution + media/assets distribution
Security WAF (Regional) 1 eu-west-2 Attached to the application load balancer
Security WAF (CloudFront) 1 Global (us-east-1) Attached to the CloudFront storefront distribution
Load Balancing ELB (Application) 1 eu-west-2 Internet-facing ALB; must be active
Compute EC2 3 minimum eu-west-2 Auto-scaling group across 2 AZs; all must be running
Serverless Lambda 6 minimum eu-west-2 Order, notification, inventory, image, search, and auth functions
Storage S3 4 minimum eu-west-2 / global Assets, product images, order exports, application logs
Storage EBS Volumes 3 minimum eu-west-2 One per EC2 instance; all must be in-use
Database DynamoDB 3 eu-west-2 cart, sessions, orders; all must be active
Networking VPC 1 eu-west-2 Application VPC
Networking Subnets 4 minimum eu-west-2 2 public + 2 private (one per AZ)
Networking Internet Gateway 1 eu-west-2 Must be attached to the application VPC
Networking NAT Gateways 2 eu-west-2 One per AZ for private subnet outbound access; must be available

Application Health Analysis


The following table shows analysis of the live discovery data.

This service supports filtering on any discovered attribute(s) for a service, counts of the result set and alert severity.

CloudWatch Alarms


This panel shows the current state of CloudWatch Alarms across the application's infrastructure. It is designed to answer "what is currently breaching its threshold?" during an incident — using the thresholds you have already defined, not arbitrary metric values.

Alarms are sorted by state (ALARM first, then NO DATA, then OK). The Billing Alarms section shows spend alerts in the same view. For this demo we are using mock data timed to the incident scenario.


CloudTrail Analysis


This pane shows analysis of the CloudTrail logs of AWS API requests. This helps with understanding "what changed?" during an incident.

For this demo we are using mock data. The live service is built and the ability to support filter by time and by service is on the roadmap.


Cost Summary


Month-to-date spend, budget status, top services by cost, and any cost anomalies detected by AWS. This panel uses amortised costs from Cost Explorer so upfront Reserved Instance and Savings Plans payments are spread evenly — making month-over-month trends meaningful.

For accounts within an AWS Organisation, costs reflect what is attributed to this member account only. For authoritative billing use the AWS Cost Management console. For this demo we are using mock data consistent with the incident scenario.


2. CDN & Security Layer

All inbound traffic enters through CloudFront before reaching any application infrastructure. The WAF rules attached to the CloudFront distributions and the application load balancer provide protection against common web exploits, bot traffic, and rate-based attacks.

During an incident: if customers cannot reach the site at all, check the CloudFront distribution status and whether the associated WAF ACL is present. A distribution with status: InProgress indicates a recent deployment is still propagating globally.

CloudFront Distributions

Expected: 2 distributions, both Deployed and enabled: true.

WAF Web ACLs

Two WAF ACLs are expected: one regional (protecting the ALB) and one global (protecting CloudFront). The regional ACL is shown below.


3. Web & Application Tier

Customer requests that pass through CloudFront and WAF are routed to the application load balancer, which distributes traffic across EC2 instances in the auto-scaling group. The EC2 instances run both the web frontend and the application API layer.

During an incident: check that the load balancer state is active and that EC2 instances are in the running state. If fewer than 3 instances are running, the auto-scaling group may be failing to launch replacements, which warrants investigation of the launch template and instance health checks.

Load Balancers

Expected: 1 Application Load Balancer, state: active, scheme: internet-facing.

EC2 Instances

Expected: 3 or more instances, all state: running, spread across at least 2 availability zones.

4. Serverless Functions

Lambda functions handle asynchronous and event-driven workloads: order confirmation emails, inventory level updates, product image resizing, search index refresh, and customer authentication token management. These functions are invoked by SQS, DynamoDB Streams, and scheduled EventBridge rules.

During an incident: if orders are being placed but confirmation emails are not being sent, or if the product catalogue appears stale, the relevant Lambda function may have a deployment error or a failed execution. Check that the expected functions are present and note the last_modified date — a very recent deployment may coincide with the start of the incident.

Lambda Functions

Expected: 6 or more functions covering order processing, notifications, inventory, image handling, search, and authentication.

5. Storage

Application storage spans two AWS services. S3 buckets hold static web assets, product images, customer order exports, and application logs. EBS volumes are attached to EC2 instances and provide the operating system and application storage for each server.

During an incident: if the site is loading without images or static assets, check that the S3 buckets are present and the CloudFront origin points to the correct bucket. If an EC2 instance has entered a degraded state, check that its EBS volume is in-use and not available (detached).

S3 Buckets

Expected: 4 or more buckets — static assets, product images, order exports, and application logs.

EBS Volumes

Expected: 3 or more volumes, all state: in-use. An available volume indicates the EC2 instance it was attached to has been terminated.

6. Database Tier

DynamoDB provides the primary data store for customer-facing application data. Three tables are in use: cart (active shopping carts), sessions (authenticated user sessions), and orders (order records). All three must be in ACTIVE status for the application to function correctly.

During an incident: a DynamoDB table in any state other than ACTIVE will cause the relevant part of the application to fail. A table in UPDATING state is undergoing a provisioned capacity change and should return to ACTIVE shortly. A table in CREATING or DELETING state warrants immediate investigation.

DynamoDB Tables

Expected: 3 tables (cart, sessions, orders), all status: ACTIVE.

7. Network Infrastructure

The network layer is typically the most stable part of the infrastructure. The components shown here — VPC, subnets, internet gateway, and NAT gateways — rarely change during normal operations. However, they are relevant during network-level incidents: if EC2 instances in the private subnets cannot reach external services (e.g. payment APIs, email providers), the most likely cause is a NAT gateway in a degraded state.

During an incident: NAT gateway issues are a common cause of “outbound connectivity from private resources is broken” incidents. Both gateways must be available. A NAT gateway in deleting or failed state should be treated as a P1 incident.

VPCs

Expected: 1 application VPC, state: available.

Subnets

Expected: 4 or more subnets — 2 public and 2 private, spread across 2 availability zones. All must be state: available.

Internet Gateways

Expected: 1 internet gateway attached to the application VPC.

NAT Gateways

Expected: 2 NAT gateways, one per availability zone, both state: available. These provide outbound internet access for EC2 instances and Lambda functions in the private subnets.

8. Incident Escalation

If you have identified a degraded or failed component, use the contact matrix below to escalate to the appropriate team. Severity is defined as follows:

P1 — customer-facing impact affecting checkout or login;
P2 — degraded performance or partial feature loss;
P3 — background processing impacted with no immediate customer-facing effect.
Layer Team On-Call Contact Escalation Path Severity
CDN / WAF Platform Engineering platform-oncall@example.com PagerDuty: Platform-Engineering-P1 P1 / P2
Load Balancer / EC2 Platform Engineering platform-oncall@example.com PagerDuty: Platform-Engineering-P1 P1
Lambda Functions Application Development dev-oncall@example.com PagerDuty: App-Dev-P1 P2 / P3
S3 / EBS Platform Engineering platform-oncall@example.com PagerDuty: Platform-Engineering-P1 P1 / P2
DynamoDB Platform Engineering platform-oncall@example.com PagerDuty: Platform-Engineering-P1 P1
Networking (NAT / VPC) Network Operations netops@example.com PagerDuty: NetOps-P1 P1 / P2

AWS Console Access

This page provides a read-only operational view. To make changes to any of the resources shown — for example, to restart an EC2 instance, modify a security group, or update a Lambda function — you must use the AWS Management Console, AWS CLI, or your deployment pipeline. Do not make manual changes to production resources without following the change management process.

-->