Category: Networking & Content Delivery


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

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의 한국어 번역입니다.

AWS WAF 서비스 공개

여러분 웹 서버의 access log 및 error log를 한번 살펴 보신 적이 있으신가요? 사용자 뿐만 아니라 크롤러 등의 정상적인 요청이 대부분이지만, 종종 이상하고 위험하게 보이는 로그도 볼 수 있습니다. 예를 들어, 제 서버를 한번 확인해 봤는데, 잘 알려진 패키지나 소프트웨어의 취약점을 이용하기 위해 자주 설치하는 주소로 요청을 보내는 경우가 매우 흔합니다. (소스 서버 IP 주소는 이미지 생성을 위해 바꾸었습니다~)

이 중에 하나라도 성공한다면, 공격자들이 취약점을 틈타서 서버 권한을 얻을 수 있습니다. 흔히 사용하거나 기본 아이디와 암호로 접근을 하거나 시스템 취약점, 언어 및 애플리케이션 취약점을 노리고 SQL Injection이나 크로스 사이트 사기 요청 등의 단계로 공격이 진행될 수 있습니다.

우리가 원하던 원치 않던 이러한 비정상적인 호출은 매일 항상(24×7) 일어나고 있습니다. 우리가 서버 업데이트를 잘하고, 소프트웨어 패치를 열심히 해서 공격 가능성을 줄이더라도 보호를 위한 추가적인 레이어를 두는 것이 좋습니다.

신규 AWS WAF 서비스
이를 위해 오늘 AWS WAF (Web Application Firewall)서비스를 공개합니다. 이 글을 읽어 보시면 아시겠지만, AWS WAF를 통해 AWS 기반의 웹 서비스를 애플리케이션 단계의 공격으로부터 보호하는 역할을 할 수 있습니다.

몇 분 안에 웹 애플리케이션 보호를 위한 설정을 할 수 있습니다. 한 개 이상의 웹 접근 제어 목록(Web Access Control Lists, Web ACL)을 만들고, 내장된 규칙(IP 주소 및 허용/거부 URL에 대한 조건 모음)을 통해 이에 대한 요청을 제어합니다. 이 ACL 목록은 Amazon CloudFront 배포 시 적용할 수 있습니다.

이러한 규칙 및 조건은 여러 가지 방법으로도 사용 가능합니다. 예를 들어 위에 로그에서 봤던 IP 주소를 모두 차단할 수 있습니다. 만약 비슷한 요청이 다른 IP로부터 오고 있다면, “/typo3”, “/xampp”와 같은 URL 기반으로도 차단이 가능합니다. 여러분 애플리케이션 내부에 있는 URL에 대해 접근을 허용하거나 차단할 수도 있고, SQL injection공격에 사용하는 다양한 패턴도 규칙을 만들어 둘 수 있습니다.

AWS WAF 개념
이제 실행 조건(condition), 규칙(rule), Web ACL 및 동작(action) 등에 대해 설명해 드리겠습니다. AWS WAF 관리 콘솔의 스크린샷으로 이해하시기 편합니다.

Conditions 들어오는 요청을 검사합니다. 요청 URL, 쿼리 스트링(query string), 특정 HTTP header 또는 HTTP 메소드 등 (GET, PUT 등):

공격자들이 자신들의 시도를 여러가지 방법으로 위장하는 경우가 종종 있기 때문에 조건을 만들기 앞서 여러 가지 변형 옵션을 찾아서 살펴 보는 것이 좋습니다.

각 조건은 IP 주소를 조사할 수도 있는데, /8, /16, /24 등의 범위 또는 싱글 IP인 경우 /32로 찾을 수 있습니다.

Rules 하나 이상의 조건에 대한 참조를 말하는 것으로 모든 조건이 만족 되어야 실행이 됩니다. 예를 들어 특정 콘텐츠를 차단하기 위해 IP 기반 규칙과 호출 기반 규칙을 함께 사용할 수 있습니다. 각 규칙은 Amazon CloudWatch 측정치로 만듭니다.

Actions 규칙의 일부분으로서 규칙에 부합하는 모든 조건에 대해 우리가 취할 행동을 말합니다. 그냥 두거나 혹은 차단하거나 부합하는 양을 측정할 수도 있습니다. (결정적인 동작을 취하기 전에 새로운 규칙을 실험해서 확인하는 것도 필요합니다.)

Web ACLs 각 규칙의 동작에 따른 여러 규칙을 참조합니다. 규칙 내 모든 조건에 맞기 전에는 각 (CloudFront) 배포에서 들어오는 호출을 정상적이지 않은 것으로 판단합니다. 이 때 규칙에 맞는 동작이 실행됩니다. 규칙이 맞지 않으면 기본 동작(차단 또는 허용)만 수행합니다.

WAF 지금 해보기
이제 조건, 규칙, Web ACL 등을 한번 같이 만들어 보겠습니다. 관리 콘솔 뿐만 아니라 AWS Command Line Interface (CLI), AWS Tools for Windows PowerShell, Web Application Firewall API를 활용하실 수 있습니다.

관리 콘솔에서 WebACL을 만드는 방법을 알려주는데 ProtectSite라는 이름을 사용해 보겠습니다.

허용 혹은 차단한 조건을 만듭니다.

서버 로그에서 가짜 IP를 차단하기 위해 BadIP라는 조건을 만들어 보겠습니다.

BadCompany라는 규칙도 만듭니다.

규칙을 선택하고 동작을 골랐습니다.(하나의 Web ACL에서는 여러 규칙을 사용할 수 있지만, 저는 하나만 골랐습니다.)

위에서 보다시피 기본 동작은 요청을 허용하는 것입니다. 실제로는 (조건 + 규칙 + Web ACL) 조합으로 10.11.12.217에서 오는 트래픽을 차단하고 다른 곳에서의 호출은 허용합니다.

다음 단계는 우리가 만든 Web ACL을 CloudFront 배포본에 적용하는 것입니다. (앞으로 더 많은 서비스에도 적용 예정입니다.)

단일 Web ACL을 여러 개 CloudFront 배포에 사용할 수 있습니다만 각 배포는 하나의 Web ACL만 적용 됩니다. 설정을 하면 몇 분 안에 적용이 됩니다. Web ACL이 동작해서 얼마나 규칙이 적용되는 지 CloudWatch 통계치를 통해 확인할 수 있습니다.

API 기능 소개
지금까지 설명한 모든 기능은 API로도 수행이 가능합니다.

  • CreateIPSet, CreateByteMatchSet, 및 CreateSqlInjectionMatchSet – 조건 생성
  • CreateRule – 조건에서 규칙 생성
  • CreateWebACL-규칙에서 Web ACL 생성
  • UpdateWebACL– CloudFront 배포에 Web ACL 적용

그 외에도 목록 보기, 정보 업데이트 및 삭제를 할 수 있는 API들이 있습니다.

GetSampledRequests 함수를 실행하면 5,000개의 호출을 해서 특정 패턴의 규칙이 적용되는지 확인해 볼 수 있습니다. 호출 결과 실행한 동작(ALLOW, BLOCK, COUNT)에 대한 상세한 정보를 얻을 수 있습니다.

지금 사용하기
AWS WAF은 오늘 부터 바로 CloudFront에서 사용할 수 있습니다. 가격은 $5/web ACL, $1/rule이며, 1백만 HTTP 호출당 $0.60 입니다.

— Jeff;

이 글은 New – AWS WAF의 한국어 한국어 번역이며, re:Invent 2015의 신규 서비스 소식입니다.

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

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 PolicyLatency로 설정하고, 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 데이터 전송 비용 가격 인하

AWS 중 데이터 송수신 비용에 대해 가격 인하 소식을 알려 드립니다. 아래 가격 정책은 2014년 12월 1일부터 적용됩니다.:

  • 인터넷 데이터 전송(Out)– AWS로부터 인터넷으로 데이터를 보내는 전송 가격을 이번 6~43% 인하합니다.(월별 총 데이터 전송량에 따라 다름)
  • CloudFront에 대한 데이터 전송– AWS에서 Amazon CloudFront에 대한 데이터 전송이 무료로 변경되었습니다.
  • CloudFront 엣지 데이터 전송– 미국, 유럽, 일본 호주에 있는 CloudFront 엣지에서 데이터 전송 가격을 4~29%로 인하합니다(엣지 위치와 지역에 따라 다름)

데이터 전송 가격 인하

아래 사항은 데이터 전송 가격 인하에 대한 개요입니다. 자세한 내용은 EC2 요금 페이지S3 요금 페이지를 살펴 보시기 바랍니다.

요금 조건 미국 서부
(오리건, 북캘리포니아)
유럽
(아일랜드, 프랑크푸르트)
아시아 퍼시픽
(싱가포르)
아시아 퍼시픽
(도쿄)
아시아 퍼시픽
(시드니)
10TB까지/월 -25% -25% -37% -30% -26%
이후 40TB/월 -6% -6% -43% -15% -21%
이후 100TB/월 -37% -5% -13%
이후 350TB/월 -33% -6% -14%

“10TB까지/월”요금은 AWS 무료 이용 한도의 데이터 전송이 끝난 후에 적용됩니다.

CloudFront 데이터 전송 가격 인하

CloudFront 인터넷 데이터 전송 가격에 대한 개요입니다. 자세한 것은 CloudFront의 요금 페이지를 살펴 보시기 바랍니다.

요금 조건 미국 유럽 홍콩, 필리핀
한국, 싱가포르, 대만
일본 호주
초기 10TB/월 -29% -29% -26% -26% -26%
이후 40TB/월 -4% -4% -4%

이들 요금은 AWS 무료 이용 한도 데이터 전송 사용 후에 적용됩니다.

예전 부터 추진하고 있는대로 계속적으로 가격을 인하하는데 초점을 맞추어 고객이 비용을 절약할 수 있도록 노력하겠습니다.

–Jeff

이 글은 AWS Data Transfer Price Reduction의 한국어 번역입니다.

AWS IP 대역 JSON 형식으로 공개

여러 고객들로부터 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 – 도메인 등록, 지역별 라우팅 기능 추가 및 가격 인하 단행

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에서 전송되는 정적인 자원을 받고 다른 장소에서는EC2Elastic 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일부터 시작합니다.:

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

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

Jeff;

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