Amazon Kinesis Review
We used Kinesis as the basis for information distribution for a mission-critical business operation. We expected a huge amount of mini …
Amazon Kinesis
Amazon Kinesis
Starting at $0.01 per GB data ingested / consumed
View PricingOverview
What is Amazon Kinesis?
Amazon Kinesis is a streaming analytics suite for data intake from video or other disparate sources and applying analytics for machine learning (ML) and business intelligence.
Recent Reviews
Using Kinesis to stream billions of messages in a day, over millions of connected devices on the field
Amazon Kinesis is being used to stream telemetry data from millions of connected devices on the field - helping to drive command and …
Don't confuse Kinesis with a Queue system.
We currently use Kinesis as a trigger for Amazon Lambda functions, however we're working at switching back to SQS since Lambda now works …
Pricing
Amazon Kinesis Video Streams
$0.00850
Cloud
per GB data ingested / consumed
Amazon Kinesis Data Streams
$0.04
Cloud
per hour per stream
Amazon Kinesis Data Analytics
$0.11
Cloud
per hour
Entry-level set up fee?
- No setup fee
Offerings
- Free Trial
- Free/Freemium Version
- Premium Consulting/Integration Services
Product Details
- About
- Tech Details
What is Amazon Kinesis?
Amazon Kinesis Technical Details
| Deployment Types | Software as a Service (SaaS), Cloud, or Web-Based |
|---|---|
| Operating Systems | Unspecified |
| Mobile Application | No |
Comparisons
Compare with
Reviews and Ratings
(24)Attribute Ratings
Reviews
(1-3 of 3)Companies can't remove reviews or game the system. Here's why
September 01, 2020
Amazon Kinesis Review
CEO (Chief Executive Officer)
Global Bestlogistics Systems S.A. de C.V. (Information Technology & Services, 1-10 employees)
We used Kinesis as the basis for information distribution for a mission-critical business operation. We expected a huge amount of mini events reporting information between a Iot of devices, databases, geo info systems, and web sites, as well as reporting (business intelligence). Kinesis was used as the messaging pipeline (nowadays streaming) that glued everything together.
- Integrating with other Amazon services
- Scaling requests
- Totally serverless platform
- Simple management
- Extended fan-out is complicated to manage.
- Documentation is confusing.
- VPC integration
Amazon Kinesis is a great replacement for Kafka and it works better whenever the components of the solution are AWS based. Best if extended fan-out is not required, but still price-performance ratio is very good for simplifying maintenance.
I would go with a different option if the systems to be connected are legacy, for instance in the case of traditional messaging clients.
I would go with a different option if the systems to be connected are legacy, for instance in the case of traditional messaging clients.
42.22222222222222%
4.2
- Real-Time Data Analysis
- N/AN/A
- Visualization Dashboards
- N/AN/A
- Data Ingestion from Multiple Data Sources
- 90%9.0
- Low Latency
- 90%9.0
- Integrated Development Tools
- 90%9.0
- Data wrangling and preparation
- N/AN/A
- Linear Scale-Out
- 60%6.0
- Machine Learning Automation
- N/AN/A
- Data Enrichment
- 50%5.0
- Lower the cost of implementation.
- Good scaling up
- Simple integration, especially with Lambda
Kinesis is oriented to streaming in a scalable way large volumes of information in real-time. Glue is more an ETL so it is not well suited for real-time applications while Beanstalk is more a simple container platform. Lambda could do the job but it would require a lot of programming to accomplish the same as Kinesis. In fact, our solution employed the four elements for different tasks but using Kinesis as the message bus.
The documentation was confusing and lacked examples. The streams suddenly stopped working with no explanation and there was no information in the logs. All these were more difficult when dealing with enhanced fan-out. In fact, we were about to abort the usage of Kinesis due to a misunderstanding with enhanced fan-out.
October 16, 2019
Using Kinesis to stream billions of messages in a day, over millions of connected devices on the field
Verified User
Executive in Information Technology
Consumer Goods Company, 10,001+ employees
Amazon Kinesis is being used to stream telemetry data from millions of connected devices on the field - helping to drive command and control use cases and also sensor data for performance monitoring. Our volume is billions of messages per day, real-time, with aggressive requirements on response and processing time. All messages are stored in a big data structure and also two-way communication with a mobile app.
- Processing huge loads of data
- Integrating well with IoT Platform on Amazon
- Integration with overall AWS Ecosystem
- Scalability
- Improve integration with AWS Lambda
- Some duplicate records coming from the stream
Perfect for real-time data processing and streaming. Also, there's no need for any specific setup - you just start using it immediately and it easily integrates with the rest of AWS capabilities (like Redshift), although integration with Lambda could be better. You can make your overall analytics landscape way simpler with Kineses even if you have non-Amazon solutions like Tableau. It all integrates really well!
100%
10.0
- Real-Time Data Analysis
- 100%10.0
- Data Ingestion from Multiple Data Sources
- 100%10.0
- Low Latency
- 100%10.0
- Integrated Development Tools
- 100%10.0
- Data wrangling and preparation
- 100%10.0
- Linear Scale-Out
- 100%10.0
- Significantly reduced the cost of our IoT platform, compared to other Cloud providers.
- Better user experience.
- Enabled real "real-time analytics."
The main benefit was around set up - incredibly easy to just start using Kinesis. Kinesis is a real-time data processing platform, while Kafka is more of a message queue system. If you only need a message queue from a limited source, Kafka may do the job. More complex use cases, with low latency, higher volume of data, real time decisions and integration with multiple sources and destination at a decent price, Kinesis is better.
When needed, Amazon engineers are accessible and provide a fast response. Documentation is good and has been improving a lot over the past couple of years.
August 22, 2018
Don't confuse Kinesis with a Queue system.
Verified User
C-Level Executive in Information Technology
Computer Software Company, 1-10 employees
We currently use Kinesis as a trigger for Amazon Lambda functions, however we're working at switching back to SQS since Lambda now works with SQS directly. We simply used Kinesis as a temporary method of plumbing requests from one Lambda function to another.
We also use it as a byproduct of using DynamoDB Streams, but only in so far as that's used under-the-hood to link changes from DynamoDB to a Lambda trigger.
We also use it as a byproduct of using DynamoDB Streams, but only in so far as that's used under-the-hood to link changes from DynamoDB to a Lambda trigger.
- Link DynamoDB change events directly to Lambda
- Fast streaming of events
- Easy to "tail" changes/latest events
- Not a queue system, so little visibility into "backlog" if there is any
- Confusing terminology to make sure events aren't missed
- Sometimes didn't seem to trigger Lambda functions, or dropped events when a lot came in
It's great for big data applications, where it's not as important to make sure each event is processed, but you're more looking for overall analytics and speed is more important than absolute detail. It's added quite a few features like analytics and other tools specifically designed around big data, but it's not the same thing as a queue system.
Originally we were forced into using Kinesis since Lambda didn't support SQS directly, but now that there is native SQS support for Lambda, we'll be switching almost all of our implementation over to use that instead. Kinesis has its strengths, but monitoring and error retry logic is not one of those.
Originally we were forced into using Kinesis since Lambda didn't support SQS directly, but now that there is native SQS support for Lambda, we'll be switching almost all of our implementation over to use that instead. Kinesis has its strengths, but monitoring and error retry logic is not one of those.
- Caused us to need to re-engineer some basic re-try logic
- Caused us to drop some content without knowing it
- Made monitoring much more difficult
- We eventually switched back to SQS because Kinesis is not the same as a Queue system
- Amazon Simple Queue Service (SQS)
Actually we didn't select Kinesis, we were forced into using it because SQS wasn't yet supported by Lambda. Unlike Kinesis, SQS supports both FIFO and standard queues which let us control order of events processed, as well as handle retry logic, failover logic, and set up CloudWatch Alarms when we have too many events in our backlog. It also lets us know when something didn't process properly and we can alert DevOps to that issue and/or retry the processes automatically.
With SQS, we have much more visibility then we ever did with Kinesis. This is very important to our use cases, as we aren't processing millions of events per second, but for us every event is very important.
With SQS, we have much more visibility then we ever did with Kinesis. This is very important to our use cases, as we aren't processing millions of events per second, but for us every event is very important.