Category: Amazon EC2

암호화는 데이터 보호 전략의 가장 중요한 영역입니다. 최근 1~2년 사이에 AWS는 클라우드 기반 정보를 저장하는 데 있어 암호화 방식을 획기적으로 단순화 시키는 많은 기능들을 선보였습니다. 이들 기능 대부분은 AWS Key Management Service (KMS)을 기반으로 하며, 아래와 같은 주제로 블로그에서 다루었습니다.

• Amazon Aurora 암호화 기능 지원 시작!.
• Amazon RDS를 위한 KMS 암호화 KMS.
• Encrypted Storage Volumes for Amazon WorkSpaces.
• S3 SSE-KMS Encryption for AWS CloudTrail.
• S3 Encryption Integrated with Amazon EMR.
• Encryption for Elastic Transcoder.
• EBS Data Volume Encryption.

더 자세한 사항은 AWS KMS와 통합 가능한 서비스 목록을 살펴 보시기 바랍니다.

많은 고객들은 AWS를 통해 좀 더 쉽게 데이터 암호화를 할 수 있게 되었고, 이를 통해 굉장히 어려웠던 일을 AWS를 통해 손 쉽게 해결할 수 있었다는 피드백을 보내주셨습니다.

EBS 부팅 볼륨 암호화
오늘 EBS 부팅 볼륨의 암호화 지원을 시작합니다. 이 기능은 최근에 EBS 스냅샷 복사 기능에서 부터 암호화 지원을 시작하였습니다.

EBS 부트 볼륨 암호화를 사용할 수 있는 Amazon Machine Images (AMIs)를 생성하고 이 AMI를 EC2 인스턴스 시작 시 사용하면 됩니다. 저장한 데이터는 모두 암호화 되며, EC2 인스턴스와 EBS 볼륨 사이의 데이터 역시 암호화 됩니다. 복호화는 인스턴스에서 필요시에만 이루어져서 메모리에만 저장됩니다.

이 신규 기능을 통해 EBS 데이터 볼륨을 비롯해서 부팅 볼륨 데이터까지 암호화 할 수 있음으로서 보안, 규정 준수 및 감사에 큰 도움이 될 것입니다. 더 나아가 KMS를 통해 암호화 키의 사용 내역 등을 감사 및 추적할 수도 있습니다.

각 EBS를 포함한 AMI는 하나 이상의 EBS 볼륨 스냅샷을 참고합니다. 첫번째 참조는 부팅 볼륨의 이미지이고, 다른 하나는 데이터 볼륨입니다. AMI를 시작하면 EBS 볼륨이 각 스냅샷으로 부터 만들어집니다. EBS가 이미 데이터 볼륨에 대한 암호화를 지원하기 (볼륨과 연계된 스냅샷 포함) 때문에 볼륨 전체에 대한 암호화를 지원하는 싱글 AMI를 만들 수 있으며, 원한다면 개별 KMS 고객 마스터 키를 각 볼륨에서 사용할 수 있습니다.

암호화된 EBS 부팅 볼륨 만들기
암호화된 EBS 부팅 볼륨 만드는 과정은 기존 AMI(리눅스나 윈도)에서 시작합니다. AMI을 직접 소유하거나 공개되어 있는 것을 바로 사용할 수 있습니다. 또는 이미지로 부터 AMI를 시작하여, 암호화된 EBS 부팅 볼륨을 이미지로 만들 수 있습니다. (예를 들어 윈도 AMI). 암호화된 AMI는 개인적으로만 사용가능하며 다른 AWS 계정에 공유할 수 없습니다.

AMI와 암호화된 스냅샷으로 ec2-copy-image 명령어를 이용하여 간단하게 새로운 AMI를 만들 수 있습니다.

$ ec2-copy-image -r source_region -s source_ami_id \
  [-n ami_name] [-d ami_description] [-c token] \
  [--encrypted] [--kmsKeyID keyid]

만약 --encrypted 파라미터와 --kmsKeyID 없이 암호화를 요청하면, 기본 EBS 고객 마스터키 (CMK)를 사용합니다.

예를 들어, Amazon Linux AMI를 복사하는 방법입니다.

$ ec2-copy-image -r us-east-1 -s ami-60b6c60a  \
  --encrypted --kmsKeyID arn:aws:kms:us-east-1:012345678910:key/abcd1234-a123-456a-a12b-a123b4cd56ef

암호화된 부팅 볼륨과 AMI를 EC2 관리 콘솔에서 만들 수도 있습니다.

암호화된 EBS 부팅 볼륨 사용하기
새 AMI를 만들고 나면, 새로운 인스턴스를 띄울 때 마다 사용할 수 있습니다. 코드를 수정하거나 운영 과정을 바꿀 필요가 없습니다.

정식 출시
본 기능은 Beijing (China)을 제외한 모든 AWS 리전에서 사용 가능하며, 암호화 기능에 따른 추가 비용은 없습니다.

— Jeff;

이 글은 New – Encrypted EBS Boot Volumes의 한국어 번역입니다.

EC2팀 Angela Chapman가 2016년에 EC2 인스턴스, 예약 및 EBS 볼륨 스냅샷 리소스 ID의 길이 변화에 대한 예고에 대한 글을 게시하여 함께 공유드립니다.
– Jeff;

EC2와 EBS는 앞으로 1년여에 걸쳐 리소스 ID 길이를 변경할 예정입니다. 2016년에 예약 인스턴스, 볼륨 스냅샷에서 ID 길이를 증가시킬 예정입니다. 2016년 말까지 길어진 ID가 제공될 예정이며, 이러한 변경으로 고객에게 큰 영향은 없을 것입니다. 그러나, ID 길이 확장에 따라 시스템 계획 및 테스트를 하실 수 있도록 사전에 공지합니다.

이번 ID 길이 확장 결정은 AWS의 지속적인 성장에 따른 이유입니다. EC2, EBS 등의 특정 리소스 ID가 향후 1년 이후에는 고갈될 것으로 생각되며, 장기적으로 새로운 인스턴스 및 예약, 볼륨 스냅샷 생성이 방해 받지 않도록 하기 위해 지금 보다 더 긴 ID를 도입 해야합니다. 새로운 ID 형식은 기존 ID 형식에서 변화는 없으며, 단순히 길이에만 변경이 있습니다. 기존의 ID 형식은 자원 식별자에 이어 8자 길이의 형식으로 되어 있으나, 새로운 포맷 뿐만 아니라 리소스 식별자 17자 길이를 사용합니다.

AWS 대부분 고객들은 이러한 변화에 의한 영향은 없습니다. 그러나 리소스 ID를 해석하고 저장하는 고객 자체 시스템에는 영향을 줄 수 있습니다. 기존 자원에 8자 길이의 기존 ID를 계속 사용할 수 있으며, 기존 ID는 변경되지 않고 계속 지원합니다. 새로운 포맷을 선택하신 후, 신규 자원에만 17자 길이의 ID를 사용할 수 있습니다. SDK는 신규 ID 대응을 지원하며, 업데이트가 필요하지 않습니다.

신규 ID를 받기 위한 기간은 2016년 1월부터 12월까지로 예정하고 있으며, 2016년 12월까지는 새로운 ID 이용은 선택 사항입니다. 2016년 12 월 이후, 즉 지금으로부터 13개월 후에는 모든 신규 인스턴스, 볼륨 예약 스냅샷이 17자의 신규 ID로 바뀝니다.
AWS Command Line Interface (CLI) , AWS Tools for Windows Powershell, AWS SDK는 신규 ID에 대응하고 있으며, 길이 포맷 변경 대응 업데이트를 할 필요가 없습니다. 신규 ID 사용 신청 프로세스에 대한 API 역시 곧 소개 할 예정입니다.

자세한 일정이나 FAQ등 추가 정보(한국어 제공)를 참고하실 수 있습니다. 만약 질문이 있는 경우에는 AWS 고객 지원 및 커뮤니티 포럼을 통해 해주시기 바랍니다.

— Angela Chapman, 선임 제품 매니저

본 글은 Heads-Up – Longer EC2 & EBS Resource IDs Coming in 2016의 한국어 번역입니다.

지난 달 EC2 전용 호스트 곧 출시된다는 소식을 알려드렸습니다. 이 서비스는 여러분의 EC2 인스턴스에 대해 실제 물리적 서버를 지정할 수 있는 것이라고 소개해 드렸습니다.

• 기존 라이센스 공유(Bring Your Own Licenses) – 현재 서버의 Windows Server, SQL Server, SUSE Linux Enterprise Server 및 기타 엔터프라이즈 소프트웨어의 라이센스를 클라우드에서도 사용할 수 있습니다. 전용 호스트는 물리적 서버의 CPU 코어 및 소켓 숫자를 정확확히 알 수 있게 되어 실제 하드웨어와 같은 라이센스를 취득 및 활용할 수 있습니다.
• 표준 규정 및 규제 요구 사항 제공 – 애플리케이션을 전용 하드웨어에 실행 할 수 있도록 전용 호스트를 할당할 수 있습니다.
• 사용 기록 확인 – AWS Config을 사용하여 각 전용 호스트에 사용되었거나 중단된 인스턴스 기록을 추적할 수 있습니다. 이러한 기록은 나중에 라이센스 통계에 활용할 수 있습니다.
• 인스턴스 제어 가능 – 전용 호스트에 EC2 인스턴스에 대한 세부적인 제어 가능합니다.

전용 호스트 정식 출시
EC2 전용 호스트 서비스는 오늘 정식 출시되었습니다. AWS 관리 콘솔, AWS 명령어 인터페이스 (CLI), AWS 윈도 PowerShell 및 AWS SDK를 통해 사용할 수 있습니다. .

먼저 콘솔에서 전용 호스트를 시작하고 EC2 인스턴스를 할당해 보고자 합니다. 먼저 EC2 콘솔을 열고 오른쪽 메뉴에서 Dedicated Hosts를 선택하고, Allocate a Host를 누릅니다.

이제 인스턴스 타입을 선택합니다. (전용 호스트에는 M3, M4, C3, C4, G2, R3, D2, I2 사용 가능) 그리고, 가용 영역(Availability Zone) 및 수량(각 전용 호스트는 같은 크기의 특정 타입을 하나 이상 설치 가능)을 정합니다.

만약 인스턴스 자동 위치(auto-placement)를 선택하면, 원하는 가용 영역에 인스턴스 타입이 전용 호스트에 자동으로 할당되고, 인스턴스 용량이 전용 호스트에 가능할 때 탑재되며 특별히 지정하지 않은 Host에 올라가게 됩니다. 만약 자동 위치를 허가하지 않으면, 인스턴스를 띄울 때 전용 호스트를 지정해야 합니다.

Allocate host를 선택하면, 다음과 같은 확인 메시지를 받게 됩니다.

전용 호스트에 대한 과금은 이 때 부터 시작됩니다. 인스턴스의 숫자나 크기는 과금에 영향을 미치지 않습니다.

또한, 전용 호스트 현황에 대해 아래와 같이 상세히 볼 수 있습니다.

여러분이 보시다시피, 전용 호스트에는 2개의 소켓과 24개의 코어가 있ㄱ, 22까지 m4.large 인스턴스를 올릴 수 있습니다. 그러나 현재는 아직 없습니다. 이제 다음 단계로 전용 호스트에 인스턴스를 실제로 올려보겠습니다. Actions를 누르고, Launch Instance(s) onto Host를 선택합니다. (EC2 실행 마법사를 사용할 수도 있습니다.)

머신 이미지를 AMI를 선택합니다. (현재 RHEL, SUSE Linux 및 윈도 라이선스 등) 특정 AMI는 전용 호스트를 사용할 수 없고 선택 가능한 이미지만 나타납니다.

인스턴스 타입은 이미 선택되어 있습니다.

전용 호스트에 실행되는 인스턴스는 항상 VPC 내에 존재해야 합니다. 하나의 전용 호스트는 한 개 이상의 VPC에 실행되는 인스턴스를 포함합니다.

남아 있는 인스턴스 실행 과정은 기존과 동일하고 전용 호스트에 실행 될 때 옵션에 접근할 수도 있습니다. 예를 들어, 전용 호스트에 스팟 인스턴스는 실행 할 수 없습니다.

EC2 인스턴스를 기존 방법으로 띄울때도 전용 호스트를 선택할 수 있습니다. Tenancy 옵션을 Dedicated host 로 바꾸고, 전용 호스트를 선택하면 됩니다. 됩니다. (No preference에서 선택할 수 있습니다.)

Affinity를 선택하면, 인스턴스와 전용 호스트 관계를 영구적으로 만들 수 있습니다. 이를 통해 인스턴스가 늘 같은 호스트에 재시작하도록 합니다. 우연히 라이센스 소프트웨어를 가진 인스턴스를 다른 전용 호스트에 띄우게 되는 가능성을 최소화 합니다. 만약 윈도우 서버 이미지를 가져와서 라이센스 사용 계약에 따라 적어도 90일 동안 특정 물리 서버에 지정할 수 있습니다.

이제 콘솔에 Dedicated Hosts에 돌아와서 전용 호스트 하나를 선택한 후 실행되는 인스턴스에 대해 살펴 볼 수 있습니다.

소프트웨어 사용 기록 확인
기존 소프트웨어를 전용 호스트에 사용 할 수 있습니다. 가상 환경에서의 사용 가능한 지 약관을 확인하고, VM Import/Export를 사용하여 기존 장비에서 클라우드로 이전할 수 있습니다. 좀 더 자세한 사항은 기존 라이센스 공유(Bring Your Own License) 문서를 참고하시기 바랍니다. 윈도 라이센스 옵션에 대해서는 Microsoft Licensing on AWS이나 Windows BYOL Licensing FAQ를 읽어보시면 됩니다.

또한, AWS Config를 이용하여 전용 호스트에 대한 설정 변경, 설치 및 운용, 중단된 인스턴스에 대한 기록을 확인할 수 잇습니다. 향후에 라이센스 사용 보고를 할 때 입증 정보가 될 수 있습니다. 콘솔에서 Edit Config Recording 버튼을 누르고, 마우스를 올리면 현재 상태를 볼 수 있습니다.

더 자세한 것인 Using AWS Config 문서를 참고하세요.

중요한 사항
이전에 말씀 드린대로 전용 호스트에 인스턴스가 할당되면 과금이 시작됩니다. 자세한 것은 전용 호스트 요금페이지를 참고하십시오.

EC2는 자동으로 여러분의 전용 호스트를 모니터링 하고 콘솔을 통해 확인할 수 있습니다. 상태가 정상이면 available이고, 전용 호스트에 이슈가 발생하면 under-assessment로 바뀝니다.

전용 호스트의 인스턴스는 항상 VPC내에 있어야 하고, Placement Group, Auto Scaling 및 Amazon RDS는 지원하지 않습니다.

전용 호스트 서비스는 US East (Northern Virginia), US West (Oregon), US West (Northern California), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo), Asia Pacific (Singapore), Asia Pacific (Sydney), South America (Brazil) 리전에서 사용 가능하며, M4, C4 등의 인스턴스 타입에 대해 각 2개의 전용 호스트를 할당 할 수 있습니다. 만약 더 많은 전용 호스트가 필요하시면, 증가 요청을 하시면 됩니다.

— Jeff;

이 글은 Now Available – EC2 Dedicated Hosts의 한국어 번역입니다.

Amazon Virtual Private Cloud(VPC)를 사용하면 논리적으로 분리된 네트워크 영역을 AWS 클라우드에 만들 수 있습니다. VPC에서 원하는 IP 주소 범위를 결정하여, 서브넷을 만들고 라우팅 테이블을 설정합니다. 또한, 사내에서 하드웨어 VPN 어플라이언스에 연결하도록 네트워크 게이트웨이를 만들 수 있습니다.

AWS 클라우드에서 동작하는 가상 프라이빗 네트워크(VPN)는 VPN 게이트웨이 또는 VGW로서 고객 데이터 센터 네트워크에 있는 고객 게이트웨이(CGW)와 연결할 수 있습니다. 오늘 이러한 VPN 서비스에 몇 가지 새로운 기능을 추가했습니다.

• NAT 탐색 지원
• 암호화 옵션 추가
• CGW IP 주소 재사용

이 세 가지의 새로운 기능을 활성화하기 위해서는 새로 VGW를 만들고 필요한 매개 변수와 함께 새로운 VPN 터널을 만들어야 합니다.

NAT 탐색 지원
네트워크 주소 변환 (NAT)은 특정 IP 주소 범위를 다른 IP 주소 범위로 변환하는 변환맵(Map)을 가집니다. VPC를 만들고 원하는 IP 대역대를 설정했을 때 여러 서브넷으로 만들어지고, 여러분의 EC2 인스턴스는 VPC내에 서브넷 중 하나에 연결됩니다. 이제 이를 VGW에 연결하려면 NAT 탐색 혹은 NAT-T를 사용 해야합니다. NAT-T는 사내 네트워크를 NAT 장치 뒤에 숨기면서, VPC에 연결할 수 있도록 합니다.

이러한 매핑은 VPN 연결이 만들어 질 때 자동으로 이루어집니다. AWS 관리 콘솔로 설정할 필요가 없으며, NAT 장치 탐색 기능을 사용하고 UDP 포트 4500 번을 사용할 수 있도록 방화벽(Firewall)을 설정하면 됩니다.

암호화 옵션 추가
여러 가지 암호화 옵션을 사용할 수 있습니다. VPC에 있는 하드웨어 VPN은 기존 데이터 센터 네트워크와 VPN에 연결되면, 여러 가지 다른 강도의 암호화 옵션을 제공합니다. 이제는 AES256을 기존의 AES128를 대체하여 사용하도록 권장됩니다. 새로운 암호 옵션을 사용한다면 전달 받는 측의 장치에서 AES128을 받지 않게 설정 해야합니다.

두 엔드포인트 사이에서는 Diffie-Hellman 키 공유 프로토콜에 의해 중요한 정보를 공유합니다. DH 그룹은 키의 해시 강도 결정과 공유에 사용됩니다. 이제는 몇 개의 그룹에서 선택할 수 있습니다.

• Phase 1에서는 DH 그룹 2, 14-18, 22, 23 및 24.
  <liPhase 2에서는 DH 그룹 1, 2, 5, 14-18, 22, 23 및 24.

VPN에 연결 된 패킷은 해시 알고리즘을 사용하여 검증합니다. 해시가 일치하는 경우, 패킷이 도중에 변경되지 않았음을 나타냅니다. 이제 256 비트 다이제스트(SHA-256)를 사용한 SHA-2를 사용할 수 있습니다. 강도가 약한 알고리즘을 사용하지 않도록 장치를 설정하여 주어야 합니다.

CGW IP 주소 재사용성
이제는 CGW을 만들 때마다 IP 주소가 고유할 필요는 없습니다. 즉, 사용하는 IP 주소를 재사용 할 수 있다는 것입니다. VPC를 사용하고 있는 사용자로부터 많은 요구가 있었던 기능입니다.

자세한 내용은 FAQ 및 VPC 네트워크 관리자 가이드를 참조하십시오.

— Jeff;

이 글은 EC2 VPC VPN Update – NAT Traversal, Additional Encryption Options, and More의 한국어 번역입니다.

지속적인 운영이 되는 일반적인 서버(또는 Amazon Elastic Compute Cloud (EC2) 의 용어로 인스턴스)로 이루어진 정적인 컴퓨팅 환경에서 대규모의 역동적이고 이질적인 환경에 마이그레이션 할 때 인스턴스를 새로운 방식으로 관리하고 제어 할 필요가 있습니다.

신규 EC2 Run Command

이를 위해 오늘 EC2 Run Command 신규 기능을 소개합니다. 이 기능은 인스턴스 (숫자와 관계 없이) 관리를 쉽고 안전한 방법으로 할 수 있습니다. 소프트웨어 설치, 특별한 스크립트 또는 Microsoft PowerShell 명령 실행, Windows Update 구성 등 다양한 엔터프라이즈 시나리오를 지원하도록 설계되어 있습니다. AWS Management Console, AWS Command Line Interface (CLI) , AWS Tools for Windows PowerShell , 그리고 AWS SDKs 에서 접근할 수 있습니다. 만약 현재 개별 인스턴스를 PS1 스크립트 또는 개별 PowerShell 명령에서 관리하고 있으시다면, 이를 하나 이상의 인스턴스에서 수행 할 수 있습니다.

이 기능은 많은 사용자와 고객들께서 요청해 주셨고, 아래 내용은 그 내용 중 일부입니다.

• 인스턴스에 대한 구성 변경을 일관성을 가지면서 임시(ad-hot) 구현할 필요성
• 여러 인스턴스에 걸쳐 신뢰성과 일관성있는 결과의 필요성
• 변경을 실시 할 수있는 사람과 할 수 있는 권한 제어의 필요성
• 어떤 조치가 이루어 졌는지의 명확한 감사(Auditing)의 경로
• 전체 원격 데스크톱 (RDP) 접근의 필요 없이 위의 사항을 하고자 하는 필요성

명령어 실행 방식은 안전하고, 신뢰할 수 있는 방법이며 편리할 뿐만 아니라 확장성이 높습니다. 자신의 명령어을 작성한 후, AWS Identity and Access Management (IAM)를 사용한 세밀한 권한 제어를 수행 할 수 있습니다. 예를 들어, 신뢰할 수 있는 사용자 그룹에 의해 엄격하게 통제된 특정 세트의 인스턴스에서 실행할 수 있는 관리 명령을 지정할 수 있습니다. 모든 명령어는 감사를 위해 AWS CloudTrail를 통해 중앙에서 기록 및 감사 할 수 있게 됩니다.

명령어 실행의 이점
새로운 Run Command의 기능은 다음과 같은 이점을 제공하도록 설계되어 있습니다 :

• 제어 및 보안: IAM 정책과 규칙(Rule)을 사용하여 명령어와 인스턴스에 대한 접근 통제를 할 수 있습니다. 따라서 인스턴스에 직접 접근하는 사용자의 수를 줄일 수 있습니다.
• 신뢰성: 구성 변경 템플릿을 생성하여 시스템의 신뢰성을 향상 시킬 수 있습니다. 이를 통해 예측 가능성을 높이면서 구성 불일치를 줄이기 위한 제어가 가능합니다.
• 가시성: Run Command을 통해 명령어 추적을 지원하여 CloudTrail 와 통합을 통한 구성 변경 사항에 대한 시각화가 가능합니다.
• 용이성: 미리 정의 된 명령어 세트를 선택하여 실행하고, 관리 콘솔, CLI 또는 API를 통해 진행 상황 추적을 할 수 있습니다.
• 사용자 정의: Run Command를 자신의 조직의 요구에 맞춘 사용자 정의 명령어로 만들 수 있습니다.

EC2 콘솔에서 Run Command 실행
Run Command는 모든 윈도우 인스턴스에서 동작하고 인스턴스 기존 EC2Config 에이전트를 사용합니다. 콘솔을 열고 Commands를 선택하고 Run Command를 사용하기 위한 조건을 확인하십시오 :

Run a command를 클릭하여 메인 Run Command 화면으로 이동합니다. 기존의 실행 결과(있는 경우)와 Run a command 버튼이 보입니다

디스플레이의 각 열은 인스턴스에서 실행 된 명령어을 나타내고 있습니다. Run a command를 클릭하여 새로운 명령을 시작합니다.

Command document 메뉴에는 7개의 미리 정의 된 명령어 및 계정에서 만든 사용자 정의 명령이 있습니다.

사용자 활용 사례에 맞춘 적절한 기술 문서와 대상 인스턴스에 대해 원하는 변경 사항을 적용할 수 있습니다. 각 문서에는 적절한 것을 선택할 수 있는 몇 가지 설명이 있습니다. 일반적인 관리 작업을 위해서는 AWS-RunPowerShellScript문서를 사용합니다. 이를 통해 모든 PowerShell 명령어을 실행하거나 기존 PowerShell 스크립트를 호출할 수 있습니다.

문서를 선택한 후, 명령어(ipconfig를 사용)를 입력하여 관심 있는 인스턴스를(속성, 태그 또는 키워드 필터링 가능) 선택합니다.

명령어 또는 스크립트를 실행하면 표준 출력에 많은 결과가 생성되고, S3 버킷 및 주요 접두어를 지정하여 결과를 저장할 수 있습니다. 그렇지 않으면, Run Command는 콘솔 출력의 처음 2500문자를 캡처하고 표시합니다.

준비가 되면 Run을 클릭합니다. 콘솔에 확인 메시지가 표시됩니다.

명령어 기록으로 돌아가서 그 결과를 확인해 봅니다.

원하는 명령어를 골라서 Output 탭을 선택합니다.

그리고 View Output을 선택합니다.

실제 환경에서 실행하기
자신의 AWS 환경에서 Run Command를 사용하는 몇 가지 방법입니다 :

• 타사 에이전트 및 소프트웨어 설치 및 구성
• 로컬 그룹 및 사용자 관리
• 설치된 소프트웨어 또는 패치 확인 및 결과 수행
• 윈도 서비스 다시 시작
• 예약 된 작업 업데이트

정식 출시
Run Command 기능은 오늘 부터 US East (Northern Virginia), US West (Oregon), and Europe (Ireland) 리전에서 사용 가능합니다. Run Command Console을 열거나 최신 AWS Tools for Windows PowerShell, AWS Command Line Interface (CLI)를 사용하시기 바랍니다. 이 서비스는 AWS 자원 사용 요금을 제외하고 무료로 제공됩니다.

— Jeff;

PS – Linux를 실행하는 인스턴스에도 같은 기능을 제공하는 것을 계획하고 있습니다. 추가 정보도 곧 알려드리겠습니다.

이 글은 New EC2 Run Command – Remote Instance Management at Scale의 한국어 번역입니다.

AWS 고객의 계획과 인프라 요구 사항에 저희에게 항상 공유해 주고, 저희는 이러한 필요를 맞추기 위해 노력해 왔습니다. EC2 인스턴스 역사를 보면 그러한 변화를 잘 파악할 수 있으며 다양한 인스턴스 타입을 추가해 왔습니다.

최근에 아래의 두가지 요구사항을 많이 받아 왔으며 매우 중요한 산업 트렌드라고 생각하고 있습니다.

• 엔터프라이즈 고객은 많은 메모리 용량을 가진 고성능의 인스턴스를 요구합니다. 인메모리 기반의 SAP HANA나 Neo4j 및 Titan 같은 실시간 분석 그리고 대용량 캐시 같은 사례가 있습니다.
• 소형 웹 사이트를 운영하는 고객은 그렇게 많은 컴퓨팅 용량을 차지 하지 않거나 모니터링이나 마이크로서비스용 서비스를 운영하기도 합니다.

이러한 요구 사항을 맞추기 위해 오늘 저희는 두 가지의 새로운 인스턴스 타입을 소개합니다. 바로 대용량 메모리를 가진 X1 인스턴스와 매우 적은 컴퓨팅 용량을 가지지만 필요 시 버스팅 기능을 가진 t2.nano입니다.

X1 – 대용량 메모리 기반
X1 인스턴스는 2TB의 메모리를 가지며 대용량 메모리 작업이 필요한 SAP HANA, Microsoft SQL Server, Apache Spark 및 Presto 같은 애플리케이션에 적합합니다.

X1인스턴스는 네 개의 Intel® Xeon® E7 프로세서를 기반으로 하고 각 프로세서는 L3 캐시의 메모리 대역폭을 가지며 고성능 대용량 메모리 앱을 지원합니다. 100개가 넘는 vCPU를 통해 이들 인스턴스가 동시 작업을 수행할 수 있습니다.

X1 인스턴스는 2016년 상반기 중에 공개할 예정이며, 더 자세한 것은 이 블로그를 통해 알려드리겠습니다.

t2.nano – 소형 서비스용(버스팅 기능 포함)
T2 인스턴스는 최저 사양의 프로세서 기준을 가지고 이를 넘어가는 경우 기존에 모아둔 CPU 크레딧이라는 사용하는 방식으로 효율적으로 인스턴스를 운영할 수 있는 모델입니다. 저희는 t2.micro, t2.small 그리고 t2.medium 등의 서비스를 제공했습니다. 버스팅 모델은 많은 고객들에게 인기가 높아지고 있으며 얼마 전 t2.large라는 인스턴스도 제공하기 시작했습니다.

다음 단계로 오늘 t2.nano라는 인스턴스 타입을 공개합니다. 1 vCPU에 512MB의 메모리를 가지며 한 시간 정도 전체 CPU를 사용할 수 있는 크레딧을 제공합니다.

트래픽이 거의 없거나 간단한 작업을 하는 서비스에 적합니다. 본 인스턴스 타입 또한 더 자세한 것은 이 블로그를 통해 알려드리겠습니다.

— Jeff;

이 글은 EC2 Instance Update – X1 (SAP HANA) & T2.Nano (Websites)의 한국어 번역이며, re:Invent 2015의 신규 서비스 소식입니다.

때로는 비지니스가 기술을 만들기도 하고, 반대로 기술이 비지니스를 만들기도 합니다!

여러분이 기존 환경에서 AWS로 이전하려고 할 때, 물리적 코어 숫자와 소켓 갯수에 맞춘 서버에 따른 소프트웨어 볼륨 라이선스를 구매하셨을 수도 있습니다.또는 특정 기간 동안 특정 서버에 실행을 하도록 하는 등 윈도 서버, 윈도 SQL 서버 및 오라클 데이터베이스와 SUSE 리눅스 엔터프라이즈 버전에는 이런 요구 사항이 있습니다.

AWS로 이전하는데 있어 이러한 라이선스를 그대로 활용할 수 있는 방법이 필요합니다. 일반적으로 저희는 BYOL(Bring Your Own License)라는 모델을 통해 이를 제공하는데, 라이선스 조항에 제대로 부합하려면 물리적 서버 기반에서 EC2 인스턴스를 연결(Mapping) 및 제어할 필요가 있습니다.

신규 Dedicated Host 모델
이러한 연결을 지원하기 위해서 Amazon EC2 Dedicated Hosts(전용 호스트)라는 새로운 모델을 발표합니다. 이를 통해 Dedicated Hosts라는 물리적 서버를 할당 받고 여기에 하나 이상의 EC2 인스턴스를 실행할 수 있습니다. 특정 물리 서버 사양을 정해 재사용하거나 기존 소프트웨어 라이선스에 맞는 환경을 구성할 수 있습니다.

BYOL 모델을 클라우드에 적용해 비용을 절감할 뿐만 아니라 EC2 Dedicated Host를 통해 엄격한 보안 준수 및 규제 요구사항에 맞출 수 있습니다. 인스턴스별 가시성 및 제어 요구사항을 물리 서버에도 적용 가능합니다. 이러한 환경에서 변경 사항에 대한 세부적 감사도 매우 중요한데 AWS Config를 통해 인스턴스 및 전용 호스트에 대한 변경 사항도 모두 기록이 가능합니다.

전용 호스트 사용하기
여러분께서는 특정 리전, 가용 영역에 특정 인스턴스 타입에 대해서 전용 호스트를 할당하실 수 있습니다.(API, CLI 및 관리 콘솔에서 가능합니다.)

각 호스트는 특정 인스턴스 타입에 따라 미리 설정된 인스턴스 숫자가 있습니다. (예를 들어, 8개 c3.xlarge 처럼). 이는 호스트를 할당하고 나면, 8개의 인스턴스를 띄울 수 있다는 이야기입니다.

배치에 대해서도 원하는 대로 가능합니다. 특정 전용 호스트에 인스턴스를 올릴 수도 있고, 여러개 중의 하나의 전용 호스트에 올릴 수도 있습니다. 인스턴스가 중단 후 재부팅, 재시작할 때 같은 전용 호스트에 배치될 수 있도록 선호 기능도 제공합니다.

새로운 모델 역시 클라우드 기반(cloudy)입니다. 여러분이 원하는 대로 호스트와 인스턴스를 할당 및 중단할 수 있으며(클라우드에서 매우 중요한 측면이지요.), 여러분의 요구 사항에 따라 변경할 수 있는 유연성 또한 제공합니다.

지불 방식
Amazon EC2 Dedicated Hosts는 예약(Reserved) 및 온디멘드 형식을 따릅니다. 어떤 경우든, 인스턴스 실행 여부와 관계 없이 전용 호스트가 할당될 때 결제가 되거나 기존에 구매한 예약 호스트를 사용하게 됩니다.

기존 머신 이미지의 경우 AWS VM Import 및 AWS Management Portal for vCenter를 통해 이전 가능합니다. 또는 AWS Marketplace에서 찾아서 이를 Amazon EC2 Dedicated Hosts에 기존 라이선스에 따라 올릴 수 있습니다. 물론 Amazon Linux AMI 및 다른 운영체제도 지원합니다.

향후 계획
새로운 전용 호스트 모델에 대해 미리 알려드리게 되어 기쁘게 생각합니다. 빠르게 새로운 소식 및 기능을 이 블로그를 통해 공유해 드리겠습니다.

— Jeff;

이 글은 Coming Soon – EC2 Dedicated Hosts의 한국어 번역이며, re:Invent 2015의 신규 서비스 소식입니다.

작년 AWS IP 대역 JSON 형식으로 공개하였습니다. 이 글은 금요일 오후에 올렸지만 주말 내내 인기 글이 되었습니다. 많은 AWS 사용자들이 아이피 대역을 활용하여 AWS 네트워크 성장함에 따라 자체 방화벽의 규칙을 관리하는데 잘 이용할 수 있게 되었습니다. 만약 AWS Direct Connect를 사용하는 고객이라면, 이 파일을 통해 접속을 위한 라우팅 테이블을 반영에 도움을 얻을 수 있습니다.

오늘은 좀 더 쉽게 이 파일 목록을 이용할 수 있도록 Amazon Simple Notification Service (SNS) 토픽을 생성해서 업데이트 내역에 대한 알림을 받을 수 있는 기능을 알려드리겠습니다. 프로그램 코드를 통해 좀 더 쉽게 업데이트 내역을 파악하여 빠르게 적용 가능합니다.

arn:aws:sns:us-east-1:806199016981:AmazonIpSpaceChanged 토픽에 가입하고 원하는 방식대로 이용하면 됩니다. (SNS 지원 프로토콜 활용 가능)

아래와 같은 형식으로 알림을 받게 됩니다.

{
  "create-time":"yyyy-mm-ddThh:mm:ss+00:00",
  "synctoken":"0123456789",
  "md5":"6a45316e8bc9463c9e926d5d37836d33",
  "url":"https://ip-ranges.amazonaws.com/ip-ranges.json"
}

AWS Lambda 함수를 통해 변경 사항을 받으실 수도 있습니다.

이제 AWS IP 대역 파일 업데이트 내역을 쉽게 받아서 파싱 후, 원하는 정보로 가공 할 수 있게 되었습니다. 좀 더 자세한 사항은 AWS IP Address Ranges 문서를 참고하시기 바랍니다.

— Jeff;

PS – 2015년 8월 25일 현재 EC2의 IP 대역은 13,065,550개의 주소를 가지고 있습니다.

이 글은 Subscribe to AWS Public IP Address Changes via Amazon SNS의 한국어 번역입니다.

올해 초에 EC2 Spot 집합 API를 소개했습니다. 이전 글에서 언급했듯이 한번의 API 요청으로 Spot 집합 인스턴스를 시작하고 관리 할 수 있습니다. 스팟 인스턴스 집합 구성을 필요로 하는 용량 시간 당 입찰 가격 인스턴스 유형을 지정하면, Spot 집합은 최저가의 EC2 용량을 찾아 내고 그 용량을 유지 합니다.

오늘은 기존 입찰 방식에 가중치를 적용하여 Spot 집합 API 기능을 더욱 강화했습니다. 새로운 기능을 통해 인스턴스 유형 및 가용 영역 안에서 애플리케이션에 가장 적합한 입찰을 진행할 수 있습니다. RequestSpotFleet API를 호출 할 때 (인스턴스 당) 입찰 가격을 지정합니다. 하지만, 요구하는 자원에 대한 자세한 조건을 주면 더 좋을 것입니다. 예를 들어, 최소 488GiB 메모리를 2개 이상의 R3(메모리 최적화) 인스턴스를 원하거나 최소 128vCPU을 C3와 C4(컴퓨팅 최적화) 인스턴스 조합으로 원하는 경우 등입니다.

신규 자원 중심 입찰 방식
새로운 자원 중심의 입찰 모델은 이러한 종류의 스팟 집합 인스턴스 요청이 가능합니다. 각 인스턴스는 만들어질 집합 크기에 영향을 주는 여러 가지 자원을 “용량 단위(capacity units)”로 유지합니다. 앞의 예제처럼 몇 GB의 RAM 또는 얼마의 vCPU 자원이 필요한가? 또는 EBS 최적 대역폭 계산 능력, 네트워크 성능 및 기타 응용 프로그램 고유 단위 등이 많습니다. 이러한 용량 단위 Spot 인스턴스 집합의 요청 매개 변수로 사용 용량 단위 전체에 대한 각 인스턴스 비율도 알려드립니다.

이를 통해 각 인스턴스 유형을 실제로 사용할 수 있는지 여부에 신경 쓰지 않고, 여러 인스턴스 유형의 자원을 경우에 따라서는 여러 가용 영역에 걸쳐 사용할 수 있습니다. 각 RequestSpotFleet 요청에는 여러 시작 설정 (launch specification)을 지정할 수 있고, 요청한 인스턴스 유형에 따라 AMI를 지정할 수 있습니다. 각 시작 설정 (launch specification)에는 다음과 같은 값을 지정할 수 있습니다 :

• WeightedCapacity – 지정된 인스턴스 유형이 전체 용량 중 얼마나 차지하게 할지를 지정합니다. Spot 인스턴스 입찰을 할 때 유닛마다 입찰 가격을 계산합니다. 예를 들어, 15.25GB 메모리 r3.large 인스턴스에 비해서, 30.5GB 메모리를 탑재 한 r3.xlarge 인스턴스에 대해 2배의 비용을 지불한다는 입찰이 가능합니다.
• SpotPrice – 특정 유닛 단위의 입찰 가격으로 인스턴스의 입찰가보다 우선합니다. 이 값을 사용하면 특정 인스턴스 유형, 가용 영역이나 서브넷을 선택하거나 하지 않도록 하는 것이 가능합니다.

아래는 메모리 기반의 시작 설정의 한 사례입니다.

먼저 원하는 용량인 488GB를 지정하고 이에 대한 대상 용량에 대한 입찰 가격 (GB/시간)을 RequestSpotFleet를 실행하면, 이 경우 r3.large에 비해 r3.8xlarge는 16배 높은 가격을 지불하고 선언 한 것입니다.

EC2 서비스에서는 이 정보를 바탕으로 유닛 당 Spot 가격이 최저에서 사용 가능한 인스턴스를 찾아 가장 경제적인 조합의 스팟 인스턴스 집합을 구축합니다. 다음과 같이 단일 인스턴스 유형을 사용한 간단한 구성이 가능합니다 :

• 2 x r3.8xlarge
• 4 x r3.4xlarge
• 8 x r3.2xlarge
• 16 x r3.xlarge
• 32 x r3.large

조금 더 복잡하게 한다면 다음과 같습니다.

• 1 x r3.8xlarge and 2 x r3.4xlarge
• 2 x r3.4xlarge and 8 x r3.xlarge
• 8 x r3.xlarge and 16 x r3.large

시간이 지남에 따라 스팟 가격 상승으로 인스턴스가 중단 된 경우, 필요한 자원을 보충하기 위한 대체 인스턴스가 시작됩니다. 이 경우, 여러분의 애플리케이션은 인스턴스 유형 (및 사용할 수 있는 메모리 용)을 감지하여 조정해야 합니다. 스팟 집합에서는 사용 가능한 리소스를 사용하여 지정된 용량을 달성하기 위해 최대 인스턴스를 추가로 확보하게 됩니다. 이전 예제에서는 512GiB 전체 집합 인스턴스의 용량을 요청했을 때 발생합니다. 또한, 작은 요청이나 용량이 큰 인스턴스가 최저가(유닛 당) 가격인 경우에도 비슷한 일이 발생합니다.

용량 단위에 대해
용량 단위는 사전에 정해져 있으며, 인스턴스의 물리적 특성과 직접 매핑할 필요는 없습니다. 몇 가지 벤치 마크 테스트를 하여 인스턴스 유형별 트랜잭션 비율(TPS)을 측정하고 있다면, 필요한 TPS를 처리 할 수​​있는 전체 용량을 요청하는 그 시점에서 가장 경제적인 EC2 인스턴스 유형을 제시합니다. 사실 스팟 인스턴스 기법은 기술과 비즈니스의 교차점에 있습니다. 여러분의 비즈니스 경제성을 개선할 수 있고, (온디멘드 인스턴스 가격보다 90% 이상 비용 절감하기 위해) 창의적이고 혁신적인 여지가 많이 있습니다.

이러한 입찰 메커니즘을 사용하면 원하는 가용 영역의 WeightedCapacity 값을 높이고, 우선 순위를 제어할 수 있습니다. 예를 들어, 동일한 인스턴스 유형으로 여러 설정을 해두고, 다른 가용 영역에 서로 다른 가중치를 설정 할 수 있습니다.

API 요청은 AWS Command Line Interface (CLI)를 사용하거나 RequestSpotFleet API를 호출하십시오.

이 기능은 모든 리전에서 스팟 인스턴스를 사용할 때 사용 가능합니다.

— Jeff;

PS – EC2 스팟 인스턴스에 대한 자세한 사항은 스팟 인스턴스 분류글을 참고하시기 바랍니다.

본 글은 New – Resource-Oriented Bidding for EC2 Spot Instances의 한국어 번역입니다.

지난번에 EC2 Spot 인스턴스의 모범 사례 에 대한 기사를 연재할 계획을 말씀드린 바 있습니다. 그 첫번째로 Spot 인스턴스를 사용하여 어떻게 하면 가격 기반 응용 프로그램을 개발할 것인가? 라는 주제로 EC2 Spot 팀의 2 명의 시니어 개발자와 함께 이야기를 하였습니다. Dmitry Pushkarev (기술 개발 담당)와 Joshua Burgin(제품 관리자)과의 대화를 인터뷰 형식으로 편집해서 제공해 드립니다.

Jeff : Spot 인스턴스 가격의 진정한 의미는 무엇일까요?

Joshua : Spot 기반 무장애 응용 프로그램을 구축 할 때, 현재 가격과 과거 가격 기록은 중요한 고려 사항입니다. 가격을 잘 살펴봄으로서 가장 가능성 높은 용량 풀(Capacity Pool)에 응용 프로그램을 배포하거나, 서비스가 방해 받을 가능성을 줄이고 가격 성능을 전반적으로 향상시킬 수 있습니다.

Spot 시장에서 인스턴스 가격은 수요와 공급으로 정해집니다. 낮은 가격이라는 것은 수요보다 많은 용량이 있다는 것을 의미합니다. 낮은 가격이거나 낮은 변동폭으로 일정한 것은 그 용량 풀은 수요가 적다는 것을 의미합니다. 예를 들어, 이전 세대의 인스턴스가 그런 경향을 가집니다.(m1.small, c1.xlarge, cc2.8xlarge 등)

Jeff : 고객이 어떻게 (가격에 따라 인스턴스가 변동될 수 있는) 환경에서 애플리케이션을 구축할 수 있을까요?

Dmitry : (Spot 인스턴스를 이용하여) 장애가 나지 않도록 응용 프로그램을 설계할 때 ‘가격 기록’을 잘 사용하는 것은 중요합니다. 고객에게도 각각 배치 전략이있습니다만 일반적으로 두 가지 개의 성공 패턴이 있습니다. 하나는 가격 변동폭이 적은 용량 풀 (인스턴스 유형 및 가용 영역)을 선택하거나, 여러 용량 풀에 필요한 용량을 분산 배치하는 것입니다.

주식 시장이라는 좋은 예가 있습니다. “가장 좋은 성능”의 용량 풀을 찾아 정기적으로 그 선택에 대해 다시 확인 할 수 있으며, 관련이 없는 풀에 걸쳐 분산시켜 장애 위험을 크게 줄일 수 있습니다.

Jeff : 용량 풀의 배치 전략에 대해 자세히 알려주세요.

Joshua : 가격 변동 폭이 안정적인 풀을 찾기 위해 최근 Spot 가격 기록을 분석하는 아이디어가 있습니다. 용량 풀에서 입찰 희망 가격(매 시간에 지불한 최대 가격)을 초과 한 최근 시점부터 현재까지 기간으로 분석하는 방법입니다. 과거의 경향이 결코 미래의 결과를 보장하는 것은 아니지만, 처음 패턴을 보기에 좋은 방법입니다. 이 전략은 개발 테스트 환경이나 장시간 분석 작업을 하는 인스턴스에 좋습니다. Amazon EMR 클러스터에 용량을 추가하는 방법으로도 좋구요. 이익을 극대화하면서 용량 풀을 계속 사용하실 거라면, 입찰 후 어느 정도 경과 한 후에는 가격을 재검토하는 것도 추천합니다.

Jeff : 고객들이 Spot 가격 기록을 어떻게 볼 수 있습니까?
Dmitry : 콘솔 또는 SDK 및 AWS 명령어 인터페이스 (CLI) 프로그램에서 볼 수 있습니다.
또한, Spot 페이지에서 접근 가능한 웹 기반 Spot Bid Advisor을 새롭게 만들었습니다. 이 도구는 여러 가용 영역 평균 통계를 표시하고 가격 변동이 작은 인스턴스 유형을 찾아기 쉽습니다. 리전, 운영 체제, 입찰 가격 (온 디멘드의 25 %, 50 %, 100 %)을 선택하면 지난 주 또는 매월 변화, 과거 빈도를 표시합니다.

GitHub의 저장소 aws-spot-labs 에 또 다른 예가 있습니다. get_spot_duration.py 스크립트로 Spot 가격 정보를 취득하여 입찰 희망 가격을 초과한 기간에 근거하여 인스턴스 유형 및 가용 영역을 사용할 수 있습니다.

Jeff : 그렇군요. 큰 인스턴스 풀을 선택하고 정기적으로 다시 살펴봐야 하는군요.

Dmitry : 네. 그게 좋은 출발점입니다. Spot을 보다 쾌적하게 사용하는 다음 단계로는 동시에 여러 풀을 사용하는 용량을 분산하는 것입니다. 왜냐하면 각 용량 풀은 물리적으로 분리되어, 가격에 관련된 이슈가 거의 없기 때문입니다. 여러 용량풀이 단기간에 동시에 가격이 상승하는 일은 매우 드뭅니다. 이를 통해 문제가 발생할 영향을 줄일 수 되고, 필요한 용량을 확보하는 데 충분한 시간을 얻을 수 있습니다.

Joshua : 이러한 용량 분산 방법은 장기적인 가격 대비 성능도 개선합니다. 만약 여러 인스턴스 유형 및 가용 영역에 균등하게 용량을 분산하고 시간 단가는 여러 풀에서 과금되므로 결과적으로 좋은 가격 대비 성능입니다.

Jeff : 너무 좋네요. 그 다음 단계가 될 입찰 전략은 어떨까요?
Joshua : 지불하고자하는 가격에 적절하게 입찰하는 것이 중요합니다. 부당하게 높은 Spot 입찰을 하는 것보다 여러 용량 풀을 신중하게 선택하고 거기에 애플리케이션을 분산 배치하여 고가용성을 제공하는 것이 좋습니다. 현재 용량 풀 가격이 상승하고 있다는 것을 발견하면, 그것은 수요가 증가하고 있다는 의미입니다. 문제를 피하기 위해 더 저렴한 풀에 업무를 마이그레이션하거나 높은 가격으로 놀고 있는 인스턴스를 종료할 것을 추천합니다.

Jeff : 더 정교한 입찰 전략을 사용하는 고객이 있습니까?

Dmitry : 많은 고객이 Spot을 사용할 수록 경쟁력 면에서 중요합니다. 프로덕션 환경을 모두 Spot에서 실행하는 고객도 있습니다. 물론 그들의 SLA를 충족하도록 추가 엔지니어링이 필요하지만… Spot에 대한 생각에 대해 의미 있는 이야기는 “클라우드 친화적” 응용 프로그램이 Spot에 의한 효과를 얻고 있다는 것입니다. 설계에 의한 복원력, 유연성, 가격을 인식하고 있다는 것을 의미합니다. 가격을 인식하고 가장 비어있는 용량 풀에 응용 프로그램을 배포 할 수 있습니다. 특히 신생 기업은 빨리 확장시키고 보다 저렴 컴퓨팅 인프라를 사용하기 위해 독창적으로 Spot을 사용하고 있습니다.

Joshua : Auto Scaling, Spot 모음, Elastic MapReduce와 같은 도구는 Spot을 조합 할 수 있으며, 특별한 추가 개발을 하지 않고 여러 용량 풀을 동시에 사용할 수 있습니다.

Spot 인스턴스에 대한 정보를 얻기 위해 앞으로도 블로그를 계속확인해 주십시오! 언제든지 여러분의 Tips(과 질문)을 댓글에 써주세요.

– Jeff ;

이 글은 Building Price-Aware Applications Using EC2 Spot Instances의 한국어 번역입니다.