Amazon Route53에서 전달을 설정하려고합니다. 마지막 DNS 서비스 (Nettica)를 통해 요청을 "aws.example.com"으로 "https://myaccount.signin.aws.amazon.com/console/"으로 라우팅 할 수있었습니다.
이 기능은 Route53에서 지원됩니까?
Nettica는 어떻게 이것을 달성합니까? 특수 A, CNAME, PTR 또는 TXT 레코드를 삽입합니까?
Amazon Route53에서 전달을 설정하려고합니다. 마지막 DNS 서비스 (Nettica)를 통해 요청을 "aws.example.com"으로 "https://myaccount.signin.aws.amazon.com/console/"으로 라우팅 할 수있었습니다.
이 기능은 Route53에서 지원됩니까?
Nettica는 어떻게 이것을 달성합니까? 특수 A, CNAME, PTR 또는 TXT 레코드를 삽입합니까?
답변:
Saurav가 설명한 것과 똑같은 문제가 발생했지만 Route 53 및 S3 이외의 솔루션이 필요했습니다. 내가 한 일을 자세히 설명하는 내 블로그에 대한 방법 안내서를 만들었습니다.
여기에 내가 생각해 낸 것이 있습니다.
Amazon S3 및 Amazon Route 53에서 사용 가능한 도구 만 사용하여 http://url-redirect-example.vivekmchawla.com 을 https의 "MyAccount"라는 별칭으로 지정된 AWS 콘솔 로그인 페이지로 자동 전달하는 URL 리디렉션을 생성 하십시오. : //myaccount.signin.aws.amazon.com/console/ .
이 안내서에서는 Amazon URL뿐만 아니라 모든 URL로 URL 전달을 설정하는 방법을 설명합니다. 특정 폴더 (예 : "/ console")로 전달하는 방법과 리디렉션 프로토콜을 HTTP에서 HTTPS로 (또는 그 반대로) 변경하는 방법을 배우게됩니다.
S3 관리 콘솔을 열고 "버킷 생성"을 클릭하십시오.
버킷 이름을 선택하십시오. 이 단계는 정말 중요합니다! 전달을 위해 설정하려는 URL과 정확히 동일하게 버킷 이름을 지정해야합니다. 이 가이드에서는 "url-redirect-example.vivekmchawla.com"이라는 이름을 사용합니다.
가장 적합한 지역을 선택하십시오. 모르는 경우 기본값을 유지하십시오.
로깅 설정에 대해 걱정하지 마십시오. 준비가되면 "만들기"버튼을 클릭하십시오.
다음 XML 스 니펫을 완전히 붙여 넣습니다.
<RoutingRules>
<RoutingRule>
<Redirect>
<Protocol>https</Protocol>
<HostName>myaccount.signin.aws.amazon.com</HostName>
<ReplaceKeyPrefixWith>console/</ReplaceKeyPrefixWith>
<HttpRedirectCode>301</HttpRedirectCode>
</Redirect>
</RoutingRule>
</RoutingRules>
위의 XML이 수행하는 작업이 궁금한 경우 "라우팅 규칙 지정 구문"에 대한 AWM 설명서를 참조 하십시오 . 보너스 기술 (여기서는 다루지 않음)이 대상 호스트의 특정 페이지로 전달됩니다 (예 :) http://redirect-destination.com/console/special-page.html
. <ReplaceKeyWith>
이 기능이 필요한 경우 요소 에 대해 읽으십시오 .
Amazon이이 버킷에 대해 자동으로 생성 한 정적 웹 사이트 호스팅 "종료점"을 기록하십시오. 나중에이 작업이 필요하므로 전체 URL을 강조 표시 한 다음 복사하여 메모장에 붙여 넣으십시오.
주의! 이 시점에서 실제로이 링크를 클릭하여 리디렉션 규칙이 올바르게 입력되었는지 확인할 수 있지만주의하십시오! 이유는 ...
<Hostname>
리디렉션 규칙 의 태그 내에 잘못된 값을 입력했다고 가정 해 보겠습니다 . myaccount.amazon.com
대신 실수로을 입력했을 수 있습니다 myaccount.signin.aws.amazon.com
. 엔드 포인트 URL을 테스트하기 위해 링크를 클릭하면 AWS는 브라우저를 잘못된 주소로 행복하게 리디렉션합니다!
실수를 확인한 후에는 <Hostname>
리디렉션 규칙에서를 수정하여 오류를 수정하게됩니다. 불행히도 링크를 다시 클릭하면 잘못된 주소로 다시 리디렉션 될 가능성이 큽니다. 비록 당신이 고정<Hostname>
항목 브라우저가 이전 (잘못된!) 항목을 캐싱합니다. 이는 Chrome 및 Firefox와 같은 브라우저가 기본적으로 캐시하는 HTTP 301 (영구) 리디렉션을 사용하기 때문에 발생합니다.
엔드 포인트 URL을 복사하여 다른 브라우저에 붙여 넣거나 현재 브라우저에서 캐시를 지우면 업데이트 된 <Hostname>
항목이 마지막으로 올바른지 확인할 수 있습니다 .
안전을 위해 엔드 포인트 URL 및 리디렉션 규칙을 테스트하려면 Chrome의 '시크릿 모드'와 같은 비공개 탐색 세션을 열어야합니다. 시크릿 모드에서 엔드 포인트 URL을 복사, 붙여 넣기 및 테스트하면 세션을 닫으면 캐시 된 항목이 사라집니다.
"레코드 세트 작성"을 클릭하면 Route53 관리 콘솔의 오른쪽에 레코드 세트 작성 창이 열립니다.
이름 필드에 S3 버킷 이름을 지정할 때 사용한 URL의 호스트 이름 부분을 입력하십시오. URL의 "호스트 이름 부분"은 호스팅 영역 이름의 왼쪽에있는 모든 것입니다. S3 버킷의 이름을 "url-redirect-example.vivekmchawla.com"으로 지정하고 호스팅 영역은 "vivekmchawla.com"이므로 입력해야하는 호스트 이름 부분은 "url-redirect-example"입니다.
이 레코드 세트의 유형으로 "CNAME-정식 이름"을 선택하십시오.
값에 대해 3 단계에서 다시 생성 한 S3 버킷의 엔드 포인트 URL을 붙여 넣습니다.
"레코드 세트 생성"버튼을 클릭하십시오. 오류가 없다고 가정하면 이제 호스팅 영역의 레코드 세트 목록에서 새 CNAME 레코드를 볼 수 있습니다.
새 브라우저 탭을 열고 방금 설정 한 URL을 입력하십시오. 나에게 그것은 http://url-redirect-example.vivekmchawla.com 입니다. 모든 것이 올바르게 작동하면 AWS 로그인 페이지로 직접 전송되어야합니다.
myaccount.signin.aws.amazon.com
별칭을 리디렉션의 도착 URL로 사용했기 때문에 Amazon은 액세스하려는 계정을 정확하게 알고 있으며 직접 연결합니다. 직원이나 계약자에게 짧고 깨끗하며 브랜드화 된 AWS 로그인 링크를 제공하려는 경우 매우 유용합니다.
개인적으로 다양한 AWS 서비스를 좋아하지만 DNS 관리를 Amazon Route 53으로 마이그레이션하기로 결정한 경우 쉬운 URL 전달이 부족할 수 있습니다. 이 가이드가 호스팅 영역에 대한 URL 전달 설정을 좀 더 쉽게 해주기를 바랍니다.
자세한 내용은 AWS 설명서 사이트에서 다음 페이지를 참조하십시오.
건배!
AWS 지원은 더 간단한 솔루션을 지적했습니다. 기본적으로 @Vivek M. Chawla가 제안한 것과 동일한 아이디어이며 더 간단한 구현입니다.
AWS S3 :
aws.example.com
Redirect all requests to another host name
URL을 선택 하고 입력하십시오.
https://myaccount.signin.aws.amazon.com/console/
AWS Route53 :
Yes
. 별명을로 변경하십시오 . Alias
Target
필드를 클릭 하고 이전 단계에서 생성 한 S3 버킷을 선택하십시오.참조 : Amazon Web Services를 사용하여 도메인을 리디렉션하는 방법
AWS 공식 문서 : Amazon Route 53을 사용하여 도메인을 다른 도메인으로 리디렉션하는 방법이 있습니까?
Redirect all requests to another host name
옵션이 여전히 존재합니까? 버킷 속성으로 이동하면 볼 수 없습니다.
nginx를 사용하여 AWS 로그인 페이지로 301 리디렉션을 처리 할 수있었습니다.
nginx conf 폴더로 이동하십시오 (필자의 경우 활성화 된 conf 파일 /etc/nginx/sites-available
에 /etc/nginx/sites-enabled
대한 심볼릭 링크를 만듭니다 ).
그런 다음 리디렉션 경로를 추가하십시오.
server {
listen 80;
server_name aws.example.com;
return 301 https://myaccount.signin.aws.amazon.com/console;
}
nginx를 사용하는 경우 영역 정점 (example.com)을 처리하기 위해 추가 서버 블록 (아파치 용어의 가상 호스트)이 있거나 설정되어 있습니다. 그중 하나가 기본 서버로 설정되어 있는지 확인하십시오.
server {
listen 80 default_server;
server_name example.com;
# rest of config ...
}
Route 53에서 A record
for를 추가하고 aws.example.com
영역 정점에 사용 된 것과 동일한 IP로 값을 설정하십시오.
아래의 원래 답변은 여전히 유효하며 Amazon Route 53을 통해 DNS 기반 URL 전달을 사용할 수없는 원인을 이해하는 데 도움이 될 수 있지만 그 동안 도입 된 Vivek M. Chawla의 완전히 간접적 인 솔루션 을 확인하는 것이 좋습니다. 웹 사이트 리디렉션 을위한 Amazon S3 지원 자체 포함 된 서버를 적게 사용하므로 AWS 내에서 무료 솔루션 만 가능합니다.
Nettica는이를 위해 사용자 지정 리디렉션 솔루션을 실행해야합니다. 여기에 문제가 있습니다.
당신은 같은 CNAME 별칭을 만들 수 aws.example.com
에 대한 myaccount.signin.aws.amazon.com
,하지만, DNS는 같은 서브 디렉토리를 앨리어싱에 대한 공식 지원을 제공하지 않습니다 console
이 예제를.
https://myaccount.signin.aws.amazon.com/
(방금 시도했습니다). 문제를 즉시 해결하고 처음에는 많은 의미를 갖기 때문입니다. 게다가, 그들의 끝에 구성하는 것은 매우 쉬워야한다.이러한 이유로 일부 DNS 제공 업체는 하위 디렉토리로의 리디렉션을 허용하는 사용자 지정 솔루션을 구현했습니다. 나는 그들이 기본적으로 자신의 도메인에 대한 CNAME 별칭을 촉진하고 즉각적인 HTTP 3xx 리디렉션을 통해 최종 목적지로 다시 리디렉션한다고 추측합니다 .
따라서 동일한 결과를 얻으려면 이러한 리디렉션을 수행하는 HTTP 서비스를 실행해야합니다. 물론 이는 바람직한 솔루션이 아닙니다. 어쩌면 누군가가 더 똑똑한 접근법을 생각해 낼 수 있습니다.