Amazon Web Services 한국 블로그

Category: Amazon Route 53

Amazon Route 53와 AWS Shield를 통한 DDoS 공격 위험 줄이기

on 12 JAN 2017 | in Amazon Route 53, AWS Shield | Permalink

지난 2016 년 10월말에 주요 DNS 공급자가 서비스 거부 공격(DDoS)으로 인한 대규모 사이버 공격 표적이되었습니다. 수천 만개의 IP 주소에서 대량 DNS 조회를 일으켜 공격함으로서 많은 인터넷 사이트 및 서비스에 대해 북미 및 유럽 사용자 접속이 불가능했습니다. 프린터, 카메라, 홈 네트워크 게이트웨이, 모니터 등 다양한 사물 인터넷(IoT) 장치로 구성된 봇넷을 사용하여 이러한 분산 서비스 거부 공격이 실행된 것으로 알려져 있습니다. 이러한 기기는 Mirai 악성 코드에 감염되어, 초당 수백 기가 바이트의 트래픽을 생성했습니다. 많은 기업 네트워크 등은 이러한 규모의 공격을 흡수 할만한 용량을 가지고 있지 않습니다.

이러한 다양한 공격 유형 DDoS 시도에 대해 보다 탄력 있고 빠른 복원력을 가진 시스템을 구축 할 수 있도록 하기 위한 권장 사항 및 모범 사례에 대한 고객의 요구가 많았습니다. 이를 위한 자료로는 “DDoS 복원력을 위한 AWS 모범 사례” 백서, Amazon Route 53 및 AWS Shield 를 활용하는 것입니다 (자세한 내용은 AWS Shield – DDoS 공격 대비 애플리케이션 보안 서비스 참조)

확장성 – Route 53는 다수 AWS 엣지 로케이션에서 호스팅하는 대량 DNS 트래픽을 흡수 할 수 있는 글로벌 서비스입니다. Amazon CloudFront와 AWS WAF등 다른 엣지 기반 서비스에도 대량 트래픽을 처리 할 수 있습니다.
복원력 – 각 에지 로케이션은 수 많은 인터넷 연결이 진행됩니다. 이를 통해 다양한 경로에 대해 장애 분리가 가능합니다. 또한, Route 53는 셔플 샤드(shuffle sharding)와 애니 캐스트 스트라이핑(anycast striping )을 사용하여 가용성을 향상합니다. 셔플 샤드에서는 위탁 집합(delegation set)의 각 네임 서버가 에지 로케이션의 고유 집합에 해당합니다. 이렇게 배치하면 내결함성이 향상되고 AWS 고객 간의 중복을 최소화합니다. 위탁 세트 중 하나의 네임 서버를 사용할 수 없는 경우, 클라이언트 시스템 또는 응용 프로그램은 다른 에지 로케이션의 네임 서버에 다시 요청을 시도하고 응답을 받습니다. 애니 캐스트 스트라이핑은 최적의 장소에 DNS 요청을 하는데 사용됩니다. 부하를 분산하여 DNS 지연 시간을 줄이는 효과가 있습니다.
완화력 – AWS Shield Standard는 가장 일반적인 공격의 96 %로 부터 고객을 보호합니다. 여기에는 SYN/ ACK 플로드 반사 공격 및 HTTP 천천히 읽기 공격 등이 포함되어 있습니다. 이전 블로그 글에서도 언급했듯이 자동으로 Elastic Load Balancing, CloudFront 배포 지점 및 Route 53 자원에 무료로 적용됩니다. (결정적 패킷 필터링과 우선 순위를 기반으로 한 트래픽 형성을 포함한) 보호 기능은 모든 AWS 에지 로케이션에 배치 된 후, 수 마이크로 초 단위로 투명하게 모든 트래픽을 검사합니다. AWS Shield Advanced에는 추가적인 DDoS 세부 공격 차단, 24×7 대응팀 연락, 실시간 통계 리포트 및 공격에 따른 비용 차단 등의 기능이 포함되어 있습니다.

더 자세한 것은 DDoS 복원력을 위한 AWS 모범 사례 및 Amazon Route 53 anycast를 참고하시기 바랍니다.

— Jeff;

이 글은 Reduce DDoS Risks Using Amazon Route 53 and AWS Shield의 한국어 번역입니다.

AWS 클라우드 에서 지리적 IP(GeoIP) 차단 관리 방법

on 23 MAR 2016 | in Amazon Route 53, AWS Web Application Firewall, 한국 기술 문서 | Permalink

글로벌 게임 서비스를 하다 보면, 여러 가지 이유로 특정 국가에 대한 IP를 차단하거나 허용해야 하는 요구 사항이 흔히 발생합니다. 대개 이를 위해서 별도의 상용 방화벽을 사용하여 지리적 IP 블록 기능을 활용하거나, 직접 방화벽을 구축하고 지리적 IP 데이터를 인터넷을 통해 찾아서 직접 관리하는 방법을 사용하기도 합니다.

이 글에서는 실제로 일어나는 서비스 시나리오에 기반해서 현재 AWS가 제공하는 기능을 최대한 활용하여 이러한 요구 사항을 충족하는 과정을 단계별로 살펴 보고자 합니다.

1. 요구 사항
A사는 전문 게임 퍼블리셔 회사이고, B 게임 개발사가 만든 X게임을 글로벌 서비스로 오픈하려고 합니다. 퍼블리싱 계약 상 중국과 일본에서 접근은 차단해야 하지만, 일부 IP는 관리 목적을 위해 접근을 허용해야 하게 되었습니다.

그 외에도 현실적인 몇 가지 요구 사항을 추가해 본다면,

게임 서비스는 로그인 서버와 게임 서버로 구분되어 있다.
로그인 서비스는 REST 방식의 HTTPS 서버이며, 게임 서버는 TCP 이다.
게임 서버는 특정 IP로 바로 접근해야 한다.
게임 클라이언트 변경은 어렵다. 운영 체제(OS) 에 대한 접근은 퍼블리싱 회사에 대해 엄격하게 제한된다. 따라서 가능한 인프라 아키텍처로 문제를 해결해야 한다.
가능하다면 장기적으로 DDoS방어력을 갖추기 바란다.

아마 인프라 보안 관련 기술 경험이 있는 분이라면 몇 가지 대안을 생각했을 것입니다. 예를 들어, 방화벽 레이어를 서버군 앞에 둔다던가 직접 HAProxy 같은 리버스 프록시를 설정하는 해 볼 수 있을 것입니다. 그렇다면, AWS 클라우드에서 이러한 지리적 IP를 쉽게 허용 및 차단하는 방법은 무엇이 있을까요?

이를 위해, AWS에서는 자체 클라우드 서비스와 파트너들이 제공하는 다양한 파트너 솔루션을 제공합니다. 이 중에서 어떤 것이 가장 간단한 것인지 찾기 위해 팀이 모였다면, 간단한 브레인스토밍을 진행할 수 있습니다.

2. 다양한 접근 방법
일반적인 해결 방법과 AWS 안에서 가능한 모든 방법을 테이블에 올려 놓는 다고 하면, 아래와 같은 방법을 고려해 볼 수 있습니다.

모바일 클라이언트 게임에서 지역을 알아내서 접근 자체를 막는 방법
상용 방화벽 레이어를 게임 서버와 로그인 서버에 구축하는 방법
HA 프록시 등으로 프록시 서버 레이어를 구성해서 두는 방법
운영 체제 내 방화벽 기능을 이용하는 방법
Amazon Route 53의 지리적 IP 라우팅 기능을 이용하는 방법
Amazon CloudFront 및 WAF(Web Application Firewall)을 사용하는 방법

요구 사항 중 가장 큰 제약 조건은 바로 2번 요구 사항입니다. 게임 서버와 로그인 서버는 각기 다른 방식으로 서버와 통신하기 때문에, 가장 쉽게 인프라 아키텍처로 해결할 수 있는 방법은 위에서 2, 3번입니다.

그렇다면 2번과 3번은 각기 어떤 단점이 있을까요? 공통적으로 TCP 접근을 위해 외부에 공개(public) IP를 오픈하고, 게임 서버와 연결해 줄 수 있는 NAT 기능까지 지원하는지 살펴 봐야 합니다. 뿐만 아니라, 지리적 IP 차단 및 관리가 용이한지도 살펴봐야 할 것이다.

따른 문제점은 상당한 비용이 발생한다는 점입니다. 지리적 IP 정보를 인터넷에서 받아서 직접 리눅스 서버 등으로 방화벽 레이어를 구축하는 경우, 지리적 IP 정보는 지역 수준의 구분은 인터넷에서 무료로 구할 수 있습니다. 하지만, 이를 이용해서 iptable과 같은 기능을 이용해서 직접 구현해야 합니다. 이런 것을 직접 구성하고 관리하는 것은 어렵습니다.

위의 그림은 이러한 경우의 아키텍처입니다. 게임 서버를 위한 지리적 IP 차단 레이어는 상용이든 직접 구현하든 고정 IP를 지원해야 하고, 방화벽 규칙을 위한 레이어가 존재해야 합니다. 여기서는 서브넷으로 상호 영역을 구분하였습니다.

요구 사항 3번 조건이 너무 강하다면, 게임 서버 앞단에는 직접 구현된 NAT 레이어와 방화벽 레이어가 존재해야 합니다. 비용 최적화를 위해서는 가능한 두 NAT 레이어를 분리해야 하는데, 그 이유는 AWS에서 고정 IP를 인스턴스에 부여하는 갯수가 제한이 있기 때문입니다.

특히, 요구 사항 4번 조건처럼 게임 개발사인 B사가 인프라 관리 요건에 맞게 클라이언트의 코드를 수정하는 것이 어려운 경우가 많습니다. 모바일 게임 클라이언트 코드에서 해결하는 방안은 쉽지 않습니다. 만약 개발사가 동의 한다면, 로그인 전에 특정 지리적 IP 정보를 알려주는 서버를 만들어서 로그인 전에 체크를 하는 방법은 있습니다.

4번 해결 방안은 퍼블리셔와 개발사 간의 계약에 의해 결정되므로 경우에 따라 가능한 해결책일 수 있습니다. 하지만, 게임 서버 안에 직접 운영 체제 방화벽으로 방어를 하는 것으로 일괄 적으로 관리할 수 있는 방안을 찾아야 한다는 단점이 있습니다.

3. AWS 클라우드에서 해법 찾기
자 이제 AWS 서비스를 통한 해법을 보다 깊게 살펴보겠습니다. 먼저 지리적 IP 처리 기능으로 활용할 수 있는 서비스는 Amazon Route53의 지리적 라우팅 기능과 Amazon CloudFront에 존재하는 AWS WAF (웹 애플리케이션 방화벽) 기능입니다. 앞의 요구 사항에 적합한 구현을 위해서는 각 서비스 기능에 대해 좀 더 깊이 있게 이해를 해야 합니다.

Rout53의 지리적 라우팅 기능은 클라이언트가 접속한 IP로 부터 지리적 위치를 알아내고 이를 특정한 AWS서비스 리소스로 라우팅해 주는 기능입니다.

위의 그림은 Route 53에서 지리적 라우팅의 설정 모습입니다. A 레코드 셋 설정을 통해 지리적으로 들어오는 IP를 ELB, S3, CloudFront의 엔드포인트 등으로 연결해 주게 됩니다.

로그인 서버 앞에서 지리적 IP콘트롤을 가장 간단하게 구성할 수 있는 것은 Route53과 CloudFront를 이용한 지리적 IP 제어 아키텍처입니다.

Amazon WAF는 현재 지리적 IP 차단 기능을 제공하지 않습니다. 따라서, 요구 사항을 해결하기 위해서는 앞단에서 먼저 지리적 위치를 어떻게든 알아내는 것이 필요합니다. 위 그림에서는 CloudFront를 2개 배포하고, 막으려는 대상 지리적 위치를 1번 CloudFront로 보냅니다. WAF의 경우는 규칙(Rule)의 순서에 따라 우선순위가 정해지는데, 허용하려는 IP 영역을 1번에 두고, 막으려는 지역, 예를 들면 한국(KR), 일본(JP), 중국(CN) 등을 전체 차단을 2번 규칙에 두면 됩니다. 지리적 제어가 필요 없는 클라이언트 지역은 2번 CloudFront로 보내게 됩니다.

그런데 이 방법에는 한 가지 문제가 존재합니다. CloudFront를 Route53에서 A레코드로 등록하려면 CloudFront에 CNAME을 할당해야 합니다. 문제는 위의 구성에서 CNAME이 두 개가 된다는 점입니다.

CloudFront는 고객이 최초 요청한 대상에 대해 체크를 하게 되는데, 만약 다른 도메인으로 경유해서 들어오게 되면 “Bad Request”라는 메시지를 던지게 됩니다.

즉, 위의 경우 1번 CF의 CNAME이 a.com, 2번 CF의 CNAME이 b.com이라고 이라고 하고, 이를 묶기 위해 c.com을 두었다면, 고객은 c.com으로 요구를 요청하게 됩니다. 1번, 2번 CloudFront모두 요청한 도메인(c.com)이 자신의 CNAME과 다르기 때문에 오류를 내게 됩니다. 이를 해결하는 방법은 매우 간단합니다. 클라이언트에서 요청할 때 헤더의 origin 값을 1번, 2번 CNAME으로 바꾸어서 전달해 주면 됩니다.

하지만, 클라이언트가 각기 다른 CNAME 값 중에 어디로 요청할 수 있다는 말은 이미 지리 정보를 클라이언트가 알고 있어야 한다는 문제에 다시 봉착 합니다. 이는 별도 지리 정보 제공 서버가 있어야 하거나, 클라이언트가 자신의 위치를 알고 있어야 합니다.

이를 해결하기 위해서는 좀 더 서비스 내부 기능을 활용하는 방법을 고안해 내야 합니다. 그 해결책 중의 하나가 바로 CloudFront 샌드위치 아키텍처입니다.

먼저 이와 같은 아키텍처를 고안하게 된 배경을 설명해 보고자 합니다. WAF는 CIDR로 IP 조건을 검색할 수 있습니다. 단 /8, /16, /24, /32 로 8비트 단위 레인지 만을 지원합니다. 중국에 속한 IP는 CIDR로 대략 6천개 정도 되는데, 이를 위 단위로 전환하면 대략 6만건의 CIDR가 됩니다.

조건이 너무 많아지면 성능 저하가 발생할 수 있고, 만약 고객이 여러 지역에 대해 관리를 해야 한다면 CIDR 형태로 WAF상에서 관리하는 것은 무척 힘든일이 될 수 있습니다.

재미난 것은 CloudFront의 고급 기능 중에 확장 헤드를 추가해 주는 기능이 있습니다. cloudfront-viewer-country라는 확장 헤더는 요청이 어느 나라에서 이루어졌는지를 헤더값으로 추가해주게 됩니다.

이렇게 확장 헤더값을 추가하는 기능보다 WAF는 앞에 존재하기 때문에 가져 올 수가 없습니다. 따라서, 이 기능을 이용하려면 WAF를 한번 더 통과하게 해서, cloudfront-viewer-country 확장 헤더 값을 추가한 이후에, 두번째 WAF에서 이 값을 이용해서 차단 할 수 있습니다.

첫번째 CloudFront를 통과하게 되면, 요청 IP가 CloudFront의 값으로 변하게 되는데, 원래 고객의 IP값은 x-forwarded-for 값에 존재합니다. 따라서 이 때 WAF 규칙을 만들 수 있게 됩니다.

각각 문자열 조건을 만든 다음 아래와 같이 WAF 규칙을 만드는 것입니다.

물론 본 아키텍처의 단점은 CloudFront의 가격이 2배가 나온다는 점입니다. 그러나, 지역별 IP 차단이라는 요구 사항에 대해 관리 및 운영 편리성을 생각하면 매우 효율적이고 간단한 해결책입니다.

게임 서비스에서 지리적 IP 관리는 매우 일상적인 요구 사항입니다. AWS 클라우드 서비스 빌딩 블록을 이용하여, 간단한 아키텍처 재구성만으로 본 요구 사항을 구성하는 해법을 찾아 보았습니다. 이러한 요구 사항을 충족해 주는 AWS 서비스나 기능이 나올 때 까지 활용해 볼 수 있는 대안이 될 것입니다.

본 글은 아마존웹서비스 코리아의 솔루션즈 아키텍트가 국내 고객을 위해 전해 드리는 AWS 활용 기술 팁을 보내드리는 코너로서, 이번 글은 박선용 솔루션즈 아키텍트께서 작성해주셨습니다.

신규 Amazon Route 53 트래픽 흐름 관리 출시!

on 11 DEC 2015 | in Amazon Route 53 | Permalink

20년전쯤 처음 도메인 주소를 등록한 기억이 납니다. 그때는 도메인명을 서버에 연결하는건 간단했습니다. 부하 분산, 지리적 중복 지원, 웹 사이트 모니터링 및 클라우드 컴퓨팅 등 그 당시에는 생각지도 못했던 것이 많습니다. 도메인 주소릴 변하지 않는 IP 주소에 하나에 연결하는 것 뿐이었습니다.

최근에 이러한 상황은 많이 달라졌습니다. 도메인 주소를 IP 주소에 연결하는 건 더 이상 1:1로 필요한 게 아니고, 대용량의 정교한 사이트들은 요청자의 근처에 있는 가장 가까운 서버로 연결하는 것이 중요해졌습니다.

Route 53 트래픽 흐름 관리
클라우드 기반 애플리케이션에서 이러한 특성을 잘 처리하도록 만들기 위해서 지난 주 Amazon Route 53에 트래픽 흐름 관리(Traffic Flow) 기능을 추가하였습니다. 여러분은 이제 사용자의 지리적 위치, 지연 속도 및 트래픽 가용성을 고려한 결합을 기반으로 클라우드나 온 프레미스 연결 지점으로 트래픽을 전달할 수 있습니다.

트래픽 라우팅 정책을 아주 기초적인 방법으로 쉽게 설정할 수 있고, 라이브러리에 있는 템플릿을 가져와서 변경할 수도 있습니다. 기존의 DNS 명에 대해 다중 정책을 만들거나 어떤 것을 활성화 할지도 결정할 수 있습니다. 또한, Route 53 콘솔에서 전 세계의 모든 트래픽 흐름을 관리할 수 있습니다.

트래픽 정책 만들어 보기

제가 가진 doordesk.com을 예를 들어 설명을 해보겠습니다. 먼저 트래픽 흐름 관리에 대한 이름과 설명을 간단히 입력합니다.

콘솔에 트래픽 정책 편집기가 보이게 됩니다.

Start point는 간단합니다. DNS가 시작입니다.

여러 종류의 규칙 및 엔드포인트로 연결할 수 있습니다.

신규 엔드포인트를 선택하면, 편집기는 상세 사항을 우리에게 보여줍니다.

Value를 선택하고 주소를 입력하면, 시작 지점에서 특정 IP 주소로 연결합니다.

이 상태에서 A 레코드를 고정 IP 주소를 연결하는 간단한 정책이 만들어진 것입니다.

만약 우리가 실 서버와 테스트 서버가 있을 경우, 95%의 트래픽을 실서버로 5%를 테스트 서버로 보낼 필요가 있다면 Weighted 규칙을 통해 아래와 같이 할 수 있습니다.

위에서 보다시피, Route 53 상태 검사 중 하나에서 규칙의 각 요소를 지정할 수 있습니다. 이를 통해 상태 검사를 통해, 잘 동작하는 엔드포인트로 트래픽을 보내 줄 수 있을 것입니다.

Failover 규칙을 사용할 수도 있습니다. 예를 들어, 서버 상태가 문제가 없다면 원래 IP주소로 보내고, 그렇지 않으면 S3에 호스팅한 장애 안내 사이트로 보내줄 수도 있습니다.

Geolocation 규칙은 사용자의 DNS 요청에 대한 지리적 원래 위치를 기반으로 트래픽을 전달하는 것입니다. 아래에 예를 참고하세요.

마지막으로 Latency 규칙이 있습니다. 이 규칙을 사용하면 DNS 요청한 곳에서 AWS 지역(Region) 중에 가장 지연 속도가 낮은 곳을 찾아서 전달해 주게 됩니다. US East (Northern Virginia)와 Asia Pacific (Tokyo) 지역에 EC2 인스턴스가 있다면, 사용자가 가장 빠른 인스턴스로 연결해 주게 됩니다. 아래에 설정 방법이 있습니다.

각 규칙들을 잘 조합해서 좀 더 복잡한 트래픽 흐름 관리를 할 수도 있습니다. 지리적 위치, 지연 속도, 가중치 및 장애 시 규칙 등을 함께 사용 가능합니다.

간단하게 테스트가 끝나면, 첫 번째 트래픽 정책을 Save as new version를 눌러 저장합니다.

정책 레코드 만들기
다음 단계로 실제로 구현한 DNS 기반 트래픽 정책을 정책 레코드로 만드는 것입니다. 콘솔에서 쉽게 할 수 있습니다. 도메인명과 DNS명만 선택하면 됩니다.

(1~2분내에) 동작이 완료되면, 새 정책 DNS 레코드가 Route 53에 반영됩니다. 변경이 일어날 때 마다, DNS TTL (Time to Live)은 사용자가 DNS 요청을 했을 때 캐시를 바꾸거나 다른 DNS에 변경을 하는 동안의 시간입니다.

각 트래픽 정책의 여러 버전을 만들거나 저장할 수 있고, (정책 레코드를 만들어) 원하는 버전을 필요할 때 사용할 수 있습니다.

정식 출시
본 기능은 바로 오늘부터 사용 가능합니다. 더 자세한 사항은 Route 53 개발자 가이드내에 Using Traffic Flow to Route DNS Traffic 문서를 참고하세요. 정책 하나당 월 $50.00 정도이며, 자세한 사항은 Route 53 가격표를 참고하세요.

— Jeff;

이 글은 New – Route 53 Traffic Flow의 한국어 번역입니다.

Route53 지연 속도 기반 라우팅 활용하기

on 26 AUG 2015 | in Amazon CloudFront, Amazon Route 53, Amazon S3, 한국 기술 문서 | Permalink

AWS는 전 세계에 11개의 리전(Region)과 30개의 가용 영역(Availability Zone)으로 글로벌 서비스를 제공함으로써, 각 국가 또는 지역 사용자에게 가장 빠른 서비스를 제공합니다. 뿐만 아니라 Amazon CloudFront라는 전용 콘텐츠 전송 네트워크를 통해 네트워크 속도 측면에서 가장 가까운 53개의 에지(Edge)에서 더 빠르게 정적 콘텐츠 및 동적 캐싱을 통해 더 빠른 서비스 전달이 가능합니다.

이를 위해 원래 콘텐츠 위치(Origin)인 S3 버킷에서 가장 빠른 클라우드프론트 에지를 찾아야 할 필요가 있습니다. 그래야 더 빠르게 콘텐츠를 배포할 수 있을 테니까요. 많은 고객들이 이러한 질문을 해주셨습니다.

이 글에서는 도메인 네임 서비스로 알려진 Amazon Route53의 여러 가지 기능 중 지연 속도 기반 라우팅(Latency based routing)을 통해 위와 같은 질문에 대한 해결 방법을 찾아 보도록 하겠습니다.

지연 속도 기반 라우팅(Latency based routing) 설정하기
만약 AWS 위에서 운영 중인 서비스가 동경 리전(Tokyo region)과 버지니아 리전(Virginia region)을 통해 서비스 되고 있을 경우, 이 서비스 도메인 이름을 Route53을 통해 등록하고 지연 속도 기반 라우팅을 설정 할 수 있습니다. 이러한 경우 Route53은 해당 서비스의 DNS 질의를 했을 때, Tokyo와 Virginia region 중 고객 입장에서 보다 낮은 지연 속도(Latency)를 가질 수 있는지 판단하여 지연이 낮은 리전의 주소를 반환합니다.

대부분의 경우, 아시아쪽 고객은 동경 리전으로 미국쪽 고객은 버지니아 리전으로 DNS 주소를 반환하고, 사용자의 접속 속도는 훨씬 빨라지게 되므로 사용자의 경험은 증가할 것입니다.

우리는 이러한 라우팅이 잘 동작하는지 검증하기 위한 도구를 만들기 위해 버지니아, 아일랜드 및 동경 리전에 각각 S3 버킷을 만들고 정적 웹 호스팅을 구현한 후 location.txt라는 파일을 만들어 각각 자신의 리전이름(예: I’m in Virginia)을 표시하도록 하였습니다.

버지니아: Virginia.cloudinternal.com
아일랜드: Ireland.cloudinternal.com
동경: Tokyo.cloudinternal.com

버킷 생성과 Index 문서 설정이 끝났다면, Route53으로 이동하여 해당 버킷이 도메인명을 통해 인터넷에서 접근할 수 있도록 Route53 Alias 기능을 이용해 ireland.cloudinternal.com, tokyo.cloudinternal.com, virginia.cloudinternal.com을 등록합니다.

사실 lbr.cloudinternal.com이 실제 지연 속도 기반 라우팅으로 설정할 도메인 이름입니다. 레코드에 등록할 때 Routing Policy는 Latency로 설정하고, Region은 타겟 S3 버킷 위치에 해당하는 리전을 설정합니다. 예를 들어, ireland.cloudinternal.com을 Target으로 등록할 때는 리전을 eu-west-1으로 선택하게 됩니다.

즉, eu-west-1(아일랜드 리전)에 가까우면 ireland.cloudinternal.com로, ap-northeast-1(동경 리전)에 가까우면 tokyo.cloudinternal.com로, us-east-1(버지니아 리전)에 가까우면 virginia.cloudinternal.com으로 DNS 응답을 받을 수 있도록 설정합니다.

라우팅 결과 살펴보기
각 지역의 가까운 곳에서 DNS Lookup을 하여 실제로 가까운 S3 버킷으로 연결되는지 시험합니다. 아일랜드와 오레곤 리전에 각각 t2.micro로 인스턴스를 실행하고, dig 명령을 실행합니다. 동경은 한국에서 연결될 가능성이 높으니 직접 자신의 랩탑에서 시험해도 좋습니다.

Oregon Instance에서 DNS lookup실행

$ ssh -i [your_key_file1]  ec2-user@52.27.81.xxx 'dig +short lbr.cloudinternal.com'
virginia.cloudinternal.com.s3-website-us-east-1.amazonaws.com.
s3-website-us-east-1.amazonaws.com.
54.231.16.60

Ireland Instance에서 DNS Lookup 실행

$ ssh -i [your_key_file2] ec2-user@54.171.115.xxx 'dig +short lbr.cloudinternal.com'
ireland.cloudinternal.com.s3-website-eu-west-1.amazonaws.com.
s3-website-eu-west-1.amazonaws.com.
54.231.129.36

한국 내에서 DNS Lookup 실행

$ dig +short lbr.cloudinternal.com
tokyo.cloudinternal.com.s3-website.ap-northeast-1.amazonaws.com.
s3-website.ap-northeast-1.amazonaws.com.
54.231.230.12

가까운 AWS 리전의 S3 주소가 반환되는 것을 확인 할 수 있습니다.

빠른 CloudFront S3 Origin 설정하기

이제 lbr.cloudinternal.com으로 CloudFront Origin을 설정하면 자동으로 가까운 S3 버킷을 Origin으로 객체(Object)를 가져오겠지만, S3는 HTTP Request header 의 Host 정보를 참조하여 Bucket 이름과 다르면 404 Not Found 페이지를 반환합니다. 따라서 추가적인 설정이 필요합니다. 지연 속도 기반 라우팅이 잘 동작하니, CDN 서비스를 요청하는 클라이언트는 Route53을 통해 내가 어느 쪽 리전으로 접근해야 하는지 확인한 후, URL에 해당 리전 정보를 포함하여 요청하면 지연 속도가 낮은 쪽의 S3 버킷을 원래 소스 저장소(Origin)로 선택할 수 있습니다.

WHERE = `dig +short lbr.domainname.com`
CF_URL = dfoijefo2eoifjeaf.cloudfront.net/$WHERE/target_file.jpg

위와 같은 로직을 수행하기 위해서 CloudFront에서 Origin과 Behavior를 아래와 같이 설정합니다.

Origin 설정

Behavior 설정

간단히 아래와 같이 가까운 Region위치를 알 수 있습니다.
한국에서 수행

$ dig lbr.cloudinternal.com +short | awk -F "." '{ print $1 }' | head -1
tokyo

Oregon region 인스턴스에서 수행

$ ssh -i [your_key_file] ec2-user@52.27.81.xxx  'dig +short lbr.cloudinternal.com' | awk -F "." '{ print $1 }' | head -1
virginia

Ireland region 인스턴드에서 수행

$ ssh -i [your_key_file2] ec2-user@54.171.115.xxx 'dig +short lbr.cloudinternal.com' | awk -F "." '{ print $1 }' | head -1
ireland

최종적으로 알게된 리전을 URL Prefix에 포함하여 요청하여 원하는 결과를 얻을 수 있습니다.

$ curl http://d2r05xiwqufy6.cloudfront.net/ireland/location.txt
I'm in Ireland.

$ curl http://d2r05xiwqufy6.cloudfront.net/tokyo/location.txt
I'm in Tokyo

$ curl http://d2r05xiwqufy6.cloudfront.net/virginia/location.txt
I'm in Virginia

지금까지 우리는 Route 53의 지연 속도 라우팅 방식을 기반으로 CloudFront의 소스 파일이 위치한 가장 가까운 S3 버킷의 위치를 찾는 문제를 해결해 보았습니다. 이를 위해 S3 정적 웹 호스팅 및 CloudFront의 몇 가지 기능을 활용하기 위한 설정이 필요했지만, 단순히 리전간에 구성된 웹 서비스의 Elastic Load Balancing 주소를 지연 속도 기반 라우팅으로 Route 53에 구성하면 복잡한 설정 없이 CloudFront을 통해 동적 콘텐츠도 활용할 수 있는 구성을 할 수 있습니다.

본 글은 아마존웹서비스 코리아의 솔루션즈 아키텍트가 국내 고객을 위해 전해 드리는 AWS 활용 기술 팁을 보내드리는 코너로서, 이번 글은 김일호 솔루션즈 아키텍트께서 작성해주셨습니다.

AWS IP 대역 JSON 형식으로 공개

on 24 NOV 2014 | in Amazon CloudFront, Amazon EC2, Amazon Route 53 | Permalink

여러 고객들로부터 AWS가 사용하는 IP 주소 범위에 대한 문의를 받는 경우가 많습니다. 고객마다 그 정보의 활용 사례는 다르지만 방화벽이나 네트워크의 접근 제어 목록 등이 대표적입니다. 지금까지는 EC2, S3, SNS, CloudFront 등의 포럼에서 사람들에게 각자 제공하기도 했습니다.

JSON 형식의 IP주소 범위 공개
JSON형식으로 범위 정보를 https://ip-ranges.amazonaws.com/ip-ranges.json에서 제공합니다. 이 데이터 API에는 공식적으로 제공하는 것으로 자주 변경될 수 있으며 그래서 정기적으로 확인할 필요가 있습니다.

일부 예제 코드는 아래와 같습니다.

{
  "syncToken": "1416523628",
  "createDate": "2014-11-20-22-51-01",
  "prefixes": [
    {
      "ip_prefix": "50.19.0.0/16",
      "region": "us-east-1",
      "service": "AMAZON"
    },
    {
      "ip_prefix": "54.239.98.0/24",
      "region": "us-east-1",
      "service": "AMAZON"
    },

“Service”키에 포함되는 값은 “AMAZON”, “EC2”, “ROUTE53”, “ROUTE53_HEALTHCHECKS”, “CLOUDFRONT” 등으로서 어떤 서비스까지 세부적으로 알 필요가 없다면, “AMAZON”를 참조해 주세요. 다른 항목은 그 하부 데이터가 되며, S3 등 몇가지 서비스는 “AMAZON”에 포함돼어 있지 않으며, 이 값은 차례차례 추가될 예정입니다.

더 자세한 정보는 AWS IP Address Ranges을 참고하시기 바랍니다.

– Jeff;

본 글은 AWS Public IP Address Ranges Now Available in JSON Form의 한국어 번역본입니다.

Route 53 – 도메인 등록, 지역별 라우팅 기능 추가 및 가격 인하 단행

on 01 AUG 2014 | in Amazon Route 53 | Permalink

Amazon Route 53는 최상의 상태 확인 서비스를 갖추고 직접 가용성을 측정할 수 있는 도메인 네임 서비스(DNS)입니다. 도메인 이름 등록과 관리 및 이제 Geo DNS를 지원함으로써 Route 53기능을 계속 강화하고 있습니다. 또한, Route53 사용 요금 인하 등 각 항목에 대해 상세하게 살펴보겠습니다.

도메인 이름 등록과 관리

저는 1995년에 처음 도메인명을 등록했습니다. 당시는 도메인 관리와 등록의 거의 모든 작업이 어렵고 비싸며, 직접 수동으로 해야 했습니다. 좋은 도메인명을 찾으면 기술적인 지식을 가진 친구를 설득해 DNS 레코드를 호스트에 올리고 이메일 기반 형식을 사용해 도메인명 등록을 온라인으로 했습니다. 그 이후, 간편한 등록과 복수의 레지스트라의 출현으로 프로세스가 어느 정도 원활하게 되었습니다.

지금까지는 외부 레지스트라에서 도메인을 등록하고 Route 53에서 호스트 존을 작성한 후 Route 53의 네임 서버를 등록하고 레지스토라에서 도메인 설정해야 했습니다. 오늘 Route 53의 도메인 이름 등록 기능의 출시로 AWS 관리 콘솔 내에서 모든 기능을 한꺼번에 할 수 있게 되었습니다(API 처리도 가능). 다양한 일반 도메인 및 국가별 최상위 도메인(TLD)중에서 도메인을 구입, 관리 및 이전 할 수 있습니다. 등록 프로세스의 일환으로 Route 53 호스트 존이 자동적으로 설정됩니다. 좋은 도메인명을 생각해 등록 한 후, 정적(Amazon Simple Storage Service S3)또는 동적(Amazon Elastic Compute Cloud EC2)으로 AWS Elastic Beanstalk, AWS OpsWorks 콘텐츠를 단 몇 분 만에 온라인 서비스가 가능합니다.

많은 AWS 이용 고객처럼 수 백에서 수 천개의 도메인명을 소유하고 있는 경우, 도메인 유효 기간을 감시하고 도메인을 업데이트 하는 것이 얼마나 힘든지 아시죠? 도메인을 Route 53에 이전함으로써 설정 가능한 유효 기간 만료 통지 기능 및 자동 갱신 기능을 이용할 수 있습니다. 도메인명 관리에서 자주 있는 실수를 피할 수 있고, 도메인 이름 대신 애플리케이션에 집중할 수 있습니다. 또한 도메인 이름 관리를 위한 모든 사용자명과 암호를 기억해야 하던 것을 그만해도 됩니다.

그럼 AWS관리 콘솔을 Route 53 API 사용한 도메인 이름 검색 및 등록 과정을 봅시다.

Route 53 Dashboard에서는 호스트 존, 상태 점검, 도메인 전체 현황을 볼 수 있습니다.:

원하는 도메인명을 입력하고 메뉴에서 TLD를 선택해 등록 프로세스를 시작합니다.:

콘솔은 선택한 도메인과 몇몇 인기있는 도메인명이 이용 가능한지를 확인합니다. 원하는 이름을 추가할 수 있습니다(아래에서는.com과.info).:

그리고 연락처 상세 정보를 입력합니다.:

도메인의 개인 정보 보호 기능을 사용할 수 있습니다. 본 설정은 스팸을 막기 위해 공개된 Whois 데이터베이스에서 개인 정보의 많은 부분을 숨김니다.

모든 준비가 되고 약관에 동의하면 도메인이 등록됩니다.:

콘솔 내에서 모든 도메인을 볼 수 있습니다.:

각각 도메인의 자세한 정보 보기도 가능합니다.:

외부 Route 53에(또 그 반대도)도메인을 이관할 수도 있습니다.:

처음에 말했듯이 Route 53 API을 통해도 도메인의 검색, 구입, 관리를 할 수 있습니다. 집에 아이가 태어나서 적합한 도메인명을 얻고자 할 때 모든 프로세스를 자동화하는 코드를 소개해 드립니다. AWS SDK for PHP을 사용하고 있습니다.

첫 단계로 원하는 도메인 명과 이용 가능한 TLD의 목록을 설정합니다.:

$LastName = 'Barr';
$Gender   = 'F';
$TLDs     = array('.com', '.org');

그리고 AWS SDK와 PHP Simple HTML DOM라이브러리를 이용해 Route 53의 클라이언트 객체를 작성합니다.:

require 'aws.phar';
require 'simple_html_dom.php';

// Connect to Route 53
$Client = \Aws\Route53Domains\Route53DomainsClient::factory(array('region' => 'us-east-1'));

다음에 가장 인기 있는 아기의 이름의 배열이 필요합니다. 이번에는 인기 있는 2013년 아기 이름 목록 사용해 PHP 배열을 만들기 위해 HTML을 파싱(Parsing)합니다.:

$HTML      = file_get_html("http://www.babycenter.com/top-baby-names-2013");
$FirstNames = array();

$Lists = $HTML->find('table tr ol');
$Items = $Lists[($Gender == 'F') ? 0 : 1];

foreach ($Items->find('li') as $Item)
{
  $FirstNames[] = $Item->find('a', 0)->innertext;
}

손수 만든 인기 이름의 목록을 사용하여 재미 있는 조합을 생성하고 Route 53의 checkDomainAvailability 기능을 호출해서 이용 가능한지를 확인합니다:

foreach ($FirstNames as $FirstName)
{
  foreach ($TLDs as $TLD)
  {
    $DomainName = $FirstName . '-' . $LastName . $TLD;

    $Result = $Client->checkDomainAvailability(array(
      'DomainName'  => $DomainName,
      'IdnLangCode' => 'eng'));
  }
  echo "{$DomainName}: {$Result['Availability']}\n";
}

사용 가능한 이름을 선택했습니다. 그리고 향후 등록 시 필요하니 연락처 정보를 패키지화합니다.:

$ContactInfo = array(
  'ContactType'      => 'PERSON',
  'FirstName'        => 'Jeff',
  'LastName'         => 'Barr',
  'OrganizationName' => 'Amazon Web Services', 
  'AddressLine1'     => 'XXXX  Xth Avenue', 
  'City'             => 'Seattle', 
  'State'            => 'WA', 
  'CountryCode'      => 'US', 
 'ZipCode'          => '98101',
  'PhoneNumber'      => '+1.206XXXXXXX',
  'Email'            => 'jbarr@amazon.com');

다음 registerDomain 기능을 사용하고, 도메인을 등록합니다.:

if ($Result['Availability'] === 'AVAILABLE')
{
  echo "Registering {$DomainName}\n");

  $Result = $Client->registerDomain(array(
    'DomainName'              => $DomainName,
    'IdnLangCode'             => 'eng',
    'AutoRenew'               => true,
    'DurationInYears'         => 1,
    'BillingContact'          => $ContactInfo,
    'RegistrantContact'       => $ContactInfo,
    'TechContact'             => $ContactInfo,
    'AdminContact'            => $ContactInfo,
    'OwnerPrivacyProtected'   => true,
    'AdminPrivacyProtected'   => true,
    'TechPrivacyProtected'    => true,
    'BillingPrivacyProtected' => true));
}

Geo Routing
Route 53의 새로운 Geo Routing기능을 사용하면 DNS 요청의 발신 위치에 따라 콘텐츠 전송을 위해 가장 적절한 AWS 자원을 선택할 수 있게 됩니다. 이로 사용자의 위치에 따른 요청에 적절한 응답을 효율적으로 제공할 애플리케이션을 구축할 수 있게 됩니다. 각 위치(대륙 국가 또는 미국의 주)마다 독립해 정적 또는 동적인 AWS 자원에 매핑할 수 있습니다. 어느 장소에서는S3에서 전송되는 정적인 자원을 받고 다른 장소에서는EC2나 Elastic Beanstalk에 실행하는 애플리케이션의 동적인 자원을 받는식입니다.

이 기능은 다양한 용도로 이용할 수 있습니다. 여기에서 몇가지 아이디어를 소개하겠습니다.:

글로벌 애플리케이션 – 같은 대륙에 있는 AWS 범위 내 요청인 경우 Amazon Elastic Compute Cloud (EC2)인스턴스 요청을 라우팅합니다. 앞으로 이로 인한 성능을 극대화할 수 있거나 법적 또는 규제 요건을 충족시킬 수 있습니다.
콘텐츠 관리 – 지리적 위치에 따라 최적화 및 맞춤형 라이선스 및 승인된 콘텐츠 접속을 사용자에게 제공합니다. 예를 들면 미국 각 주에 따라 각각 다른 컨텐츠 및 자원을 사용할 수 있고, 전 세계의 특정 지역에서만 유효한 콘테스트 및 프로모션을 할 때 초기의 필터링 기능을 제공하기 위해서 이 기능을 이용할 수 있습니다.
일관성 있는 엔드 포인트 – 특정 위치가 같은 엔드 포인트에 매핑 하는 것을 보증하기 위해 엔드 포인트에 대한 위치 매핑을 설정합니다. MMOG를 실행할 때, 사용자 위치에 따라 라우팅 하는 것으로 성능을 향상시키거나 지연을 줄이거나 시간 기반의 스케일링을 더 잘 제어하거나 비슷한 배경과 문화를 가진 사용자가 게임 내의 같은 게임 서버로 보낼 수 있습니다.

이 기능을 이용하려면 단순히 Routing Policy로 Geolocation의 Route 53 레코드 세트를 작성할 뿐입니다. 각 레코드 셋이 DNS 엔트리(예를 들어www.jeff-barr.com) 에서 특정 AWS 자원, S3의 버킷, EC2인스턴스 또는 Elastic Load Balancer에 매핑 될 수 있습니다. 오늘 출시한 Geolocation 정책을 가진 각 레코드 세트는 DNS 엔트리 요청이 특정 대륙 국가, 미국의 주 경계(geo lookup의 IP에서 결정)내의 것인 경우만 유효하게 됩니다. 각 레코드 세트는 명확한 방법으로 계층을 형성하는 가장 적합한 레코드 셋을 이용합니다. 기본 엔트리를 작성해 어느 엔트리에도 맞지 않는 경우에 사용되도록 할 수도 있습니다.

이 기능은 AWS관리 콘솔, Route 53 API(AWS Command Line Interface CLI)에서 설정할 수 있습니다. 애플리케이션에 따라서는 DNS 데이터베이스로부터 정보에 따라 레코드 세트를 생성하는 것도 가능합니다.

www.jeff-barr.com에 대한 대부분의 방문자에 대해서는 정적인 콘텐츠를 제공하여 아시아로부터의 방문자에 대해서는 동적 콘텐츠를 제공하고 싶다면, 다음과 같은 절차를 밟습니다. 우선 S3버킷을 가르키는 “www”의 레코드 세트를 작성합니다.:

그리고 레코드 세트를 작성해 위치를 아시아로 향하게 합니다. 이것은 Elastic Load Balancer를 바라보게 합니다.:

가격 인하
마지막으로 Standard 및 LBR(Latency-Based Routing)의 요청에 대한 요금을 20% 인하하게 되었습니다. 가격 인하는 2014년 8월 1일부터 시작합니다.:

Standard Queries -$0.40(100만 쿼리마다)-최초 10억 쿼리/월$0.20(100만 쿼리마다)-10억 쿼리 이상/월
LBR Queries -$0.60(100만 쿼리마다)-최초 10억 쿼리/월$0.30(100만 쿼리마다)-10억 쿼리 이상/월
Geo DNS Queries -$0.70(100만 쿼리마다)-최초 10억 쿼리/월$0.35(100만 쿼리마다)-10억 쿼리 이상/월

지금 당장 이용할 수 있습니다
이들의 새 기능은 지금 당장 이용할 수 있습니다. 또 가격 인하도 이미 적용됩니다!

— Jeff;

본 글은 Route 53 Update – Domain Name Registration, Geo Routing, and a Price Reduction의 한국어 번역입니다.