| Service | Billed by | Estimated Monthly Cost (e.g., 100k requests) |
|---|---|---|
| AWS Lambda | Number of requests + execution time (GB-seconds) | ~ $2–$5 |
| AWS X-Ray | Number of trace segments (measured per invoke) | ~ $2.50 / 1 million trace segments |
| CloudWatch Logs | GB of stored logs + log event ingestion | ~ $0.50–$1 / GB |
| CloudWatch Custom Metrics | $0.30 / metric / month (after first 10 free metrics) | ~ $0.60 for 2 metrics |
| CloudWatch Alarms | $0.10 / alarm / month | ~ $0.10–$0.50 |
| SNS (email alerts) | Free for email (SMTP) | $0 |
| Component | Notes | Cost |
|---|---|---|
| Lambda MonitorFunction | 100,000 invocations/month, avg duration 600ms, 128MB RAM | ≈ $2.50 |
| X-Ray | One trace per invoke (100k trace segments) | ≈ $2.50 |
| CloudWatch Logs | Logs for latency + EMF custom metrics | ≈ $1–$2 (depends on log volume / JSON size) |
| Custom Metrics: ProcessingTime | Written in EMF format → billed per metric name | ~$0.30–$0.60 |
| Alarm CloudWatch + SNS | One alarm, one email topic | ~$0.10 |
| Estimated total / month | ~ $6–$8.50 / month |
| Issue | Optimization Suggestion |
|---|---|
| High X-Ray cost | Enable tracing only for critical Lambdas (sampling rate 10–20%) |
| Too many logs | Use log level filters (e.g., log latency only if > 500ms) |
| Expensive custom metrics | Combine multiple metrics into one EMF log if possible |
| Logs stored for too long | Set Log Group Retention to 7 or 14 days |
| Too many frequent CloudWatch queries | Create summary dashboards instead of running ad-hoc queries |
| High Lambda GB-seconds usage | Reduce timeout or memory where unnecessary |
AWS Cost Explorer
AWS CloudWatch Billing Alerts
X-Ray + CloudWatch Metrics
Lambda Tags
cost-center, env, etc., for better cost classificationBased on tools like AWS Cost Explorer and metrics from X-Ray & CloudWatch, the system currently costs around $6–$9/month for 100,000 requests. Most costs come from Lambda execution, X-Ray tracing, and CloudWatch logs/metrics. Optimization measures include adjusting sampling rates, reducing log size, shortening log retention periods, and consolidating metrics.
| Observation from X-Ray & CloudWatch | Suggested Optimization |
|---|---|
| ⏱️ Average latency > 600ms | 🔁 Use caching to reduce processing time — e.g., cache DB/API results via Redis or S3 |
| 🚀 Random latency spikes (800–1000ms) | 📦 Increase memory (CPU scales with RAM) — try 256MB or 512MB instead of 128MB |
| 📉 High ProcessingTime variability | 🔄 Offload heavy tasks to async processing — e.g., logging/email → SNS or SQS + Lambda |
| 🔁 Frequent repeated Lambda invocations | ⛔ Add throttling or deduplication at the API caller side |
| 📊 Stable metrics but slow response | ⚙️ Investigate external dependencies (e.g., slow APIs, RDS, network latency…) via traces |
| 📉 Long “Initialization” time | 🛠️ Reduce cold starts — keep warm or avoid large global variables outside handler |
There are many ways to optimize your system. One highly effective method is to trigger automatic resource scaling upon alerts — such as increasing memory when latency thresholds are breached, helping your app perform more reliably and efficiently.