fix(aws-apigateway): CloudWatch logging should be disabled by default (under feature flag)#21546
fix(aws-apigateway): CloudWatch logging should be disabled by default (under feature flag)#21546mergify[bot] merged 7 commits intoaws:mainfrom corymhall:corymhall/apigateway/disable-cloudwatchrole
Conversation
… (under feature flag) Currently when you create a RestApi cloudwatch logging is enabled by default. This will create an IAM role and a `AWS::ApiGateway::Account` resource, which is what is used to allow API Gateway to write API logs to CloudWatch logs. There can only be a single API Gateway account per AWS environment (account/region), but CloudFormation will not throw an error if you try to create additional accounts. Instead it will update the existing account with the new configuration. This can cause issues if customers create more than 1 RestApi. The following scenario is an example. 1. Create a single `RestApi` A new `AWS::ApiGateway::Account` and IAM role is created. 2. Create a second `RestApi` Another `AWS::ApiGateway::Account`/IAM role is created which _overwrites_ the first one. The first RestApi now uses the account/role created by this `RestApi`. 3. Delete the second `RestApi` The `AWS::ApiGateway::Account`/IAM role is deleted along with the second `RestApi`. The first `RestApi` no longer has access to write to CloudWatch logs. Because of this behavior, the correct thing to do is to disable CloudWatch logs by default so that the user has to create the global resource separately. This new behavior is behind a feature flag `@aws-cdk/aws-apigateway:disableCloudWatchLogs`. In addition, the default retention policy for both the API Gateway account and IAM role has been set to `RETAIN` so that existing implementations that do not use the feature flag can avoid the above scenario. The resources will be unmanaged, but existing RestApis will not break. closes #10878
| set to `false`. To change this default behavior you can enable the feature flag | ||
| `@aws-cdk/aws-apigateway:disableCloudWatchRole` |
There was a problem hiding this comment.
Double checking - is this how we want to phrase feature flagged defaults? All new apps will have the flag enabled and it might confuse people. Maybe it'd be better to directly call out that the FF in the first sentence?!
There was a problem hiding this comment.
Good point. Just pushed an update, let me know what you think or feel free to suggest different wording.
| export class Test extends cdk.Stack { | ||
| constructor(scope: cdk.App, id: string) { | ||
| super(scope, id); | ||
| const api = new apigateway.RestApi(this, 'my-api', { | ||
| retainDeployments: true, | ||
| }); | ||
| api.root.addMethod('GET'); // must have at least one method or an API definition | ||
| } | ||
| } | ||
|
|
||
| const app = new cdk.App(); | ||
| new IntegTest(app, 'cloudwatch-logs-disabled', { | ||
| testCases: [ | ||
| new Test(app, 'default-api'), | ||
| ], | ||
| }); |
There was a problem hiding this comment.
Is this not missing the FF in the context?
There was a problem hiding this comment.
All features flags are enabled by default for integration tests.
|
Might this be a good opportunity to update the integration tests to the new style? |
TheRealAmazonKendra
left a comment
There was a problem hiding this comment.
Updating the tests certainly isn't mandatory for this change, so giving approval either way, but adding do-not-merge just in case you want to do that first. If not, we can remove the label and let this merge.
I should have been the one to suggest this 🤣 |
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Currently when you create a RestApi cloudwatch logging is enabled by
default. This will create an IAM role and a
AWS::ApiGateway::Accountresource, which is what is used to allow API Gateway to write API logs
to CloudWatch logs. There can only be a single API Gateway account per
AWS environment (account/region), but CloudFormation will not throw an
error if you try to create additional accounts. Instead it will update
the existing account with the new configuration.
This can cause issues if customers create more than 1 RestApi.
The following scenario is an example.
RestApiA new
AWS::ApiGateway::Accountand IAM role is created.RestApiAnother
AWS::ApiGateway::Account/IAM role is created whichoverwrites the first one. The first RestApi now uses the account/role
created by this
RestApi.RestApiThe
AWS::ApiGateway::Account/IAM role is deleted along with the secondRestApi. The firstRestApino longer has access to write toCloudWatch logs.
Because of this behavior, the correct thing to do is to disable
CloudWatch logs by default so that the user has to create the global
resource separately. This new behavior is behind a feature flag
@aws-cdk/aws-apigateway:disableCloudWatchLogs.In addition, the default retention policy for both the API Gateway
account and IAM role has been set to
RETAINso that existingimplementations that do not use the feature flag can avoid the above
scenario. The resources will be unmanaged, but existing RestApis will
not break.
I've updated all the existing integration tests to use the old behavior by explicitly setting
cloudWatchLogs: true. I then added a new integration test for the new behavior.closes #10878
All Submissions:
Adding new Unconventional Dependencies:
New Features
yarn integto deploy the infrastructure and generate the snapshot (i.e.yarn integwithout--dry-run)?By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license