도메인을 구입했다.
짜잔.. 분명히 구매 후 최대 3일 걸릴거라고 고지했으면서 10분만에 뚝딱해주다니.. AWS는 역시 빠르다. 구입한 도메인은 하나를 api 서버 엔드포인트, 하나는 amplify에 붙여 서비스 도메인으로 사용할 예정이다. amplify는 프론트 파트에서 작업할 것이고 우선 lambda의 api gateway에 해당 도메인을 붙이는 과정을 포스팅 하겠다.
AWS 리소스로 인터넷 트래픽 라우팅
공식문서를 참고하여 하나 하나 따라해보도록 한다.
api.example.com과 같이 생성하려는 Route 53 레코드의 이름과 일치하는 사용자 지정 도메인 이름이 있는 API Gateway API입니다.
- 이는 생성된 API Gateway의 도메인 설정이 Route 53 레코드의 이름과 일치해야 한다는 의미이다. default로 설정된 현재 상황에서는 cloudformation을 통해 이를 교체하도록 한다.
- API Gateway의 도메인 설정을 위해서는 API Gateway의
Custom domain names섹션으로 가 새로운 엔드포인트를 만들어 주어야 한다. 이때 이름은 당연히 구매한 도메인으로 이루어진 서브 도메인이어야 한다. 나의 경우는,api.catchcatch.link로 해두었다.
- 위에서 볼 수 있듯, ACM로부터 certificate를 받아와서 지정해주어야 한다. ACM의 TLS 인증서를 사용하는 것은 무료라고 한다. 아래와 같이 생성한 다음, 위의 ACM certificate에 등록해주면 된다.
- TIP, 등록하는 Domain Name은 FQDN(Fully qualified domain name)으로, 정규식을 지원받는 모든 도메인에 대한 인증을 적용시켜준다. 위처럼
*.catchcatch.link를 적용할 시,www.catchcatch.link,image.catchcatch.link등의 경로를 모두 보호받을 수 있다. ACM 으로 요청한 인증서는발급에 1시간 정도 소요되니 기다리도록 한다.
ACM pending validation
- 위의 사진처럼 요청한 것이 2시간이 지나도 발행되지 않았다. 이와 관련된 문제를 찾아보다, DNS 검증과 관련된 문서를 찾아볼 수 있었다. DNS 공급자는 도메인을 정의하는 레코드 테이블을 갖고, ACM에서 발급한 인증서는 해당 레코드와 대응이 되어야 하는 것으로 보였다. 나의 경우, ACM으로 발급한 인증서에 대응되는 레코드가 없었기 때문에
위 create records in route 53 버튼을 클릭해서 CNAME 레코드를 만들어 연결해주니 상태가 정상적으로 돌아왔다.
default로 설정된 현재 상황에서는 cloudformation을 통해 이를 교체하도록 한다.
-
오늘도 어김없이 AWS Serverless Application Model 공식문서를 찾아왔다. 해당 부분은,
AWS::Serverless::Api의 property 중,DomainConfiguration이다.BasePath: List CertificateArn: String -> ACM에서 발급한 인증서의 Arn. 당연히 필수적으로 기입한다. DomainName: String -> 적용하고자 하는 도메인 이름. 무조건 적는다. EndpointConfiguration: MutualTlsAuthentication: MutualTlsAuthentication OwnershipVerificationCertificateArn: String Route53: Route53Configuration SecurityPolicy: String -
위에서 언급한 두가지 외에 중요하게 적용될 요소는,
Route53Configuration이다. 하지만 해당 요소가AWS SAM에만 있고, Required가 아니기 때문에 자동으로 생성할 것으로 추측된다. 나는 위에서 만들었던 Route53 정보들을 반영하여 작성하고자 한다. (Route53의 리소스는 cloudformation으로 관리되지 않는 정적 리소스라고 생각되기에..)
이렇게 구성한 다음, deploy를 해봤는데 에러가 발생했다.
누가봐도, cloudformation 에서 domainname으로 된 엔드포인트를 만들어서 쓰겠다는 선언이었다. 그리하여 (지금은 포스팅에서 지웠지만)위에서 생성한 API Gateway의 Endpoint를 삭제해줬다.. ^^ -
근데도 오류가 났다. 예상하기로는
https://api.catchcatch.link/Stage/~~의 접근이 되어야 하는데 403 forbidden이 뜨는 것이다. 이를 조금 검색해보니, Basepath가 stagename을 감싸는 형식이 되는지라, 아무래도 Basepath가 지정되지 않으면 안된다고 한다. 그래서, 다음과 같이 작성한 후 테스트를 해보았다.
결과가 너무 잘 전달된다 !
마지막 검증
정말 TLS가 적용된 거야?
막연하게 궁금증을 해결하기 위해서 SSL 검증에 대한 검색을 해보았고 그리 어렵지 않게 도메인에 대한 SSL 연결성 테스트 사이트를 찾을 수 있었다. 결과는..
다른 사이트들은 A+도 나오는 것 같았다. 정보들은 대충 handshake가 이루어지는 모든 플랫폼에 대해서 테스트, 그리고 암호화 공격에 대한 공격 등으로 점수를 매기는 것으로 유추되었다. 나중에 기회가 된다면 보안성을 더 강화하고 싶다 흐흐.
