# Managed Flink vs Lambda (Kinesis) — Decision Matrix (July 2026)

| Need | Prefer Managed Flink | Prefer Lambda + Kinesis |
| --- | --- | --- |
| Stateful joins / rolling windows across keys | Yes | Only with external store (DynamoDB/ElastiCache) — usually harder |
| Event-time correctness + late data | Yes (watermarks) | Fragile without custom state |
| CEP / multi-event patterns | Yes | Custom state machine |
| Simple filter / enrich / fan-out | Overkill | Yes |
| Sub-second autoscaling to zero | No (KPUs + orchestration KPU) | Better idle economics |
| Team skill | Java/Scala/PyFlink | Existing Lambda skills |

## Cost levers (verify on pricing page)

- **1 KPU** = 1 vCPU + 4 GB; plus **+1 orchestration KPU** per Flink application.
- Per-second billing with a short minimum (see Managed Flink pricing docs).
- Watch `millisBehindLatest`, checkpoint duration, and parallelism / ParallelismPerKPU.

## Artifact note

Pair with a fat-JAR deploy to S3 + `kinesisanalyticsv2` application update. Use Studio for exploration; promote to a standard application for production.