AWSLambdaFullAccess becomes AWSLambda_FullAccess

The AWS Toolkit for Visual Studio is great, when it works, but when it breaks, it’s a headache. The AWS Toolkit allows you publish your .NET code to AWS Lambda, with a API gateway already setup for you. It does this with a Cloud Formation stack under the hood, and this encapsulates the steps required to publish the Lambda, connect and configure the API gateway, and give you a public URL to play with.
Now, as of the 1st of March 2021, AWS deprecated the policy AWSLambdaFullAccess and replaced it with the similarly named AWSLambda_FullAccess – which is one underscore, but perhaps an hour of work to change.
First off, the error isn’t very helpful;
AspNetCoreFunctionRole | UPDATE_FAILED | 1 validation error detected: Value ‘AWSLambdaFullAccess‘ at ‘policyArn’ failed to satisfy constraint: Member must have length greater than or equal to 20 (Service: AmazonIdentityManagement; Status Code: 400; Error Code: ValidationError; Request ID: cec22c28-2aae-4de8-9ef7-51880070081d; Proxy: null) |
What does that mean, well, after googling, I found out that the policy had been deprecated, and set about editing the cloudformation stack.
So, I went into AWS, found the cloud formation stack, and tried to edit the template. But I couldn’t edit it, just make a copy of it (perhaps there is a better way here!, please leave a comment!) – and then I created a new Cloud Formation Stack, with a new name, but with the policy AWSLambdaFullAccess changed to AWSLambda_FullAccess
Back in Visual Studio, I clicked on the “Publish to AWS Lambda”, then selected the new stack from the drop down list, and pressed publish. Finally it worked!
It gave me a new API endpoint URL, which I didn’t want, and I had to reconfigure some permissions and the VPC that I had applied to the lambda manually.
Not a good experience at all, and I would really like to slap the AWS engineer that for making that change.
Following up from this post yesterday, I figured out how to update the existing Cloud Formation Stack, which importantly, allowed me to keep the same URL, and maintained the VPC and custom permissions.
So, First off, you go into the stack – press the Template tab, then View in Designer.
If you flick the language settings from JSON to YAML and back again, you get the JSON in a pretty format, so you can search for the AWSLambdaFullAccess and replace it with AWSLambda_FullAccess – Once finished, you can save the template locally, which you will upload again later., by pressing File > Save
Back in the Stack, press the Change Sets tab, and press Create Change set, select “Replace current template”, then “upload a template file”, and upload the file from the previous step. Press Next > Next > Next, then create change set.

Once you’ve done that, you’ll need to execute the change set.
However, if you’re like me, your stack will be in an invalid state, which you have to fix first, so you need to rollback the changeset, while ignoring the error that stopped the automatic rollback in the first place.
(from: https://aws.amazon.com/premiumsupport/knowledge-center/cloudformation-update-rollback-failed/)
If you want to skip FAILED resources during rollback, complete the following:
1. From the Stack name column, select the stack that’s stuck in UPDATE_ROLLBACK_FAILED status.
2. Choose Stack Actions, and then choose Continue update rollback.
3. In the Continue update rollback dialog box, expand Advanced troubleshooting.
4. In the Resources to skip – optional section, select the resources that you want to skip.
5. Choose Continue update rollback.
Once you’ve successfully rolled back the stack, then you can execute the change set, and your cloudformation stack should be back working again, and you can deploy again from Visual Studio.