Financial Services Industry - Incident Detection and Response Alarming Best Practices
4 minute read
Content level: Intermediate
0
The intention of this documentation is to provide the building blocks to create critical CloudWatch alarms which are fit for onboarding to Incident Detection and Response. It contains specific alarm best practices for AWS Services commonly used in the Financial Services Industry.
Overview
Financial services organizations use AWS to power payment processing, trading platforms, banking applications, and regulatory reporting. End users expect instant transactions with zero data loss. "Down" means failed payments, halted trades, or regulatory violations.
Operational characteristics for Incident Detection and Response:
- Steady-state traffic during market hours — Trading and payment volumes are predictable during business hours. Static thresholds work well; anomaly detection catches after-hours anomalies.
- Zero transaction loss tolerance — A dropped payment or failed trade has direct financial and regulatory consequences.
- Sub-100ms latency SLOs — Trading and real-time payment systems require tight latency thresholds compared to other industries.
Baseline Alarms
For alarm configurations (metric names, thresholds, periods, statistics), see the individual IDR recommended AWS service articles linked below. This page identifies which services matter for financial services workloads and why.
Critical Path Architecture
Financial services workloads typically have two distinct critical paths:
Path 1 — Transaction Processing (Payments / Trading)
Client --> API Gateway / ALB --> Compute (ECS/EKS/Lambda)
--> Transactional Data Store
|
+--> Message Queue (settlement)
Path 2 — Real-Time Data Ingestion (Market Data / Event Streaming)
Data Feed --> Streaming Service (Kinesis/MSK) --> Compute (Lambda/ECS)
--> Low-latency Data Store --> API Gateway (consumer APIs)
Critical Path Services
| Service | Role in Workload | Why It Matters |
|---|---|---|
| API Gateway | Entry point for banking APIs and partner integrations | Single point of failure for all inbound transactions |
| Elastic Load Balancer | Load balancing for transaction services | Distributes traffic to compute tier; failure = all users impacted |
| ECS | Transaction processing compute (containerized services) | Capacity exhaustion causes transaction timeouts |
| EKS | Alternative compute layer for microservices | Pod/node failures degrade transaction throughput |
| RDS | Ledger database, transaction records | Unavailability or replication lag = data inconsistency, failed writes |
| DynamoDB | Session state, Global Tables for multi-region consistency | Throttling or errors block real-time lookups; replication lag breaks consistency |
| Kinesis Data Streams | Market data ingestion, event streaming | Processing lag means stale data driving trading decisions |
| Amazon MSK | High-throughput streaming for trading data | Offline partitions or consumer lag = missed market events |
| SQS | Settlement queues, async transaction processing | Queue backlog = delayed settlements, reconciliation failures |
| Lambda | Event processing, data transformation | Errors or throttles block transaction pipeline stages |
Industry-Specific Threshold Considerations
| Service | Consideration | Reason |
|---|---|---|
| ALB / API Gateway | Tighter latency thresholds than default | Trading and payment SLOs often require sub-100ms; default thresholds are too loose |
| RDS | Lower replication lag tolerance | Regulatory requirement for data consistency across regions; stale reads = compliance risk |
| DynamoDB | Lower replication latency tolerance for Global Tables | Multi-region consistency critical for active-active banking platforms |
| Kinesis / MSK | Lower iterator age / consumer lag tolerance | Real-time market data; stale data drives incorrect trading decisions |
| SQS | Lower message age tolerance | Settlement transactions have regulatory deadlines; delayed processing risks compliance violations |
Reference Architectures
Industry-Specific Operational Notes
- Market hours — Trading platforms see peak load during market open/close (e.g., 09:30–16:00 ET for US equities). Alarm thresholds should account for predictable daily peaks.
- End-of-day batch processing — Settlement and reconciliation jobs run after market close. Queue depth and processing latency spike predictably during these windows.
- Multi-region DR requirements — Regulators often require active-active or rapid failover across regions. Replication lag alarms are compliance-critical, not just operational.
- Change freeze windows — Many financial institutions enforce deployment freezes during market hours. Alarms that fire during these windows require different escalation paths.
- Language
- English
No comments
