Data Scientist at a tech services company with 11-50 employees
Real User
Top 20
Sep 26, 2025
Regarding areas of AWS Lake Formation that could be improved or enhanced, I prefer not to answer, mainly because I do not believe that I would be the most valuable person to ask, as I have not used all of its different capabilities to the maximum to give an opinion. Regarding optimization of the governance aspect of AWS Lake Formation in the future, people in general would prefer not to work with multiple tools that do nearly the same thing. I would rather have a tool that is specialized for governance and that is its sole purpose. Rather than creating an additional hundred tools, optimizing a tool to have a centralized location to do governance would be beneficial. Then users would not need to search extensively to figure out varying capabilities. Of course, there are some edge cases such as AI, where governance and guardrails might require different solutions. The general scope or principle is if you incorporate IoT or a lake house or do machine learning orchestration, you would rather simplify the scope instead of complicating it with many different types of services.
Full Data Engineer at a financial services firm with 10,001+ employees
Real User
Top 20
Aug 29, 2025
I don't know any features that I would want to see included in the future releases of AWS Lake Formation. Making queries in SQL is a reality now, and in the future, it would be beneficial if AWS implements a feature where AI can provide better analytics, because nowadays AI can produce good analytics, but it's not ideal. If AWS introduces better analytics features in the future, I think it will be very beneficial.
I think AWS Lake Formation could improve by enforcing the least privilege by design, moving from ad hoc grants to role-based access controls. In Kafka, using one search, such as index-level rolling, can be enhanced, and in Spark Synapse, applying row and column-level security along with dynamic data masking for PHIs, as implementing temporary audit access for on-call or break-glass scenarios, are improvements I envision.
There is a specific issue when we list the tables and database in AWS Lake Formation regarding the UI. When we list tables, and to provide context, here and in many companies, we have numerous tables and schemas. This large amount of tables generates a long list. The UI of AWS Lake Formation is not very responsive. The UI has a lag when showing information, when clicking from one page to another, or when trying to find information. There is a search box at the top of the page, and when we type, searching for a sales table for instance, the response takes a long time. This complaint is not exclusive to AWS Lake Formation, but we observe this behavior in AWS Lake Formation as
If I could improve AWS Lake Formation, I would add more integrations with SageMaker. I would have built-in functions that provide statistics for the data when using the GUI, such as SageMaker Insights.
VP- Cloud Data/ Solution Architect at a financial services firm with 10,001+ employees
Real User
Oct 9, 2023
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.
Technical Head & Director - Data , AI & Robotics at a financial services firm with 10,001+ employees
Real User
Dec 30, 2020
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.
Head of Business Intelligence, Analytics and Big Data Service Line at a computer software company with 10,001+ employees
Real User
Nov 2, 2020
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.
Vice President Application Security North America at BNP Paribas
Real User
Top 20
Sep 23, 2020
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.
AWS Lake Formation is a service that makes it easy to set up a secure data lake in days. A data lake is a centralized, curated, and secured repository that stores all your data, both in its original form and prepared for analysis.
Regarding areas of AWS Lake Formation that could be improved or enhanced, I prefer not to answer, mainly because I do not believe that I would be the most valuable person to ask, as I have not used all of its different capabilities to the maximum to give an opinion. Regarding optimization of the governance aspect of AWS Lake Formation in the future, people in general would prefer not to work with multiple tools that do nearly the same thing. I would rather have a tool that is specialized for governance and that is its sole purpose. Rather than creating an additional hundred tools, optimizing a tool to have a centralized location to do governance would be beneficial. Then users would not need to search extensively to figure out varying capabilities. Of course, there are some edge cases such as AI, where governance and guardrails might require different solutions. The general scope or principle is if you incorporate IoT or a lake house or do machine learning orchestration, you would rather simplify the scope instead of complicating it with many different types of services.
I don't know any features that I would want to see included in the future releases of AWS Lake Formation. Making queries in SQL is a reality now, and in the future, it would be beneficial if AWS implements a feature where AI can provide better analytics, because nowadays AI can produce good analytics, but it's not ideal. If AWS introduces better analytics features in the future, I think it will be very beneficial.
I think AWS Lake Formation could improve by enforcing the least privilege by design, moving from ad hoc grants to role-based access controls. In Kafka, using one search, such as index-level rolling, can be enhanced, and in Spark Synapse, applying row and column-level security along with dynamic data masking for PHIs, as implementing temporary audit access for on-call or break-glass scenarios, are improvements I envision.
There is a specific issue when we list the tables and database in AWS Lake Formation regarding the UI. When we list tables, and to provide context, here and in many companies, we have numerous tables and schemas. This large amount of tables generates a long list. The UI of AWS Lake Formation is not very responsive. The UI has a lag when showing information, when clicking from one page to another, or when trying to find information. There is a search box at the top of the page, and when we type, searching for a sales table for instance, the response takes a long time. This complaint is not exclusive to AWS Lake Formation, but we observe this behavior in AWS Lake Formation as
There are areas that could be improved in AWS Lake Formation, and functionality that could be included in future releases.
If I could improve AWS Lake Formation, I would add more integrations with SageMaker. I would have built-in functions that provide statistics for the data when using the GUI, such as SageMaker Insights.
Not everybody can use AWS Lake Formation. You need to have data experience to use the product.
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.
AWS Lake Formation's pricing could be cheaper.
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.
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.
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.