Route table (in private subnet) won't change by adding VPCE as destination for aws secrets manager. Tried with new SG too (not using default SG). Any idea?
Based on the comments.
Secrets Manager (SM) uses VPC interface endpoints . This is new generation of endpoints, as compared to VPC gateway endpoints for S3 and DynamoDB. The new generation does not modify route tables (RTs). In contrast, the gateway endpoints do modify RTs specified when creating these endpoints.
For seamless work with the interface endpoints, it is important that the VPC has enableDnsHostnames
and enableDnsSupport
enabled , as well as private DNS for the endpoint. In addition, security group of the endpoint usually needs to be adjusted to allow connections on port 443.
Recently I removed all NAT Gateways which originally allowed my private subnets to connect to the internet (including the Secrets Manager). I assumed that the NAT Gateway was a security vulnerability, expensive infrastructure and not required for private instances to contact the AWS Secrets Manager. I was wrong. My ECS task failed, and stated that the Secrets Manager resource could not be accessed.
I recommend using the AWS VPC Reachability Analyzer to debug these network issues, it helped me.
This will enable you to verify if the EC2 instance you launched in the private subnet can contact the VPC Endpoint (eg. Secrets Manager).
Now that you have a means to quickly verify reach-ability, here are some steps that you might need to take in order to ensure your private subnet can contact AWS services like the Secrets Manager. Please consult AWS documentation as I may have outdated information.
com.amazonaws.${AWS::Region}.secretsmanager
and use the appropriate value for the AWS region
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.