To call AWS Cloud Development Kit (CDK), we just need to provide the credentials, which is important; without that, it will not be able to call. If that particular thing is on UAT or production, it is easy, as we can provide that particular role to that EC2 machine, and then it will call. Rather than providing the .env files and all, we can call that. However, when we are developing these particular things on the local machine, we just need to provide the .env files, so we do not have any other option. In that condition, if a developer accidentally pushes those environment variables to other things such as GitHub or any SCM, there are chances that a particular hacker or an unintended person can access our whole infrastructure. AWS could provide something where these are the keys which you can use in development mode. For production and UAT environments, you can provide the role. For those particular development keys, they would not have that much access, but we currently have to do this on our own while creating all these things. That particular pain point regarding AWS Cloud Development Kit (CDK) is the only one I have; all other things are features.
AWS Cloud Development Kit (CDK) can be improved with the implementation of best practices for the constructs, such as using L2 and L3 constructs when available. They could include sensible defaults and best practices, and also improve organizing the code. Adding unit tests for constructs would be beneficial, along with enhancing security. Optimizing the development and deployment pipeline, improving configuration management, performance, and the documentation part with clearer comments explaining certain configurations would make it better.
Mid TypeScript/AWS Engineer at a comms service provider with 10,001+ employees
MSP
Top 10
Dec 27, 2024
There is room for improvement in the use of EventBridge and the initial setup of CDK, which can be a bit challenging. The IAM policies could be simplified to make the setup process more straightforward. AWS could also improve the transparency of Lambda's internal processes and provide more visibility into Lambda logs.
Independent Consultant at Ministerie van Infrastructuur en Waterstaat
Consultant
Feb 6, 2024
They could allow combining multiple languages, such as JavaScript and Python for the platform. At present, we can use only one language. There could be a possibility of building infrastructure offline, in a Docker instance, for debugging and testing purposes. At present, it takes two minutes to complete the deployment. However, it takes a lot of time to repeat the process in case of any mistakes or errors. Thus, it would be easier to test the code offline. We encountered a limitation with the WebSocket API in AWS, specifically regarding the absence of binary coding. It consumes a lot of bandwidth while transforming binary data to base64.
Chief- Operations : AMS and Senior Advisor at a tech services company with 501-1,000 employees
Real User
Nov 17, 2023
The primary issue we've encountered is pricing. Some customers find the pricing to be somewhat high. Additionally, there's a discrepancy between the promised resource utilization and the actual utilization. The resource utilization calculations don't align with the provided guidelines. So, the pricing and resource utilization calculations could be refined.
Learn what your peers think about AWS Cloud Development Kit (CDK). Get advice and tips from experienced pros sharing their opinions. Updated: August 2026.
AWS Cloud Development Kit (CDK) is a development platform that provides speed, seamless AWS service integration, and ease of deployment for various cloud applications, making it an efficient choice for infrastructure management and code-based deployments.CDK enhances cloud infrastructure management through features like multi-language support and integration with AWS services such as Lambda and DynamoDB. It improves workflow efficiency by reducing boilerplate configuration, allowing users to...
To call AWS Cloud Development Kit (CDK), we just need to provide the credentials, which is important; without that, it will not be able to call. If that particular thing is on UAT or production, it is easy, as we can provide that particular role to that EC2 machine, and then it will call. Rather than providing the .env files and all, we can call that. However, when we are developing these particular things on the local machine, we just need to provide the .env files, so we do not have any other option. In that condition, if a developer accidentally pushes those environment variables to other things such as GitHub or any SCM, there are chances that a particular hacker or an unintended person can access our whole infrastructure. AWS could provide something where these are the keys which you can use in development mode. For production and UAT environments, you can provide the role. For those particular development keys, they would not have that much access, but we currently have to do this on our own while creating all these things. That particular pain point regarding AWS Cloud Development Kit (CDK) is the only one I have; all other things are features.
AWS Cloud Development Kit (CDK) can be improved with the implementation of best practices for the constructs, such as using L2 and L3 constructs when available. They could include sensible defaults and best practices, and also improve organizing the code. Adding unit tests for constructs would be beneficial, along with enhancing security. Optimizing the development and deployment pipeline, improving configuration management, performance, and the documentation part with clearer comments explaining certain configurations would make it better.
There is room for improvement in the use of EventBridge and the initial setup of CDK, which can be a bit challenging. The IAM policies could be simplified to make the setup process more straightforward. AWS could also improve the transparency of Lambda's internal processes and provide more visibility into Lambda logs.
At the beginning, there were some issues regarding different plugins.
They could allow combining multiple languages, such as JavaScript and Python for the platform. At present, we can use only one language. There could be a possibility of building infrastructure offline, in a Docker instance, for debugging and testing purposes. At present, it takes two minutes to complete the deployment. However, it takes a lot of time to repeat the process in case of any mistakes or errors. Thus, it would be easier to test the code offline. We encountered a limitation with the WebSocket API in AWS, specifically regarding the absence of binary coding. It consumes a lot of bandwidth while transforming binary data to base64.
The primary issue we've encountered is pricing. Some customers find the pricing to be somewhat high. Additionally, there's a discrepancy between the promised resource utilization and the actual utilization. The resource utilization calculations don't align with the provided guidelines. So, the pricing and resource utilization calculations could be refined.
Using AWS CDK requires some knowledge of popular programming languages.