Amazon Kinesis Data Streams
View on GitHubAmazon Kinesis Data Streams
Amazon Kinesis Data Streams is a regional, managed, shard-based streaming service for collecting and storing ordered, append-only data records in real time. Producers write records to streams and consumer applications read records, optionally using enhanced fan-out for dedicated throughput. It typically sits between data producers (applications, devices, logs) and stream-processing or storage services for real-time analytics, processing, and durable replay.
🗂 Resource Category
Analytics • Application Integration
🧠 Exam Memory Hook
Think: "Ordered, replayable, shard-based stream for real-time processing = Amazon Kinesis Data Streams"
📖 Ownership
Classification: AWS Managed Service
AWS responsibilities: AWS operates and maintains the underlying service platform, network, and physical infrastructure that runs Kinesis Data Streams, including the control plane, storage layer, and service endpoints. AWS secures and patches the service platform, underlying operating systems, hypervisor, and physical hosts that support the managed stream infrastructure. AWS is responsible for service availability controls, internal scaling of the control plane, and integration points it provides such as server-side encryption mechanics when using AWS KMS.
Customer responsibilities: The customer configures streams, shard counts, retention settings, encryption key usage and policies, producers and consumers, IAM permissions, monitoring and alarms, and data lifecycle integration with downstream services. Customers are responsible for application logic, client libraries, managing retry/backoff, consumer scaling, data schema, partition key design, and for implementing secure access, logging, and audit of their producers and consumers. Customers must monitor stream capacity and scaling needs and perform operational tasks like scaling shards (splitting/merging) when using the shard capacity model.
Patching responsibilities: AWS patches the physical infrastructure, hypervisor, managed service platform, and any managed runtime components that run the Kinesis service. The guest operating system is not applicable to customer-managed components of this service because the service platform is managed by AWS. The customer is responsible for patching and maintaining their producer and consumer applications, any client libraries they deploy, application runtimes, packaged dependencies, and any compute resources those applications run on.
🏗 Typical Architecture
💡 Top 5 Features
- Shard-based ordered, append-only stream for durable record ingestion.
- Support for multiple independent consumers with options for shared throughput or enhanced fan-out.
- Ability to replay and reprocess data within the configured retention window.
- Server-side encryption integration with AWS Key Management Service for encrypting stream data at rest.
- APIs for single and batch writes (PutRecord, PutRecords) and for retrieving records with shard iterators.
✅ Top 5 Use Cases
- Real-time ingestion of clickstream or event data for downstream stream processing and analytics.
- Low-latency telemetry and IoT data collection where consumers perform real-time transformations or alerting.
- Buffering and decoupling of event producers from consumers to allow independent scaling and replay.
- Feeding real-time analytics engines or machine learning scoring pipelines via Kinesis Data Analytics or custom consumers.
- Reliable transport for audit, log, or transaction events that require ordering and replay for debugging or compliance.
🏗 Architecture Placement
Amazon Kinesis Data Streams sits in the data ingestion layer as a regional, account-level streaming endpoint that receives records from producers (applications, devices, agents) and exposes them to stream consumers or downstream services. It commonly connects to consumers such as AWS Lambda, Kinesis Data Analytics, or Kinesis Data Firehose for processing, transformation, or delivery to storage. Placement is typically between event sources and processing/long-term storage systems and can be reached via public endpoints or VPC endpoints depending on network design. Streams are configured per region and per account.
🎯 Commonly Used With
- AWS Lambda
- Amazon Kinesis Data Firehose
- Amazon Kinesis Data Analytics
- Amazon CloudWatch
- AWS Identity and Access Management
🌍 5 Real-World Examples
- A financial trading system publishes market events to Kinesis Data Streams so analytics consumers can compute indicators and trigger risk alerts in near real time.
- An online media platform ingests user playback events to Kinesis Data Streams to feed real-time personalization and quality-of-experience monitoring.
- A telecommunications fleet of IoT devices sends telemetry to Kinesis Data Streams for low-latency processing and downstream archival via Firehose to object storage.
- An e-commerce platform streams order and checkout events into Kinesis Data Streams to decouple order intake from fulfillment and analytics systems.
- A healthcare monitoring solution collects device-generated patient telemetry into Kinesis Data Streams to enable streaming analytics and replayable data for investigations.
🎓 AWS Exam Clues
- Use when you need ordered, durable, replayable records with explicit shard capacity units.
- Choose Kinesis Data Streams when multiple independent consumers require access to the same stream data for real-time processing.
- Consider shard design and partition key strategy when low-latency and even distribution of load are exam decision factors.
- When retention and the ability to replay records are required for debugging or catch-up processing, Kinesis Data Streams is relevant.
- Monitor CloudWatch metrics and alarms for shard-level throttling and consumer lag as part of operational design decisions.
📝 Quick Revision
Amazon Kinesis Data Streams provides a managed, shard-based real-time stream for ingesting, ordering, and replaying event records; producers write records and consumers read them, optionally using enhanced fan-out. Use it for low-latency stream processing with multiple consumers; design considerations include shard capacity planning, partition key strategy, retention settings, encryption, and monitoring.
🏷 Keywords
shard • partition key • sequence number • enhanced fan-out • PutRecord • PutRecords • GetRecords • shard iterator • consumer • Kinesis Agent • server-side encryption • replay