Hello, I’m having an issue with the cloud formation resources in a CDK project. I’m calling the project resource directly using the CloudFormation cdk lib, (which is a 1-1 to the Cfn template) the status is stuck as CREATE_IN_PROGRESS until reaching timeout and writes to the error output as Internal Failure.
I’m positive my credentials and permissions are correct because I’m using them as a CLI call to create them and it succeeds.
Are you able to get any logging of the process? As as I understand it all CF resources, including ours, should work as level 1 CDK constructs and there are no known bugs with the project resource. I’ll see if we can look into this on our side too and try to reproduce.
It would be great to learn more about your use case. If you’d be willing to share please let me know.
In regards to logging, the only output I would get regarding the project resource was the Internal Failure after timing out the loading bar during deploy.
Hi,
I have the exact same problem with cdk deployment of MongoDB Atlas resources (MONGODB::ATLAS::PROJECT). The deployments gets stuck in CREATE_IN_PROGRESS and fails after a while with “Internal Failure”. Would be great if you could share some insights, what am I missing?
Hi David_Boschmann, thanks for your comment. There are a few possibilities that may cause this error which I have highlighted below. If these don’t unblock you directly, feel free to create a new issue in our GitHub repo and can have someone help you further.
Activate the 3rd party extension for MONGODB::ATLAS::PROJECT in each AWS region and from each AWS account that you wish to deploy from
Ensure you have sufficiently strong AWS IAM Activation Role attached to this 3rd party extension. For sample IAM Role see here
Ensure your activated 3rd party public extension matches name exactly to MONGODB::ATLAS::PROJECT (you may need to delete private extension if this namespace is already occupied)
Ensure your MongoDB Atlas Programmatic API Keys (PAKs) being used with CloudFormation have sufficiently strong permissions (Organization Project Creator or Organization Owner)
Ensure your MongoDB Atlas PAKs have correct IP Address / CIDR range access, for testing purposes you can with caution open keys to all access by adding “0.0.0.0/1” and “128.0.0.0/1”
Thanks a lot.
The problem were missing activation role permissions (for some reason AdminAccess seems to be not sufficient).
I have another question about step 5, since I don’t want to open the mongodb to 0.0.0.0/1 for production. Can I somehow determine which IP/IP-range will be used during cdk deployment?
Hi David, keep in mind that AWS CDK gets synthesized into AWS CloudFormation on your behalf. So you will need to determine IP Address / CIDR Range that CloudFormation is using to deploy your MongoDB Atlas clusters and other resources.
AWS has a large pool of IP addresses that are used by its services, and these IP addresses can change frequently as new resources are added and old resources are retired. AWS does not publish a list of specific IP addresses that are used by CloudFormation or other services.
Instead, AWS provides a list of IP address ranges that are used by its services which varies by each AWS region. The list of IP address ranges is updated weekly and is available on the AWS IP Address Ranges page: AWS IP address ranges - AWS General Reference.
Lastly, given you mentioned you are seeking to deploy your AWS CDK resources into production I would in addition contact AWS / your AWS rep to help provide additional guidance on this matter as well. Hope this helps.
Just curious if anyone else has determined the best avenue for this. My assumption is that I need to get the ip address that is being used by cloudformation to create the database and use that dynamically in the ipAddress whitelist each time. Yet because I am not finding anything on the web concerning my assumption as the solution nor anything within the awscdk-resources-mongodbatlas and AtlasBasicPrivateEndpoint, i fear I am wasting my time. From what I understand this ipAddress is only regarding the initial deploy. Yet no one would want to open 0.0.0.0/1 in production as the work around and I believe there should be better guidance from MongoDB on this matter.
Stumbled upon the same issue. Fixed by adding “resources.cloudformation.amazonaws.com” to my CDK execution role Trusted entities AssumeRolePolicyDocument