Category: 한국 기술 문서


AWS Lambda와 WAF를 이용한 Rate-Based Blacklisting 기능 구현

여러분들 대다수는 원하지 않는 요청이나, crawl-delay directive의 기준을 무시하는 봇이나 크롤러 같은 스캐닝 도구로 인해 웹서버의 가용성에 문제가 발생하는 경우를 고민해 보셨을 것입니다. 흔히 HTTP flood 라고 불리는 분산 서비스 거부 공격(DDoS)의 목적은 시스템에 부담을 일으켜서 정상 사용자의 사용을 방해하기 위한(아래 그림 처럼) 것입니다.

이 글에서는 원하지 않는 트래픽을 요청량 기준으로 자동으로 탐지하고 AWS WAF (현재 WAF의 기능은 Amazon CloudFront 의 컨텐츠 배송 서비스 상에서 동작합니다)의 구성을 업데이트하여 악의의 사용자로부터의 요청을 차단하는 방법을 소개합니다.

이와 같은 기능을 AWS Lambda를 사용하여 CloudFront의 엑세스 로그에서 악성 요청을 식별하도록 구현하게 됩니다. 이 기능은 Amazon CloudWatch 상의 메트릭들을 활용하여 얼마나 많은 요청들이 처리되었고, 블락된 오리진의 수가 얼마인지를 모니터합니다. 또한 AWS WAF서비스는 수작업으로 잘 알려진 봇 네트웍 같이 금지하고 싶은 IP 대역을 추가할 수도 있습니다.

위 그림은 모든 요청을 처리하다가 웹서버의 모든 리소스를 소진하는 모양을 나타냅니다. 아래 그림은 본 포스팅에서 제시된 방법을 통해 블랙리스트 처리된 소스로부터의 요청을 차단하는 과정을 도식화 한 것입니다.

솔루션 개요

여러분의 리소스에 대한 부담을 방지하기 위한 방식은 요청률 기반 블랙리스팅(rate-based blacklisting)을 구현하는 것입니다. 이를 통해 웹 어플리케이션 환경이 얼마나 많은 요청들을 처리할 수 있는지에 대한 임계치를 세울 수 있습니다. 만약, 봇, 크롤러 혹은 임계치를 상회하는 공격이 들어온다면 AWS WAF를 통해 자동으로 차단될 것입니다.

위의 그림에서 회색 박스에 포함된 영역이 이 기능을 수행하는 AWS서비스들입니다. 시나리오를 위해 CloudFront와 Amazon S3, Amazon EC2, Amazon RDS를 사용하여 웹사이트의 정적, 동적 컨텐츠를 제공하도록 구성합니다. CloudFront가 웹 어플리케이션에 대한 요청을 받을 때마다, AWS WAF는 모든 요청들을 검사하고, 해당 요청을 허용할 지, 차단할지를 소스 IP기준으로 CloudFront에 설정합니다. 아래 그림은 전체적인 아키텍쳐와 동작 순서를 보여줍니다.

  1. CloudFront 가 웹어플리케이션 앞 단에서 요청들을 받고, 요청에 대한 구체적인 정보를 담아서 S3버킷으로 access logs를 보낸다.
  2. S3버킷에 신규 엑세스 로그들이 저장될 때 마다, 람다 펑션이 기동된다.
  3. 람다 펑션은 어떤 IP로부터 기준치 이상의 요청이 들어 왔는지를 분석하고, AWS WAF 블락 리스트에 추가한다. AWS WAF는 지정된 기간동안 해당 IP를 블락한다. 이 지정된 기간이 끝나면, AWS WAF는 다시 해당 IP로부터의 요청을 허용한다. 단, 해당 IP로부터의 트래픽을 모니터링하는 것은 계속된다.
  4. 람다 펑션은 분석된 요청들의 갯수나 블락된 IP주소의 갯수 같은 CloudWatch 메트릭들을 퍼블리싱 한다.

다음은 AWS 서비스들이 어떤 방식으로 정해진 작업들을 수행하는지를 설명합니다.:

  • AWS WAF – 수정 가능한 웹 보안 규칙을 정의하고 이것을 통해 웹 어플리케이션으로의 트래픽을 허용하거나 차단하는 기능을 제공합니다. 이 서비스에서는 아래와 같이 3가지 규칙을 사용하게 됩니다.:
    1. 자동 블락킹 – 이 규칙은 악성 요청으로 식별된 IP주소를 추가합니다. 지금 시나리오에서는 이 규칙을 설정함과 동시에, 블락리스트된 IP주소들에서 들어오는 모든 신규 요청들이 드랍되기 시작하고, 람다가 지정된 폐기 기간(디폴트로 4 시간 설정됨)이 지나 해당 IP를 블락리스트에서 제거하기 전까지 유지됩니다.
    2. 수동 블락킹 – 이 규칙은 수작업으로 특정 IP 주소를 블락 리스트에 추가하는 데 사용됩니다. 해당 IP주소는 관리자가 수작업으로 리스트에서 제거하기 전까지 계속 블락됩니다.
    3. 자동 카운트 – 이것은 일종의 휴지통 개념입니다. 지정된 IP로부터의 요청이 바로 블락킹되지는 않고, 준 실시간성으로 요청 갯수가 트랙킹됩니다. 이를 통해 자동 블락 리스트에서 제거된 이후 해당 IP의 행동에 대한 가시성을 제공해 줄 수 있습니다.
  • Lambda – 서버를 준비할 필요없이 코드를 실행시켜 주는 서비스 입니다. 단지 여러분의 코드를 업로드하면 람다에서 알아서 실행에 필요한 모든 것을 담당합니다. 람다를 통해 다른 AWS서비스들이 행동기반으로 자동으로 기동되도록 작성될 수 있습니다. 이번 시나리오에서는 S3에 엑세스 로그 파일이 업로드 될때 마다 람다 펑션이 실행되도록 구성하였습니다. 이 기능은 해당 로그 파일내 공격자IP들을 식별하고 그것들을 AWS WAF로 블락킹 처리하도록 하는 과정을 담당합니다.
  • CloudFront – 컨텐츠 배포 웹 서비스로서, 다른 AWS서비스들을 통합하여 낮은 레이턴시와 높은 전송 속도로 컨텐츠를 배포할 수 있는 쉬운 방법을 제공합니다. CloudFront는 기본적으로 한시간 내로 엑세스 로그를 제공합니다. 그러나 어떤 로그는 지연될 수 있습니다. 이 시나리오에서 CloudFront는 웹 어플리케이션의 동적, 정적 컨텐츠를 제공하게 됩니다.
  • S3 – 높은 가용성, 확장성, 내구성과 낮은 레이턴시를 가진 저장소를 저렴한 비용으로 이용할 수 있도록 합니다.  이번 시나리오에서는 CloudFront의 엑세스 로그파일이 지정된 S3버킷에 저장되도록 구성됩니다.
  • CloudWatch – AWS상에서 운영되는 어플리케이션과 각종 리소스들에 대한 모니터링 서비스 입니다. 이번 시나리오에서는 람다 펑션에 의해 처리되는 요청의 갯수와 블락된 IP주소의 갯수에 대한 메트릭을 트랙킹하게 됩니다.
  • AWS CloudFormation – AWS인프라의 전개를 주기적으로 혹은 반복적으로 수행할 수 있도록 해주는 서비스입니다. CloudFormation을 통해 필요한 모든 리소스와 상관관계를 하나의 템플릿 파일로 정의할 수 있습니다. 이번 시나리오에서는 필요한 전체 솔루션 스택을 한번에 쉽게 구성할 수 있도록 준비하였습니다.

이번 시나리오에서는 S3버킷, 분당 요청수 제한기준, 블랙리스트에 IP주소를 담아두는 기간 등을 설정하게 됩니다.

AWS 관리 콘솔을 통해 진행하기

시작하기 앞서, 컨텐츠를 제공할 CloudFront 배포지점이 이미 있다고 가정하겠습니다. 만약 없다면, 다음 절차(Creating or Updating a Web Distribution Using the CloudFront Console)대로 만들어 보십시오. 본 시나리오에선 필요한 환경을 간단히 구축하기 위해 CloudFromation 템플릿을 활용해 보도록 하겠습니다. 관련 내용이 알고 싶으시면 이 내용(CloudFormation User Guide)을 참고하시기 바랍니다.

단계 1: CloudFromation 템플릿을 사용하여 환경 구축

  1. CloudFormation console로 갑니다.
  2. 각자 적합한 리전으로 변경합니다. CloudFormation을 사용하게 되면 모든 리소스들이 CloudFormation템플릿을 생성했던 리전에 생성됩니다. 이번 시나리오에서는 람다를 활용하기 때문에, 어느 리전이 람다 활용이 가능한지 확인하기 위해 AWS Global Infrastructure Region Table 을 체크합니다.
  3. 신규 스택 생성(Create New Stack) 버튼을 클릭합니다.
  4. 템플릿 선택화면에서, GitHub(this GitHub repository)에서 waf_template.json를 찾아서 업로드 합니다.
  5. 상세 내역 화면에서, (아래 화면 예시 처럼):
    1. Stack name란에, 적당한 스택이름을 줍니다. 스택이름을 너무 길게 주는 경우, 람다펑션을 실행 할때 에러가 날 수도 있습니다.
    2. Create CloudFront Access Log Bucket란에서 CloudFront Access Log를 위한 버킷을 만들려면 yes를 클릭하고, 기존 버킷을 활용하려면 no를 선택합니다.
    3. CloudFront Access Log Bucket Name란에 CloudFront가 엑세스 로그를 넣기 위한 S3버킷의 이름을 지정합니다. 만약 b 단계에서 no 를 선택했다면 공란으로 놔둡니다.
    4. Request Threshold란에 분당 기준으로 블락킹 없이 제공될 수 있는 최대 요청 갯수를 지정합니다.
    5. WAF Block Period란에 초단위로 임계치를 넘은 IP주소에 대해 얼마동안 블라킹을 할 것인지 설정합니다.
    6. WAF Quarantine Period란에 AWS WAF가 블락킹에서 해제된 IP를 얼마동안 모니터링 할 것인지 설정합니다.
    7. Options 페이지에서 Next를 클릭합니다.
    8. Review 페이지에서 ‘I acknowledge that this template might cause AWS CloudFormation to create IAM resources‘ 체크 박스를 체크하고 Create를 클릭합니다.

이 템플릿으로 이번 시나리오를 실행하는데 필요한 모든 요소들이 마련됩니다: 람다 펑션, 모든 필요한 규칙들이 설정되어 있는AWS WAF Web ACL ( Malicious Requesters라는 이름으로), CloudWatch 커스텀 메트릭, 그리고 만약 Create CloudFront Access Log Bucket란에서 yes를 선택했다면 CloudFront Access Log Bucket Name 란에 주어진 이름으로 버킷이 생성될 것입니다.

단계2: CloudFront 배포 설정 업데이트

AWS WAF를 활성화 시키고, 전 단계에서 생성했던 버킷을 가지고 로깅을 하기 위해 CloudFront 배포 설정을 업데이트 합니다. (만약 이미 CloudFront Access Log를 위한 S3버킷을 가지고 있다면 이번 단계를 생략합니다):

  1. CloudFront console을 열고 업데이트 대상 배포지점을 선택합니다.
  2. Distribution Settings  화면에서, General 탭을 선택하고 Edit를 클릭합니다.
  3. AWS WAF Web ACL 설정을 업데이트 합니다(아래 그림처럼). 옵션 메뉴에는 모든 활성화된 Web ACL들이 나타나는데, 여기서 단계 1에서 생성했던 것(Malicious Requesters)을 선택합니다.
  4. Logging란에 On을 선택합니다.
  5. Bucket for Logs란에 단계 1에서 지정했던 버킷을 선택합니다.
  6. 변경내용을 저장합니다.

만약 CloudFront Access Log를 위한 S3버킷을 이미 가지고 있다면, 신규 로그파일이 해당 버킷에 추가될 때마다 람다 펑션을 기동시키기 위해 S3 이벤트 통보 기능을 활성화 합니다(more details을 참조하세요). 이를 위해, S3 console 을 오픈하고 버킷 속성에서 다음 그림에서 표시된 부분처럼 설정해 줍니다. 만약 람다 펑션 설정 부분이 비 활성화 되어 있다면, 해당 버킷이 CloudFormation팀플릿을 실행했던 리전인지를 확인하기 바랍니다.

단계 3: [생략 가능] CloudFormation 파라메터 수정

만약 단계 1에서 CloudFormation 스택을 생성한 뒤에 설정했던 파라메터 값을 변경하고자 한다면(예를 들어, IP 관련된 블락킹 기간 등을 바꾸고자 하는 경우), 새로 스택을 만들 필요없이 아래 절차대로 변경하면 반영됩니다:

  1. CloudFormation console에서 스택 목록 중 원하는 것을 선택합니다.
  2. Actions 을 클릭하고Update Stack.을 선택합니다.
  3. Select Template 페이지에서, Use the current template을 선택하고 Next를 클릭합니다.
  4. Specify Details 페이지에서, Rate-Based Blacklisting Parameters값을 원하는 값으로 변경합니다(예를 들자면 아래 그림처럼):
  5. Options 페이지에서, Next를 클릭합니다.
  6. Review 페이지에서, I acknowledge that this template might cause AWS CloudFormation to create IAM resources 체크박스를 클릭하고 Update를 클릭합니다.

CloudFormation 은 새로운 파라메터 값으로 스택을 업데이트 하게 됩니다.

AWS CLI 이용하여 스택을 생성하는 방법

이외에도, 여러분들은 AWS CLI를 써서 스택을 생성할 수도 있습니다. 아래 코드는 스택을 만드는 한가지 샘플입니다.(red로 표시되는 부분이 변경될 부분입니다).

aws cloudformation create-stack --stack-name <STACK_NAME> --template-body file:///<PATH_TO>/waf_template.json --capabilities CAPABILITY_IAM --parameters ParameterKey=CloudFrontCreateAccessLogBucket,ParameterValue=yes ParameterKey=CloudFrontAccessLogBucket,ParameterValue=<LOG_BUCKET_NAME> ParameterKey=RequestThreshold,ParameterValue=400 ParameterKey=WAFBlockPeriod,ParameterValue=1400 ParameterKey=WAFQuarantinePeriod,ParameterValue=14400

또한 this GitHub repository에서 waf_template.json 을 찾을 수 있습니다.

테스팅

이번 포스팅에서 제시된 내용을 테스트 해보기 위해서는 CloudFront 가 새 로그파일을 생성할 때 까지 기다려야 합니다. 이런 대기시간이 싫다면, this sample access log file 링크에 있는 샘플을 가지고 바로 S3 버킷에 올려서 테스트 할 수도 있습니다. 업로딩이 끝나고, IP 주소값들이 자동으로AWS WAF의 Auto Block Set 섹션에 들어가 있는지 확인해 보시기 바랍니다.

그리고 CloudWatch 메트릭이 업데이트 되어 있는지도 확인해 보시기 바랍니다. 또한 람다가 로그파일을 분석하는데 몇 초의 시간이 소요되고  CloudWatch가 신규 메트릭 정보를 보여주는 데 최대 2분 정도 소요된다는 점을 알고 계시기 바랍니다. 아래 그림은 Auto Block Set 섹션에 람다에서 처리했던 IP주소들이 어떻게 들어 있는 지를 보여줍니다.

CloudWatch가 어떻게 메트릭 정보를 표시하는지 보기 위해, CloudWatch dashboard를 참조하시면 좋을 것 같습니다.

요약

본 포스팅에서, 여러분들은 지정된 기준 값 이상으로 과다하게 요청하는 특정 IP주소를 자동으로 블락킹 하는 방법에 대해 살펴보았습니다. 여기에서 제시된 Lambda script 를 가지고 여러분들의 상황에 맞게 변경하여 활용하셔도 됩니다. 예를 들어 CloudFront 가 생성하는 데이터를 분석할 수도 있겠습니다(sc-bytes of access log file 같은 정보 등을 분석하여 관련 요청을 블락킹 하는 식으로)

만약 여러분들이 본 포스팅에 대해 질문이나 코멘트가 있다면, 아래 “Comments” 섹션이나 AWS WAF forum에 남겨주시기 바랍니다.

– Heitor

본 글은 AWS Security Blog의 How to Configure Rate-Based Blacklisting with AWS WAF and AWS Lambda에 대한 번역으로 AWS코리아의 보안 분야 솔루션 아키텍트로 일하시고 있는 임기성님께서 작성해 주셨습니다. (more…)

AWS 클라우드를 배우는 방법 (1) – 국내 출간 서적

외부에서 AWS와 관련된 강의를 나가 보면, 많은 분들이 저에게 AWS 클라우드를 공부하는 방법을 물어옵니다. 모든 IT 업무 영역을 다루는 폭넓은 서비스와 깊이 있는 다양한 기능을 배우기가 쉽지는 않기 때문이실텐데요. 이 시리즈를 통해 몇 가지 좋은 리소스를 알려드립니다.

  1. AWS 클라우드를 배우는 방법 (1) – 국내 출간 서적
  2. AWS 클라우드를 배우는 방법 (2) – 온라인 교육 및 실습
  3. AWS 클라우드를 배우는 방법 (3) – AWS 전문 교육 과정

맨 먼저 많은 분들이 떠올리시는 것이 입문 할 수 있는 책입니다. 국내에서도 AWS 클라우드를 실제 사용하고 활용해 본 분들이 저술하신 책을 많이 나와 있고, 이를 통해 공부하는 것을 추천합니다. AWS 서비스의 혁신 속도가 매우 빨라서 책에 쓰인 기술이 최신의 정보는 아닐지라도, 기초와 핵심 서비스에 대한 이해를 높이는 데는 큰 도움이 됩니다.

마침 지난 주에도 국내 저자들이 직접 저술한 AWS 관련 책이 발간되기도 하였습니다. 그래서, 이 글에서는 국내에 나와 있는 저서 및 번역서를 하나씩 살펴 보고 여러분의 선택에 도움을 드리고자 합니다.

아마존 웹 서비스를 다루는 기술 : 실무에서 알아야 할 기술은 따로 있다!
(2014년 09월 – 이재홍 저)

이 책은 방대한 AWS 클라우드의 기초 개념 부터 핵심 서비스 그리고 다양한 기능을 모두 섭렵하고 있을 뿐 아니라, 간단한 튜토리얼과 스크린샷으로 직접 서비스를 해볼 수 있도록 한다는 점이 특징입니다. 책이 두꺼운 만큼 내용도 알찹니다. 뿐만 아니라 저자는 자신의 블로그인 pyrasis.com 책의 모든 내용을 직접 올려서 공개하는 파격적인 공유 정신을 실천하고 있습니다. 새로운 내용이 올라오면 블로그 내용을 업데이트하기도 합니다.

직접 책을 저술하신 이재홍님은 회사를 다니는 동안 그동안 공부하고 사용해 왔던 AWS 관련 정보를 모아서 블로그에 올리면서 많은 사람들이 도움을 주는데 보람을 느끼고 있다고 합니다. 여세를 몰아 작년에는 ‘가장 빨리 만나는 Docker’를 출간과 동시에 온라인에 올렸으며, ‘가장 빨리 만나는 Go 언어’ 역시 같은 방식으로 제공 중입니다.

아마존 웹 서비스를 이용한 글로벌 서비스 인프라 설계
(2016년 04월, 윤상배·김창수 저)

이 책은 하나의 가상 회사가 처음 AWS 클라우드를 도입할때, 프로토 타이핑부터 시작해 전 세계를 대상으로 하는 서비스로 확장하는 과정을 다루고 있습니다. 이 과정을 따라가면서 AWS를 이해하고 글로벌 서비스를 위한 인프라 구축에 대한 정보를 제공하고 있는 것이 특징입니다.

기존에 서비스를 나열하는 방식이 아니라 작은 서비스를 키워 가는 과정에서 필요한 아키텍처 변화에 대한 다양한 AWS 서비스를 소개하고 있습니다. 뿐만 아니라, 중간 중간에 개발과 운영을 병행하는 데브옵스(DevOps) 베스트 프랙티스를 소개하여, 클라우드를 통한 인프라 자동화를 통해 좀 더 개발에 집중할 수 있는 다양한 도구 즉, AWS API, CLI 및 Chef, Jenkins 등의 서드파티 CI/CD 도구를 포함하고 있는 것도 특징적입니다.

마지막 장에는 최근에 AWS가 출시한 IoT 서비스와 실시간 빅데이터 분석을 위한 Amazon Kinesis에 대한 정보도 포함하고 있습니다.

아마존 웹 서비스 클라우드 디자인 패턴 설계 가이드
(2013년 5월, 타마가와 켄 외, 박상욱 역)

다양한 IT 업무의 요구 사항을 어떻게 AWS 클라우드 서비스의 빌딩 블록을 이용하여 구축할 것인가? 이러한 질문에 대한 해답이 바로 ‘Cloud Design Pattern(CDP)’입니다. CDP는 일본의 AWS 솔루션 아키텍트인 타마가와 켄이 처음 만든 일종의 레시피 가이드로서 총 48개의 클라우드 디자인 패턴을 알기 쉽게 설명하고 있으며, 각 패턴 도입 시에 주의해야 할 것들에 대해서도 일러주고 있습니다.

특정 업무 요구 사항에 대한 AWS 서비스를 조합하는 방법과 아키텍처를 기반으로 장단점과 유의점도 포함합니다. 이 책의 내용은 아마존 웹 서비스를 기반한 일반적인 클라우드 설계의 베스트 프랙티스를 제공합니다. 실제 적용 사례를 구체적인 시나리오를 통해 소개하고 있어 직접 따라 해보며 배울 수 있도록 구성되어 있습니다.

아마존 웹 서비스 클라우드 디자인 패턴 구축 가이드
(2013년 11월, 오오사와 후미타카, 박상욱 역)

이 책은 아마존 웹 서비스 클라우드 디자인 패턴 설계 가이드의 후속작으로 CDP를 만든 감수자이 특정 웹 사이트 시나리오와 몇 가지 CDP를 실제 아마존 웹 서비스(AWS)에 적용할 때 어떻게 할 것인지를 구체적으로 설명한 것입니다. 첫번째 책을 번역하신 클라우드 노아의 CEO이자 AWSKRUG의 공동 리더인 박상욱님이 두번째로 번역한 책입니다.
책의 주요 내용은 그중 AWS의 핵심 서비스를 이용하여 우리가 흔히 구축해야 하는 아키텍처인 이미지 동영상 제공 사이트, 전자상거래 사이트, 이벤트 사이트를 실제 구축하는 경험을 제공하고 있습니다. 초반 부터 AWS의 기초적인 사항과 CDP에 대한 일반적인 부분을 다루기 때문에 굳이 앞의 책을 사지 않더라도, 실질적인 구축 경험을 얻기를 원한다면 따로 구매해서 읽어도 좋습니다.

서버/인프라 실전 구축 가이드 아마존 웹 서비스부터 도커까지
(2015년 9월, 이토 나오야 외, 성창규 역)

이 책은 대규모 웹 서비스 환경을 운영한 경험자와 아마존 웹 서비스(AWS)의 엔지니어, 실제 모바일 게임 등을 운영하는 엔지니어들이 실무에서 접한 새로운 IT 기술에 대한 경험을 다루고 있습니다. 이런 기술을 아직 접해 보지 못한 소프트웨어 개발자에게는 매우 생소할 수도 있지만, IT에 대한 기본적인 지식이 있는 엔지니어라면 누구든 따라 할 수 있도록 실습 위주로 구성돼 있어 클라우드 기술을 통해 인프라 운영을 접해 보고 싶은 엔지니어라면 도움이 될 것입니다.

책의 전반부는 클라우드를 통한 프로그래머블한 인프라 운영에 대한 기본 개념을 설명하고, 아마존웹서비스와 코드 개발로서 인프라(Infra as a Code) 운영에 대한 개념 지속적 통합(CI) 및 Docker 콘테이너 기술까지 다룬다. 흥미로운 점은 이 책의 후반부는 실질적인 클라우드 기반 웹 서버 운영 및 콘텐츠 배포와 유지 보수까지 다룬다는 점에서 균형있는 책입니다.

그 밖에도 브이시스템즈의 이근우님이 저술한 아마존 웹 서비스 A to Z(2014년 12월 발간) 및 AWS의 Chief Evangelist인 Jeff Barr가 저술한 아마존 웹 서비스 완벽활용법 (2013년 4월, 최용호 번역) 등의 입문서들도 출간되어 있습니다.

최근 AWS 클라우드 기술의 국내 도입이 빨라지면서, 출판사 및 테크라이터들이 이와 관련된 서적 출간도 예상되고 있으며 하반기에 다수의 국내 서적이 출간될 것 같습니다. 이에 대한 AWS의 도움이 필요하시면 언제든지 aws-korea-devsupport@amazon.com으로 문의하시기 바랍니다.

Channy(윤석찬);

개발자들이 말하는 AWS 기반 ‘서버 없는 아키텍처’

2014년 AWS re:Invent에서 처음 발표된 AWS Lambda는 클라우드에서 확장성에 대한 고민 없이도 경량의 애플리케이션을 실행하는 새로운 클라우드 함수입니다. 이를 통해 고객들로 부터 로그 분석, 이미지 처리 등 다양한 응용 사례들이 나오고 있지만, 그 중에서도 서버 없는(Serveless) 아키텍처를 실험하고 응용하고 있다는 점은 매우 고무적인 현상입니다.

특히, 2015년 6월 출시된 아마존 API 게이트웨이(Amazon API Gateway)와도 연계가 가능합니다. 이를 통해 외부에서 들어오는다양한 API 호출 대한 실행도 가능하여, API Gateway와 함께 AWS 자원을 제어하는 모든 종류의 기능을 수행할 수 있습니다.

모바일, 웹, 기업용 또는 IoT 애플리케이션에서 REST 기반 호출 서비스를 위한 API를 개발자가 손쉽게 생성, 게시, 유지관리, 모니터링할 수 있습니다. 기존에 API를 운영하고 있는 경우, 외부 혹은 사내팀에게 API를 제공할 때 필요한 많은 부담을 덜어주는 역할을 합니다.

오늘은 한국 개발자들이 이러한 AWS의 서버 없는 아키텍처를 어떻게 활용하고 있는지 다양한 경험들을 녹은 블로그 글들을 엄선해서 소개하고자 합니다.

AWS Lambda를 이용해서 HTTP API 만들기 #1, #2 by Outsider’s Dev Story

아주 간단한 API 두 개를 만드는데 아주 긴 설명을 했지만, 서버를 하나도 띄우지 않고 HTTP API를 만들었다. 설명은 아주 길게 했지만 실제로 하면 간단한 설정일 뿐이다.(초기에는 삽질이 좀 필요하겠지만 ) 예제는 아주 간단한 API였지만 실제로는 꽤 수준 높은 부분까지도 서버 구성을 하나도 하지 않고 이 조합으로 만들 수 있을 거라고 생각한다. 그래서 요즘 이 serverless 아키텍처에 관심이 있다.

일본어 RSS 번역해서 보기 – AWS Lambda 이용 by Seapy

이번 개발을 하면서 느낀 건 2가지였습니다. 첫째는 Node.js 도 재미있다는 거였습니다. 이번 개발을 하기 전까지는 필요성을 못 느꼈는데 서버 운영하기 싫은 간단한 것들 만들 때 Lambda에 올릴 것들은 Node.js 배워서 해보면 재미있겠다는 생각이 들었습니다. 두 번째는 Serverless 트렌드가 일회성으로 끝나지 않고 앞으로 많은 비중을 차지하게 될 것이라고 느꼈습니다. 직접 해보니 특정 영역에서 확실한 장점이 보였습니다.

AWS 람다(Lambda) 그리고 GitHub 자동배포 연동 by 개발자 PIGNOSE의 연구실

AWS Lambda를 이용하여 코드배포 자동화 서비스를 구성해볼려고 했습니다. 참고로 회사에서 기존에 이용하던 배포 프로세스는 Visual Studio를 이용해 개발을 완료, Github에 푸시하고 플러그인을 통해 AWS Beanstalk에 republish를 하였습니다. 이러한 기능을 이용하다 문득 이렇게 생각했습니다. “GitHub에 커밋으로 맨 앞에 Deploy라는 문자를 적으면 자동으로 배포할 수 는 없을까?” 이런 생각을 시작으로 Lambda를 NodeJS로 설정하고 작업을 시작했습니다.

Serverless 실시간 대전게임 by hyunjong-lee

지인의 소개로 Gaming on AWS 해커톤 행사를 알게 되었는데 서버 없는 (Serverless) 구조를 통한 게임 플랫폼 개발을 하는 것이 주제였습니다. Amazon Web Services (AWS)를 그전까지 한번도 써본적 없던 필자는 처음엔 무슨 의미인지 이해하지 못하였는데 같이 참가한 친구들의 도움으로 어떤 의미인지 뒤늦게 깨달았습니다. -_-a

Serverless 아키텍처의 세상이 온다 by 골빈해커의 생각의 파편들

AWS Lambda와 API Gateway가 런칭할 때부터 관심은 가지고 있었지만…최근에 몇 가지 개인 프로젝트를 하면서 사용해보게 되었는데, 정말 인상적이었다. “와, Serverless의 세상이 진짜 오는구나.” 얼마전에 슬랙 명령어와 개인적으로 사용하는 범용 함수를 간단한 API로 만들어서 사용하려고 했는데, 겨우 이것때문에 EC2등의 서버를 추가하는 것이 좀 부담스러웠다. 그래서 문득 생각난 것이 AWS Lambda 여서 사용해보게 되었다. “와, 정말 편하다.”…관리적인 측면에서 이처럼 편할 수가 없다. 단순히 서버 관리뿐 아니라, 배포나 확장 문제, 또한 보안 측면에서도 거의 신경 쓸 부분이 없다. “이것이 바로 레알 클라우드 서버야” 라는 느낌이랄까?”

그 밖에 몇 가지 도움 될 만한 블로그 글 몇 가지를 더 소개해 드립니다.

많은 한국 개발자들이 이미 AWS의 다양한 서비스 빌딩 블록을 이용하여 서버 없는 아키텍처를 실험하고, 현장에서 적용해 가고 있다는 점에서 매우 감사하면서 놀랍습니다. 혹시 더 좋은 글이 있으시면 언제든지 aws-korea-blog@amazon.com으로 알려주시면 소개해 드리겠습니다.

더 자세한 정보는 AWS Lambda 한국 블로그 글AWS Compute 블로그 (영문)을 참고하시면 도움이 되실 것입니다.

또한, AWS 기술 백서 중 AWS Serverless Multi-Tier Architectures (영문)를 통해 보시면 세 가지 멀티 티어에 대한 설계 방법도 보실 수 있습니다.

Amazon S3 웹 사이트를 위한 서버 없는 백엔드 아키텍처 예제

모바일 앱을 위한 서버 없는 아키텍처 예제

마이크로서비스를 위한 서버 없는 백엔드 아키텍처 예제

Channy(윤석찬);

 

Amazon SES 기반 대량 메일 반송 처리 자동화

서양 격언 중 ‘Don’t reinvent the wheel.’이라는 말이 있습니다. ‘바퀴를 다시 발명하지 마라.’라는 이 말은 이미 만들어져서 잘 되고 있는 것을 처음부터 다시 만들 필요는 없다는 의미입니다. 즉, 불필요하게 처음부터 다시 시작하지 말라는 것을 강조하는 말입니다.

AWS는 여러분이 꼭 사용해야 하지만, 새로 만들 필요 없는 다양한 애플리케이션 서비스를 제공합니다. 그 중에 대용량 메일을 보낼 때, 유용하게 사용할 수 있는 Amazon Simple Email Service가 있습니다.  Amazon SES는 대용량 메일 전송에 따른 확장성이 우수하고, 비용 효율적인 이메일 서비스입니다. 아마존이 가지는 공신력에 기반하기 때문에, 사설로 메일로 보내는 것보다 상대적으로 블록 당할 우려가 적으면서 동시에 대량 메일을 발송 처리 할 수 있습니다.

AWS 고객 중 사용자에게 제공할 각종 뉴스 제공 뿐 아니라, 로그인 계정을 생성하거나 인증을 할 때 메일을 통해서 진행하는 경우가 많고, Amazon SES는 가장 좋은 선택 사항입니다.

Amazon SES를 통해 대량 메일을 전송하는 경우, 한가지 주의점은 바로 반송(Bounce)되는 메일 주소에 대한 관리입니다. 너무 높은 반송률이 일정 기간 지속되면, 미리 사전 안내를 하고 그래도 지속되면 해당 계정을 차단하게 됩니다.

특히, 글로벌 대상 게임 서비스를 하는 경우, 메일 전송 대상이 블록 되기 쉬운 중국 지역이거나 기타 관리되지 않는 메일 계정으로 대량 발송되는 경우 반송이 많이 발생할 수 있는데, 해당 메일 계정으로 다시 발송 되지 않도록 하는 것이 중요합니다. 이를 위해서는 발송 메일 리스트를 적절하게 DB화해서 관리하는 것과 더불어 반송 메일의 리스트를 추출해서 발송 메일 리스트 DB에 반영하는 자동화된 관리가 필요합니다.

이번 글에서는 반송 메일의 구조와 그것을 자동화하기 위한 접근 방안을 살펴보겠습니다.

반송 메일 시뮬레이션
Amazon SES에서는 반송 메일을 시뮬레이션 할 수 있는 기능이 존재합니다. 간단한 설정을 거쳐 도메인명을 등록할 수도 있고, 개별 이메일 주소를 등록해서 사용할 수도 있습니다. 여기서는 반송 메일을 확인해 보기 위해서 간단히 메일 주소를 등록하도록 합니다. 본인이 테스트를 할 수 있는 메일 계정을 그림 1과 같이 등록을 합니다.


[그림 1] 이메일 주소 등록

메일을 등록하고 나면, 해당 메일 주소로 확인을 위한 링크 메일이 옵니다. 링크를 클릭하고 나면 메일 계정은 “확인됨 (verified)”으로 바뀝니다.


[그림2] 확인됨으로 변경된 이메일 주소

반송 시뮬레이션은 간단합니다.

메일 주소를 클릭하면 상세 정보 화면이 나오는데, 알림(Notification) 항목에서 원하는 반송 메일에 대한 SNS 알림을 구성할 수 있습니다. 여기에는 피드백, 불만 메일 등이 포함됩니다. 여기서는 단순히 반송(Bounce) 메일에 대한 SNS 토픽을 구성하도록 합니다.


[그림3] 다양한 알림의 구성

Edit버튼을 눌러 반송에 대한 SNS 토픽을 지정하면 되는데, 그를 위해서 미리 SNS 토픽을 생성하면 됩니다. 생성한 토픽을 설정에서 등록하면 되는데, 그림 4 처럼 설정하면 됩니다.


[그림 4] 반송에 대한 SNS 토픽 지정

토픽을 지정하고 난 다음, 반송 메일 테스트를 진행할 수 있습니다. AWS는 테스트를 위한 메일 주소를 제공하는데, 다음 링크를 보면 몇 가지 시뮬레이션을 위한 테스트 메일 계정이 제공됩니다.

▶ SES 이메일 전송 테스트: http://docs.aws.amazon.com/ko_kr/ses/latest/DeveloperGuide/mailbox-simulator.html

5개의 이메일 주소가 제공되는데, 반송 메일을 위한 주소는 bounce@simulator.amazonses.com 입니다. “Send a Test Email” 버튼을 눌러서 그림 5와 같이 반송 테스트 메일로 주소를 보내면 SNS 토픽에 지정된 구독자로 메시지가 전달됩니다.


[그림 5] 반송 시뮬레이션

반송 메시지를 보면 아래 내용과 같습니다.

{
    "notificationType":"Bounce",
    "bounce":{
        "bounceSubType":"General",
        "bounceType":"Permanent",
        "reportingMTA":"dsn; a8-52.smtp-out.amazonses.com",
        "bouncedRecipients":[
            {
                "action":"failed",
                "emailAddress":"bounce@simulator.amazonses.com",
                "status":"5.1.1",
                "diagnosticCode":"smtp; 550 5.1.1 user unknown"
            }
        ],
        "timestamp":"2016-04-14T03:32:10.835Z",
        "feedbackId":"0100015412d37d6e-0db83713-bf1f-4d7d-8042-8f0c970ea69e-000000"
    },
    "mail":{
        "timestamp":"2016-04-14T03:32:10.000Z",
        "source":"seanparkxxxx@gmail.com",
        "sourceArn":"arn:aws:ses:us-east-1:55062xxxxxxx1:identity/seanparkxxxx@gmail.com",
        "messageId":"0100015412d37b9d-05f93ae2-7bff-44c0-a17e-873fa090b77e-000000",
        "destination":[
            "bounce@simulator.amazonses.com"
        ],
        "sendingAccountId":"550622xxxxx1"
    }
}

여기까지는 반송 시뮬레이션을 위한 간단한 튜토리얼에 해당합니다. 이제 자동 처리를 위해서는 이러한 메시지를 구분해서 특정 저장소에 저장하는 것이 바람직합니다. 우리는 이 메시지를 Amazon DynamoDB에 저장해서 사용하도록 합니다.

반송 메일 자동 저장 하기
여기서는 자동화를 위해서 SNS 토픽을 생성하고, 이 토픽이 AWS Lambda 함수를 호출해서 DynamoDB에 메시지를 저장하도록 할 예정입니다.

이러한 각 서비스의 생성을 위해서 CloudFormation을 통해 생성을 합니다. 다음 링크의 CloudFormation 템플릿을 다운 받아 사용하십시오.

CloudFormation 템플릿의 내용을 전체 소스를 설명하기 보다는 필요한 내용만 살펴보도록 합시다. 먼저 람다 함수를 위해서는 실제 람다의 구현 소스와 LamdaExecutionRole 그리고 LambdaInvokePermission이 필요하다.

아래 소스 코드 구조는 이러한 내용을 담고 있습니다.

"PushSNSTopicToDDBFucntion": {
      "Type": "AWS::Lambda::Function",
…
    },
    "LambdaExecutionRole": {
      "Type": "AWS::IAM::Role",
      …
        }]
      }
    },    
    "LambdaInvokePermission": {
      "Type": "AWS::Lambda::Permission",
      "Properties": {
        …
      }
    },

그 다음에는 DynamoDB 테이블을 지정하고 있습니다. DynamoDB의 경우, 키 스키마에 쓰일 속성을 정해 주어야 합니다. 또한, 키 스키마의 경우 HASH, RANGE는 순서대로 기술해야 하며 그 순서가 뒤바뀌면 에러를 내보냅니다.

이 템플릿을 실행해서 서비스를 생성하고, 생성된 토픽만 SES에서 연결해 봅시다. 그림 6은 템플릿을 생성할 때의 파라미터입니다. DynamoDB의 읽기/쓰기 용량을 지정할 수 있는데, 기본 값은 5입니다.


[그림 6] 템플릿의 파라미터 설정

그런 이후 시뮬레이터를 실행하면 DynamoDB에 그림 7과 같이 메시지들이 들어가 있는 것을 확인할 수 있습니다.


[그림 7] 반송 메시지의 DynamoDB 입력 모습

자동화를 위해 CloudFormation으로 SES 토픽, 람다 함수 그리고 DynamoDB 테이블을 생성하여 반송 메일 메시지를 저장하도록 하였습니다. 이제 여러분이 조금만 수정을 하면 반송 메일을 효율적으로 수집하고 처리할 수 있는 자동화 구성이 가능하게 됩니다.

예를 들어, SQS를 이용해서 반송 메일 주소를 처리하게 하는 방법을 사용하거나, 람다 함수를 수정해서 RDB에 업데이트를 하는 방법도 가능할 것입니다.

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

AWS 관리 콘솔에서 교차 계정 접근(Cross-Accounts Access) 활용하기

AWS는 클라우드에서 보안을 최우선으로 하며, 다양한 보안 관련 서비스와 기능 및 선택 사항을 제공하고 있습니다. 특히, 사용자 권한 관리는 AWS IAM(Identity and Access Management)이라는 서비스를 통해 구성하고 관리하게 됩니다. IAM은 다양한 기능을 가지고 AWS 리소스를 사용하는데, API 수준의 세부적인(fine-grained) 접근 제어를 지원합니다.

IAM 서비스 및 교차 계정 접근 제어
IAM 기능을 잘 활용할 경우 고객 서비스 운영 중 특정 사용자나 관리자 또는 개발자의 권한을 모두 구분하여 제어할 수 있습니다. 따라서, 잘못된 운영이나 실수를 권한을 제한하여 막을 수 있고, 필요에 따라서 제한적으로 가능하게 할 수 있습니다.

예를 들어 네트워크 관리자에게 데이타베이스에 대한 접근 운영 권한을 주는 것은 좋은 방법이 아닐 것입니다. 이러한 제한은 사고를 방지할 수도 있으며, 경우에 따라 API 권한(credential)을 획득한 악의적인 접근을 IAM을 통해 원천적으로 차단할 수도 있습니다.

IAM은 사용자(User, 이하 User)라는 개념과 역할(Role, 이하 Role)이라는 개념을 동시에 제공합니다. User는 특정 권한을 가진 사용자를 뜻하며, 별도의 URL을 통해 AWS 관리 콘솔에 직접 로그인할 수 있는 사용자(사람)을 의미합니다. 역할의 경우는 특정 권한을 특정 서비스나 사용자에 부여할 수 있으며, 변경도 가능합니다. 뿐만 아니라, Role은 password나 access key가 없어 상대적으로 보다 안전하게 사용이 가능하며, User는 Role의 권한을 받아 AWS 리소스에 편리하고 안전하게 접근이 가능합니다.

다만, 여러 User가 복수 계정에서 서로 다른 Role을 손쉽게 이동하면서 관리해야 할 경우를 위해 지난 해 교차 계정 접근 제어(Cross-Account Access) 기능을 출시하였습니다. 이를 통해 AWS 관리 콘솔에서 Role 전환을 쉽게 할 수 있게 하여, User가 여러 AWS 계정 (또는 여러 Role) 환경에서 효과적으로 일을 더 쉽게 할 수 있게 됩니다.

또한, 관리자가 허용한 특정 User에 대해 다른 사용자 이름과 암호를 입력(혹은 기억하는)없이 다른 계정을 관리하기 위해 역할을 전환할 수 있습니다. 위의 설명한 교차 계정 접근 제어는 API로도 가능하나, 오늘은 AWS 관리 콘솔에서도 어떻게 설정하는지 간단한 예를 들어 설명드리겠습니다.

IAM User와 Role 생성하기
우선 AWS IAM에서 Chulsoo라는 User를 생성합니다. User를 생성하고 해당 User 가 AWS 관리 콘솔에 로그인 하기 위해서는 암호 설정이 필요합니다.

User를 생성한 후에 Chulsoo를 선택하여 암호를 설정합니다.

Chulsoo는 현재 아무런 권한이 없으므로 암호를 설정한 후에 AWS 관리 콘솔에 로그인은 가능하나, 다른 작업을 전혀 할 수 없습니다.

이제 Chulsoo라는 User에게 VPC 관련 설정을 할 수 있는 권한을 주고 싶다면, 권한을 가진 Role을 생성하여 진행 할 수 있습니다. IAM 메뉴에서 Role을 선택하고 Create new Role을 선택합니다.

여기서는 NetworkAdmin 이라는 이름으로 Role을 생성합니다. Role을 생성한 후 해당 Role을 다른 AWS 계정 또는 현재 사용중인 AWS 계정에게 권한을 위임 가능하게 하려면, Role for Cross-Account Access를 선택하여 Provide access between AWS accounts you own을 선택합니다. 즉, 해당 Role을 역서 선택한 Account에게 권한을 위임할 수 있도록 허가하는 것입니다.

위와 같이 선택하여 진행하면 아래와 같이 계정 ID(Account ID)를 입력하는 곳으로 넘어갑니다. 본인의 계정 ID를 안다면 입력하고, 만약 모른다면 Console에서 My Account메뉴에서 본인의 Account ID를 확인할 수 있습니다.

Role과 동일한 Account 인 경우에도 입력이 필요하므로 꼭 입력을 하여 진행합니다. 입력 후 진행하면 이제 해당 Role이 가질 Policy를 선택합니다. 이 예제에서는 NetworkAdmin으로 이름에 맞게 VPC권한을 선택합니다.

Policy 선택 후 진행하면 아래와 같이 설정된 설정한 Role에 대한 정보와 유용하게 사용될 Switch role을 위한 링크가 제공됩니다.

User에 Role 권한 추가하기
다음으로 특정 User 역시 Role을 사용할 수 있도록 권한을 주어야만 합니다. 즉, Chulsoo는 NetworkAdmin Role을 실행할 수 있는(Assume) 권한이 있어야만 합니다. 위 단계에서 생성된 Role ARN을 기억하여 Chulsoo의 권한 설정을 진행합니다.

IAM의 User에서 Chulsoo를 선택하고 Permissions에서 Inline Policies를 선택합니다. IAM Policy 문법을 모른다면 Policy Generator를 선택하면 쉽게 Policy를 구성할 수 있습니다.

Policy Generator를 선택 후 아래와 같이 입력합니다. 풀어 설명하면 권한을 허가(Allow)하는데 해당 허가하는 AWS Security Token Service의 AssumeRole API를 Amazon Resource Name(ARN)에 대해서 허가한다는 정책입니다.

Review Policy에서 구성된 Policy를 확인할 수 있습니다. 아래와 같은 정책이 생성되어 해당 User에 적용됩니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1458698661000",
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole"
            ],
            "Resource": [
                "arn:aws:iam::XXXXXXXXXXXX:role/NetworkAdmin"
            ]
        }
    ]
}

Switch Role 사용하기
이제 User와 Role이 모두 생성되었으니, 해당 User로 AWS 관리 콘솔에 로그인합니다. User로 로그인하기 위해서는 별도 IAM User sign-in 주소를 사용합니다. IAM 대시 보드에서 주소를 확인할 수 있습니다. IAM 사용자들이 기억하기 쉬운 도메인 주소로 재설정한 후, 북마크 해서 사용할 수 있습니다.

웹 브라우저에서 해당 주소를 입력하고 앞에서 생성한 Chulsoo와 지정한 암호를 입력하여 로그인합니다. 로그인을 하였으나, 현재 아무런 권한이 없습니다. 앞에서 생성한 NetworkAdmin을 권한을 등록 사용할 수 있도록 switch role in the console 주소를 이용합니다.

만약 업무에서는 IAM을 관리하는 관리자가 요청된 권한을 가진 Role을 생성하고 switch role을 위한 아래 링크 주소를 User에게 주는 방식으로 쉽게 관리가 가능합니다.

Chulsoo user로 로그인 한 후에 위 주소를 브라우져에 입력하면 아래와 같이 Switch Role 지정 화면으로 이어집니다.

Switch Role 버튼을 누르면 바로 해당 Role로 AWS 관리 콘솔에 로그인이 됩니다. Role로 지정한 색과 이름이 오른쪽 윗 부분에 쉽게 표시됩니다.

VPCFullAccess 권한을 가진 NetworkAdmin Role을 가지고 있으므로, 다른 AWS Service에서는 전혀 작업을 할 수 없으나, VPC 메뉴에서는 모든 관련 작업을 할 수 있습니다.

예를 들어 RDS Instance를 확인하려 할 경우 권한이 없는 에러가 발생합니다.

다른 Role로 전환하기
위에서 NetworkAdmin Role을 만든 것과 동일한 방법으로 RDS만 관리할 수 있는 Role을 생성하여 동일하게 Chulsoo user가 사용할 수 있도록 추가합니다.

여기서는 RDSAdmin Role을 생성하여 구성하였습니다. 동일한 방법으로 Switch Role을 하여 등록하면 아래와 같이 RDSAdmin Role로 변경된 것을 확인할 수 있습니다.

이제 RDS메뉴로 가면 DB를 생성할 수도 있고, RDS instance도 확인이 가능합니다.

위와 같이 구성하면 이제 Chulsoo user를 NetworkAdmin과 RDSAdmin을 자유롭게 변경하면서 작업을 할 수 있습니다. 메뉴에서 원하는 Role을 선택하면 바로 해당 Role로 전환이 됩니다.

이처럼 교차 계정 접근를 통해 Role을 사용하면 동일 AWS 계정내에서는 제한적인 권한으로 안전하게 AWS 서비스를 운영하거나 사용할 수 있고, 다른 Account ID를 통해 다른 사용자에게 권한을 위임할 수도 있습니다. IAM User Credential을 배포하는 방식이 아닌 Role을 배포하는 방식을 활용하면 보다 안전하게 권한 관리를 할 수 있으며, 보안 입장에서도 편리하게 운영이 가능합니다. Dev/Test/Prod 환경에서 위와 같은 User/Role을 이용하여 AWS를 안전하게 사용하시길 권고 드립니다.

더 자세한 정보는 How to Enable Cross-Account Access to the AWS Management Console(영문)이나 도움말 – IAM 역할과 리소스 기반 정책의 차이을 참고하시기 바랍니다.

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

AWS 2016년 월간 웨비나 녹화 및 발표 자료 모음

AWS코리아에서는 AWS 클라우드 기초 지식과 최신 기술을 소개하는 온라인 세미나인 웨비나(Webinar)를 주기적으로 개최하고 있습니다. 지난 온라인 세미나 발표 자료 및 녹화 동영상을 통해서도 배울 수 있으며, 녹화 시 사용자들의 Q&A 등을 통해 더 자세한 내용도 확인하실 수 있습니다.

AWS 클라우드 기술을 이해하시는데, 도움이 되시길 바라며 매월 혹은 반기별 웨비나 일정은 Twitter 혹은 Facebook을 참고하시기 바랍니다.

알림: 동영상 다시 보기는 플래시가 설치된 PC에서만 가능합니다. (매월 업데이트 됩니다.)

8월 16일(수)

AWS 클라우드 데이터 이전을 위한 6가지 전략

6월 29일(수)

AWS 코드 서비스 특집 – 아마존 데브옵스 문화와 함께

AWS 101 기초 웨비나 – 직접 해보는 클라우드 시작하기

  • 연사: 지정아(AWS코리아, 어카운트 매니저), 양승도 (AWS코리아, 솔루션즈아키텍트)
  • * Youtube로 다시 보기

5월 25일(수)

Amazon Elasticsearch Service 소개 및 활용 방법

베스핀글로벌과 함께하는 AWS 101 기초 웨비나

3월 30일(목)

AWS Mobile 서비스 특집

NDS와 함께 하는 AWS 101 기초 웨비나

2월 27일(수)

Amazon Elasticsearch Service 소개 및 활용 방법

AWS 101 기초 웨비나

AWS Direct Connect 서울 리전에 연결하기

지난 1월 7일 Asia-Pacific (Seoul) 리전이 국내에 개설 된 이후, 가장 많은 주목을 받은 AWS 서비스 중 하나가 바로 AWS Direct Connect 서비스입니다.

AWS Direct Connect는 여러분의 회사 내부 네트워크 혹은 기존 데이터 센터 환경의 온프레미스 IT 자원과 AWS 클라우드 자원을 전용 회선으로 연결하여, 하이브리드 환경을 구축할 수 있는 서비스 입니다. 전용 회선의 장점인 높은 보안성 및 일관된 네트워크 성능을 제공하고, AWS 서비스의 트래픽 비용 (Data transfer Out)을 절감시킬 수 있는 장점이 있습니다.

이 글에서는 Direct Connect를 구성하였을 때, 구체적인 모습과 서비스 설정 방법에 대해 상세히 설명 드리고자 합니다.

Direct Connect Location이란?
AWS 클라우드의 각 리전(Region)은 독립된 건물과 네트워크를 가진 복수개의 가용 영역(Availability Zone, AZ)으로 이루어져 있습니다. 여러분의 클라우드 자원을 멀티 AZ로 구성할 수 있고, 각 AZ에 나눠진 자원들은 하나의 가상 네트워크(Virtual Private Cloud)로 구성되어 있어 손쉽게 높은 가용성을 얻을 수 있습니다.

따라서, AWS에서는 각 리전 마다 한 개 이상의 AWS Direct Connect Location(이하, DX Location)을 지정하여 각 AZ에 있는 자원들을 빠른 네트워크 환경에서 연결할 수 있습니다. DX Location은 망 중립성을 제공하는 로컬 데이터 센터 사업자 중 AWS에서 지정하는 데이터 센터 상면 공급 사업자입니다. 해당 사업자의 상면에 AWS에서 네트워크 장비들을 설치하고, 백엔드로 AWS 모든 가용 영역(AZ)과 고속 전용 회선을 통해 연결해 놓은 곳을 의미합니다.

좀 더 쉽게 말씀 드리면, AWS 리전 내 만들어진 모든 클라우드 자원과 단일 회선 연동을 통해 연결될수 있도록 해 주는 브로커 역할을 수행합니다. 전 세계에 리전별로 다수의 AWS DX Location이 운영되고 있으며, 한국에서는 KINX가 파트너로 서비스를 제공합니다. 향후 고객의 피드백에 따라 DX Location은 계속 추가될 수 있습니다.

AWS Direct Connect 서비스를 구성하기 위해서는 몇 가지 단계를 거쳐야 합니다. 첫 번째 단계는 전용 회선을 여러분의 데이터 센터에서 DX Location까지 연결 하는 것이고, 그 다음에는 AWS 관리 콘솔에서 연결 설정을 수행하는 것입니다.

구성 방법: 1단계- 전용 회선 연결
전용 회선은 엄밀히 말하면 인터넷과 완전히 분리된 일대일 임대 회선(Leased Line)을 의미하고, 기업용 전용 회선으로 실제 구현 방식은 Leased Line, MPLS, MSPP, VPLS 등의 다양한 기반 기술로 구성됩니다. 간단히 말씀드리면, 네트워크 Layer1/2레벨의 물리적 구성을 하는 것입니다.

전용 회선 연결은 국내 모든 회선 사업자를 통해 하실 수 있습니다. 다만, AWS에서는 이들 중 일정 요건을 충족하는 사업자에 AWS Direct Connect 파트너 인증을 하고, AWS 고객을 더 잘 돕도록 하고 있습니다. 현재 한국 내에 AWS Direct Connect 파트너는 드림라인, KINX, 세종 텔레콤이 있습니다.

다만, AWS Direct Connect 파트너가 아니더라도 전용 회선 연결에 대한 부분은 기존 사업자들이 시장에서 해 오던 서비스 영역과 같기 때문에 여러가지 이유로 다른 사업자의 회선을 사용하셔야 할 경우에는 사용이 가능합니다.

AWS Direct Connect 파트너 인증을 가진 사업자와 일반 회선 사업자의 가장 큰 차이점은, AWS 파트너는 AWS 서비스에 대한 전반적인 이해를 기반으로 일대일로 모든 물리적/논리적 설정을 도와드리고, 이슈 발생 시 빠르게 대응이 가능하다는 점입니다. 또한, 1Gpbs 내에서 다양한 대역폭의 선택을 원하실 경우 Direct Connect 파트너는 여러분이 원하시는 속도에 맞춰 Direct Connect 회선을 구성해 드릴 수 있는 반면에, 일반 회선 사업자는 1G또는 10G의 대역폭 만을 구성할 수 있습니다.

구성 방법 2단계- 전용 회선 연결 대역폭(Bandwidth) 결정
DX Location 상면에 위치한 AWS 네트워크 장비는 1G 또는 10G 포트 만을 가지고 있습니다. 즉, 여러분의 전용 회선은 1Gbps또는 10Gbps로만 연결이 가능하다는 것을 의미합니다.

AWS 관리 콘솔에서 아래와 같이 Direct Connect 서비스를 신청하실 때 가장 먼저 하셔야 하는 것은 DX Location을 선택 후 1G 또는 10G 중 하나를 선택하는데, 이때 선택된 대역폭에 따라 AWS에서 해당 네트워크 장비의 특정 포트를 할당해 드립니다.

그런데, 1Gpbs의 대역폭이 너무 크고 그 정도가 필요하지 않으신 경우에는, 앞서 말씀 드린대로 AWS Direct Connect 파트너를 통해서 다양한 대역폭 사이에서 신청을 할 수 있습니다. AWS 파트너는 AWS 네트워크 장비 앞단에 추가적인 장비를 설치하여 1G또는 10G회선을 나누어 서비스할 수 있으며, 파트너 전용 콘솔을 통해 여러분이 원하시는 대역폭에 따라 50/100/200/300/400/500Mbps 중 하나를 선택하실 수 있습니다.

구성 방법 3단계 – 논리적인 구성 설정
물리적인 전용 회선 연결을 모두 마치고 나면, 논리적인 설정 단계로 들어갑니다.  전용 회선 연결이 마치면, 네트워크 관점에서는 장비 포트에 전기적인 신호가 감지되어 여러분의 네트워크 장비의 해당 포트에서 녹색 불빛이 반짝거림을 의미합니다.

실제 트래픽을 흘려보내기 위해서는 논리적인 설정 즉 인터페이스 및 패킷에 대한 라우팅 설정이 필요합니다. AWS Direct Console 관리 콘솔로 가보면 다음과 같은 화면이 나오며, State가 Available로 표시됩니다. 아래의 그림에 나와있는 예시는 1Gbps의 물리적인 회선이 연결되었다는 것을 의미하는데, 실제 구성을 위해서 해당 물리 구성을 기반으로 논리적인 인터페이스를 만들고 원하는 설정을 해야 합니다.

메뉴에서 해당 연결(Connection)을 선택하고, Create Virtual Interface를 클릭하면 아래와 같은 Virtual Interface를 설정하는 화면이 나오는데, 제일 처음 해야 하는 일은 해당 인터페이스를 하나의 VPC와 연결하는 Private Interface로 설정할지, 아니면 S3와 같은 공개 인터넷 서비스에 사용될수 있는 Public Interface로 사용할 지를 결정하는 것입니다.

Private 인터페이스로 구성하기

위의 예시 에서는 먼저 Private 인터페이스를 선택했고, 해당 인터페이스가 어느 VPC에 연결될 지를 골라주는 메뉴가 있습니다. VPC에 연결할 때 사용하는 방법은 가상 게이트웨이(VPW)와 라우팅 연결을 하는 것입니다. VGW는 VPN을 구성하실 때 사용하셨던 구성 요소인데, Direct Connect에서도 VGW를 사용하게 됩니다. VGW는 각 VPC마다 단 하나만 연동될 수 있으므로, VGW를 선택하시면 해당 VGW가 연결된 VPC를 선택했다는 것을 의미합니다.

그 다음은, BGP 설정을 위한 IP Address 입력인데, Private Interface의 경우 임의의 사설 IP를 받아서 설정이 가능하므로, 비교적 간단하게 설정하실 수 있습니다.

해당 설정을 마치고, 다음 단계를 클릭하면, AWS 콘솔에서 자동으로 Router의 Configuration을 만들어 주는데, 여러분의 데이터 센터에서 사용하시는 라우터를 선택하시면 해당 설정을 그대로 받으실 수 있고, 만약 리스트에 없을 경우 Generic Configuration을 받으셔서, 수동으로 설정하시면 BGP Neighbor 가 구성 되는 것을 보실 수 있습니다.

참고로 말씀드리면, VPN 설정에서는 제공되는 라우팅 옵션으로 Static 또는 BGP 중 선택이 가능했으나, Direct Connect의 경우에는 BGP 옵션만을 제공하니 주의 하시기 바랍니다. 고객에게서 어떤 장비를 써야 하는지 추천을 요청 받는 경우가 종종 있으나, BGP라는 표준 라우팅 프로토콜이 지원되는 모든 장비를 사용하실 수 있습니다. (최근에는 라우터 뿐만 아니라 방화벽 혹은 스위치도 라우팅을 지원하는데, 일반적으로 라우팅 장비가 아닌 경우에는 BGP는 추가적인 라이선스를 구매하셔야 지원되는 경우가 있으니 잘 확인하시기 바랍니다.)

Public Interface로 구성하기
이번에는 퍼블릭 서비스를 위한 Public Virtual Interface 설정 방법을 한번 살펴 보도록 하겠습니다.

Public Interface 설정에는 Private Interfac e설정과는 다르게 반드시 사전에 준비되어야 할 한 가지가 있습니다. 즉, 해당 인터페이스에 사용될 공인 IP주소가 필요합니다. 이때 필요한 IP Range는 일대일(Peer to Peer) BGP 연결이므로 /31 bit의 공인 IP 대역을 사용하면 되는데, 만약 가용한 공인 IP가 없으실 경우에는 AWS Support를 통해 신청하시면 하나의 /31 Bit 대역의 공인 IP페어를 할당 받으실 수 있습니다.

공인 IP뿐만 아니라 공인 ASN(Autonomous System Number)도 넣으실 수 있는데, 만약 현재 ASN을 가지고 계시지 않을 경우, 사설 ASN 중 임의의 번호를 선택하실 수 있습니다. Private interface 설정과 또 다른 한 가지는 VGW를 선택하는 항목이 없다는 것입니다. 앞에서 설명 드렸듯이, VGW는 하나의 VPC와 연결되는 게이트웨이라서 퍼블릭 인터페이스 구성에는 특정 VPC에 연동이 되지는 않습니다.

모든 설정을 정상적으로 마치고 다음 단계로 넘어가면, State 가 Verifying 이라고 표시되는 화면을 보실 수 있습니다.

라우팅 설정은 이전 Private Interface 설정 때와 마찬가지로 그대로 해주시면 되는데, 설정 후에도 바로 통신이 되지는 않습니다. 그 이유는 AWS의 Public 서비스들과 라우팅 연동이 되는 구성이기 때문에 여러분이 설정하신 공인 IP주소, ASN 등이 실제 유효한 정보인지를 먼저 검증하는 과정을 거치게 되며, 이는 최대 36시간 까지 소요될 수 있습니다.

DX Location 설정 완료 및 테스트
모든 설정이 완료되고, 여러분의 라우터로 연결된(Advertised) AWS의 공인 서비스 대역을 확인해 보실 수 있습니다. 아 위와 같은 다양한 IP 대역이 수신되는 것을 보실 수 있습니다.

해당 대역들은 AWS의 VPC를 제외한 모든 Public 서비스들에 대한 엔드포인트 IP대역으로써, 이를 통해 인터넷을 통하지 않고도 Direct Connect 전용 회선을 통해 다양한 서비스들을 보다 안정적으로 사용하실 수 있습니다.

더 자세한 사항은 AWS Direct Connect 홈페이지한국어 기술 문서를 참고하시면 됩니다.

이 글에 대한 정보를 간략하게 요약한 AWS Direct Connect 가이드(PDF)을 참고하시고, DX에 대한 복잡한 질문/추가 질문은  aws-dx-korea@amazon.com나 AWS Direct Connect 파트너인 드림라인, KINX, 세종 텔레콤을 통해 문의하시기 바랍니다.

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

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

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

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

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

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

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

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

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

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

  1. 모바일 클라이언트 게임에서 지역을 알아내서 접근 자체를 막는 방법
  2. 상용 방화벽 레이어를 게임 서버와 로그인 서버에 구축하는 방법
  3. HA 프록시 등으로 프록시 서버 레이어를 구성해서 두는 방법
  4. 운영 체제 내 방화벽 기능을 이용하는 방법
  5. Amazon Route 53의 지리적 IP 라우팅 기능을 이용하는 방법
  6. 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 활용 기술 팁을 보내드리는 코너로서, 이번 글은 박선용 솔루션즈 아키텍트께서 작성해주셨습니다.

AWS Well-Architected Framework 한국어 백서 공개 (2017년 업데이트)

여러분이 애플리케이션을 클라우드 내에서 훌륭한 구조로 설계(Well-Architected)하여 그 완성도를 높힐 수 있도록 수 천개의 고객사의 협력과 AWS 솔루션즈 아키텍트를 통해 클라우드 시스템 설계를 위한 모범 사례 및 핵심 전략을 AWS Well-Architected Framework으로 정리한 바 있습니다.

이번에 한국 고객을 위해 AWS Well-Architected Framework 한국어 기술 백서(PDF 버전)를 공개합니다.

이 문서에서는 좋은 설계를 위한 몇 가지 질문을 포함하고 있습니다. 모범 사례를 기준으로 아키텍처를 비교하여, 단점을 해결하는 방법을 배울 수 있습니다. AWS Well-Architected는 보안성, 신뢰성 및 성능 효율, 비용 최적화, 운영 효율성 등 다섯 가지를 기반으로 합니다.

지난 AWS Cloud 2017 행사에서는 양승도 AWS 솔루션즈 아키텍트께서 AWS Well-Architected Framework에 대한 강연 (동영상)을 진행하였습니다.

최고의 클라우드 아키텍쳐 구성에 대한 비법도 얻으시고, 여러분의 현재 아키텍쳐에 대해 되돌아 보고, 개선할 사항을 확인해 보시기 바랍니다.

– AWS코리아 마케팅팀

AWS 보안 기술 백서 한국어 버전 대거 공개

아마존 웹 서비스에서는 2016년 1월 서울 리전 개설 이후 한국 고객들의 클라우드 보안과 관련한 다양한 정보에 대한 요구와 피드백을 받아왔습니다.

이미 글로벌 문서로 영어로 제공 중인 다양한 기술 백서 중에 특별히 보안 분야 백서를 엄선 후 한국어 작업을 진행하여, 아래와 같이 다수의 신규 보안 기술 백서를 공유할 수 있게 되었습니다.

아래 보안 기술 백서를 통해 고객들이 AWS 클라우드 보안에 대한 이해도를 높이는 데 도움이 되기를 바랍니다. 주변의 많은 분들에게 알려주시면 감사하겠습니다. (아래 링크를 누르시면, PDF 버전으로 다운로드 가능합니다.)

신규 한국어 보안 기술 백서

  • 규모별 보안: AWS 기반 거버넌스 


 – 본 기술 백서는 AWS로 워크로드를 마이그레이션할 때 자주 간과되는 장점은 제공되는 많은 거버넌스 활성 기능을 활용하여 규모에 맞는 더욱 높은 보안 수준을 달성할 수 있다는 것입니다. 이 문서에서는 AWS를 사용하여 IT 리소스에 대해 높은 수준의 거버넌스를 달성할 수 있는 방법에 대해 설명합니다.
  • 규모별 보안: AWS에서 로깅하기 


 – 본 기술 백서는 로깅과 관련된 일반적인 규정 준수 요구 사항의 개요 및 AWS CloudTrail을 사용하여 이러한 요구 사항을 충족하는 방법에 대해 설명합니다. AWS CloudTrail은 보안 및 운영 관점에서 매우 유용한 일반 로깅 도메인으로 구성되어 있습니다.
  • Securing Data at Rest with Encryption(저장 데이터 암호화)
  – 본 기술 백서는  AWS 서비스에서 데이터를 안전하게 암호화할 수 있는 옵션에 대해 개괄적으로 설명하고 암호화 키가 저장되는 위치와 암호화 키에 대한 액세스 제어 방법의 관점에서 이러한 옵션을 설명합니다. 서버 측 암호화 방법과 클라이언트 측 암호화 방법은 다양한 AWS 서비스에서 이러한 암호화를 수행하는 개별적인 예를 통해 설명합니다.
  • AWS 사용을 위한 감사 보안 체크리스트 – 본 기술 백서는 AWS 고객의 내부 규정 준수 팀과 이러한 팀의 외부 감사자 그리고 내부 검토 또는 외부 감사를 위해 AWS 사용을 평가 또는 감사하는 담당자를 대상으로 작성되었습니다. 또한 산업 또는 규제 표준에서 요구할 수 있는, 조직의 AWS 사용에 대한 보안 평가를 설계하고 실행하는 데 유용한 체크리스트를 제공합니다. 이 백서는 애플리케이션의 운영 준비 상태 평가에 유용한 운영 및 아키텍처 지침을 제공하는 운영 체크리스트 백서를 바탕으로 작성되었습니다.
  • AWS Security by Design 소개  – 본 기술 백서는 고객이 AWS 계정 설계를 정형화하고, 보안 제어를 자동화하고, 감사를 간소화하도록 해주는 보안 보장 접근법입니다. 본 백서에서는 Security by Design의 개념을 설명하고, 여러 산업계에 대규모의 보안 및 규정 준수를 유지하기 위한 4단계 접근법을 소개하며, AWS 고객이 AWS 환경에 보안을 적용하는 데 사용할 수 있는 리소스에 대해 알아보고, 제어가 작동 중인지 확인하는 방법에 대해 소개합니다.

이외, 기존에 있던 보안 컴플라이언스 관련 백서의 목록도 추가합니다.

기존 한국어 보안 기술 백서

  • AWS Security Best Practices(AWS 보안 모범 사례) – 본 기술 백서는 Information Security Management System(ISMS)를 정의하고 조직의 보안 정책 및 프로세스 세트를 구축하는 데 도움이 되는 보안 모범 사례를 제공하므로 AWS 클라우드에 있는 데이터 및 자산을 보호할 수 있습니다. 또한 AWS의 자산을 확인, 분류 및 보호하고 계정, 사용자 및 그룹을 사용한 AWS 리소스에 대한 액세스 관리 및 클라우드에서 데이터, 운영 체제, 애플리케이션 및 전반적인 인프라를 보안 조치할 수 있는 방법을 제시하는 등 다양한 보안 주제의 개요를 제공합니다.
  • AWS Risk and Compliance(Amazon Web Services: 위험 및 규정 준수)



 – 본 기술 백서는  AWS 고객이 IT 환경을 지원하는 기존의 제어 프레임워크에 AWS를 통합하는 데 도움이 될만한 정보를 제공하기 위해 작성되었습니다. 이 문서는 AWS 컨트롤을 평가하는 기본 접근법을 포함하며 고객이 제어 환경을 통합할 수 있도록 지원하는 정보를 제공합니다. 또한 일반적인 클라우드 컴퓨팅 규정 준수 문제에 대한 AWS 관련 정보를 다룹니다.
  • Overview of Security Processes(Amazon Web Services: 보안 프로세스의 개요) – 본 기술 백서는  “AWS가 내 데이터를 보호하는 데 어떠한 도움을 줄 수 있습니까?”라는 질문에 답하기 위해 작성되었습니다. 특히, AWS의 물리적 보안 운용 프로세스를 AWS 관리 하에 있는 네트워크 및 인프라의 관점에서 설명하고 서비스별 보안 구현에 대해서도 설명합니다.
  •  DDoS 대응을 위한 AWS 모범사례 – 본 기술 백서는 DDoS(Distributed Denial of Service) 공격에 대비하여 Amazon Web Services(AWS)에서 실행하는 애플리케이션의 복원력을 높이고자 하는 고객을 대상으로 합니다. 본 백서에서는 DDoS(Distributed Denial of Service) 공격의 개요, 가용성 유지에 도움이 되는 기술, 참조 아키텍처에 대한 설명을 통해 복원력 향상을 위한 아키텍처 지침을 제공합니다.