-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(aws-apigateway): CloudWatch logging should be disabled by default (under feature flag) #21546
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this not missing the FF in the context?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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). |
… (under feature flag) (aws#21546) 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. 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 aws#10878 ---- ### All Submissions: * [x] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) ### Adding new Unconventional Dependencies: * [ ] This PR adds new unconventional dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-new-unconventional-dependencies) ### New Features * [x] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)? * [x] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)? *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
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.
RestApi
A new
AWS::ApiGateway::Account
and IAM role is created.RestApi
Another
AWS::ApiGateway::Account
/IAM role is created whichoverwrites the first one. The first RestApi now uses the account/role
created by this
RestApi
.RestApi
The
AWS::ApiGateway::Account
/IAM role is deleted along with the secondRestApi
. The firstRestApi
no 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
RETAIN
so 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 integ
to deploy the infrastructure and generate the snapshot (i.e.yarn integ
without--dry-run
)?By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license