Category: Launch*


Amazon MQ – ActiveMQ용 관리형 메시지 브로커 서비스

메시징은 분산 애플리케이션의 일부분을 차지하면서 복원성을 더하고 확장성이 뛰어난 아키텍처의 구현을 가능케 합니다. 예를 들어 올해 초, Amazon Simple Queue Service(SQS)Amazon Simple Notification Service(SNS)는 프라임 데이의 고객 주문 처리를 지원하면서 도합 400억 개의 메시지를 초당 1,000만 개의 속도로 처리하였고, 고객에게는 어떠한 문제도 표시되지 않았습니다.

SQS와 SNS는 클라우드상에서 빌드된 애플리케이션에 대해 광범위하게 사용되었습니다. 하지만 많은 대형 고객들이 이미 오픈 소스 또는 상용 라이선스 메시지 브로커를 사용하고 있습니다. 고객의 애플리케이션은 미션 크리티컬이며, 이를 지원하는 메시징 또한 마찬가지입니다. 우리의 고객들은 메시징 인프라의 설치 및 지속적인 유지 관리를 “고통스러운 일”이라 설명하며, 이를 위해 인력 기준으로 주당 10시간을 사용한다고 보고합니다.

새로운 Amazon MQ
이제 우리는 Amazon MQ를 출시합니다. 이는 클릭 세 번으로 몇 분 만에 시작할 수 있는 Apache ActiveMQ용 관리형 메시지 브로커 서비스입니다. 아실 수도 있겠지만 ActiveMQ는 빠르고 기능이 다양하여 인기가 많은 오픈 소스 메시지 브로커입니다. 대기열 및 주제, 지속적 및 비지속적 구독, 푸시 기반 및 폴링 기반 메시징, 그리고 필터링을 제공합니다.

관리형 서비스로서 Amazon MQ는 ActiveMQ의 관리 및 유지 관리를 처리합니다. 여기에는 브로커 프로비저닝, 패치 적용, 고가용성을 위한 장애 탐지 및 복구, 그리고 메시지 지속성에 대한 책임이 포함됩니다. Amazon MQ를 사용하면 ActiveMQ 콘솔과 JMS, NMS, AMQP, STOMP, MQTT 및 WebSocket 등 업계 표준 메시징 API 및 프로토콜에 직접 액세스할 수 있습니다. 이를 통해 코드 재작성 없이도 이러한 표준을 사용하는 모든 메시지 브로커로부터 Amazon MQ로 이동할 수 있으며, 이때 지원되는 애플리케이션도 함께 이동합니다.

개발 및 테스팅용 단일 인스턴스 Amazon MQ 브로커, 또는 빠른 자동 장애 조치를 포함하여 AZ를 확장하는 활성/대기 페어를 생성할 수 있습니다. 어느 쪽이든 AZ에 걸친 데이터 복제와 브로커 인스턴스 및 메시지 스토리지를 위한 종량 과금제 모델을 얻습니다.

Amazon MQ는 AWS 제품군의 완성된 부분으로, 서비스 API 사용을 위한 인증 및 권한 부여용 AWS Identity and Access Management(IAM)의 사용을 포함합니다. Amazon CloudWatch 지표를 사용하여 대기열 깊이와 같은 지표를 지속적으로 확인하고 필요한 경우 소비자 집합의 Auto Scaling을 시작할 수 있습니다.

Amazon MQ 브로커 시작
Amazon MQ 콘솔을 열고, 원하는 AWS 리전을 선택하고, 브로커 이름을 입력하고 [Next step]을 클릭하는 것으로 시작합니다.

그런 다음 인스턴스 유형을 선택합니다. 여기서는 대기를 생성하겠습니다. 그리고 [Create broker]를 선택합니다([Advanced settings] 섹션에서 VPC를 선택하고 기타 설정을 세부 조정할 수도 있습니다).

5~10분 정도면 제 브로커가 생성되어 사용할 준비가 끝납니다.

브로커 액세스에 사용할 URL과 엔드포인트를 클릭 한 번으로 사용할 수 있습니다.

제공된 링크에서 ActiveMQ 웹 콘솔에 액세스할 수 있습니다.

브로커가 인스턴스, 주제 및 대기열 지표를 CloudWatch에 게시합니다. 이것이 인스턴스 지표입니다.

지금 이용 가능
Amazon MQ는 지금부터 미국 동부(버지니아 북부), 미국 동부(오하이오), 미국 서부(오레곤), EU(아일랜드), EU(프랑크푸르트)아시아 태평양(시드니) 리전에서 사용 가능합니다.

AWS 프리 티어를 통해 1년 동안 매달 단일 AZ 마이크로 인스턴스를 최대 750시간 사용하고, 최대 1기가바이트씩 저장할 수 있습니다. 이후에는 인스턴스 시간과 메시지 스토리지에 따라 결제되고, AWS 외부에서 브로커에 액세스한 경우 인터넷 데이터 전송 요금이 추가됩니다.

Jeff;

Amazon EC2 베어 메탈 인스턴스(하드웨어 직접 액세스 포함) 출시!

고객들이 AWS에 대한 새롭고 특별한 요구 사항을 가지고 우리를 찾아오면, 우리는 여기에 귀를 기울이고, 많은 질문을 던지며, 그 요구 사항을 이해하고 해결하는 데 최선을 다합니다. 이렇게 할 때 결과로 나오는 서비스 또는 기능을 일반적으로 사용할 수 있도록 합니다. 각각의 고객에게 별개로 1회성 서비스나 기능을 빌드하지 않습니다. 그러한 모델은 복잡하고 확장이 어렵기 때문에 우리는 이런 방식으로 하지 않습니다.

대신 모든 AWS 고객은 우리가 빌드한 것이 무엇이든 액세스할 수 있고, 모두가 혜택을 누리게 됩니다. AWS 기반 VMware 클라우드가 이러한 전략 실행의 좋은 예입니다. 하드웨어에서, AWS 클라우드 내에서 가상화 스택을 직접 실행함으로써 고객이 AWS에서 제공하는 탄력성, 보안 및 안정성(다양한 서비스는 말할 것도 없습니다)에 액세스할 수 있기를 원한다는 이야기를 들었습니다.

우리는 다른 고객들 또한 베어 메탈 하드웨어에 대한 사용 사례에 관심이 있고, 중첩 가상화로 인한 성능 저하를 원치 않는 것을 파악했습니다. 가상화 환경에서 언제든 사용 가능하거나 완전히 지원되지 않는 성능 카운터인텔® VT와 같은 하위 수준 하드웨어 기능을 활용하는 애플리케이션은 물론 하드웨어에서 직접 실행되거나 비가상화 환경에서의 사용에 대한 라이선스 및 지원을 받는 애플리케이션에 대한 물리적 리소스 액세스를 원했습니다.

여러 해에 걸쳐 네트워킹, 스토리지 및 기타 EC2 기능을 가상화 플랫폼에서 전용 하드웨어로 이동하려는 노력이 이미 진행되어 가능한 해결책에 대한 완벽한 기반이 제공되었습니다. 이제 Amazon EC2용 컴퓨팅 집약적 C5 인스턴스 이용 가능이라는 게시물에서 설명한 이러한 노력에는 전용 하드웨어 액셀러레이터 세트도 포함됩니다.

요청한 대로 VMware에 베어 메탈 액세스를 제공했으니, 이제 모든 AWS 고객들을 위해서도 똑같이 하겠습니다. 이를 통해 여러분들이 할 수 있는 것들이 무척 기대됩니다!

새로운 베어 메탈 인스턴스
오늘은 i3.metal 인스턴스의 퍼블릭 미리 보기를 출시합니다. 양쪽의 장점을 모두 제공하는 EC2 인스턴스 시리즈의 첫 번째 제품으로, 운영 체제가 기본 하드웨어에서 직접 실행되도록 하면서 클라우드의 모든 이점에 액세스할 수 있도록 합니다. 인스턴스를 통해 프로세서 및 기타 하드웨어에 직접 액세스할 수 있으며, 사양은 다음과 같습니다.

  • 프로세싱 – 2.3GHz에서 실행되는 2개의 인텔 Xeon E5-2686 v4 프로세서, 총 36개의 하이퍼스레드 코어(72개의 논리 프로세서).
  • 메모리 – 512GiB.
  • 스토리지 – 15.2테라바이트의 로컬, SSD 기반 NVMe 스토리지.
  • 네트워크 – 25Gbps의 ENA 기반 향상된 네트워킹.

베어 메탈 인스턴스는 EC2 패밀리의 완성된 멤버이며, Elastic Load Balancing, Auto Scaling, Amazon CloudWatch, Auto Recovery 등을 활용할 수 있습니다. 또한 AWS 데이터베이스, IoT, 모바일, 분석, 인공 지능보안 서비스의 전체 스위트에 액세스할 수 있습니다.

현재 미리 보기 진행 중
현재 베어 메탈 인스턴스의 퍼블릭 미리 보기를 출시 중입니다. 시험해 보고자 하는 경우 지금 가입하세요.

이제 특수 애플리케이션 또는 가상화된 구성 요소 스택을 AWS로 가져와 베어 메탈 인스턴스에서 실행할 수 있습니다. 컨테이너를 사용 중이거나 이를 고려 중인 경우 이러한 인스턴스가 CoreOS의 뛰어난 호스트를 만듭니다.

새로운 C5 인스턴스 중 하나에서 작동하는 AMI는 I3 베어 메탈 인스턴스에서 또한 작동합니다. ENA 및 NVMe 드라이버를 보유해야 하고, ENA에 대해 태그 지정되어야 합니다.

Jeff;

이 글은 AWS re:Invent 2017 행사의 주요 서비스 출시 소식으로  Amazon EC2 Bare Metal Instances with Direct Access to Hardware의 한국어 번역입니다.

AWS IoT, 가격 인하를 위한 신규 요금 모델 예고

많은 AWS 고객들이 AWS IoT를 사용해 연결된 디바이스를 보다 지능적으로 만들고 있습니다. 이러한 디바이스는 개별 현장(지하, 공중, 수중, 공장 및 병원 입원실)에서 데이터를 수집하여 측정하고 AWS 클라우드에 대한 게이트웨이로 AWS IoT를 사용합니다. 클라우드에 연결되면 고객은 Amazon Simple Storage Service(S3)Amazon DynamoDB에 디바이스 데이터를 기록하고, Amazon KinesisAWS Lambda 함수를 사용해 데이터를 처리하며, Amazon Simple Notification Service (SNS) 푸시 알림과 기타 다양한 기능을 시작할 수 있습니다.

새로운 요금 모델(20-40% 인하)
고객 여러분에게 더 나은 가치를 제공하기 위해 오늘부터 AWS IoT 요금 모델을 변경합니다. 대부분의 고객은 20-40%의 가격 인하 혜택을 누릴 수 있으며, 일부는 워크로드에 따라 훨씬 더 많은 할인을 받게 됩니다.

기존 모델은 서비스와 주고 받는 메시지 수에 부과되는 요금을 기반으로 했습니다. 이와 같은 통합형 모델이 출발점으로는 좋았지만, 일부 고객은 실제 사용하지 않은 AWS IoT 부분에 대한 요금을 지불하게 된다는 맹점이 있었습니다. 예를 들어 어떤 고객은 자주 발생하지 않는 스파스 규칙 세트를 이용해 매우 자주 AWS IoT를 ping하는 디바이스를 사용합니다. 새로운 모델은 각 구성 요소마다 독립적으로 요금을 부과하도록 세분화되었습니다(모든 요금은 미국 동부(버지니아 북부) 리전)에 연결되는 디바이스에 적용됨.

연결 – 디바이스가 AWS IoT에 연결된 총 시간을 기준으로, 1분 단위로 측정됩니다. 100만 분 연결에 대해 $0.08의 요금이 부과됩니다(24시간 연중 무휴 연결 시 디바이스 한 대당 연 $0.042 상당). 디바이스는 추가 비용 없이 30초 ~ 20분 간격으로 연결 유지 ping을 보낼 수 있습니다.

메시징 – 디바이스와 AWS IoT 사이에 전송되는 메시지 수를 기반으로 측정됩니다. 요금은 메시지 백만 건당 $1에서부터 시작되며 대량 구매 요금은 백만 건당 $0.70로 매우 저렴합니다. 최대 128킬로바이트 크기의 메시지를 주고 받을 수 있습니다. 메시지는 5킬로바이트 단위로 측정됩니다(이전의 512바이트에서 증대). 예를 들어 8킬로바이트 메시지 한 건은 두 건의 메시지로 측정됩니다.

규칙 엔진 – 규칙당 최소 하나의 작업이 있다는 전제 하에 규칙이 트리거될 때마다, 규칙 내에서 실행된 작업의 수를 기준으로 측정됩니다. 트리거된 규칙 백만 건당 $0.15, 실행된 작업 백만 건당 $0.15로 요금이 책정되었습니다. 5킬로바이트를 초과하는 메시지를 처리하는 규칙은 5킬로바이트 크기의 다음 배수에서 계산됩니다. 예를 들어 8킬로바이트 메시지를 처리하는 하나의 규칙은 두 개의 규칙으로 계산됩니다.

디바이스 섀도우 및 레지스트리 업데이트 – 디바이스 섀도우 또는 레지스트리 데이터에 액세스하거나 수정하기 위한 작업 수를 기준으로 측정되며, 작업 백만 건당 $1.25입니다. 디바이스 섀도우 및 레지스트리 작업은 디바이스 섀도우 또는 레지스트리 레코드 크기의 1킬로바이트 단위로 측정됩니다. 예를 들어 1.5킬로바이트 섀도우 레코드 업데이트 한 건은 두 건의 작업으로 측정됩니다.

AWS 프리 티어는 최대 50대의 디바이스 집합을 수행하기에 충분한 연결 시간(분), 메시지, 트리거된 규칙, 규칙 작업, 섀도우 및 레지스트리 사용량을 할당합니다. 새로운 요금은 2018년 1월 1일부터 자동으로 적용됩니다. 업데이트된 요금이 적용되는 시점에 AWS IoT 요금 페이지에 게시됩니다.

re:Invent의 AWS IoT
올해 AWS re:Invent에 전체 AWS IoT 트랙이 실려 있습니다. 예시:

Philips, Panasonic, Enel, Salesforce가 발표하는 고객 세션도 마련되어 있습니다.

Jeff;

이 글은 AWS IoT Update – Better Value with New Pricing Model의 한국어 번역입니다.

새 소식 – 대화형 AWS 비용 탐색기 API

몇 년 전 AWS 비용의 추적, 할당 및 관리가 가능하도록 AWS 비용 탐색기를 출시했습니다. 그 출시에 대한 대응과 이후의 추가 기능은 매우 긍정적이었습니다. 하지만, 일부 고객들은 Jeff Bezos의 의견처럼 매우 불만스러워 했습니다.

새롭게 서비스를 출시하면, 항상 고객에게 더 많은 것을 요구합니다. 예를 들어 많은 고객들은 IT 인프라 대부분을 AWS 클라우드로 이동한 후, 비용 탐색기에 공급되는 전체 데이터에 대한 많은 요청을 받았습니다. 이러한 고객들은 프로그래밍 방식으로 AWS 비용을 탐색하고, 애플리케이션별 및 부서별 비용으로 원장 및 회계 시스템을 업데이트하기 위한 목적을 가지고 있습니다. 또한 지출을 요약하는 높은 수준의 대시보드를 직접 만들어 운영 합니다. 일부 고객들은 비용 탐색기에서 공급하는 차트 및 보고서로부터 데이터를 추출하는 데 공을 들여왔습니다.

새로운 비용 탐색기 API 출시
오늘 비용 탐색기로 공급되는 기본 데이터를 프로그래밍 방식으로 이용 가능합니다. 새로운 비용 탐색기 API는 위에 설명한 모든 것을 할 수 있도록 여러 기능을 제공합니다. 비용 및 사용량 데이터를 검색하여 여러 차원(서비스, 연결 계정, 태그, 가용 영역 등)에 걸쳐 필터링 및 그룹화하고, 일 또는 월별로 집계할 수 있습니다. 이를 통해 단순하게 시작(총 월별 비용)하고, 요청을 원하는 상세 수준(프로덕션으로 태그 지정된 DynamoDB 테이블에 쓰기)으로 구체화하면서 몇 초 만에 해답을 얻을 수 있습니다.

작업은 다음과 같습니다.

GetCostAndUsage – 필터링 및 그룹화를 포함하여 단일 계정 또는 모든 계정(모든 멤버 계정에 액세스할 수 있는 조직의 마스터 계정)에 대한 비용 및 사용량 지표를 검색합니다.

GetDimensionValues – 지정된 기간에 대한 지정된 필터로 이용 가능한 필터 값을 검색합니다.

GetTags – 지정된 기간에 대해 이용 가능한 태그 키 및 태그 값을 검색합니다.

GetReservationUtilization – 지정된 기간(일별 또는 월별 세부 수준에 필터링 및 그룹화 포함)에 대한 EC2 예약 인스턴스 활용을 검색합니다.

이러한 기능, 그리고 이를 통해 얻는 데이터가 비즈니스에 대한 더 나은 통찰력을 제공하는 흥미로운 무언가를 하는 능력을 제공할 것입니다. 예를 들어 개별 마케팅 캠페인 또는 개발 프로젝트를 지원하는 데 사용하는 리소스에 태그를 지정한 다음 비용을 심층 분석하여 비즈니스 가치를 측정할 수 있습니다. 이제 사이버 먼데이블랙 프라이데이와 같은 중요 이벤트에 대해 인프라에 어느 정도 비용을 사용할지 상세한 단위까지 파악할 수 있는 잠재력을 갖게 된 것입니다.

알아야 할 것들
다음은 API를 사용하는 방법에 관해 생각할 때 몇 가지 알고 있어야 할 사항입니다.

그룹화 – 비용 탐색기 웹 애플리케이션은 한 가지 수준의 그룹화를 제공하지만, API는 두 가지 수준을 제공합니다. 예를 들어 비용 또는 RI 사용률을 서비스별 및 리전별로 그룹화할 수 있습니다.

페이지 매김 – 대용량 데이터를 반환하고 nextPageToken을 포함하여 페이지 매김에 대한 AWS 차원의 모델을 따릅니다. 추가 데이터를 이용 가능한 경우의 페이지 매김 예입니다. 이 기능을 간단하게 호출하여 토큰을 제공하면 계속 진행됩니다.

리전 – 서비스 엔드포인트는 미국 동부(버지니아 북부) 리전에 있으며, 모든 AWS 리전에 대한 사용량 데이터를 반환합니다.

요금 – 각 API 호출 요금은 0.01 USD입니다. 좀 더 자세히 살펴보기 위해 API를 사용하여 대시보드를 만들고, 사용자들로부터 월별 1,000회의 호출이 있다고 가정하겠습니다. 대시보드에 대한 운영 비용은 10 USD정도로 예측합니다. 자체 시스템을 설치하고 데이터를 추출 및 수집한 다음 대화형 쿼리에 응답하는 데 비하면 훨씬 저렴합니다.

비용 탐색기 API는 지금 이용 가능하며 오늘부터 사용할 수 있습니다. 자세히 알아보려면 비용 탐색기 API에 대해 읽어 보십시오.

Jeff;

이 글은 New – Interactive AWS Cost Explorer API의 한국어 번역입니다.

Amazon EC2 업데이트 – 신규 X1e 인스턴스 타입과 더욱 강력한 서비스 수준(SLA) 지원

올해 초에 4개의 AWS 리전에 4TB의 메모리를 포함한 x1e.32xlarge 인스턴스를 출시했습니다. 그리고 출시 후 2개월이 지난 현재, 고객들은 이 인스턴스를 사용하여 대용량 메모리를 활용할 수 있는 고성능 관계형 및 NoSQL 데이터베이스, 인 메모리 데이터베이스, 그리고 기타 엔터프라이즈 애플리케이션을 실행하고 있습니다.

5가지 이상 크기의 X1e
5개의 추가적인 인스턴스 크기가 포함된 메모리 최적화 X1e 패밀리를 소개합니다. 라인업은 다음과 같습니다.

모델 vCPU 메모리(GiB) SSD 스토리지(GB) 네트워킹 성능
x1e.xlarge 4 122 120 최대 10Gbps
x1e.2xlarge 8 244 240 최대 10Gbps
x1e.4xlarge 16 488 480 최대 10Gbps
x1e.8xlarge 32 976 960 최대 10Gbps
x1e.16xlarge 64 1,952 1,920 10Gbps
x1e.32xlarge 128 3,904 3,840 25Gbps

인스턴스는 대용량 L3 캐시와 많은 메모리 대역폭을 갖추고 2.3GHz에서 실행되는 쿼드 소켓 인텔® Xeon® E7 8880 프로세서에 의해 구동됩니다. ENA 네트워킹 및 EBS 최적화가 표준이며, 최대 14Gbps의 EBS 전용 처리량을 포함합니다(인스턴스 크기에 따라 다름).

오늘 출시의 일환으로 모든 크기의 X1e를 아시아 태평양(시드니) 리전에서 사용할 수 있습니다. 따라서, 미국 동부(버지니아 북부), 미국 서부(오레곤), EU(아일랜드), 아시아 태평양(도쿄)아시아 태평양(시드니) 리전의 온 디맨드 및 예약 인스턴스에서 이를 시작할 수 있습니다.

더욱 강력한 EC2 서비스 수준(SLA) 추가
좋은 소식이 하나 더 있습니다!

지금 이후로 모든 리전 및 모든 AWS 고객에 대한 EC2 및 EBS 모두의 EC2 서비스 수준 계약(SLA)을 99.99% (기존 99.95%)로 높혔습니다. 지속적인 인프라 및 서비스 품질 투자와 함께 운영 우수성에 집중한 덕분에 이러한 변화가 가능했습니다.

Jeff

AWS Direct Connect Gateway 출시 – 리전 간 VPC 접근 기능 제공

지난 2012년 AWS Direct Connect를 출시하여, 기업 고객들이 기존 사무실 및 데이터 센터와 AWS와 전용선으로 연결할 수 있게 되어 개인 정보 보호 개선, 데이터 전송 대역폭 추가, 보다 예측 가능한 데이터 전송 성능 개선이 가능합니다.  최근 집계에 따르면 60곳 이상에서 접근 가능하며, 서울 리전의 경우도  드림라인, KINX, 세종 텔레콤, LG유플러스 등 파트너를 통해 연결하실 수 있습니다.

오늘 부터 AWS Direct Connect 게이트웨이(Gateway)를 추가하여 Direct Connect를 더 단순하면서도 더 강력한 도구로 만들고 있습니다. 모든 리전의 Direct Connect 고객에게 전역 Amazon IP 경로를 수신할 수 있는 퍼블릭 가상 인터페이스를 만들고, Amazon 서비스에 대한 퍼블릭 엔드포인트에 액세스하고, Direct Connect 요금 모델을 업데이트할 수 있는 기능을 제공합니다.

그럼 각 기능을 자세히 살펴보겠습니다.

새로운 Direct Connect 게이트웨이
이제 새로운 Direct Connect 게이트웨이를 사용하여 여러 AWS 리전에 걸쳐 있는 Virtual Private Cloud(VPC)에 연결할 수 있습니다. 더 이상 VPC마다 BGP 세션을 여러 개 설정할 필요가 없기 때문에, 관리 워크로드는 물론 네트워크 장치의 부담도 줄어듭니다.

또한 이 기능을 사용하면 모든 Direct Connect 위치에서 연결된 모든 VPC에 연결할 수 있으므로 리전 간 AWS 서비스를 사용하는 비용이 한층 더 절감됩니다.

다음은 Direct Connect 게이트웨이로 간소화된 구성을 보여 주는 다이어그램입니다(각 “자물쇠” 아이콘은 가상 프라이빗 게이트웨이를 나타냄). 먼저 아래와 같은 상태로 시작합니다.

그리고 최종적으로 다음과 같은 상태가 됩니다.

특정 Direct Connect 게이트웨이를 참조하는 VPC들의 IP 주소 범위가 중첩되지 않아야 합니다. 현재는 모든 VPC가 동일한 AWS 계정에 속해야 하지만, 앞으로 이를 좀 더 유연하게 만들 계획입니다.

각 게이트웨이는 모든 퍼블릭 AWS 리전에 걸쳐 존재하는 전역 객체입니다. 게이트웨이를 통한 리전 간의 모든 통신은 AWS 네트워크 백본에서 이루어집니다.

Direct Connect 게이트웨이 생성
Direct Connect 게이트웨이는 Direct Connect 콘솔에서 만들거나 코드에서 CreateDirectConnectGateway 함수를 호출하여 만들 수 있습니다. 저는 콘솔을 사용해 보겠습니다.

Direct Connect 콘솔을 열고 [Direct Connect Gateways]를 클릭해 시작합니다.

아직 게이트웨이가 없기 때문에 목록이 비어 있습니다. [Create Direct Connect Gateway]를 클릭해 다음과 같이 변경합니다.

게이트웨이 이름을 지정하고, 우리 네트워크의 프라이빗 ASN을 입력한 다음 [Create]를 클릭합니다. 이때 ASN(자율 시스템 번호)은 RFC 6996에 정의된 프라이빗 범위 중 하나에 속해야 합니다.

잠시 후 상대방 AWS 리전에 새 게이트웨이가 나타납니다.

오하이오에 Direct Connect 연결이 생겼고, 저는 이것으로 VIF를 생성하려고 합니다.

이제 해당 게이트웨이 및 연결을 참조하는 프라이빗 VIF를 생성합니다.

몇 초 안에 사용할 준비가 됩니다.

이미 CIDR이 중첩되지 않는 VPC 한 쌍이 있고, 각각에 가상 프라이빗 게이트웨이가 연결되어 있습니다. 다음은 VPC입니다. 데모이기 때문에 편의상 둘 다 같은 리전에 있는 VPC를 보여 드리겠습니다.

가상 프라이빗 게이트웨이는 다음과 같습니다.

Direct Connect 콘솔로 돌아가서 Direct Connect 게이트웨이로 이동합니다. 게이트웨이를 선택하고 [Actions] 메뉴에서 [Associate Virtual Private Gateway]를 선택합니다.

그런 다음 가상 프라이빗 게이트웨이 두 개를 선택하고 [Associate]를 클릭합니다.

일반적인 경우처럼 두 VPC가 별개의 AWS 리전에 있더라도 동일한 절차가 적용됩니다. 이 블로그 게시물에서는 일을 쉽게 하기 위해 두 번 대신 한 번만 작업을 했습니다.

1분 정도면 가상 게이트웨이 연결이 완료됩니다([associating] 상태로 시작).

상태가 associated로 바뀌면 VPC가 어떤 AWS 리전에 있든 간에 AWS Direct Connect 연결을 통해 온-프레미스 네트워크와 VPC 간에 트래픽이 흐를 수 있습니다.

서비스 엔드포인트를 위한 퍼블릭 가상 인터페이스
이제 퍼블릭 가상 인터페이스를 만들고, 여기에서 Direct Connect를 통해 AWS 퍼블릭 서비스 엔드포인트에 액세스한 다음 원하는 AWS 리전(AWS 중국 리전 제외)에서 실행 중인 AWS 서비스를 이용할 수 있습니다. 이러한 인터페이스는 (BGP를 통해) Amazon의 전역 IP 경로를 수신합니다. Direct Connect 콘솔에서 이러한 인터페이스를 만들 수 있습니다. 먼저 아래 그림처럼 [Public] 옵션을 선택합니다.

업데이트된 요금 모델
AWS 리전과 AWS Direct Connect 위치가 계속해서 늘어난다는 점을 고려하여, 이제 Direct Connect 위치와 원본 AWS 리전의 위치를 기준으로 데이터 전송 요금을 산정합니다. 새 요금 체계는 AWS Direct Connect 위치를 기준으로 하던 이전 모델보다 간단합니다.

지금 사용 가능
이 새로운 기능은 바로 오늘부터 사용할 수 있습니다. 무료로 Direct Connect 게이트웨이를 만들고 사용해 보십시오. 포트 시간 및 데이터 전송에는 일반적인 Direct Connect 요금이 청구됩니다.

Jeff;

이 글은 New – AWS Direct Connect Gateway – Inter-Region VPC Access의 한국어 번역입니다.

Amazon S3 신규 기본 암호화 및 보안 기능 업데이트

지난 2006년 S3를 발표했을 때, “각 블록은 ACL(액세스 제어 목록)로 보호되기 때문에 개발자가 원한다면 데이터를 프라이빗 데이터로 유지해도 되고, 읽을 수 있는 데이터로 공유해도 되고, 읽고 쓸 수 있는 데이터로 공유해도 된다”라고 알려드렸습니다.

접근 권한 부여를 위한 ACL과 프라이빗 버킷을 적용했던 바로 그 첫 번째 모델부터 우리는 필요에 따라 고객 및 파트너와 데이터를 공유하는 동시에 데이터를 안전하게 보호할 수 있는 도구를 제공하겠다는 목표를 가지고 버킷 정책, 서버 액세스 로깅, 버전 관리, API 로깅, 교차 리전 복제, 그리고 클라이언트서버 측 암호화 옵션 등의 지원을 추가해 왔습니다. 이와 함께 대규모 콘텐츠 검색, 분류 및 보호 도구인 Amazon Macie를 출시하여 인공 지능과 기계 학습의 장점도 가져왔습니다.

그리고 오늘, 드디어 S3에 다음 다섯 가지의 암호화 및 보안 기능을 새로 추가합니다.

  • 기본 암호화 – 이제 암호화되지 않은 객체를 거부하는 버킷 정책을 구성하지 않고도 버킷의 모든 객체를 암호화된 형식으로 저장하게 할 수 있습니다.
  • 권한 확인 – S3 콘솔에서는 공개 액세스가 가능한 각 S3 버킷 옆에 눈에 잘 띄는 표시가 나타납니다.
  • 교차 리전 복제 ACL 덮어쓰기 – AWS 계정 간에 객체를 복제할 때, 대상 계정에 대한 모든 액세스 권한을 제공하는 새 ACL을 해당 객체로 가져오도록 지정할 수 있습니다.
  • KMS를 사용한 교차 리전 복제 – 이제 AWS Key Management Service(KMS)로 관리하는 키를 사용해 암호화된 객체를 복제할 수 있습니다.
  • 세부 인벤토리 보고서 – 이제 S3 인벤토리 보고서에 각 객체의 암호화 상태도 표시됩니다. 또한 이 보고서 자체도 암호화가 가능합니다.

그럼 각 기능을 자세히 살펴보겠습니다.

기본 암호화
S3 객체를 위한 서버 측 암호화 옵션에는 S3 관리 키를 사용하는 SSE-S3, AWS KMS 관리 키를 사용하는 SSE-KMS, 사용자 관리 키를 사용하는 SSE-C, 이렇게 세 가지가 있습니다. 특히 유휴 상태에서도 반드시 암호화해야 한다는 규정 준수 요건을 충족해야 하는 고객을 비롯하여 일부 고객들은 새로 저장하는 모든 객체를 버킷 정책으로 암호화해 왔습니다. 이렇게 하면 요건을 준수하는 데 도움이 되기는 하지만, 암호화되지 않은 객체의 저장을 거부하는 것만으로는 완벽한 솔루션이라 할 수 없습니다.

이제 버킷 암호화 구성을 설치하여 버킷의 모든 객체를 암호화된 형태로 저장하도록 강제할 수 있습니다. 즉, 암호화되지 않은 객체가 S3에 입력되면 이 구성에 따라 암호화 사용을 지시하고, 해당 버킷에 지정된 암호화 옵션을 사용해 그 객체를 암호화하게 됩니다(PUT 요청으로 다른 옵션도 지정 가능).

다음은 버킷을 새로 만들 때 S3 콘솔을 사용하여 이 기능을 활성화하는 방법입니다. 평상시처럼 버킷의 이름을 입력하고 [Next]를 클릭합니다. 그런 다음 아래로 스크롤하여 [Default encryption]을 클릭합니다.

원하는 옵션을 선택하고 [Save]를 클릭합니다(AWS-KMS를 선택하면 KMS 키도 지정해야 함).

PUT 버킷 암호화 기능을 호출해서 이와 같이 변경할 수도 있습니다. 이 경우에는 SSE 알고리즘(SSE-S3 또는 SSE-KMS)을 지정해야 하고, 선택적으로 KMS 키를 참조할 수 있습니다.

이 기능을 구현할 때는 다음을 염두에 두십시오.

SigV4 – S3 REST API를 통해 버킷 정책에 액세스하려면 SigV4로 서명하고 SSL 연결을 이용해야 합니다.

버킷 정책 업데이트 – 암호화되지 않은 객체를 거부하는 기존의 버킷 정책을 살펴본 다음 주의해서 수정해야 합니다.

대량 사용 – SSE-KMS를 사용하고 초당 수백에서 수천 개의 객체를 업로드하는 경우, 암호화 및 암호 해독 작업에 대한 KMS 제한에 걸릴 수 있습니다. 이 경우 다음과 같이 지원 사례를 제출해 한도를 높여 달라고 요청하기만 하면 됩니다.

교차 리전 복제 – 암호화되지 않은 객체는 대상 버킷의 구성에 따라 암호화됩니다. 이렇게 암호화된 객체는 그 상태로 유지됩니다.

권한 확인
버킷 정책, 버킷 ACL 및 객체 ACL를 조합하면 버킷과 버킷 내 객체에 대한 액세스를 매우 세밀하게 제어할 수 있습니다. 사용자의 정책과 ACL을 합쳐 원하는 효과를 얻을 수 있도록 하기 위해, AWS는 최근 S3 버킷 보호를 위한 관리형 구성 규칙을 선보였습니다. 게시물에서 언급했듯이, 이러한 규칙에는 자동 형식 추론을 사용하기 위한 기술이 들어가 있습니다.

이제 바로 그 기본 기술을 사용하여 버킷 정책 및 ACL을 변경하자마자 그 효과를 확인할 수 있습니다. 퍼블릭 액세스를 위해 버킷을 여는 즉시 이러한 효과가 확인되기 때문에 자신 있게 변경할 수 있습니다.

다음은 S3 콘솔 기본 페이지의 모양입니다(편의상 액세스 열 기준으로 정렬).

버킷 중 하나로 들어가 살펴보면 퍼블릭 표시기도 나와 있습니다.

또한 어떤 권한 요소(ACL, 버킷 정책 또는 둘 다)가 퍼블릭 액세스를 지원하고 있는지도 확인할 수 있습니다.

교차 리전 복제 ACL 덮어쓰기
고객들은 흔히 미션 크리티컬 객체 및 데이터를 다른 AWS 계정의 대상 버킷으로 복사할 때 S3의 교차 리전 복제를 사용합니다. 이 복제 프로세스는 객체를 복사하는 한편 객체 ACL 및 그 객체와 연결된 모든 태그를 복사합니다.

여기에 전송 중 ACL를 교체하여 대상 버킷의 소유자에게 모든 액세스 권한을 부여할 수 있도록 함으로써 이 기능을 더욱 유용하게 만들었습니다. 이러한 변경 덕분에 소스 및 대상 데이터의 소유권을 AWS 계정 간에 나눌 수 있고, 이를 토대로 원본 객체와 그 복제본에 대한 소유권 스택을 별도로 관리할 수 있습니다.

복제 설정 시 이 기능을 활성화하려면 계정 ID 및 버킷 이름을 지정한 다음 [Save]를 클릭하여 다른 계정과 다른 리전에 있는 대상 버킷을 선택합니다.

그런 다음 [Change object ownership…]을 클릭합니다.

또한 대상 계정의 대상 버킷에 대한 키 정책을 보다 쉽게 설정할 수 있도록 했습니다. 따라서 계정에 로그인하여 원하는 버킷을 찾은 다음, [Management] 및 [Replication]을 차례로 클릭하고 [More] 메뉴에서 [Receive objects…]를 선택하기만 하면 됩니다.

소스 계정 ID를 입력하고, 버전 관리를 활성화하고, 정책을 살펴보고 적용한 다음 [Done]을 클릭합니다.

KMS를 사용한 교차 리전 복제
SSE-KMS로 암호화한 객체를 리전 간에 복제하는 데는 흥미로운 문제가 있는데, 오늘은 이 문제를 다루고자 합니다. KMS 키는 특정 리전에 고유한 키이기 때문에 암호화된 객체를 복제만 해서는 효과가 없습니다.

이제 교차 리전 복제를 설정할 때 대상 키를 선택할 수 있습니다. 복제 프로세스 중 암호화된 객체는 SSL 연결을 통해 대상으로 복제됩니다. 이어서 대상에서는 복제 구성에 지정된 KMS 마스터 키로 데이터 키를 암호화합니다. 이때 객체는 원래의 암호화된 형태를 끝까지 유지하며, 실제로 달라지는 것은 키가 들어 있는 봉투뿐입니다.

아래 그림은 복제 규칙을 설정할 때 이 기능을 활성화하는 방법을 보여줍니다.

단, 앞서 언급한 것처럼 이 기능을 많이 사용하려면 먼저 KMS 한도 증가를 요청해야 할 수 있습니다.

세부 인벤토리 보고서
마지막으로 역시 중요한 기능이라면, 이제 각 객체의 암호화 상태에 대한 정보를 담은 일별 또는 주별 S3 인벤토리 보고서를 요청할 수 있습니다.

보시다시피 보고서에 대한 SSE-S3 또는 SSE-KMS 암호화를 요청할 수도 있습니다.

정식 출시
모든 기능을 바로 사용할 수 있습니다! 이러한 기능은 무료로 제공되지만 KMS 호출, S3 스토리지, S3 요청 및 리전 간 데이터 전송에는 일반 요금이 청구됩니다.

Jeff;

이 글은 New Amazon S3 Encryption & Security Features의 한국어 버전입니다.

Amazon Aurora 기반 PostgreSQL 호환 서비스 정식 출시

작년 말 Amazon Aurora 서비스에 PostgreSQL 호환 기능 추가 계획에 대해 이야기했습니다.  발표 직후 비공개 베타 버전을 출시했으며, 금년 초 공개 프리뷰를 통해이를 따라 갔다. 베타 및 미리보기 중에 많은 피드백을 받았으며 제품이 고객의 요구를 충족시키고 기대치를 초과 할 수 있도록 최선을 다했습니다.

정식 출시
오늘 Amazon Aurora기반 PostgreSQL 서비스를 정식 출시 하며, 우선 토교 리전을 포함 4개 AWS 리전에서 사용가능합니다.  PostgreSQL 9.6.3과 호환되며 최대 64TB의 스토리지를 지원하도록 자동으로 확장되며, 컴퓨팅 성능과 가용성을 개선하기 위해 6-way 복제 기능을 제공합니다.

Amazon Aurora 기반 MySQL 서비스 처럼  관리 서비스로서 설정과 사용이 매우 쉽습니다. 성능 측면에서 보면 PostgreSQL을 직접 실행 한 경우 얻을 수있는 처리량의 최대 3 배를 기대할 수 있습니다 (Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases  참고)

RDS Console에서 Amazon Aurora를 엔진으로 선택하고 PostgreSQL과 호환되는 에디션을 선택하고 Next를 클릭하여 PostgreSQL과 호환되는 Amazon Aurora 인스턴스를 시작할 수 있습니다.

그런 다음 인스턴스 클래스, 단일 또는 다중 AZ 배포 (각각 dev / test 및 production에 적합)를 선택하고 인스턴스 이름 및 관리자 자격 증명을 설정하고 Next를 클릭합니다.

6개의 인스턴스 클래스 (2 – 64 vCPU 및 15.25 – 488 GiB 메모리) 중에서 선택할 수 있습니다.

db.r4인스턴스 클래스는 Aurora와 RDS에 추가 된 새로운 클래스이며 최상위 더 많은 용량을 제공합니다. db.r4.16xlarge 는 추가 쓰기 성능을 제공하며 두 개 이상의 샤드 된 데이터베이스 대신 단일 오로라 데이터베이스를 사용할 수 있습니다.

또한 다음 페이지에서 VPC 및 공용 액세스 가능성과 같은 네트워크 옵션부터 많은 고급 옵션을 설정할 수 있습니다.

클러스터 이름 및 기타 데이터베이스 옵션을 설정할 수 있습니다. 암호화는 사용하기 쉽고 기본적으로 사용 가능합니다. 내장 기본 마스터 키를 사용하거나 직접 선택할 수 있습니다.

장애 조치 (failover) 동작, 스냅 샷 백업의 보존 기간을 설정하고 향상된 모니터링을 통해 세부 (OS 수준) 메트릭 수집을 활성화하도록 선택할 수도 있습니다.

원하는대로 설정 한 후에는 Launch DB Instance를 클릭하여 계속 진행하십시오!

새 인스턴스 (다중 AZ를 지정한 이후 Primary 및 Secondary 지정)가 몇 분 안에 실행됩니다.

각 PostgreSQL과 호환되는 인스턴스는 CloudWatch에 44개의 메트릭을 자동으로 게시합니다.

향상된 모니터링을 사용하면 각 인스턴스는 인스턴스 별 및 프로세스 별 메트릭을 추가로 수집합니다. 인스턴스가 시작될 때 또는 나중에 Modify Instance을 통해 활성화 할 수 있습니다. 다음은 향상된 모니터링이 활성화되었을 때 수집 된 일부 측정 항목입니다.

Manage Graphs (그래프 관리)를 클릭하면 표시되는 메트릭을 선택할 수 있습니다.

프로세스 별 메트릭도 사용할 수 있습니다.

최대 15 개의 Aurora 복제본을 만들어 읽기 용량을 확장 할 수 있습니다.

클러스터는 복제본에서 요청을로드 밸런스하기 위해 접근할 수있는 단일 엔드 포인트를 제공합니다.

성능 살펴보기
이전에 언급했듯이 통계는 자동으로 사용 설정됩니다. Amazon Aurora 기능은 데이터베이스 엔진에 직접 연결되어있어 각 쿼리를 깊이 조사하고 사용하는 데이터베이스 리소스 및 전반적인 응답 시간에 기여하는 방식을 확인할 수 있습니다. 다음은 초기보기입니다.

각 쿼리의 동시 복사본 수를 보려면 SQL 쿼리로 보기 방식을 구분 할 수 있습니다.

이 글에 있는 것 보다 더 많은보기와 옵션이 있습니다. 자세한 내용은 Using Performance Insights을 참조하십시오.

Amazon Aurora PostgreSQL 서비스로 이전
AWS Database Migration ServiceSchema Conversion Tool은 상용 및 오픈 소스 데이터베이스에 저장된 데이터를 Amazon Aurora로 이동할 수 있도록 도와줍니다. 스키마 변환 도구는 MySQL과 PostgreSQL 사이에서 선택할 수 있도록 데이터베이스 스키마와 코드를 신속하게 평가합니다. 신규 무료 DMS 프로그램을 사용하면 DMS 및 SCT를 사용하여 무료로 Aurora로 마이그레이션 할 수 있으며 여러 유형의 DMS 인스턴스에 최대 6 개월간 접근 할 수 있습니다.

이미 PostgreSQL을 사용하고 있다면 PostGISdblink를 포함한 확장 기능 목록을 지원한다는 소식을 듣게 될 것입니다.

정식 출시
미국 동부 (버지니아 북부), 유럽 연합 (아일랜드), 미국 서부 (오레곤) 및 미국 동부 (오하이오) 지역에서는 Amazon Aurora와 PostgreSQL 호환성을 사용할 수 있으며 가능한 한 빨리 다른 사람들과 함께 할 수 있습니다.

Jeff;

이 글은 Now Available – Amazon Aurora with PostgreSQL Compatibility 의 한국어 번역입니다.