For the most recent update on ongoing service disruptions affecting the AWS Middle East (UAE) Region (ME-CENTRAL-1), refer to the AWS Health Dashboard. For information on AWS Service migration, see How do I migrate my services to another region?
When I connect to the SageMaker Studio Lab top page from several VM environments or CURL, it returns HTTP 403. Is this expected behavior?
When I try to connect to SageMaker Studio Lab's top page ( https://studiolab.sagemaker.aws/ ), that is, before logging in, I encounter HTTP 403. Is it specification? How do I avoid this behavior?
Of course, my environments usually work well, and I never encounter the same problem when I connect to other websites, such as https://dev.aws .
The information when I tried it is as follows:
URL: https://studiolab.sagemaker.aws/
From Google Compute Engine, Via Microsoft Edge:
From my home (Tokyo, Japan), Via CURL:
% curl ifconfig.io
138.64.82.105
% curl -Lv https://studiolab.sagemaker.aws/
* Host studiolab.sagemaker.aws:443 was resolved.
* IPv6: (none)
* IPv4: 18.65.207.117, 18.65.207.47, 18.65.207.72, 18.65.207.128
* Trying 18.65.207.117:443...
* Connected to studiolab.sagemaker.aws (18.65.207.117) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/cert.pem
* CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES128-GCM-SHA256 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
* subject: CN=studiolab.sagemaker.aws
* start date: Sep 23 00:00:00 2023 GMT
* expire date: Oct 22 23:59:59 2024 GMT
* subjectAltName: host "studiolab.sagemaker.aws" matched cert's "studiolab.sagemaker.aws"
* issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M01
* SSL certificate verify ok.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://studiolab.sagemaker.aws/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: studiolab.sagemaker.aws]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.6.0]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: studiolab.sagemaker.aws
> User-Agent: curl/8.6.0
> Accept: */*
>
< HTTP/2 403
< server: CloudFront
< date: Tue, 18 Jun 2024 05:03:11 GMT
< content-type: text/html
< content-length: 919
< x-cache: Error from cloudfront
< via: 1.1 3a7ba6126d80753b7016dac95efbb35c.cloudfront.net (CloudFront)
< x-amz-cf-pop: NRT57-P3
< x-amz-cf-id: 0U9Ku45-FWA3Vy9UsVIvR8ZSf6UdsbvEI1hKl-ZPgHaco2rXWkrRow==
<
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>403 ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
Request blocked.
We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
<BR clear="all">
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
<BR clear="all">
<HR noshade size="1px">
<PRE>
Generated by cloudfront (CloudFront)
Request ID: 0U9Ku45-FWA3Vy9UsVIvR8ZSf6UdsbvEI1hKl-ZPgHaco2rXWkrRow==
</PRE>
<ADDRESS>
</ADDRESS>
* Connection #0 to host studiolab.sagemaker.aws left intact
</BODY></HTML>
% curl -LI https://dev.aws
HTTP/2 301
content-length: 0
location: https://aws.amazon.com/developer/
date: Tue, 18 Jun 2024 05:09:32 GMT
server: AmazonS3
x-cache: Hit from cloudfront
via: 1.1 e2880d2d728b87f682842f2e2f05968c.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT57-P4
x-amz-cf-id: VDxO5djPyTs2HTOplIuM4WZhtIeIUiAoMAgy0nvY3w9OpXUYmXfTYw==
age: 6
HTTP/2 200
content-type: text/html;charset=UTF-8
server: Server
date: Tue, 18 Jun 2024 05:09:37 GMT
x-amz-rid: H49SYMBGMG5JSAG26Q1A
set-cookie: aws-priv=eyJ2IjoxLCJldSI6MCwic3QiOjB9; Version=1; Comment="Anonymous cookie for privacy regulations"; Domain=.aws.amazon.com; Max-Age=31536000; Expires=Wed, 18 Jun 2025 05:09:37 GMT; Path=/; Secure
set-cookie: aws_lang=en; Domain=.amazon.com; Path=/
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
strict-transport-security: max-age=63072000
x-amz-id-1: H49SYMBGMG5JSAG26Q1A
last-modified: Fri, 07 Jun 2024 15:36:29 GMT
x-content-type-options: nosniff
vary: accept-encoding,Content-Type,Accept-Encoding,User-Agent
x-cache: Miss from cloudfront
via: 1.1 a0c8ca5c55854408aacaabfb864516d0.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT57-P1
x-amz-cf-id: UvQVGExr4Hf-xhQGMC98JsCKd1NR7xEBcVTb6QISmOepBpM4v5U3fA==
- Newest
- Most votes
- Most comments
Hi,
You need to respect the SigV4 signing protocol in your REST requests for them to succeed: https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html
Those pages propose a simple solution via CURL; https://how.wtf/aws-sigv4-requests-with-curl.html and https://stackoverflow.com/questions/76234432/use-temporary-credentials-to-sign-aws-sigv4-request-using-curl
Best,
Didier
I also successfully connected to the same website from EC2 via Microsoft Edge, but I couldn't via CURL. It seems It is not a client
or source IP address problem.
Thank you for mentioning the document about the SigV4 signing protocol when you connect via REST web API. However, in this case, opening the top page using web browsers returns 403. It should not be a web API call. Additionally, https://studiolab.sagemaker.aws/ is the top page of SageMaker Studio Lab. So, you should not need any authentication to view the introduction to the service.