Category: Compute


EC2 X1 인스턴스 타입 출시 – 2TB급 메모리 필요 업무 수행 가능

많은 AWS 고객께서 메모리가 많이 소요되는 빅데이터, 캐싱 및 분석 업무를 클라우드에서 실행하면서 더 많은 메모리를 가진 EC2 인스턴스에 대한 요청이 있으셨습니다.

작년 가을 저희는 새로운 X1 인스턴스 타입에 대한 계획을 발표하였고, 오늘 x1.32xlarge을 신규 출시합니다. 본 인스턴스 타입은 아래의 스펙을 가지고 있습니다.

  • 프로세서: 4 x Intel™ Xeon E7 8880 v3 (Haswell) 2.3 GHz – 64 cores / 128 vCPUs.
  • 메모리: 1,952 GiB – Single Device Data Correction (SDDC+1).
  • 스토리지: 2 x 1,920 GB SSD.
  • 네트워크 대역폭: 10 Gbps.
  • Dedicated EBS 대역폭: 10 Gbps (추가 비용 없이 EBS Optimized 제공).

Xeon E7 프로세서는 Turbo Boost 2.0 (3.1 GHz 이상), AVX 2.0AES-NI 뿐만 아니라 TSX-NI를 지원합니다. AVX 2.0 (Advanced Vector Extensions)는 HPC, 데이터베이스, 비디오 프로세싱 업무의 성능을 높여주며, AES-NI는 AES 암호화 처리 속도가 올라갑니다. 신규 TSX-NI는 트랜잭션 메모리라는 기능도 지원합니다. 이를 통해 동시성, 멀티쓰레드 애플리케이션이 기본적인 수준에서 각 메모리 접근을 제어하는 잠그고 해제하는 과정을 줄임으로서 공유 메모리를 효율적으로 사용할 수 있습니다.

오늘 X1 인스턴스 타입은 US East (Northern Virginia), US West (Oregon), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo), Asia Pacific (Singapore)Asia Pacific (Sydney) 리전에서 우선 출시합니다. 사용하시려면, 사용 신청을 해주시기 바랍니다. 빠른 시일 내에 다른 리전에서도 서비스할 수 있기를 기대합니다.

3년간 부분 예약 인스턴스의 비용은 시간당 $3.970 (US East (Northern Virginia) 리전 경우)이며, 더 자세한 가격은 EC2 요금표를 참고하시기 바랍니다. 예약 인스턴스전용 호스팅으로 사용 가능하며, 스팟 인스턴스 지원은 가까운 시기에 지원 로드맵에 포함되어 있습니다.

아래는 x1.32xlarge에 대한 스크린샷입니다. lscpu를 통해 128 vCPUs 쓰레드가 4개의 소켓에 연결된 것을 보실 수 있습니다.

부팅 시, 커널에서 현재 메모리량을 보여줍니다.

리눅스 top 명령을 통해 메모리 사용량을 보실 수 있습니다.

엔터프라이즈급 SAP 업무 처리 가능
X1 인스턴스는 SAP 업무에 대한 성능 인증을 받았습니다. SAP HANA에 대한 SAP OLAP 및 OLTP 성능 기준을 맞추었습니다.

현재 온-프레미스에서 운영중인 부분을 이제 손쉽게 이전할 수 있으며, SAP HANA 이전 버전 뿐만 아니라 S/4HANA와 같은 최신 차세대 소프트웨어 사용도 가능합니다.

많은 AWS 고객께서 현재 HANA를 여러개의 R3 인스턴스를 통해 사용하고 있습니다. 이러한 업무들은 하나의 X1 인스턴스에서 수행 가능합니다. 설정이 더 간편해지고 비용도 더 저렴합니다. 이전에 말씀 드린대로 SAP HANA Quick Start (PDF)를 통해 설정 방법을 배우실 수 있스니다.

또한, SAP HANA Studio를 통해 X1 인스턴스에 실행도 가능합니다.

X1 인스턴스를 통해 재해 복구(DR)이나 고가용성(HA) 같은 경우도 SAP HANA에 적용하실 수 있습니다.

  • 자동 복구 – RPO (Recovery Point Objective) 및 RTO (Recovery Time Objective) 뿐만 아니라 싱글 인스턴스에 대한 EC2 Auto Recovery 기능 사용 가능
  • 빠른 스탠바이 – 2개의 가용 영역(AZ)에 실행하여 HANA System Replication를 통해 스탠바이를 두어 동기화 가능
  • 웜 대기(Warm Standby) / 수동 장애 조치(Manual Failover) – 기본 X1 인스턴스 및 더 작은 두번째 인스턴스를 운영하면서, 장애 조치가 필요한 상황이 생긴 경우 두번째 인스턴스를 중단하고 X1으로 타입을 교체한 후 빠르게 스케일 업 전환이 가능합니다. 이는 AWS 클라우드에서만 가능한 빠른 저비용 조치 방법입니다.

오늘 HANA Quick Start 내용도 수정하여, SAP HANA를 신규 혹은 기존 VPC에서 테스트가 된 설정으로 한 시간내에 세팅하는 방법도 추가하였습니다.

시작하기 문서를 통해 SAP HANA에 필요한 운영체제 패키지와 설치 방법, 관련 설정에 대해 확인 하실 수 있습니다. 또한, SAP HANA Migration Guide(PDF)를 통해 기존 온-프레미스나 AWS 기반 SAP HANA를 어떻게 이전하는지에 대한 정보도 제공합니다.

Jeff;

이 글은 X1 Instances for EC2 – Ready for Your Memory-Intensive Workloads의 한국어 번역입니다.

EC2 Run Command 기능 업데이트 – 문서 및 명령어 관리 기능 등

EC2 Run Command를 통해 Amazon EC2 인스턴스를 편리하게 확장 가능한 방식으로 관리할 수 있습니다. (자세한 내용은 EC2 Run Command – 대규모 원격 인스턴스 관리을 참조하십시오).

오늘이 기능에 몇 가지 향상된 기능이 있습니다.

문서 관리 및 공유 – 사용자 지정 명령 문서를 작성하여 다른 AWS 계정 또는 모든 AWS 사용자에게 공유 할 수 있습니다.

사전 정의 명령 추가 – 몇 가지 새로운 사전 정의 명령을 사용하여 Windows 인스턴스의 관리를 단순화 할 수 있습니다.

오픈 소스 에이전트 – 인스턴스 용 에이전트 Linux 버전이 GitHub 오픈 소스 형태로 사용할 수 있습니다.

문서 관리 및 공유
Run Command에서 실행하는 명령 문서 관리 및 공유 할 수 있게되었습니다. 이에 따라 변동성을 줄이고 오류 출처를 제거 할 수 있기 때문에 관리 과정 상 엄격히 통제할 수 있습니다. 또한, 다른 AWS 사용자에 의해 생성 및 공유된 명령 문서를 사용할 수 있습니다.

이 기능은 고객으로부터 피드백 받은 몇 가지 시나리오를 지원하도록 설계되었습니다. 고객은 하나의 계정에서 문서를 작성하고, 같은 조직 속에 있는 다른 계정에 공유하고자 하는 의견을 제시하였습니다. 또 다른 고객은 일반적인 작업을 패키징하고, 커뮤니티에 공유하고 싶어 하였습니다. AWS 파트너는 일반적인 설치 및 제공, 고유의 관리 작업을 캡슐화하고 싶다는 의견을 주었습니다.

아래는 자신이 만든 공개된 명령 문서를 공유하거나, 공유 문서를 참조하는 방법입니다.

문서를 클릭하여 내용을 확인 할 수 있습니다.

그리고 어떤 매개 변수가 있는지 알 수 있습니다.

또한, 실행하기 전에 문서를 확인할 수 있습니다 (특히, 문서가 공유 된 것 인 경우, 아래는 권장되는 모범 사례입니다)

새로운 명령을 만들 수 있습니다 (내장 AWS-RunShellScript 명령을 단순화 시킨 버전을 사용하고 있습니다).

마지막으로 업로드하여 테스트 한 문서를 공유 할 수 있습니다. 공용 또는 특정 AWS 계정에 공유 할 수 있습니다.

이 기능에 대한 자세한 내용은 Creating Your Own Command를 참조하십시오.

사전 정의 명령 추가
많은 AWS 고객은 Microsoft Windows가 실행중인 EC2 인스턴스의 유지 및 관리에 Run Command를 사용하고 있습니다. 몇 가지 일반적인 작업을 간단하게 합리화하기 위해 설계된 네 가지 명령을 새로 추가했습니다.

AWS-ListWindowsInventory – 인스턴스의 인벤토리 정보를 수집합니다 (운영 체제, 설치된 애플리케이션, 설치된 업데이트) 결과는 S3 버킷에 저장할 수 있습니다.

AWS-FindWindowsUpdates – 적용되지 않은 Windows Update 목록을 제공합니다.

AWS-InstallMissingWindowsUpdates – 적용되지 않은 Windows Update 목록을 설치합니다.

AWS-InstallSpecificWindowsUpdates – Knowledge Base (KB) ID로 지정된 특정 Windows Update 세트를 설치합니다.

오픈 소스의 에이전트
인스턴스 Simple Systems Manager (SSM) 에이전트 Linux 버전이 GitHub의 https://github.com/aws/amazon-ssm-agent에서 사용할 수 있습니다.

이 코드에 Pull Request 제공 부탁드립니다 (자세한 내용은 CONTRIBUTING.md를 참조하십시오).

정식 출시
본 기능은 US East (Northern Virginia), US West (Oregon), Europe (Ireland), US West (Northern California), Europe (Frankfurt), Asia Pacific (Tokyo), Asia Pacific (Singapore), Asia Pacific (Sydney), 및 South America (Brazil) 리전에서 사용 가능합니다.

더 자세한 내용은 Managing Amazon EC2 Instances Remotely (Windows)  및 Managing Amazon EC2 Instances Remotely (Linux)를 참고하시기 바랍니다.

Jeff;

이 글은 EC2 Run Command Update – Manage & Share Commands and More의 한국어 번역입니다.

EC2 전용 호스팅(Dedicated Hosts) 서울 리전 출시!

오늘 부터 Asia Pacific (Seoul) 리전에서 Amazon EC2 전용 호스팅 기능을 사용하실 수 있습니다. Amazon EC2 전용 호스팅은 고객의 가상 서버를 특정 물리적 서버에 올려서 운영할 수 있는 서비스입니다. 전용 호스팅을 사용하면 기존 서버에 한정된 소프트웨어 라이선스를 사용할 수 있고, 물리적 장치에 대한 규정 준수 요구 사항을 해결하면서 클라우드 활용을 통한 빠른 혁신과 투자 비용도 절감할 수 있는 선택 사항입니다.

예를 들어 윈도 서버, SQL Server 및 SUSE Linux Enterprise Server 등 물리 서버에 라이센스 규정이 있는 소프트웨어를 사용 가능합니다. 비용에 대해서는 요금표를 참고하시면 됩니다.

현재 서울 리전에서는 M4, C4, R3, I2 및 D2 인스턴스타입에 대한 전용 호스팅을 지원합니다. 좀 더 자세한 사항은 Amazon EC2 전용 호스팅 시작하기 문서를 참고하시고, EC2에서 기존 물리 서버에서 구매하셨던 윈도 소프트웨어 라이선스를 사용하시기 위해서는 Windows Bring Your Own License (BYOL) FAQ를 참고하시기 바랍니다.

더 자세한 사항

이 글은 Amazon EC2 Dedicated Hosts are now available in the Asia Pacific (Seoul) Region의 한국어 편집본입니다.

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 Elastic Beanstalk – 신규 관리형 플랫폼 업데이트 기능

AWS Elastic Beanstalk은 웹 서비스 운영 및 웹 애플리케이션 배포를 간단하게 해주는 서비스입니다. 여러분이 개발한 코드를 업로드만 하면, Elastic Beanstalk에서 나머지 해야 할 일인 용량 미리 산정, 로드 밸런싱 설정, 오토 스케일링 및 헬스 체크 및 모니터링 등을 알아서 해 줍니다.  여러분은 Java, PHP, Ruby, Node.ps, Python, .NET, Go,  Docker 등 다양한 개발 플랫폼을 사용할 수도 있습니다.

Elastic Beanstalk은 주기적으로 새로운 플랫폼과 운영체제, 웹 서버, 언어별 프레임워크 등을 업데이트합니다. 지금까지는 이것을 수동으로 콘솔, CLI 혹은 API로 직접 업데이트 해야 했습니다. 많은 기능을 관리형으로 제공했지만, 여전히 관리해야할 항목이 하나 남아 있었습니다.

자동 플랫폼 업데이트 기능
오늘 Elastic Beanstalk에 자동 플랫폼 업데이트 기능을 추가하여, 더욱 강력한 서비스로 거듭나게 되었습니다. 주간 유지 보수 방식을 선택하면 Elastic Beanstalk이 알아서 여러분의 최신 서비스 환경을 자동으로 업데이트 합니다.

업데이트는 변경이 불가능한(immutable) 배포 모델을 사용하여 설치됩니다. 즉, 업데이트된 인스턴스가 사용 가능하게 되어 헬스체크로도 애플리케이션을 확인할 수 있을 때 까지는 기존 환경에서 변화가 없다가, 완료되면 바뀌는 방식입니다. 만약 이슈가 업데이트 도중 발생되면, 사용자 트래픽은 기존의 인스턴스로 가게 됩니다. 따라서 이러한 배포 모델을 통해 업데이트 도중에서 여러분의 애플리케이션이 기존 사용자에게 별 문제 없이 제공된다는 것을 의미합니다.

마이너 업데이트 및 패치를 자동으로 업데이트 하도록 추가할 수 있을 뿐만 아니라 관리 화면 밖에서도 업데이트를 할 수 있습니다. 다만, 중요한 업데이트의 경우, 배포 전에 애플리케이션 테스트를 해 보아야 하기 때문에 이는 자동으로 되지 않고 수동으로 작업을 하게 됩니다.

Elastic Beanstalk 콘솔에서 Configuration 탭에서 선택할 수 있습니다:

Managed Updates 탭에서 설정을 할 수 있습니다.

정식 출시
본 기능은 오늘 부터 모든 리전에서 사용이 가능하며, 추가 비용은 없습니다. 다만, 배포 모델에 따라 업데이트 시 추가로 뜨는 EC2 인스턴스에 대한 비용을 청구될 수 있습니다.

Jeff;

이 글은 New – Managed Platform Updates for AWS Elastic Beanstalk의 한국어 번역입니다.

개발자들이 말하는 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 S3 VPC 엔드포인트, 서울 리전 지원 시작

지난해 5월 11일 Amazon Virtual Private CloudAmazon Simple Storage Service (S3)를 보다 편리하게 이용하기 위해 출시된 “Amazon S3용 VPC 엔드포인트”를 소개합니다. 오늘 부터 Asia-Pacific (Seoul) 리전에서 사용 가능 합니다.

Amazon S3는 안전하고 내구성 높은 확장 가능한 객체 스토리지 서비스입니다. Amazon VPC에서 클라우드 내부에 논리적으로 분리 된 영역을 확보하고 여기에 고객이 정의하는 가상 사설 네트워크를 만들어 서비스 할 수 있습니다.

VPC를 만들 때 보안 그룹액세스 제어 목록(ACLs) 에 의해 인바운드 및 아웃 바운드 트래픽을 제어 할 수 있습니다. 지금까지 EC2 인스턴스에서 공용 리소스에 액세스하려는 경우 인터넷 게이트웨이 또는 일부 NAT 인스턴스를 이용해야했습니다.

S3용 VPC Endpoint
VPC 엔드 포인트라는 개념을 통해 VPC에서 S3로 접근이 가능해집니다. VPC 엔드 포인트는 간단한 설정, 높은 신뢰성, 게이트웨이 및 NAT 인스턴스를 필요로하지 않는 안전한 S3 연결을 제공합니다.

개별 서브넷에서 실행중인 EC2 인스턴스는 동일한 리전에 있는 S3 버킷 객체 API 접근을 제어 할 수 있습니다. S3 버킷 정책을 이용​​하여, 어떤 VPC 또는 VPC 엔드 포인트에 접근하는 방법을 설정할 수 있습니다.

VPC Endpoint 생성 및 사용
VPC Endpoint는 AWS 관리 콘솔, AWS 명령어 모드 (CLI), AWS 윈도 파워셀 도구, and the VPC API를 활용할 수 있습니다. 이 글에서는 콘솔에서 새 엔드 포인트를 작성해 보도록 하겠습니다. 콘솔에서 VPC 대시 보드를 열고 리전을 선택하십시오. 네비게이션 바의 “Endpoints”항목을 클릭하십시오.

이미 여러 VPC 엔드 포인트가있는 경우이 목록에 표시됩니다.

“Create EndPoint”를 클릭하여 VPC를 선택하고, 필요한 경우 접근 정책을 변경하십시오.

VPC 엔드 포인트 접근 정책은 신뢰하지 못하는 S3 버킷에 대한 통신 허가 및 금지를 설정 할 수 있습니다. (기본적으로 모든 S3 버킷에 통신 할 수 있습니다.) 또한, 특정 VPC 또는 VPC 엔드 포인트로 부터 통신을 제어 할 수 있습니다. 이러한 접근 정책은 "aws:SourceVpc" 또는 "aws:SourceVpce" 조건으로 만들어 집니다. (자세한 내용은 기술 문서를 참조하십시오.)

위의 스크린 샷에서 볼 수 있듯, 앞으로 다른 AWS 서비스 VPC 엔드포인트도 만들 수 있습니다.

그리고, VPC 엔드 포인트에 대한 접근 허용 VPC 서브넷을 지정합니다.

위의 스크린샷에서 보시다시피 VPC 엔드포인트를 만들 때, 서브넷의 공용 IP 주소에 의한 S3와의 통신이 약간 단절되므로 주의하시기 바랍니다.

VPC 엔드 포인트를 작성하면, S3 공용 엔드 포인트와 DNS 이름은 제대로 작동합니다. VPC 엔드 포인트는 단순히 EC2에서 S3로 통신 경로를 변경하는 것입니다.

서울 리전 기능 추가
Amazon S3의 VPC 엔드포인트 지원은 2015년 5월 11일 정식 출시 되었으며, 오늘 부터 서울 리전에서도 사용 가능합니다. 좀 더 자세한 것은 VPC 엔드포인트 기술 문서를 참고하세요.

이 글은 New – VPC Endpoint for Amazon S3Introducing Amazon VPC Endpoints for Amazon S3 in South America (Sao Paulo) and Asia Pacific (Seoul)를 편집하였습니다.

AWS Lambda 함수에서 VPC내 자원 접근 기능 출시

몇 달 전에 곧 AWS Lambda 함수에서 VPC내 자원을 접근할 수 있을 거라고 예고해 드렸습니다. 오늘 부터 이 기능을 사용하실 수 있습니다.

Lambda 함수를 통해 Amazon Redshift 데이터웨어 하우스, Amazon ElastiCache 클러스터, Amazon Relational Database Service (RDS) 인스턴스 및 특정 VPC 내에서만 접근할 수 있는 서비스 엔드 포인트에 접근할 수 있습니다. 이를 위해 자신의 VPC를 하나 선택하고 적절한 서브넷과 보안 그룹을 지정하면 됩니다. Lambda 함수가 VPC 내의 리소스에 접근할 수 있도록 하기 위해 Lambda는 이러한 정보를 바탕으로 Elastic Network Interfaces (ENI)와 사설 IP 주소를 지정합니다.

VPC내 리소스 접근하기
새로운 함수를 만들 때 설정하거나, VPC 접근을 위해 기존 함수를 업데이트 할 수 있습니다. Lambda 콘솔 또는 CLI에서 기능을 구성 할 수 있으며, 아래는 콘솔에서 설치 방법입니다.

위의 화면에 따라 설정하면 되며, 더 자세한 것은 Configuring a Lambda Function to Access Resources in an Amazon VPC의 문서를 참고하시기 바랍니다.

알아 두실 점
아래는 새로운 기능에 대한 몇 가지 알아두시면 좋은 점들입니다.

ENI & IP 주소 자원 – 처리할 이벤트 수에 따라 Lambda가 자동으로 확장하므로 VPC는 지정된 서브넷에 충분한 IP 주소를 가지고 있어야합니다.

인터넷 접속 – 특정 함수에 대해 이 기능을 활성화하면 해당 함수는 일반적으로 인터넷에 접근할 수 없습니다. 만약 함수가 인터넷 접속이 필요하다면, VPC에서 Managed NAT Gateway를 설치하거나 (자세한 내용은 AWS 신규 NAT 게이트웨이 서비스 출시! 참고) 자신의 NAT 인스턴스를 구성해야 합니다.

보안 그룹 – 람다 함수를 위해 사용하는 보안 그룹이 서브넷과 인터넷 자원에 대한 접근을 제어합니다.

S3 엔드포인트 –VPC에 있는 S3 엔드 포인트(자세한 내용은 New – VPC Endpoint for Amazon S3)에 접근 기능도 사용 가능합니다.

온라인 세미나 – 더 자세한 사항은 Essentials: Introducing AWS VPC Support for AWS Lambda 온라인 세미나에 참여해 보십시오.

Jeff;

이 글은 New – Access Resources in a VPC from Your Lambda Functions의 한국어 번역입니다.

AWS Lambda와 Slack을 이용한 DevOps Chatroom 구현하기

Slack이 제공하는 협업을 위한 채팅을 통해 DevOps팀에서 실제 운영이나 서로 의견이나 정보를 다양한 플랫폼에서 동시에 주고 받을 수 있습니다. 예를 들어, 스마트폰 앱을 이용하거나 맥에서는 클라이언트 도구도 제공하고 있습니다. 메시지를 다양한 형태로 전달할 수 있는 Amazon SNS(Simple Notification Service)를 통해 이벤트를 발생시키고, AWS Lambda 는 SNS를 통해 전달된 메시지를 이벤트 트리거(Event trigger)를 통해 원하는 코드를 직접 수행 할 수 있습니다.

Slack은 API를 통해 메시지를 보낼 수 있는 방법을 제공하고 있습니다. AWS Lambda에서 알림을 받아 Slack 대화 채널로 메시지를 전달할 수 있습니다. 이에 관한 간략한 소개는 ChatOps를 위한 AWS Lambda를 통한 Slack 통합 샘플 코드에서 제공하고 있습니다. 이번 글에서는 좀 더 상세하게 해당 기능을 소개하여 쉽게 구성할 수 있도록 도움을 드리고자합니다.

1. AWS Elastic Beanstalk로 웹 서비스 구성하기
AWS Elastic Beanstalk을 사용하면 아주 쉽게 웹 서비스를 바로 만들 수 있습니다. 또한, ELB(Elastic Load Balancing)과 RDS(Relational Database Service)를 같이 생성해 주며, Auto Scaling Group도 자동으로 생성하여 트래픽을 분산하고 스케일링을 자동화 할 수 있습니다. Auto Scaling을 위한 Policy 역시 생성되며, 확장을 위한 조건 및 정책 변경이 가능합니다.

Beanstalk은 로컬에서 개발한 코드를 AWS 환경에 바로 배포가 가능합니다. 로컬에서 Git을 이용하여 개발 후 EB CLI(Elastic Beanstalk CLI)를 통해 쉽게 업로드하여 배포할 수 있습니다. 로컬 환경에 EB CLI를 설치하고 웹서비스는 Github awslabs에 있는 Node.js로 만들어진 예제를 사용하겠습니다.

원하는 폴더를 생성 후 Github에서 예제를 다운로드합니다.

$ git clone https://github.com/awslabs/eb-node-express-sample.git
Cloning into 'eb-node-express-sample'...
remote: Counting objects: 56, done.
remote: Total 56 (delta 0), reused 0 (delta 0), pack-reused 56
Unpacking objects: 100% (56/56), done.
Checking connectivity... done.

Git사용을 위한 초기화를 진행합니다.

$ git init .
Reinitialized existing Git repository in /Users/ilho/Github/ebsample1/ebsample2/eb-node-express-sample/.git/

EB CLI를 설정하면 $ eb라는 명령을 통해 Elastic Beanstalk을 로컬 환경에서 구성하여 사용할 수 있습니다. 처음에 개발하는 폴더를 Root로 지정하고 Beanstalk 환경에 대한 설정을 진행합니다. eb init이란 명령으로 수행합니다. Beanstalk을 어느 Region에 생성할지부터 서비스 이름 등 기본적인 설정을 진행합니다. 현재 AWS Lambda가 도쿄 리전에서 지원하고 있기 이를 활용하기 위해 Elastic Beanstalk을 도쿄 리전에서 시작해 보겠습니다.

AWS Elastic Beanstalk은 Node.js외에도 Java, .NET, PHP, Python, Ruby, Go, Docker를 모두 지원합니다.

a0999b0edcf5:eb-node-express-sample ilho$ eb init
Select a default region
1) us-east-1 : US East (N. Virginia)
2) us-west-1 : US West (N. California)
3) us-west-2 : US West (Oregon)
4) eu-west-1 : EU (Ireland)
5) eu-central-1 : EU (Frankfurt)
6) ap-southeast-1 : Asia Pacific (Singapore)
7) ap-southeast-2 : Asia Pacific (Sydney)
8) ap-northeast-1 : Asia Pacific (Tokyo)
9) ap-northeast-2 : Asia Pacific (Seoul)
10) sa-east-1 : South America (Sao Paulo)
11) cn-north-1 : China (Beijing)
(default is 3): 8

Select an application to use
1) MyNewTest
2) ebsample1
3) [ Create new Application ]
(default is 3): 3

Enter Application Name
(default is "eb-node-express-sample"): ebsample2
Application ebsample2 has been created.
 
It appears you are using Node.js. Is this correct?
(y/n): y
Do you want to set up SSH for your instances?
(y/n): y
 
Select a keypair.
1) example_key1
2) example_key2
3) example_key3
4) example_key4
5) [ Create new KeyPair ]
(default is 5): 4

Beanstalk Application을 AWS 콘솔을 통해서도 만들 수 있지만, EB 명령을 이용하여 로컬에서 바로 생성을 시킬 수 있습니다. Eb create 명령을 사용하여 Beanstalk 환경을 구성합니다. 아래처럼 필요한 환경을 구성하면서 만들어지는 내용을 확인할 수 있습니다. 명령을 실행하여 AWS 콘솔에서 환경이 구성되는 것을 확인할 수도 있습니다. 환경이 구성 중에는 회색으로 표기되며 모두 정상적으로 만들어지면 녹색으로 변경되어 상태를 구분할 수도 있습니다.

$ eb create web2-env
WARNING: You have uncommitted changes.
Creating application version archive "app-5529-160121_085131".
Uploading ebsample2/app-5529-160121_085131.zip to S3. This may take a while.
Upload Complete.
Environment details for: web2-env
Application name: ebsample2
Region: ap-northeast-1
Deployed Version: app-5529-160121_085131
Environment ID: e-immiw7zwnk
Platform: 64bit Amazon Linux 2015.09 v2.0.6 running Node.js
Tier: WebServer-Standard
CNAME: UNKNOWN
Updated: 2016-01-20 23:51:35.207000+00:00
Printing Status:
INFO: createEnvironment is starting.
INFO: Using elasticbeanstalk-ap-northeast-1-1234567890 as Amazon S3 storage bucket for environment data.
INFO: Created load balancer named: awseb-e-i-AWSEBLoa-5F13U6NNRGJT
INFO: Environment health has transitioned to Pending. There are no instances.
INFO: Created security group named: awseb-e-immiw7zwnk-stack-AWSEBSecurityGroup-59FO03AWS48X
INFO: Created Auto Scaling launch configuration named: awseb-e-immiw7zwnk-stack-AWSEBAutoScalingLaunchConfiguration-42NJ3UCM61ZD
INFO: Added instance [i-00952c8f] to your environment.
INFO: Created Auto Scaling group named: awseb-e-immiw7zwnk-stack-AWSEBAutoScalingGroup-1QP37B57TQ43O
INFO: Waiting for EC2 instances to launch. This may take a few minutes.
INFO: Created Auto Scaling group policy named: arn:aws:autoscaling:ap-northeast-1:1234567890:scalingPolicy:6b7c0afe-3c1e-436d-a2e0-fcbc96d9c3c2:autoScalingGroupName/awseb-e-immiw7zwnk-stack-AWSEBAutoScalingGroup-1QP37B57TQ43O:policyName/awseb-e-immiw7zwnk-stack-AWSEBAutoScalingScaleUpPolicy-6FX2ZY0A9VIG
INFO: Created Auto Scaling group policy named: arn:aws:autoscaling:ap-northeast-1:1234567890:scalingPolicy:e8e7a4c3-af2f-4557-98e2-2dc472470f2e:autoScalingGroupName/awseb-e-immiw7zwnk-stack-AWSEBAutoScalingGroup-1QP37B57TQ43O:policyName/awseb-e-immiw7zwnk-stack-AWSEBAutoScalingScaleDownPolicy-1RY0SZO4CF9VP
INFO: Created CloudWatch alarm named: awseb-e-immiw7zwnk-stack-AWSEBCloudwatchAlarmHigh-10PTC4TZJA6XR
INFO: Created CloudWatch alarm named: awseb-e-immiw7zwnk-stack-AWSEBCloudwatchAlarmLow-1485FJORPZ9R3
INFO: Environment health has transitioned from Pending to Ok.
INFO: Successfully launched environment: web2-env

eb 명령어를 이용하면 바로 브라우져를 통해 Beanstalk으로 구성된 웹페이지를 열어볼 수 있습니다.

$ eb open

2. CloudWatch Alarm에 Notification 추가하기
Elastic Beanstalk은 Auto Scaling Group, CloudWatch Alarm, ScalingPolicy, SNS를 모두 구성해 줍니다. 자동으로 만들어진 SNS Topic을 이용하여 Lambda 함수와 연계되도록 구성을 할 수도 있고, 별도의 SNS Topic을 구성하여 Lambda 함수와 연계할 수도 있습니다.

CloudWatch 메뉴로 이동하여 자동으로 생성된 CloudWatch Alarm을 찾아 알람이 발생하면 SNS로 Notification을 전달 할 수 있도록 추가합니다.

기본으로 CPUUtilization을 모니터링하여 알람이 발생하도록 구성되어 있습니다. 스케일인-아웃(Scaling-in/out)을 위한 두 개의 알람이 생성되어 있으며, 해당 알람을 선택하여 Modify를 선택하고 Notification을 아래와 같이 추가합니다.

3. AWS Lambda에 Slack메시지 전송 함수 생성하기
Lambda에서는 Slack을 위한 함수가 예제로 추가되어 있습니다. 아래와 같이 slack으로 검색하면 Node.js와 Python 을 지원하는 Slack-echo-command, cloudwatch-alarm-to-slack 함수가 있습니다. 여기서는 Node.js를 사용하도록 하겠습니다.

cloudwatch-alarm-to-slack을 선택 후 Event Source로 앞에서 확인한 SNS Topic을 선택합니다. 해당 SNS Topic에 메시지가 전달되면 Lambda 함수가 자동으로 실행됩니다. 다음으로 제공하는 코드의 내용을 원하는 Slack 채팅 그룹, 채널에 메시지를 전달하기 위한 내용이 Comment에 설명되어 있습니다. 우선 Slack Incoming WebHooks 을 사용하여 메시지를 전달할 수 있도록 정보를 확인합니다.

  1. https://<your-team-domain>.slack.com/services/new로 이동합니다.
  2. “Incoming WebHooks”을 검색하여 채팅 그룹와 채널을 선택하고, 추가합니다.
  3. “Webhook URL” 을 확인하고 노트합니다.

Webhook URL이 노출되지 않도록 AWS KMS(Key Management Service)를 이용하여 Webhook URL을 암호화합니다. 별도의 암호화 관리를 하지 않고 쉽게 사용할 수 있는 서비스입니다. AWS CLI를 통해 직접 콘솔을 통하지 않고도 키 생성이 가능합니다.

1) AWS CLI로 KMS에 Key를 생성합니다. 이 예제에서는 Tokyo Region의 KMS에 키를 생성합니다.

$ aws kms create-key --region ap-northeast-1
{
"KeyMetadata": {
"KeyId": " xxxxxx-xxxx-xxx-xxxx-xxxxxxxx ",
"Description": "",
"Enabled": true,
"KeyUsage": "ENCRYPT_DECRYPT",
"KeyState": "Enabled",
"CreationDate": 1453342025.031,
"Arn": "arn:aws:kms:ap-northeast-1:1234567890:key/xxxxxx-xxxx-xxx-xxxx-xxxxxxxx",
"AWSAccountId": "123456789"
}
}

2) Key 사용이 쉽도록 Alias를 생성합니다. 이 예제에서는 SlackKey라는 이름으로 타겟 키를 지정하여 Alias를 생성합니다.

$ aws kms create-alias --alias-name "alias/SlackKey" --target-key-id " xxxxxx-xxxx-xxx-xxxx-xxxxxxxx " --region ap-northeast-1

3) WebHook URL을 생성한 키와 AWS CLI를 이용하여 암호화합니다. URL은 프로토콜 부분은 제외하고 입력합니다.

$ aws kms encrypt --key-id alias/SlackKey --plaintext "hooks.slack.com/services/abcdefghijklmnopqrstuvwxyz" --region ap-northeast-1
{
"KeyId": "arn:aws:kms:ap-northeast-1:1234567890:key/ xxxxxx-xxxx-xxx-xxxx-xxxxxxxx ",
"CiphertextBlob": "AbcdfghijksN8ta1n/abdefjiowl/x5RwtKZGSctHgnMVKeNo2xZjoAAACnMIGkBgkqhkiG9abcdefghijklmnb3DQEHATAeBglghkgBZQMEAS4wEQQMPWtiU2OmhyBJ9/swAgEQgGCZJ7fabcdefghijklmnUt6ltc1avMiWQawdgW9tj8Xv3drF7savCoL0oVDzRYRabcdefghijklmncIjX4LdXbAIg6nNWcF2JEa4v9Ze9WWNA9yrzJmmNs="
}

4) 암호화되어 생성된 WebHook URL을 Lambda코드의 kmsEncryptHookUrl 변수에 입력합니다. 입력할 Slack 채널명도 slackChannel 변수에 입력합니다.

var AWS = require('aws-sdk');
var url = require('url');
var https = require('https');
var hookUrl, kmsEncyptedHookUrl, slackChannel;

kmsEncyptedHookUrl = 'AbcdfghijksN8ta1n/abdefjiowl/x5RwtKZGSctHgnMVKeNo2xZjoAAACnMIGkBgkqhkiG9abcdefghijklmnb3DQEHATAeBglghkgBZQMEAS4wEQQMPWtiU2OmhyBJ9/swAgEQgGCZJ7fabcdefghijklmnUt6ltc1avMiWQawdgW9tj8Xv3drF7savCoL0oVDzRYRabcdefghijklmncIjX4LdXbAIg6nNWcF2JEa4v9Ze9WWNA9yrzJmmNs="';  // Enter the base-64 encoded, encrypted key (CiphertextBlob)
slackChannel = '#general';  // Enter the Slack channel to send a message to

5) Lambda 함수가 KMS를 사용하여 URL Decryption을 해야하므로 함수가 KMS를 사용할 수 있는 권한이 필요합니다. Lambda 함수가 사용할 Role에 KMS의 Decrypt API 접근 허용을 추가합니다. 아래 예제는 lambda_basic_execution role의 Policy에 추가한 화면입니다.

6) Lambda 함수에 lambda_basic_execution role을 지정하고 함수를 생성합니다.

7) Lambda Event Source의 처음 설정은 Disabled 이므로 Enabled로 변경합니다.

4. Slack 대화방에서 메시지 확인하기
Beanstalk에서 만든 사이트는 현재 트래픽이 없으므로, CPUUtilization이 낮아 Low CPU Alarm이 생성되어 메시지가 전달되게 됩니다. 아래와 같이 Slack 대화방에 해당 Alarm이 전달된 것을 확인할 수 있습니다.

Beanstalk을 활용하여 아주 간단히 웹서비스를 만들고 CloudWatch 알람 이벤트를 소스로 Lambda 함수를 활용하여 Slack 서비스에 메시지를 자동으로 포스팅하는 서비스를 상세히 구현해 보았습니다. Ops 혹은 DevOps팀에서 AWS의 여러 상태 정보나 메시지를 받아서 활용할 수 있습니다. Slack에서는 메시지의 포맷을 변경하거나 할 수 있는 여러가지 예제를 제공하고 있어 보아 다양한 메시지 구현이 가능합니다.

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

EC2 인스턴스 ID 길이 증가 변경 실시

작년 11 월에 (2016년 변경 예고) EC2 및 EBS Resource ID, 길이 증가 예정 공지를 미리 한 바 있습니다. 오늘부터 2016 년 12 월 초까지 새로운 포맷 (17자 리소스 ID)를 각 리전마다 사용자별로 리소스 유형에 따라 선택할 수 있습니다. 지정한 리전, IAM 사용자 (또는 루트 계정)에 대해 긴 ID를 선택하면 이후에 새로 생성 된 자원은 긴 ID가 할당됩니다.

오늘부터 EC2 인스턴스와 EC2 예약 인스턴스를 새로운 형식으로 선택할 수 있습니다. 각 예약은 단일 인스턴스 시작 요청의 결과를 의미하지만,  여러 인스턴스를 시작할 때도 연관됩니다.

만약 AWS API를 직접 호출하는 라이브러리, 개발 도구 및 응용 프로그램을 만들고 있다면, 긴 ID를 선택하는 경우 테스트를 진행 하시기 바랍니다! 만약 ID를 메모리나 데이터베이스에 저장하고 있다면, 고정 길이 필드, 데이터 구조, 스키마 문자열 정규식 등을 상세하게 확인하십시오. 사용 중단(Opt-out)하기 전에 만들어진 리소스는 짧은 ID로 남아 있습니다. 긴 ID와 짧은 ID를 모두 처리 할 수​​ 있도록 코드를 수정하십시오.

긴 ID 사용을 진행(Opt-in)하시려면, AWS Management Console, AWS Command Line Interface (CLI)AWS Tools for Windows PowerShell, 와 API를 사용할 수 있습니다. 테스트를 통해 해결해야 할 과제가 판명 된 후 짧은 ID 재 사용도 가능합니다.

긴 ID 사용하기 – AWS 관리 콘솔
AWS 관리 콘솔에서 EC2화면의 Resource ID length management를선택합니다.

원하는 리소스 타입에 대해 Use Longer IDs를 선택합니다.

긴 ID 사용하기 – AWS CLI
AWS CLI에서는 modify-id-format 명령어를 사용하여 원하는 리소스 타입을 지정합니다.

$ modify-id-format --resource instance --use-long-ids

아래와 같이 할 수도 있습니다.

$ modify-id-format --resource instance --no-use-long-ids

긴 ID 사용하기 – AWS 윈도 파워셀
AWS 윈도 파워셀에서는   Edit-EC2IdFormat cmdlet을 사용하고 원하는 리소스 타입을 지정합니다.

PS C:\> Edit-EC2IdFormat -Resource instance -UseLongId True

아래와 같이 할 수도 있습니다.

PS C:\> Edit-EC2IdFormat -Resource instance -UseLongId False

긴 ID 사용하기 – AWS SDK
여러분이 직접 만든 도구에서 AWS API를 사용하신다면, ModifyIdFormat 함수를 실행하고, 특정 리소스을 선택한 후 UseLongIds 파라미터 값을 True로 지정합니다.

꼭 알아두실 점

IAM 사용자 및 계정 수준에서 설정할 수 있습니다. 설정 후 새로 생성 된 리소스에 새로운 긴 ID로 변경되는데는 몇 분 정도 걸립니다. ID는 API의 결과와 명령 줄의 결과 콘솔에서 확인할 수 있습니다.

특정 IAM 사용자가 설정 후, 리소스를 만드는 경우 다른 사용자에게도 긴 ID가 보입니다. 혼란을 피하기 위해 테스트 목적의 AWS 계정을 따로 만들거나, 평소 사용하지 않는 AWS 리전을 테스트 용으로 선택할 수 있습니다.

이 블로그 게시물의 내​​용은 모든 AWS 리전 및 계정에 적용됩니다. 2016 년 3 월 7 일 이후에 생성 된 AWS 계정은 기본적으로 긴 인스턴스 ID와 예약 인스턴스 ID를 할당하지만, 필요에 따라 긴 ID 설정을 취소할 수 있습니다.

직접 테스트를 진행하여, 여러분의 개발 및 운영 도구, 각종 프로그램 코드 및 응용 프로그램이 요구 사항대로 동작하도록 개선하여 2016 년 12 월까지 전체 AWS 계정에 긴 ID 설정을 진행하시기를 권장합니다. 앞으로  긴 ID가 강제로 적용되어 생기는 어려움이 없도록 여러분의 협조 부탁드립니다.

더 자세한 사항은 자세한 일정이나 FAQ등 추가 정보(한국어 제공)를 참고하시기 바랍니다.

Jeff

PS – EBS 볼륨 및 스냅 샷의 긴 ID 변경은 2016년 4 월을 예정하고 있습니다.

이 글은 They’re Here – Longer EC2 Resource IDs Now Available의 한국어 번역입니다.