-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
feat(ec2): add interface endpoint dynamodb #30162
Conversation
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.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request
. Additionally, if clarification is needed add Clarification Request
to a comment.
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
76d5467
to
162dda7
Compare
Add Eventbridge's missing VPC endpoints. I identified the missing VPC endpoints using the following procedure: 1. Retrieved a list of interface endpoints using the command below ```sh % aws ec2 describe-vpc-endpoint-services \ --filter Name=service-type,Values=Interface \ --query 'ServiceDetails[].[ServiceName,BaseEndpointDnsNames[0]]' \ --output json --region us-east-1| jq -r '.[] | @csv' // result "aws.api.us-east-1.bcm-data-exports","bcm-data-exports.us-east-1.vpce.amazonaws.com" "aws.api.us-east-1.freetier","freetier.us-east-1.vpce.amazonaws.com" "aws.api.us-east-1.kendra-ranking","kendra-ranking.us-east-1.vpce.amazonaws.com" "aws.api.us-east-1.qbusiness","qbusiness.us-east-1.vpce.amazonaws.com" // omit ``` 2. Obtained the differences by comparing the implementation with the list 3. Verified the differing endpoints exist in the documentation and added them to the implementation Ref: * https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html Note: * This PR doesn't include DynamoDB interface endpoint because #30162 already opened. ### Checklist - [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
### Issue # (if applicable) None ### Reason for this change There some interface vpc endpoints which is not supported by AWS CDK. ### Description of changes I've added the following VPC endpoints. - airflow.api-fips - airflow.env-fips - applicationinsights - emr-serverless-services.livy - pcs - pcs-fips - pi - pi-fips - q - rbin - service.user-subscriptions - ssm-fips - ssm-quicksetup - timestream-influxdb-fips - wellarchitected Since a PR has already been created for the following endpoints, this PR does not address them. - kinesis-streams-fips (#31350) - dynamodb (#30162) ### Description of how you validated changes These endpoints are obtained from AWS CLI. ```sh $ aws ec2 describe-vpc-endpoint-services --filters Name=service-type,Values=Interface Name=owner,Values=amazon --region us-east-1 --query ServiceNames ``` ### Checklist - [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
### Issue # (if applicable) None ### Reason for this change There some interface vpc endpoints which is not supported by AWS CDK. ### Description of changes I've added the following VPC endpoints. - airflow.api-fips - airflow.env-fips - applicationinsights - emr-serverless-services.livy - pcs - pcs-fips - pi - pi-fips - q - rbin - service.user-subscriptions - ssm-fips - ssm-quicksetup - timestream-influxdb-fips - wellarchitected Since a PR has already been created for the following endpoints, this PR does not address them. - kinesis-streams-fips (aws#31350) - dynamodb (aws#30162) ### Description of how you validated changes These endpoints are obtained from AWS CLI. ```sh $ aws ec2 describe-vpc-endpoint-services --filters Name=service-type,Values=Interface Name=owner,Values=amazon --region us-east-1 --query ServiceNames ``` ### Checklist - [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
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.
Thanks for your contribution, and sorry about the wait! Taking an initial look through the changes, I'm not sure about the new Private DNS behaviour being added. I left a comment below that I think should be addressed before moving forward with the rest of the changes.
@@ -613,6 +614,7 @@ export class InterfaceVpcEndpointAwsService implements IInterfaceVpcEndpointServ | |||
|
|||
/** | |||
* Whether Private DNS is supported by default. | |||
* If the interface endpoint doesn't support Private DNS, privateDnsDefault will be set false. |
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.
I'm a little skeptical about this behaviour. If we're only adding this in now, I assume it means that there are no other services out of the hundreds listed above which don't support private DNS. Is there any documentation we have to back up that claim?
If DynamoDB is the only service that doesn't support it, I'm curious what happens when we try deploying without these checks in place; what sort of errors get thrown (if any) and how does it look in the console? If there are other services that also don't support private DNS, what does their behaviour currently look like?
From the original issue, it seems like private connections might be supported anyways (documentation), but this could also be something separate.
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.
Private connections are supported, but private DNS is not supported for DynamoDB.
Document is here.
AWS PrivateLink for Amazon DynamoDB does not support the following:
- Private and Hybrid Domain Name System (DNS) services
I tried enabling private DNS through the Management Console and CloudFormation, but it resulted in an error.
Previously, similar restrictions existed for S3 interface endpoint, but resolved through an update.
Ref:
Currently, DynamoDB is the only service where private DNS cannot be used with interface VPC endpoints.
This is likely due to the fact that DynamoDB originally only had Gateway VPC Endpoint.
I think we could remove the logic that sets privateDnsDefault to false specifically for DynamoDB.
In this case, if privateDnsDefault is not specified, it defaults to true and results in a deployment error. However, deployment can succeed if privateDnsDefault is explicitly set to false.
Furthermore, since DynamoDB may support private DNS in the future, the process of setting the default to false might become unnecessary.
What do you think?
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.
If it fails at deploy time, I think it should be fine that we don't need the extra logic on our end. The error message also seems descriptive enough that users could figure out the source of the issue and resolve it on their end.
So going forward, I think we can scrap the getPrivateDnsDefault
method and the related documentation around it. It'd be nice to catch it earlier, but I don't think the added complexity is worth it, especially if this only applies to a single service.
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.
Thank you.
I have only added the DynamoDB interface endpoint and removed the methods.
I also added a unit test and an integ test for when privateDnsEnabled is set to false.
83de21e
to
30a970c
Compare
Pull request has been modified.
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.
Thanks for addressing the feedback! I think removing the privateDnsDefault
logic seems like a good way forward. Seems like the error message it throws at deploy time, "Private DNS can't be enabled because the service com.amazonaws.us-east-1.dynamodb does not provide a private DNS name.
" is descriptive enough that it'll direct people to private DNS as the issue, and they can just set privateDnsEnabled
to false to deploy successfully.
@@ -613,6 +614,7 @@ export class InterfaceVpcEndpointAwsService implements IInterfaceVpcEndpointServ | |||
|
|||
/** | |||
* Whether Private DNS is supported by default. | |||
* If the interface endpoint doesn't support Private DNS, privateDnsDefault will be set false. |
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.
If it fails at deploy time, I think it should be fine that we don't need the extra logic on our end. The error message also seems descriptive enough that users could figure out the source of the issue and resolve it on their end.
So going forward, I think we can scrap the getPrivateDnsDefault
method and the related documentation around it. It'd be nice to catch it earlier, but I don't think the added complexity is worth it, especially if this only applies to a single service.
Pull request has been modified.
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.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request
. Additionally, if clarification is needed add Clarification Request
to a comment.
Exemption Request: only added DynamoDB interface endpoint. I don't think it's necessary to add or update the README. |
@Leo10Gama |
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.
LGTM, thanks for the contribution!
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
@Mergifyio update |
✅ Branch has been successfully updated |
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). |
1 similar comment
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). |
Comments on closed issues and PRs are hard for our team to see. |
Issue # (if applicable)
Closes #29547
Reason for this change
Description of changes
Add DynamoDB interface endpoint and validation
Description of how you validated changes
Added unit tests and integ test.
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license