Amazon Kinesis Reviews

Amazon Kinesis is a service in AWS used for data ingestion. We pull data into Kinesis streams from various sources like OCS and then consume it for analysis and reporting.

I find almost all features valuable, especially the timing and fast pace movement. The best part is that there is no loss of data.

The price is not much cheaper. So, there is room for improvement in the pricing. 

I have been working with Amazon Kinesis for about 18 months. I have hands-on experience using and providing it.

The performance is quite good, and it's stable. Stability is okay. We didn't face any issues with stability.

It is a scalable solution. It has been in continuous use for two years. So, there are over 20,000 end-users of this solution.

The customer service and support are great. They have provided great assistance when needed.

The initial setup is not straightforward; it has medium complexity. It took almost two weeks to complete the implementation and coding.

Developers are required, along with release managers and other roles. There is a big team that works on the maintenance of the solution. 

The price is not much cheaper, but I can't say it's too expensive either. However, the customers do not have to pay any additional costs. 

I would definitely recommend using the solution. It's a great service, and it can be used wherever it's applicable in their model and architecture.

Overall, I would rate the solution an eight out of ten. 

We have utilized the solution for ingesting the data from different applications. For example, when people use a web server they send their weblogs, and clickstreams and the service provider wants to know how many users are currently using the site and what their areas of interest are, we use Amazon Kinesis which has the capability to enable the analytics and provide the information to them.

We also use Amazon Kinesis Data Firehose for putting the IoT data on the Kinesis Data Streams because the data has to be brought from on-prem to the cloud in order to perform the analysis.

The solution has improved our organization by saving time. Before launching the solution, the only thing we have to do is know the volume of the data and what is the frequency of the data we are going to receive. Based on that, we can configure the capacity of the Kinesis Data Streams, so it divides our requirements in terms of the shards or partitions. Unlike Kafka which works in partitions, Amazon Kinesis works in shards. This means the solution can handle thousands of requests per second for writing and reading. The writing capacity is one KB per request and the reading capacity is four KB per request.

The solution has the capacity to store the data anywhere from one day to a week and provides limitless storage for us. The data is time-stamped, and the data is in sequence, so we don't need to maintain the sequence or order of the data, and multiple consumers can reference the data in the Kinesis Data Streams simultaneously. Using the same data one application can perform Task A, and another application can perform Task B. 

The Kinesis Data Stream is integrated with Amazon CloudWatch where we can monitor all the requests of who wants to read information, what kind of APIs are being requested, what errors there are, who is producing them, and who are the data consumers. All the information is logged in one spot and this allows us to identify the problematic points easily.

The solution allows us to apply the security so the consumers can have access, based on the subscription they have.

Amazon Kinesis has a fan-out feature that allows us to increase the throughput when the number of consumers increases, instead of having to pull the data from the consumer side the information is posted by the solution itself.

The services which are described in the documentation could use some visual presentation because for someone who is new to the solution the documentation is not easy to follow or beginner friendly and can leave a person feeling helpless.

I have been using the solution for five years.

The stability is good as long as no configuration mistakes are made and the data source works properly.

The scalability is good but if for example, we only created one stream, then wanted to scale it further, we would have to continuously monitor using CloudWatch to ensure the shards are not getting overloaded, otherwise, we have to split the shards. We would have to merge the shards if it is under load. The implementation is only required once with some monitoring and after that, it is very easy to scale. The scalability has some limitations but there is also an on-demand option with a script so when we need to scale up the capacity we can and if we need to decrease the capacity, we can. We can also stop the service completely by scheduling it based on event triggers.

The technical support was not able to resolve the one issue we had.

Positive

The initial setup is straightforward and I give it an eight out of ten. The deployment takes around five minutes. 

We have to create our service using CLI Streams, or we can create using the console because we have to provide the configuration, including, what throughput we want, and how many reads and writes we want to be supported. Once we launch, we'll be charged monthly. Setup is very easy, we have to specify whether we want encryption of the data or not if it is accessible to everyone or not, and what kind of services are going to interact with the solution. In AWS, we have to specify, and then we have to provide the roles and policies based on the consumers.

The implementation is completed in-house.

The solution is worth the money because it is easier to set up, and since it is integrated with all the AWS services, we can manage the security, the monitoring requirements, and manage the audit information, much easier. 

The solution is costly. There is a fee to activate the service and even if it is not being used there is a monthly fee because they continue to maintain the service. If we want to retain the data for longer durations then we are charged the equivalent of Amazon S2 or S3 services. The fee is based on the number of hours the service is running. 

I give the solution a nine out of ten.

No maintenance is required for the solution because it is cloud-based.

The solution is available in all three zones, Amazon Kinesis is a good solution if a person wants scalability, availability, and durability of data. I recommend the solution to anyone already using AWS Amazon-managed Kafka service.

The solution provides real-time event streaming. 

From my experience, one of the most valuable features is the ability to track silent events on endpoints. Previously, these events might have gone unnoticed, but now we can access them within the product range. For example, if a customer reports that their calls are not reaching the portal files, we can use this feature to troubleshoot and optimize the system.

I suggest integrating additional features, such as incorporating Amazon Pinpoint or Amazon Connect as bundled offerings, rather than deploying them as separate services.

I have been using the product for a year. 

My company has four to five customers. The scalability of Amazon Kinesis has improved various data processing capabilities.

I am happy with the tool's customer support. 

Amazon Kinesis' deployment is easy. 

The tool's pricing is cheap. 

If you're considering using Amazon Kinesis for the first time, I would advise exploring their services. It can be useful for capturing real-time events, greatly benefiting your solution. I rate it a seven out of ten. 

To recover data and send it to the cloud. A few of our clients have Amazon Web Services and we use Kinesis to deploy the data to their mobiles and to their data processing system. Also to do data analytics.

The management and analytics are valuable features.

A snapshot from the stream of the data analytics I already have on the cloud. do a snapshot to stop the process and restart a few weeks later when I have more data or more availability of the client teams.

I have been using Amazon Kinesis for two years. 

The stability is a ten out of ten. 

We use cloud automation for deployment. We deploy the tags in minutes, and we can also use confirmation to test each part and test end-to-end use cases before we deploy them to the client. So we do everything with cloud automation, and it takes a few minutes to deploy a production environment.

The solution is cheap. 

Overall, I rate the solution an eight out of ten. 

We collect data from AWS IoT Core and then capture the stream in Amazon Kinesis. The data is then stored in S3 and shifted to Snowflake for analysis.

What I like about Amazon Kinesis is that it's very effective for small businesses. It's a well-managed solution with excellent reporting. Amazon Kinesis is also easy to use, and even a novice developer can work with it, versus Apache Kafka, which requires expertise.

My company found some Amazon Kinesis discrepancies, so it's looking forward to a more modernized solution from Apache Kafka.

One area for improvement in the solution is the file size limitation of 10 Mb. My company works with files with a larger file size.

The batch size and throughput also need improvement in Amazon Kinesis. The solution needs to be more open regarding the type of files for streaming and the streaming size. Amazon should not limit those aspects. It should be unlimited. If a company is ready to pay, why not make it unlimited?

What I want to add to Amazon Kinesis is modernization based on the container environment, where I can add containers and more workers. I also expect some human resources to be added and an SLA agreement with Amazon, if possible.

I've been using Amazon Kinesis for about one year, and I'm still using it.

Amazon Kinesis could be more stable. One of my clients rejected it, while some clients find it okay, stability-wise. I'd rate Amazon Kinesis stability as five out of ten.

I can rate Amazon Kinesis scalability according to the organization size and data load. For a small organization using the solution and Lambda with some transformation through AWS Glue, Amazon Kinesis is the best, scalability-wise. However, if you're dealing with a billion tuples, for example, the solution isn't as scalable, so I would go for Apache Spark or Apache Kafka to handle the load.

When I see that the processing takes longer than fifteen minutes with Lambda and the tenants fail, I use Apache Spark for processing, but that could take up to three or four days to be comparable to big data technologies.

I'd rate the scalability of Amazon Kinesis as four out of ten.

My company contacted some premium partners and technicians of Amazon Kinesis and found the technical support good, but with some limitations. I'd rate support a seven out of ten. Though it had limitations, the interaction with support was pleasant.

Neutral

In the future, my company plans to switch to Apache Kafka because it's very flexible and easier to manage. It's also easier to control and manage limits about topics. On the other hand, Amazon Kinesis has some limitations to its charts. It also has a 10 Mb limit to its file size, so if you have a 20 Mb file, you have to make it 10 Mb.

Amazon Kinesis is easy to set up, and it's a ten out of ten for me. Setting it up is a straightforward process.

My company set up Amazon Kinesis for the client.

If you ask a client about Amazon Kinesis pricing, the client usually says it's high. If you ask a business owner, the business owner would tell you that pricing for Amazon Kinesis is a little bit high. For each region, it's a little bit high.

There is a particular concern regarding Amazon Kinesis here in Pakistan because there's no zone in Pakistan. Amazon needs to develop zones here because Pakistan is the biggest country in the region after India. Amazon is losing a lot of business in Pakistan because there's no AWS zone here.

AWS also didn't accept my Pakistan credit card when I was trying to register with AWS. AWS should develop trust here in Pakistan and excellent AWS zones, so Pakistan businesses that want to purchase Amazon Kinesis won't need to depend on Singapore or India.

When I'm closing a deal with a new client, the client would ask, "Why do you need to sign up with a zone in India or Singapore to save data?" I don't have an answer to that question, so a workaround would be to develop on-premise environments for clients to save data.

Amazon Kinesis pricing is sometimes reasonable and sometimes could be better, depending on the planning, so it's a five out of ten for me.

Nowadays, my company works with AWS, Snowflake, Redshift, Amazon Kinesis, Firehose, Aurora, and Athena. In the future, my company plans to work with SAP HANA.

My rating for Amazon Kinesis is six out of ten.

My company is a user of Amazon Kinesis.

We are using Kinesis' third-party streaming engine. We are using the AWS cloud and are moving to Azure.

One of the best features of Amazon Kinesis is the multi-partition. 

Another valuable feature of Kinesis is that when it is down, and in the backup stage, the data is still available. 

Currently, Kinesis provides only seven days of retention support. It would be beneficial if this could be extended to upwards of 40 days or more. 

In the next future release, I would like to see a library that is Java-compliant. It would be beneficial if Amazon Kinesis provided document-based support on the internet to be able to read the data from the Kinesis site.

I have been using Amazon Kinesis for almost two years.

Amazon Kinesis is stable. I do not see any issues.

The solution is scalable. We have 20 team members using Kinesis.

We have not required support from Amazon.

The initial setup of Amazon Kinesis is easy. 

We have been looking for a streaming tool. We looked into Kafka, E-Hub, and Kinesis. Kafta is better than Kinesis as it has multiple cloud connectors. More features are available by default with Kafta.

Overall, I would rate Amazon Kinesis a seven out of ten.

We had real-time streaming of data and a very large volume of user activity. We applied machine learning to the data streams. So, Kinesis basically made sure that we got the data, and we didn't lose the data.

I'm not using it at my current organization. I used it at the last company. Kinesis replaced a whole tier of servers. So, we didn't need to have a server to catch the data and then send the data somewhere else. Kinesis was the input port for very large amounts of data.

What turns out to be most valuable is its integration with Lambda functions because you can process the data as it comes in. As soon as data comes, you'll fire a Lambda function to process a trench of data.

One thing that would be nice would be a policy for increasing the number of Kinesis streams because that's the one thing that's constant. You can change it in real time, but somebody has to change it, or you have to set some kind of meter. So, auto-scaling of adding and removing streams would be nice.

I'd like to see the size of a Kinesis message go to at least one megabyte per message. That would be nice, but that's an extreme case.

I have been using it since it came out in 2014.

It is stable.

It is scalable. In the previous company, it was customer-facing. So, there were hundreds of thousands of users. There were very large data volumes.

In this company, we'll probably use Kinesis. We haven't used it yet. We have some more projects that'll come along, and then we'll need it.

I was there when it was beta. They were pretty good then, and they're still pretty good. So, they were five out of five. They were right on top of it.

Positive

We didn't use any other solution for streaming data. 

It was pretty straightforward. I had one person who did all DevOps. It did not need a dedicated person.

We had seen an ROI. We wouldn't have been able to build the product without it.

It was actually a fairly high volume we were spending. We were spending about 150 a month.

There were some that we considered, but it was a little cruder.

To someone who would like to implement it, I would simply tell not to shove giant bricks in. Data has to be reasonably sized. A single Kinesis message is measured in K, not megabytes. It's not meant for gigantic things. There is a different strategy for streaming data.

I'd rate it at least a nine out of ten. It was very close to perfect.

Our primary use case of this solution is as an intricate part of our data pipeline to deal with all of our big data problems. The traffic in our industry is highly volatile. At any given time we could have 10,000 users, and five minutes later it could be 100,000. We need systems fast enough to deal with that elasticity of demand, and the ability to deal with all the big data problems. Volume, velocity, ferocity, things like that. That's where we use the Kinesis platform. They have different iterations of it. The normal Kinesis Stream, is a little bit more manual, but we use that for our legacy technology, and for the more recent ones, we use Kinesis Firehose.

We dynamically change some of our product offerings based on user interaction. We can respond faster to user behavior, rather than waiting for the data to be at rest. We run some analytics models, and can then react in real time.

When it comes to Kinesis Firehose, the most valuable feature is the auto-scaling. It does auto-sharing, auto-correction, things like that and responds dynamically. Secondly, it innately has all the features of our reliable data pipeline, allowing you to store raw documents and transform data on the fly. When data comes into the stream through Firehose, we can see it and analyze every single object, keep the raw objects, carry out some transformations on it in flight, and then put it at rest. It allows us to do some real time analytics using Kinesis Analytics. We do anomaly detection in flight as well. We receive any changes with regards to user patterns and behaviors, in real time because Kinesis allows that.

They recently expanded the feature sets, but when we were implementing it, it could only deliver to one platform. I'm not sure where it's at now but multiple platforms would be beneficial. I'd also like to have some ability to do first in, first out queuing. If I put several messages into Firehose, there's no guarantee that everything will be processed in the order it was sent. 

We've had no problems with stability and we implemented well over a year ago. 

The scalability of this solution is good. We are using it extensively with pretty much every single one of the flows.

The technical support could be improved. They tend to send you back to the documentation. 

We switched to Kinesis because of the technical complexity of the previous solution. In the previous solution, Ops would write feeds on the SQS queue, and then it required physical machines to connect, pull the data, transform it and write. That required three or four different technologies. Kinesis has removed a lot of technical complexity to the architecture.

The initial setup was straightforward. Both the user interface and the programmatic access is very intuitive. And again, it's not difficult, even non-technical people would be able to set it up. It took two people to implement. I was responsible for data architecture and we had a developer to transform the data inside. Deployment took less than an hour. The documentation was very helpful. 

We've been able to drop our costs for ingesting data by about 60 to 70%.

We didn't evaluate anything else because no other product offered that type of fast solution at the time. Whatever we looked at added technical complexity to the architecture.

It's important to think about how you are going to fix the end points that connect to your Kinesis files.

I would rate this solution a nine out of 10. 

I work in a gaming company that builds games for the global market. We use Amazon Kinesis to stream events. 

I have worked in companies that build tools in-house. They face scaling challenges. 

Amazon Kinesis should improve its limits. 

I have been using the product for a month. 

I rate the tool's stability a ten out of ten. 

My company has two to three users for Amazon Kinesis. 

I rate the tool's deployment a nine out of ten. Deployment takes one day to complete. 

The tool's entry price is cheap. However, pricing increases with data volume. 

I rate Amazon Kinesis a seven out of ten. 

We use the solution for streaming data, in simpler terms. For example, there is a backend application; we need to make that data available for analysis. On the backend side, we don't store the history. We get all the events regarding changes incrementally. If something changes, an event is generated. This is a convenient way to keep track of all the changes.

Amazon Kinesis is similar to Kafka, another type of streaming technology, which can be referred to as a queue service to exchange data. Setting Amazon Kinesis up is quick and easy; it only takes a few minutes to configure the necessary settings and start using it. In comparison, Kafka requires setting up a cluster, even if it is available in the cloud, which can be time-consuming. Amazon Kinesis has a user-friendly interface, making it easy to adjust and scale up the number of shards if needed. The cloud is especially useful when starting something new and not needing a lot of resources initially, but with the potential to upgrade later when there is a larger load. Although there is a cost associated with using the cloud, Amazon Kinesis is very flexible and can be easily adjusted when necessary, making it a great advantage.

Kinesis can be expensive, especially when dealing with large volumes of data.

I have been using the solution for two years.

The solution is stable and I don't recall any issues. Once we set the solution up, it usually works and we only investigate if we encounter a problem. However, if there is a large number of events to process, due to limited capacity for example with the shards, then some events may be delayed. This can be easily resolved by adjusting the configuration to provide more capacity.

The solution is scalable, but this also comes with a financial cost. If we want to increase throughput, we can simply increase the number of shards or adjust some config parameters, which can be done in a matter of minutes if we know how to do it. We can scale the solution almost without limitation.

There are a lot of details involved with the initial setup, so if we need something at the outset, we can set up the solution easily. However, the details are important since they are related to how much money we pay and we need to tailor the solution to our needs. If we want to do something more sophisticated, then we need to spend more time comprehending all the details. Initially, we can easily set something up, but eventually, we need to understand it better and adjust it more to our needs.

Cloud services are often cheaper in the beginning, but when the amount of data and needed resources grows, they cost more and more. In my opinion, it is sometimes simpler to use an existing service rather than having to maintain our own internal infrastructure. This way, we can focus on the things we are good at and can make money from, rather than having to employ people to support the infrastructure. In general, cloud services are very convenient to use, even if we have to pay a bit more, as we know what we are paying for and can focus on other tasks. However, if the scale is large, I would consider making changes depending on the situation.

I give the solution a nine out of ten. Amazon Kinesis is easy to use and configure, especially in the beginning. The solution is stable and I have not encountered any issues with it, nor am I aware of any. The solution is effective.

I don't see any missing features in Amazon Kinesis. I haven't spent a lot of time with this interface, as I have only configured it once. If any changes need to be made, I simply adjust Amazon Kinesis and it works. I only go into Amazon Kinesis if there is a need for a new data stream to be included or if the throughput needs to be increased. This doesn't happen very often.

Depending on the requirements, if there is a need to stream data and access it in real time, then I would consider Amazon Kinesis. However, if there is no need for real-time data access, then I will look for some other cheaper options. Companies such as Redshift, Snowflake, and BigQuery are developing databases with built-in streaming functionality. Depending on the case, this may be an option to consider. It also depends on the target; sometimes it is better to use the mechanisms available in the target tool. If we want to have the data on a stream or some hot stories, then I would consider Amazon Kinesis in that case.