I have a aws cognito user group configured to my serverless.yml. Whenever I do a serverless deploy, it will try to create the same user pool domain even though it already exist, hence returning me the error of:
[aws-cognito-idp-userpool] domain already exist
The only workaround is for me to delete the user pool domain every time I want to do a serverless deploy from the AWS UI. Anyone faced this issue before?
I believe there's no way to skip it,
Check this - https://github.com/serverless/serverless/issues/3183
You can try to break the serverless.yaml file into multiple files and deploy them separately for easier management,
So use the file only to create/deploy resources you need to freshly create.
The serverless.yaml will get converted into the vendor-specific Code to Infra service file,
eg. CloudFormation for AWS
Hope this helps
This is actually a CloudFormation issue vs. a Serverless issue. I ran into it in my Serverless app, BUT had my UserPool* resources independently defined in the resources section of the serverless.yml file. I changed the Domain Prefix and that requires the resource to be recreated. Here's the issue: CloudFormation always creates a resource first before deleting the old one, which blocks the new domain from being associated with the User Pool.
I've seen this behavior with other resources and the recommended behavior is to:
1. Blank out the resource from the template
2. Update the stack (deletes resource)
3. Restore the resource in template
4. Update the stack (creates a new one vs. replace).
This way you still leverage your automation tools without going to the console. Not perfect, and it'd be more preferable if there was a way to force the replacement sequence in CloudFormation. If your setup has Serverless generating the resource, then deleting via the console may be your only option.
Related
I have two CDK/Cfn stacks which instantiate application load balancers with SSL certificates. I'm using DNS validation which the CDK manages by creating a Lambda function which requests and validates the certificates.
Unfortunately, those Lambda functions were manually deleted and now when I try to update my CDK resources, CloudFormation attempts to replace these Lambdas but fails because they no longer exist.
I wish that CloudFormation would behave like Terraform and just say "oh that thing I need to replace isn't there, nbd I needed to replace it anyway, so let's carry on" but it does not.
Not sure how to get out of this jam. Any help is appreciated.
The easiest fix to this drift is redeploying your CDK app with the deleted resource temporarily removed (e.g. commented out). CloudFormation will "delete" the already deleted resource, bringing the template back into sync with the deployed configuration. Then add back the resource to your app and deploy again. Problem solved.
There's a complication in your case. The missing Lambda function is being constructed indirectly by a higher-level CDK construct. Removing the L2/L3 parent will destroy more resources than just the Lambda. If you want to avoid this collateral damage, you can use escape hatch syntax and the node.tryRemoveChild method to surgically remove the missing Lambda only.
You have to import them back to CloudFormation. In TF it is same, and you also import resources into TF.
As described in the documentation, I think CloudFormation will update with no interruption just by changing to add a tag.
In my case, another team uses terraform to add tag resources with generic tags, and my team uses CloudFormation to update the application-specific tags. Does this cause replacement...?
Also, this only occurred for limited resources such as security groups.
Does anyone know anything about this issue?
Cloudformation is a Jealous Tool - in otherwords, if it doesn't control the Resource in entirety it will overwrite changes, assuming that the changes are in a location it thinks it has to update.
In order for CloudFormation stacks not to do work that is not needed they generate ChangeSets - indicating what resources need updating/rebuilding/ect. If you don't change anything in the template (or your cdk stack) then the ChangeSet won't update that resource cause nothing needs to change. Depending on the resource (and it varies from service to service) sometimes changes made outside of CloudFormation control (by either other services like Terraform or by manual changes in the console - both of which are referred to as 'Drift') dont get overwritten by the stack updating (most common I can think of is API gateway - adding / deleting resources or methods doesn't always get re done by a redeploy of the stack.
However, for things like tags, yes - it will overwrite any changes made in there at any time and reapply the tags as of the moment it deploys - (again, depending on the Service) often even if there are no other changes to deploy for that given resource. I suspect the reason for this is because of the way AWS uses tags on the backend to sort and search resources.
Your best bet is to pick one service and do everything with it.
Each of these two tools will overwrite the tags the other created. You can configure Terraform to ignore certain tags However I'm not sure you can configure CloudFormation to ignore any tags. I think CloudFormation will always delete tags that it doesn't manage. In general it's not going to work well using both CloudFormation and Terraform to manage the same resources.
We're (mostly happily ;)) using the AWS CDK to deploy our application stack to multiple environments (e.g. production, centralized dev, individual dev).
Now we want to increase the security by applying the least privilege principle to the deployment role. As the CDK code already has all the information about which services it will touch, is there a best practice as to how to generate the role definition?
Obviously it can't be a part of the stack as it is needed to deploy the stack.
Is there any mechanism built in to the CDK (e.g. construct CloudFrontDistribution is used thus the deployment role needs to have the permission to create, update and delete CloudFrontDistributions - possibly even after the CloudFrontDistribution is mapped to only do that to that one distribution).
Any best practices as how to achieve that?
No. Sadly there isn't currently (2022-Q3) a way to have the CDK code also provide a IAM policy that would grant you access to run that template and nothing more.
However, everything is there to do it, and thanks to aspects it could probably be done relatively easily if you wanted to put in the leg work. I know many people in the community would love to have this.
You run into a chicken and an egg problem here. (We encounter a similar issue with Secret Manager and initializing secrets) pretty much the only solution I've found that works is a first time setup script that uses an SDK or the CLI to run the necessary commands for that first time setup. Then you can reference that beyond there.
However, it also depends on what roles you're taking about. Cdk deploy pretty much needs access to any given resource you may be setting up - but you can limit it through users. Your kept in a secret lock box root admin setup script can setup a single power user, that can then be used for initial cdk deploys. You can set up additional user groups that have the ability to deploy cdk or have that initial setup create a cdk role that cdk deploy can assume.
I am exploring backing up our AWS services configuration to a backup disk or source control.
Only configs. eg -iam policies, users, roles, lambdas,route53 configs,cognito configs,vpn configs,route tables, security groups etc....
We have a tactical account where we have created some resources on adhoc basis and now we have a new official account setup via cloud formation.
Also in near future planning to migrate tactical account resources to new account either manually or using backup configs.
Looked at AWS CLI, but it is time consuming. Any script which crawls through AWS and backup the resources?
Thank You.
The "correct" way is not to 'backup' resources. Rather, it is to initially create those resources in a reproducible manner.
For example, creating resources via an AWS CloudFormation template allows the same resources to be deployed in a different region or account. Only the data itself, such as the information stored in a database, would need a 'backup'. Everything else could simply be redeployed.
There is a poorly-maintained service called CloudFormer that attempts to create CloudFormation templates from existing resources, but it only supports limited services and still requires careful editing of the resulting templates before they can be deployed in other locations (due to cross-references to existing resources).
There is also the relatively recent ability to Import Existing Resources into a CloudFormation Stack | AWS News Blog, but it requires that the template already includes the resource definition. The existing resources are simply matched to that definition rather than being recreated.
So, you now have the choice to 'correctly' deploy resources in your new account (involves work), or just manually recreate the ad-hoc resources that already exist (pushes the real work to the future). Hence the term Technical debt - Wikipedia.
I'm new to a large AWS deployment where stuff is mostly deployed through CloudFormation (and some through Terraform). But there are always cases where something has been deployed manually and not through code. Is there a reliable way to quickly figure out if a resource (say, an EC2 instance) already existing in the deployment was deployed through IaC or manually? A CloudFormation-specific answer will be good enough for now.
Going through literally hundreds of CloudFormation stacks manually and looking for the resource is not an option.
You can identify the resources created by cloudformation. Cloudformation applies few default tags as mentioned here
aws:cloudformation:logical-id
aws:cloudformation:stack-id
aws:cloudformation:stack-name
You can run a script to check whether the resource contain one/all of these tags to update your count.
Offical documentation on resource tags
Unfortunately looking at an AWS resource you don't see how it got created. While some resources might have been tagged by CloudFormation indicating that they got created by a CloudFormation stack, that's only valid for a subset of resources.
The only reliable way to figure out whether or not a resource got created via a CloudFormation stack is to go through all CloudFormation stacks and check whether or not the resource in question is a part of it. While that might be cumbersome when doing manually, it's also something you can automate using the AWS CLI.