- 最新
- 最多得票
- 最多評論
Hi, I agree with your diagnosis: your 2 messages (Sagemaker and S3) about Inaccessible host tend to say the vpc endpoint security group(s) is(are) too stringent and do not allow the establishment of a tcp session toward those service endpoints.
So, it's weird that "Allow All Traffic" does not improve the situation. Did yo check that your service endpoints were active in your vpc?
What you can try to better understand at this stage is to launch a (small) EC2 instance - with proper execution role to access the service endpoints - in your vpc to try to telnet the endpoints and see if you get more details about the issue.
I personally use this telnet method when I get similar issues: https://netbeez.net/blog/telnet-to-test-connectivity-to-tcp/
Best, Didier
I encountered this same scenario and this what was causing it for me.
TLDR: Make sure you have the correct security group specified in your sagemaker domain default user settings
When you create a Sagemaker Domain you can specify defaultUserSettings
. One of these settings is a list of security group ids.
The security group ids that you include in this list are the ones Sagemaker Studio will use communicate to resources inside of your VPC.
If you do not specify the security groups here Sagemaker will default to a security group it creates that has a single outbound rule allowing for NFS communication on port 2049 so the sagemaker service can access the data in your efs. Since it has no rules for communication anywhere else it will fail to access the interface endpoints you may have set up - com.amazonaws.us-east-1.sagemaker.api
being one of them.
Here is some CloudFormation showing which setting I am talking about:
"sagemakerDomain": {
"Type": "AWS::SageMaker::Domain",
"Properties": {
"AppNetworkAccessType": "VpcOnly",
"AuthMode": "IAM",
"DefaultUserSettings": {
"ExecutionRole": {
"Fn::ImportValue": "sagemakerRoleArn"
},
"SecurityGroups": [
{
"Fn::GetAtt": [
"defaultSagemakerSGF82111E2",
"GroupId"
]
}
]
},
相關內容
- AWS 官方已更新 1 年前
- AWS 官方已更新 1 年前