AWS Lake Formation Reviews

It primarily focuses on managing data permissions and entitlements and plays a crucial role in data control and governance within AWS. Once our data is stored in the cloud, we grant access to various users and applications for various purposes, such as analytics, reporting, or other data-driven activities. To manage these access patterns, we define permissions either by giving direct access to users or by creating roles via AWS IAM which can be configured within AWS Lake Formation.

It is seamlessly integrated within the AWS ecosystem, making it straightforward to manage access patterns for AWS-native services.

There are significant challenges when dealing with external applications, and vendors, or pursuing a hybrid cloud strategy because AWS Lake Formation is specific to AWS and does not integrate seamlessly with third-party services or other cloud providers. Another limitation is that Lake Formation might not offer out-of-the-box automated reporting, so you may need to create your solutions for tracking and reporting on permissions granted to users. It falls short when it comes to more granular access control, such as cell-level or row-level entitlements which is a significant drawback for organizations that require precise control over who can access specific rows of data.

I have been working with it for three and a half years.

You can reach out to AWS support through support tickets, and their response time is generally quite efficient. Typically, you can expect a response within a few hours, sometimes even on the same day, and at the most, by the next day. Also, if your organization is a significant AWS customer, you may have recurring calls with AWS account managers. These calls provide an opportunity to discuss service roadmaps and request specific features or enhancements for a service. AWS takes these requests seriously and may prioritize them on its roadmap, often opening a feature request and providing a timeline for its implementations. I would rate it seven out of ten.

Neutral

Our company has adopted both AWS and Azure, and we are looking for a solution that aligns strategically with our multi-cloud environment. While there are certain drawbacks with AWS Lake Formation, especially in terms of integration and fine-grained access control, it's essential to choose a solution that works cohesively in this hybrid cloud setup.

While AWS Lake Formation may have certain drawbacks, especially when it comes to integration with external systems and cell-level entitlements, it can still be a valuable choice if your use case is entirely AWS-native. In such cases, it's recommended to leverage the native AWS services available for managing data access and governance. However, if you're operating in a multi-cloud environment with Azure in the mix, it might be more beneficial to explore alternative solutions that offer better integration and more extensive access control capabilities. Overall, I would rate it six out of ten.

We use AWS Lake Formation typically for the data warehouse.

Customers choose to go with AWS Lake Formation because it's a cloud-based solution, and customers don't want to invest in on-premises hardware and software.

AWS Lake Formation's pricing could be cheaper.

I have been working with AWS Lake Formation for two years.

AWS Lake Formation is a stable solution.

AWS Lake Formation is a scalable solution. Our customers are mostly medium to enterprise-level businesses.

AWS Lake Formation's technical support is good and satisfactory.

Positive

AWS Lake Formation is a bit expensive.

My advice to users is that they first need to know what they want to achieve out of AWS Lake Formation. They need to have a clear-cut expectation from the solution, and they should involve a knowledgeable partner.

Overall, I rate AWS Lake Formation an eight out of ten.

We primarily use the solution in order to build infrastructure. It's basically for building network infrastructure.

The solution is quite good at handling analytics. It's done a good job at helping us centralize them.

We occasionally work with third-party libraries and they fail to integrate with this product effectively.

For the end-users, it's not as user-friendly as it could be. For example, if I have a Lake Formation return, once the code is in place, then working Lake Formation, or deploying Lake Formation code, still requires an engineer as opposed to being automated to the extent where end-users can actually deploy the whole infrastructure. 

The other issue is the debugging on the solution is not so straightforward. This should be simplified.

I've been using the solution for about a year and a half. It hasn't quite been two years. I haven't used it for that long.

The stability has come with time. At first, it wasn't so stable. We had some trouble and there was a bit of a learning curve. It gets easier and much more stable after you deploy.

While we are okay with the tooling, we're still working on the scaling process. Right now, there are no immediate challenges.

The solution isn't used by end-users. It's just used by our engineering staff who are working on the infrastructure.

Often, the people who handle the initial contact may or may not have the experience you need. It takes a while sometimes to get a person who can help. If it's a bigger issue, most of the time we have to engage the senior associates, and sometimes it takes time to find the right person. 

They also have hundreds of services there, and therefore, depending on where the problem is, finding the right person for the right service is an issue, due to the fact that, on the onset as an end-user, I don't know where the problem could be.

For example, while I may be working on the Lake at the surface, the problem may be on the Lake Formation. However, it could also be an EMR issue. Or it could be an issue in Spark, or it could be an issue within the EMR. and so on. That's why it's hard to get to the right person. You need to figure out the root cause then they need to figure out the best person to deal with the root cause.

That said, in terms of responsiveness, I don't have a problem with them. They do try to be helpful. It's just that the way the system is designed,getting to the right technical hand is complex and can take a while.

We didn't previously have another solution. Our instinct is to stick with internal solutions before moving out and looking for third-party options.

I would not describe the initial setup process as straightforward. There's definitely a learning curve involved. However, once you understand everything, it does get easier.

Once you deploy the solution, it stabilizes pretty fast and everything is a bit better from there onwards.

We're strictly customers of AWS. We're end-users.

I'm not sure which version of the solution we're using.

My advice to other organizations would be to not think of this solution as a one-time activity. It's an ongoing thing. It's a big change and there will new services and therefore it's constantly changing. You have to make sure that it's part and parcel of your everyday operations. 

The solution is pretty stable, or stable in the long run. However, every single day there is a need to grow the infrastructure, or there are new services being added externally and internally. You deploy more applications. You deploy more code. You deploy new libraries. You'll have to stay on top of everything to make sure it stays aligned with changes.

Overall, I would rate the solution at a seven out of ten.

We primarily use the solution as a cloud data warehouse.

The security of the solution is pretty good.

The solution has many features that are applicable to events such as audits.

The solution offers a lot of documentation online that users can use to help with troubleshooting or learning the systems. We rely on these materials when we need support.

The solution could make improvements around orchestration and doing some automation stuff on AWS front automation. It would be useful if we could use automation to build images and use hardened images which are CIS compliant. 

For AWS, currently, we are facing the challenge when previewing. On AWS, we have set up a scanner instance with a Nexus scanner. For some reason, the scanner instance has been set up on AWS so that if it's in one region or maybe if it is deployed on one subnet, the other subnet is not reachable within the same region. The scanner is not reachable to the different subnets. For example, if there is a subnet A where the scanner is deployed, and if we want to scan the subnet B within the same region, the scanner is not reachable due to the fact that it's in Subnet A. That's a problem we are currently facing and trying to troubleshoot that.

I've been using the solution for about three years at this point.

The solution is very stable. We haven't experienced issues such as bugs or glitches. AWS if very good, performance-wise. It doesn't crash or freeze.

I don't really have any insights into scaling the solution. It's not my area of expertise. I haven't attempted to scale yet, so I can't speak to its capabilities.

We have different project teams using the solution across the organization curently.

We've never dealt with technical support just yet. If there is a need, we might reach out. However, I can't speak to their level of service as we've never used them yet.

Each team in our organization has the option to work with whatever solution they like. Others might use Azure, for example. We, right now, use AWS which we find to be more agile and scalable.

Whichever solution a team chooses wold be based on their own unique requirements.

I wouldn't describe the initial setup as complex. It's pretty straightforward.

For deployment, you basically just download it and start working. It's easy.

We didn't really have a deployment strategy in place. We are at the start of all of this automation stuff. Right now, different project teams are using the cloud. It's new for them as well. We are trying to see how best we can try to get these images, hardened images, deployed in an automated fashion.

There is a dedicated team that handles maintenance on the product. Every product team is responsible for their own setup plan (subscription), and they maintain it. Maintenence might be five or ten people per 1,000 users. It depends on the team size. Eveyone is scattered all across the globe. It's pretty difficult to say which team is handling maintenance and how many are responsible for it as different teams are independantly using the solution. 

I'm not privvy to licesning information. I'm not sure how much the solution costs.

Our company does not have a business relationship with AWS. We're just a customer.

I'm not sure which version of the solution we're using.

The thing is that we are not forcing the end-user or the project team to deploy the application. They have the liberty to choose their own platform. Either they can go with AWS or they can go with Azure. Most of the projects which are deployed on non-Windows OS tend to go for AWS.

My area of expertise is more in the auditing of the security standards and maintaining the security requirements as per the industry standard. I'm more in a security architect kind of role.

Every solution has its pros and cons, however, for our purposes, this solution works quite well for us.

I'd rate it overall at eight out of ten.

In general, our clients use this as storage for raw data coming from systems. Our experience is that from the raw data you have to build up the data lake like a data warehouse. It's quite easy to pass from S3, for example, to Redshift. We used the data lake on AWS to store raw data and in some other cases to process advanced analytics. But the main use case here is storing raw data or archiving some data.

I would suggest using the entire ecosystem of AWS for this kind of job. The most important advantage of using AWS Lake Formation is its ability to connect the data lake to the other technologies in AWS. This is what I advise my clients.

Usually, you define an architecture in which you build up a data platform. The different technologies are different layers of that platform. My advice is to use the AWS technologies altogether. This can give a greater boost to the developer of the data platform.

In our experience what could be improved are not the support, performance or monitoring, but at a managerial level, the very expensive professional services of AWS. This could be an area of improvement for them. It's too expensive to acquire their support.

Generally, when you adopt a new technology, you always have to acquire a basket of professional services from the vendor. It's not only for system integrators, but also for clients because they always need some support. In this case, AWS is very expensive.

Something else they could improve is covering the end-to-end of the data platform with AWS products. They have to evolve. They have to improve the tools of data visualization a lot with QuickSight and ETS tool Glue. If they want to provide an end-to-end service with all the technologies to build up a complete data platform they need to improve these two technologies, these two solutions.

I have been using AWS Lake Formation for more or less one year.

We don't have our own projects. We are system integrators so we have projects based on customer requests.

AWS Lake Formation is stable.

AWS Lake Formation seems to be very scalable.

The initial setup is not so complex. There are no issues with deployment.

Also, because of the initial configuration, we usually ask for their support. Probably, for this reason we didn't have any trouble because they were able to do that. This is probably a reason the initial setup was not so complex.

On a scale of one to ten, I would give AWS Lake Formation a nine.

In our experience, this AWS solution is one of the main players now on the market in this field.

Additionally, because they can connect the offer in terms of infrastructure and software, sometimes you can combine the price and discount of infrastructure and software. This could be an advantage for clients.