Dashboard for monitoring the success rate of the ALB, covering individual APIs published under 14 API path rules. instead of overall sucess rate

Architectural Caveat & Alternative Solution

The proposed Target Group approach is excellent only if your 14 path-based routing rules map to 14 separate Target Groups. If multiple paths point to the same Target Group (e.g., a monolithic backend), standard CloudWatch metrics cannot distinguish between them.

If your paths share Target Groups, use this precise approach instead:

1. Enable ALB Access Logs

Activate Access Logs on your ALB and route them to an Amazon S3 bucket or a CloudWatch Log Group. These logs capture the exact request_url and matched_rule_priority for every single request.

2. Query via CloudWatch Logs Insights or Athena

Run a query to isolate the request count and 5XX error rates per path rule.

Example CloudWatch Logs Insights Query:

fields @timestamp, requestUri, status
| filter requestUri like /api/
| stats count(*) as TotalRequests, sum(status >= 500 and status <= 599) as ErrorCount by requestUri
| sort TotalRequests desc

3. Use CloudWatch Contributor Insights (Recommended for Dashboards)

• Create a Contributor Insights rule using your ALB Access Logs.
• Set the keys to request_url (or matched_rule_priority) and status.
• Filter for status >= 500.
• This generates a dynamic, real-time widget showing the 5XX error rate per individual API path, which you can pin directly to your main CloudWatch Dashboard.

To monitor individual API success rates for your Application Load Balancer with 14 path-based routing rules, you should leverage CloudWatch metrics with proper dimensioning and create a custom dashboard. Here's the approach:

1. Enable Detailed Metrics with Proper Dimensions

Application Load Balancer publishes metrics to CloudWatch that can be filtered using dimensions. The key is to use target group-level metrics rather than just load balancer-level metrics. Each of your 14 API paths should be associated with separate target groups, which will allow you to track metrics individually.

2. Key Metrics to Monitor Per API Path

For each API path/target group, monitor:

• Request Count: Total number of requests to each specific API
• 5XX Error Rate: Server-side errors for each API path
• 4XX Error Rate: Client-side errors indicating bad requests or configuration issues
• Target Response Time (Latency): Performance metrics for each API

3. Create a Custom CloudWatch Dashboard

Build a CloudWatch Dashboard that displays metrics for each of your 14 APIs. You can filter metrics by:

• LoadBalancer dimension for overall ALB metrics
• AvailabilityZone and LoadBalancer dimensions for zone-specific metrics
• Target Group dimensions to isolate metrics for each API path

4. Set Up CloudWatch Alarms

Configure alarms for each API path to detect issues:

• Alert when 5XX error rate exceeds acceptable thresholds (typically >0%)
• Alert when 4XX error rate exceeds thresholds (typically >1%)
• Monitor target response time to identify performance degradation
• Track unhealthy host counts per target group

5. Implementation Structure

Organize your monitoring by creating separate widgets in your dashboard for each API, showing:

• Request count trends
• Error rate percentages (both 4XX and 5XX)
• Latency metrics
• Success rate calculations (derived from total requests minus errors)

This approach provides granular visibility into each API's performance while maintaining the ability to view overall ALB health when needed.
Sources
Application Load Balancer (ALB) - Prebid Server Deployment on AWS
CloudWatch metrics for your Application Load Balancer - Elastic Load Balancing