Category: Virtual Private Cloud


Amazon DynamoDB에 대한 VPC 엔드포인트 추가

오늘부터 Amazon DynamoDB에 대한 Amazon Virtual Private Cloud (VPC)  엔드 포인트를 (서울 리전 포함) 모든 AWS 리전에서 사용할 수 있습니다. AWS 관리 콘솔 또는 AWS 명령줄 인터페이스 (CLI)를 사용하여 즉시 엔드 포인트를 프로비저닝 할 수 있습니다. DynamoDB의 VPC 엔드 포인트 사용에는 추가 비용이 들지 않습니다.

AWS 고객은 각자 자원에 대한 통신 보안 또는 외부 격리가 필요한 이유로 Amazon VPC (Virtual Private Cloud) 내에서 애플리케이션을 실행합니다. 이전에는 VPC내 EC2 인스턴스가 DynamoDB에 접속하려면 두 가지 옵션이 있었습니다.

먼저 인터넷 게이트웨이 (NAT 게이트웨이 또는 인스턴스 공용 IP 할당)를 사용하거나 VPN 또는 AWS Direct Connect를 통해 로컬 인프라로 모든 트래픽을 라우팅 한 다음 DynamoDB로 다시 라우팅 할 수 있습니다. 이러한 솔루션은 데이터 보안 및 네트워크 처리량에 영향을 미치기 때문에 NACL 또는 보안 그룹을 구성하여 DynamoDB에 대한 접근만 제한 할 수 있습니다. 아래 그림은 이러한 이전 방식의 아키텍처 입니다.

엔드 포인트 만들기

이제 DynamoDB에 대한 VPC 엔드포인트를 만들어 보겠습니다. DescribeVpcEndpointServices API 호출로 지원 여부를 알 수 있습니다.

Bash

aws ec2 describe-vpc-endpoint-services --region ap-northeast-2
{
    "ServiceNames": [
        "com.amazonaws.ap-northeast-2.dynamodb",
        "com.amazonaws.ap-northeast-2.s3"
    ]
}

다양한 API를 사용하여, 엔드포인트 설정도 가능합니다.

이제 콘솔 사용 방법을 알려 드리겠습니다. 먼저 VPC 콘솔로 이동하여, 사이드 바에서 “Endpoints”를 선택합니다. 거기에서 “Create Endpoint”를 클릭하면 됩니다.

엔드포인트에 대한 AWS Identity and Access Management (IAM) 정책 섹션을 확인할 수 있습니다. 이는 일반 IAM 정책에서 DynamoDB가 지원하는 모든 세분화된 접근 제어를 지원하며 IAM 정책 조건에 따라 접속을 제한 할 수 있습니다.

현재 VPC 내 인스턴스에 대한 전체 접속 권한을 부여하고 “Next Step”를 클릭하십시오.

이를 통해 VPC 경로 테이블 목록을 가져오고, 경로 테이블 중 어느 쪽에 내 엔드포인트를 할당할지 선택하고 “Create Endpoint”를 선택합니다.

콘솔에서 나오는 경고 메시지에서 공용 IP 주소를 기반으로 DynamoDB에 대한 소스 제한 사항이 있는 경우, DynamoDB에 접근하는 인스턴스의 소스 IP가 사설 IP 주소가됩니다

DynamoDB 용 VPC Endpoint를 VPC에 추가 한 후,  아키텍처는 아래와 같이 단순화 됩니다.

진짜 간단하게 끝낼 수 있습니다. 오늘 부터 바로 사용 가능하며 더 자세한 사항은 기술 문서를 참고하시기 바랍니다.

– Randall;

이 글은 New – VPC Endpoints for DynamoDB의 한국어 번역입니다.

AWS Direct Connect 업데이트 – 링크 집합 그룹 출시

오늘 AWS Direct Connect의 새로운 기능인 링크 집합(Link Aggregation) 출시 기능에 대해 말씀 드리고자 합니다.

일부 AWS 고객은 자신의 내부 네트워크와 46 개의 Direct Connect 위치 중 하나에 여러 개의 연결 (일반적으로 포트라고 함)을 설정 하고자 하는 요구 사항이 있었습니다.합니다. 어떤 고객은 AWS 외부 네트워크 문제에도 탄력적인 고가용성 링크를 만들고자 하거나, 단순히 더 많은 데이터 전송 처리량이 필요로 하는 경우도 있습니다.

이러한 중요한 고객 요구를 지원하기 위해 이제 최대 4 개의 포트를 구입하여 단일 관리 연결로 관리할 수 있습니다. 이를 링크 집계 집합 또는 LAG라고 합니다. 본 설정을 통해 네트워크 트래픽을 개별 패킷 수준에서 포트를 통해 로드 밸런싱됩니다. 모든 포트는 동시에 활성화되며, 단일 BGP 세션으로 나타납니다. 그룹 전체 트래픽은 동적 LACP (Link Aggregation Control Protocol – 또는 ISO/IEC/IEEE 8802-1AX:2016)를 통해 관리됩니다. 그룹을 만들 때 연결을 활성화하기 위해 활성화되어야 하는 최소 포트 수를 지정합니다.

여러 포트가 있는 새 그룹을 요청할 수 있으며, 기존 포트를 새 그룹으로 합칠 수 있습니다. 모든 포트는 동일한 속도 (1Gbps 또는 10Gbps)를 가지게 됩니다.

모든 포트는 AWS 측 동일한 장치에 연결됩니다. 기존 네트워크 장치에 여유 공간이 있는 한 기존 그룹에 포트를 추가 할 수 있습니다. (Direct Connect Console서 사용할 수 있음). 기존 그룹을 확장 및 장치에 열려있는 포트가 없는 경우, 새 그룹을 신청하고 기존 연결을 마이그레이션 하기만 하면 됩니다.

다음은 AWS Dicrect Connect 콘솔에서 링크 집합을 사용하는 방법입니다. 먼저 처음부터 새로운 LAG를 생성합니다.

둘째, 기존 연결에서 LAG 생성을 할 수 있습니다.


링크 집합 그룹 기능은 오늘 부터 미국 동부 (버지니아 북부), 미국 서부 (캘리포니아 북부), 미국 동부 (오하이오), 미국 서부 (오레곤), 캐나다 (중부), 남미 (상파울루), 아시아 태평양 ), 아시아 태평양 지역 (서울) 에서 사용할 수 있습니다. 이번 달 말까지 나머지 지역에서도 사용할 수있을 것으로 기대합니다.

AWS Direct Connect에 대한 더 자세한 사항은 아래를 참고하시기 바랍니다.

아울러 작년 re:Invent에서 Direct Connect Bundles 를 공개했습니다. 이 프로그램을 통해 고급 하이브리드 참조 아키텍처를 보실 수 있습니다.  더 자세한 것은 아래 영문 발표를 참고하시기 바랍니다.

Jeff;

이 글은 AWS Direct Connect Update – Link Aggregation Groups, Bundles, and re:Invent Recap의 한국어 편집본입니다.

AWS IPv6 업데이트 – 서울 리전 포함 글로벌 및 지원 서비스 확대

AWS는 이미 Elastic Load Balancing, AWS IoT, AWS Direct Connect, Amazon Route 53, Amazon CloudFront, AWS WAF, S3 Transfer Acceleration 기능을 시작으로 지난 몇 년 동안 여러 가지 AWS 여러 부분에 IPv6 지원을 추가하기 위해 노력해 왔습니다. 지난 달 (오하이오 리전을 시작으로) VPC 기반 EC2 인스턴스의 IPv6 지원을 시작하였습니다.

오늘 부터 VPC에서 EC2 인스턴스에 대한 IPv6 지원은 총 15 개 리전에서 사용 가능하며, 9 개 리전에서 IPv6에 대한 Application Load Balancer 지원이 제공됩니다.

이제 IPv6 주소를 사용하여 서버, 개체 저장소, 부하 분산 및 콘텐츠 배포 서비스와 통신 할 수 있는 응용 프로그램을 손쉽게 구축하고 배포 할 수 있습니다. Apple 및 다른 모바일 기기 공급 업체의 IPv6 지원에 대한 최신 지침에 따라 모바일 응용 프로그램은 AWS와 통신 할 때 IPv6 주소를 사용할 수 있습니다.

총 15개 리전에서 IPv6 지원 시작
기존 및 신규 VPC에서 EC2 인스턴스에 대한 IPv6 지원은 현재 미국 동부 (버지니아 북부), 미국 동부 (오하이오), 미국 서부 (캘리포니아 북부), 미국 서부 (오레곤), 남아메리카 (상파울루), 캐나다 아시아 태평양 (서울), 아시아 태평양 (시드니), 아시아 태평양 (뭄바이), AWS (아시아 태평양 지역), 아시아 태평양 지역 GovCloud (미국) 리전에서 사용 가능합니다.

새 VPC를 만들 때 AWS 관리 콘솔에서 IPv6을 활성화 할 수 있습니다.

Application Load Balancer 지원
미국 북동부 (버지니아 북부), 미국 서부 (캘리포니아 북부), 미국 서부 (오레곤), 남아메리카 (상파울루), EU (아일랜드), 아시아 태평양 (도쿄), 아시아 태평양 (싱가포르), 아시아 태평양 (Sydney) 및 AWS GovCloud (US) 리전은 IPv6를 듀얼 스택 모드로 지원하므로 IPv4 또는 IPv6을 통해 접근 할 수 있습니다 (몇 주 이내에 나머지 리전에 대한 지원이 추가 될 예정입니다).

ALB를 구성 할 때 dualstack 옵션을 활성화 한 다음 보안 그룹이 요구 사항에 따라 IPv6 트래픽을 허용하거나 거부하는지 확인하십시오. 듀얼 스택 옵션을 선택하는 방법은 다음과 같습니다.

set-ip-address-type 명령을 실행하거나 SetIpAddressType 함수를 호출하여 옵션을 활성화 할 수도 있습니다. 이 새로운 기능에 대한 자세한 내용은 Load Balancer Address Type 설명서를 참조하십시오.

AWS IPv6 지원 현황 요약
VPC에서 EC2 인스턴스에 대한 IPv6 지원 시작에 앞서 이미 다양한 IPv6 지원을 제공하고 있으며, 상세 내용은 다음과 같습니다.

  • Amazon CloudFront, WAF 및 S3 Transfer Acceleration -개별 CloudFront 배포 지점에 IPv6 지원을 사용할 수 있습니다. 새로 생성 된 배포 지점은 기본적으로 IPv6을 지원하며, 기존 배포판은 업그레이드 할 수 있습니다 (Route 53 별칭 레코드를 사용하는 경우 도메인에 AAAA 레코드도 추가해야 합니다). IPv6 지원을 사용하면 새 주소가 CloudFront Access Logs에 표시됩니다.  AWS WAF를 사용하여 IPv4 또는 IPv6 주소를 통해 오는 요청을 검사하고, S3 Transfer Acceleration을 위한 새로운 이중 스택 엔드 포인트를 사용할 수도 있습니다.
  • Amazon Route 53 -IPv6을 통한 DNS 쿼리에 대한 지원을 추가했습니다. (필수 AAAA 레코드에 대한 지원이 이미 마련 있습니다). IPv6 엔드 포인트 상태 검사를 지원하므로 엔드 포인트의 상태를 모니터링하고 DNS 장애 조치를 조정할 수 있습니다.
  • AWS IoT -인터넷 연결 장치와 AWS IoT 간의 메시지 교환을 위한 IPv6 지원을 제공합니다.
  • Amazon S3 –  듀얼 스택 엔드 포인트를 통한 S3 버킷 접근 지원이 가능합니다.
  • Elastic Load Balancing – Elastic Load Balancer를 위해 공개라우팅 가능한 IPv6 주소를 지원합니다.
  • AWS Direct Connect – 공개 및 비공개 VIF (가상 인터페이스)에서 단일 및 이중 스택 구성을 지원합니다.

Jeff;

이 글은 AWS IPv6 Update – Global Support Spanning 15 Regions & Multiple AWS Services의 한국어 번역입니다.

Amazon EC2 인스턴스 및 VPC IPv6 지원 시작

모바일 앱, 커넥티드 디바이스 및 IoT 분야에서 인터넷의 지속적인 성장으로 업계 전반에 IPv6 전환이 촉발되었습니다. 2010 년에서 부터 미국 정부 기관은 공개 서버 및 서비스를 가능한 빨리 IPv6로 옮기고 있습니다. 128 비트의 주소 공간을 갖춘 IPv6는 성장 여지가 충분하며 새로운 애플리케이션 및 연결 확장성에 큰 도움이 됩니다.

Amazon EC2 및 VPC IPv6 지원
올해 초 Amazon S3, IPv6 주소 지원 시작을 시작으로 Amazon CloudFront, Route53, WAF 및 S3 Transfer Acceleration의 IPv6 지원을 진행하였습니다. 오늘 그 다음 단계로 Virtual Private Cloud (VPC)와 VPC내 EC2 인스턴스에 대한 IPv6 지원을 시자하며, 우선 US East (Ohio) 리전부터 시작합니다.

IPv6 지원은 신규 혹은 기존 VPC에서도 가능하며 VPC-VPC간에도 콘솔 (혹은 API 및 CLI)를 통해 선택할 수 있습니다.

각 VPC은 개별적 /56 주소 영역을 Amazon GUA (Global Unicast Address)에서 얻으며, 각 VPC내 서브넷에는 /64를 할당할 수 있습니다.

Amazon S3에서 처럼 각 인스턴스에 해당 DNS 항목과 함께 IPv4 주소와 IPv6 주소를 할당하는 이중 스택 모델을 사용합니다. 두 버전의 프로토콜을 모두 지원하므로 리소스 및 응용 프로그램에 접근에 대한 호환성과 유연성이 보장됩니다.

VPC 내의 보안 그룹, 라우팅 테이블, 네트워크 ACL, VPC 피어링, 인터넷 게이트웨이, Direct Connect, VPC 흐름 로그(Flow Logs) 및 DNS 질의 등은 모두 현재와 같은 방식으로 작동합니다. 애플리케이션 로드밸런서(ALB)의 이중 스택 모델에 은 예정되어 있으며, 장기적인 로드맵을 가능한 한 빨리 알려 드리겠습니다.

AWS Direct Connect IPv6 지원
AWS Direct Connect Console내 가상 인터페이스(VIFs)에서 IPv4 및 IPv6 주소를 선택할 수 있습니다.

각 VIF는 BGP 피어링 세션을 각각 IPv4와 IPv6을 지원 합니다.

신규 Egress-Only 인터넷 게이트웨이 IPv6 지원

IPv6에 주요 특징 중 하나는 모든 주소가 인터넷 라우팅이 가능하여, 인터넷에 연결할 수 있다는 것입니다. IPv4 전용 VPC에서 공용 IP 주소를 EC2 인스턴스에 할당하면 1:1 NAT(Network Address Translation)가 인스턴스와 사설 주소로 설정됩니다. IPv6을 사용하는 VPC에서 각 인스턴스의 주소는 공개되어 있습니다. 직접 연결을 통해 많은 네트워킹 문제를 해결하지만, 사설 서브넷을 만드는 또 다른 메커니즘이 필요합니다.

오늘 IPv6 지원을 통해 VPC용 비공개 서브넷을 구현하는 데 사용할 수 있는 새로운 Egress-Only Internet Gateway (EGW)를 소개합니다. EGW는 NAT 인스턴스의 집합보다 설치 및 사용하기가 쉽고 무료로 사용할 수 있습니다. 수신 트래픽을 차단하면서 아웃 바운드 트래픽을 허용 할 수 있습니다 (인터넷 게이트웨이가 보안 그룹과 연결). 일반적인 방식으로 EGW를 생성하고, 이를 사용하여 인바운드 IPv6 트래픽을 제한할 수 있습니다. IPv4 트래픽에 NAT 인스턴스 또는 NAT 게이트웨이를 계속 사용할 수 있습니다.

정식 출시
EC2 IPv6 지원은 US East (Ohio) 리전에서 오늘 부터 추가 비용 없이 사용 가능합니다. M3, G2를 제외한 모든 현 세대 EC2 인스턴스 타입에서 사용 가능합니다.

다른 리전의 IPv6 지원 확대는 계획 중에 있으며, 준비되는 대로 계속 알려드리겠습니다.

Jeff;

이 글은 AWS re:Invent 2016 신규 출시 소식으로 New – IPv6 Support for EC2 Instances in Virtual Private Clouds의 한국어 번역입니다. re:Invent 출시 소식에 대한 자세한 정보는 12월 온라인 세미나를 참고하시기 바랍니다.

Transit VPC를 통한 Cloud HUB 디자인하기 – AWS 서드 파티 도구 기반

Amazon Virtual Private Cloud(VPC)는 AWS 클라우드의 가상네트워크 환경을 구성하는 기본 서비스로서, 필요에 따라 원하는 수 만큼의(기본: 리전당 5개) 가상 네트워크 환경을 생성하실 수 있습니다. 그러나, 기존 데이터 센터나 사무실의 온-프레미스 네트워크 혹은 복수의 VPC를 서로 연동해야하는 경우가 있습니다. 이때, VPC간 연결 혹은 VPC와 온 프레미스(데이터 센터)를 어떻게 연동할지, 그리고 더 나아가 구성된 네트워크 환경에서 운용될 어플리케이션 서비스의 트래픽 흐름은 어떻게 될지 등을 면밀히 검토해 보아야 합니다.

온 프레미스(데이터 센터)와  연결 구성시 추천하는 첫번째 방법은 AWS Direct Connect를 활용하여, 모든 VPC에 가상 회선(Virtual Circuit) 을 할당하여 상호간 라우팅이 가능하도록 구성하는 것입니다. 그런데, 단일 리전 연동이 아닌 복수개의 리전에 걸쳐 AWS클라우드 가상 네트워크 인프라를 구성해야 하는 요건이 있을 경우에는 모든 VPC에 Direct Connect의 가상 회선을 연결하는 것은 사실상 불가능에 가깝습니다.

이러한 상황에서 고려해 볼 수 있는 아키텍쳐 디자인이 바로, 두번째로 Transit VPC를 통한 Cloud HUB 디자인 입니다. Cloud HUB는 말그대로 하나의 VPC가 모든 연결을 맺는 HUB VPC가 되고, 온 프레미스(데이터센터) 및 다른 VPC들은 Spoke VPC 가 되게 한후, 모든 통신은 HUB VPC를 경유하게 하는 구성입니다.

CSR100V를 통한 Cloud HUB 디자인
이러한 구성을 위한 필수 요건으로 Transitive Routing(전달받은 라우팅 경로를 3자에게 전달 방식)이라고 하는 기능이 필요하며, AWS Marketplace의 Cisco 소프트웨어 라우터인 CSR1000V와 같은 서드 파티 제품을 사용하여 아래와 같이 구성할 수 있습니다.

image001[그림1. Cisco CSR1000V를 이용한 Transitive Routing 구성 방식]

Cisco CSR1000V는 Cisco의 하드웨어 라우터 제품 중 ASR(Aggregation Services Router) 이라고 하는 엔터프라이즈 엣지(Edge)용 라우터를 가상 머신(VM)의 형태로 출시한 소프트웨어 라우터입니다. OSPF, EIGRP, BGP 등의 다양한 라우팅 프로토콜 및 IPSEC VPN ,방화벽 등의 보안기능들을 지원합니다. 또한, CSR 이 가지고있는 IOS-XE라는 운영체제(OS)는 하드웨어 제품과 동일한 CLI 및 인터페이스를 제공하여 많은  네트워크 엔지니어 들에게 친숙한 구성 환경을 제공한다는 장점을 가지고 있습니다.

상기 디자인과 같이 CSR1000V를 HUB VPC의 라우터로 구성하면 Spoke VPC가 생성된 AWS리전에 상관없이 스포크 일대일(Spoke-to-Spoke)통신 또는 스포크와 허브간(Spoke-to-Hub) 통신이 IPSEC 터널을 통해 쉽게 이루어지 됩니다. 특히, Cisco 라우터 설정에 익숙하지 않은 사용자라고 할지라도 Transit Network VPC (Cisco CSR 1000V 기반 아키텍쳐) 백서에 포함된 CloudFormation 템플릿을 사용하면,  손쉽게 위와 같은 Cloud HUB구성을 하실 수 있습니다. 또한, 새로운 VPC 추가 시에도 간단히 VGW에 특정 태그(Tagging)만 추가하면 자동으로 Cloud HUB환경에 Spoke VPC로 등록 되는 환경이 만들어 집니다.

다만, 아직 서울리전에는 Cisco CSR 1000V제품이 출시되어 있지않아 서울 리전을 HUB로 지정할 수는 없습니다. Cisco CSR1000V를 사용하기 어려울 시에는 AWS Marketplace에 등록되어 있는 Vyatta 또는 Fork버전인 VyOS 를 사용하여 유사한 구성을 하실 수 있습니다. Vyatta는 리눅스 기반으로 Qugga등의 오픈소스 라우팅 소프트웨어들이 패키지의 형태로 구성된 제품으로서, 현재 저렴한 커뮤니티 버전이 제공되며, AWS Marketplace를 통해 서울리전에서도 사용하실 수 있습니다. 이에 따라, 해당 제품을 기반으로 서울 리전을 HUB 로 구성가능한 Cloud HUB디자인을 살펴보도록 하겠습니다.

Vyatta 및 VyOS를 통한 Cloud HUB 디자인

image003[그림2. Vyatta 혹은 VyOS를 이용한 Transitive Routing 구성 방식]

상기 디자인은 앞에 사용된 Cisco CSR1000V 이 있던 자리를 Vyatta 혹은 VyOS라우터로 변경한 디자인 입니다. Vyatta 라우터도 CSR1000V과 같이 BGP를 포함한 다양한 라우팅 프로토콜을 지원하여, 기능적으로 손쉽게 CSR1000V과 같은 역할을 수행할 수 있습니다. 그런데, 실제 IPSEC 터널 구성을 해보면 아래와 같이, IP SEC 터널은 정상적으로 맺어져 UP 상태가 되더라도, BGP Neighbor로부터 아무 경로도 업데이트 받지 못하는 모습을 보시게 됩니다.

image005[그림 3. Transit VPC에서 확인하는 BGP 라우팅 테이블]

image007[그림 4. Spoke VPC의 IPSEC 터널 정보 : Tunnel UP상태지만 라우팅 정보는 수신 안됨]

위와 같은 증상은 타 리전간의 구성(AS Number가 다를 경우)에서는 나타나지 않고, 같은 리전 내의 VPC간 구성에서 나타납니다. 그 원인은 BGP 라우팅 프로토콜이 가진 기본적인 루프 방지 기능(Loop prevention)때문에, 동일 AS Number를 가진 BGP Neighbor로부터 들어오는 라우팅 업데이트는 차단을 하도록 되어 있는 라우팅 규칙 때문입니다.

Cisco CSR1000V 제품으로 구성된 이전 디자인에서는 정상적으로 라우팅 테이블이 업데이트 되는 모습을 보실수 있는데 , 이는 Cisco CSR1000V 의 경우 ‘as-override’ 라는 AS Number 정보를 무시하는(Override) 기능을 가지고 있기 때문인데, Vyatta 라우터의 경우는 아직 해당 기능을  제공하지 않습니다. 따라서, Vyatta라우터를 사용한 위와 같은 VPC 구성 시에는 Spoke VPC들이 서로 다른 리전(서로 다른 AS Number사용시)에 있을 때만 구성하실 수 있다는 제약이 있습니다.

단일 VPC(VGW)를 통한 Cloud HUB 디자인 아키텍처
이러한 Vyatta 라우터가 가진 제약을 극복할 수 있는 방안으로 고려해 보실 수 있는 새로운 VPC 디자인은 아래와 같이 하나의 VPC(VGW)를 HUB로 지정하고, 각각의 Spoke VPC에 Vyatta 라우터를 구성한 후 HUB VPC에 연결하는 방법입니다. 이때 각각의 Spoke VPC는 IPSEC 터널 구성시 원하는 숫자(지원 AS Number 대역 : 64512 ~ 65535)를 AS Number로 지정할 수 있으므로 이전 디자인상의 제약 사항 이었던 AS Number의 중복으로 인한 문제는 사라지게 됩니다.

image009Amazon VPC에서 IP SEC VPN을 구성하는 절차는 이 글의 주제에 포함되지 않으므로 자세히 말씀 드리진 않겠지만, 간략히 다음과 같은 단계에 의해 구성됩니다. (더 자세한 사항은 기술 문서를 참고하시기 바랍니다.)

  1. CGW생성 : 생성시 온 프레미스 VPN장비의 Public IP 주소 설정 (또는 EC2 EIP)
  2. VGW생성 후 구성을 원하는 Spoke VPC에 부착 (Attach)
  3. 생성한 CGW와 VGW를 연결하여 VPN 연결 설정 후, 라우터 설정 파일을 다운로드 받아 VPN장비(하드웨어 또는 EC2 인스턴스)에 설정

 Amazon VPC는 사용자들이 보다 쉽고 빠르게 다양한 제품들과의 IPSEC 터널 구성을 지원하고 있는데, 아래 화면과 같이 다양한 장비에 대한 설정파일을 제공하고 있어서, 사용자는 손 쉽게 원하는 장비에 대한 설정파일을 받아 설정을 완료할 수 있습니다.

image011

Cloud HUB 구성 시작하기
본격적으로 Vyatta에 대한 설정파일을 다운로드 받아, 해당 내용을 그대로 Vyatta 라우터에 적용하여 구성해보겠습니다. 이때 주의할 사항으로 Vyatta인스턴스에 해당 설정을 적용할 때에는, 기본적으로 Public IP(EIP) 정보가 설정되어 있는 로컬 어드레스(Local-address) 부분에 현재 Vyatta 라우터 인스턴스의 eth0인터페이스에 할당되어 있는 Private IP정보로 변경해 주시면 됩니다.

set vpn ipsec ike-group AWS lifetime '28800'
set vpn ipsec ike-group AWS proposal 1 dh-group '2'
set vpn ipsec ike-group AWS proposal 1 encryption 'aes128'
set vpn ipsec ike-group AWS proposal 1 hash 'sha1'
set vpn ipsec site-to-site peer 52.193.81.195 authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer 52.193.81.195 authentication pre-shared-secret '@#$@#$'
set vpn ipsec site-to-site peer 52.193.81.195 description 'VPC tunnel 1'
set vpn ipsec site-to-site peer 52.193.81.195 ike-group 'AWS'                                    
set vpn ipsec site-to-site peer 52.193.81.195 local-address '52.197.159.126' -> Private IP변경
set vpn ipsec site-to-site peer 52.193.81.195 vti bind 'vti0'
set vpn ipsec site-to-site peer 52.193.81.195 vti esp-group 'AWS'

또한, BPG 라우팅 설정 부분에서도 아래와 같이 Spoke VPN의 Subnet중 원하는 대역 혹은 VPC의 모든 CIDR대역을 HUB로 광고(Advertise)하는 설정을 추가해야 합니다.

이때 만약 Vyatta인스턴스가 속한 Subnet이 아닌 VPC 전체에 대한 CIDR범위를 BGP 설정에 추가하면, 정상적으로 HUB VPC에 라우팅이 광고 되지 않으며, 반대로 Vyatta 인스턴스가 속한 Subnet 범위에 맞는 CIDR 범위만 을 BGP설정에 추가하면, 정상적으로 라우팅이 HUB VPC(VGW)로 광고 되는 모습을 볼 수 있지만, 해당 VPC가 가지는 다른 Subnet 영역에 대한 경로들은 추가되지 않아 궁극적으로 우리가 원하는 Spoke VPC의 Private Subnet 간 통신을 위한 라우팅 구성이 불가하게 됩니다.

위의 문제를 해결하기 위해서는, 각 Spoke VPC의 Vyatta 라우터 설정에서, 통신을 위해 라우팅 설정이 필요한 VPC CIDR 범위를 Static 라우팅을 통해 먼저 설정한 후, BGP설정에도 해당 대역을 추가해 주어야 합니다.

이 작업까지 완료하면, Vyatta 라우터가 위치한 Subnet 뿐만 아니라, 전체 VPC의 CIDR을 HUB VPC의 VGW로 광고하게 되며, 모든 경로(Route)들은 HUB VPC에 연결된 Spoke VPC로 전파되어 Any to Any 의 라우팅 경로가 구성됩니다. 아래는 Spoke VPC A – CIDR : 10.0.0.0/16 설정 예시입니다.

set protocols bgp 65002 network 0.0.0.0/0
set protocols static 10.0.0.0/16 next-hop 10.0.0.1 distance 10
#(10.0.0.0/16은 VPC 전체의 CIDR이며, 10.0.0.1은 해당 VPC에서 사용하는 Default G/W로써, 여러분이 사용하시는 VPC CIDR의 .1 주소는 기본적으로 Default G/W로 설정되어 있습니다.)
set protocols bgp 65002 network 10.0.0.0/16 
# BGP에 해당 CIDR (10.0.0.0/16)을 추가

모든 설정을 마치면, 아래와 같이 HUB VPC의 VPN 터널의 상태가 UP으로 변경됩니다.

image013

라우팅 경로가 모든 VPC에 제대로 업데이트 되었는지 여부는 다음과 같이 확인해 볼 수 있습니다.

  1. HUB VPC : VGW로부터 연결된 Spoke VPC 들의 경로가 자동으로 업데이트 되는지 확인 image015
  2. Spoke VPC A : HUB VPC – 100.64.127.224/27 , Spoke VPC B – 20.0.0.0/16 경로 확인
    image017
  3. Spoke VPC A 의 Route 테이블 확인
    image019
  4. Spoke VPC B : HUB VPC – 100.64.127.224/27 , Spoke VPC A – 10.0.0.0/16 경로 확인
    image021
  5. Spoke VPC B 의 Route 테이블 확인
    image023

Cloud HUB 구성 테스트 하기

위와 같이 라우팅 정보가 정상적으로 확인되면 모든 설정이 끝난 것입니다. 마지막으로 Spoke to Spoke VPC 의 통신이 제대로 이루어 지는지 Ping테스트를 통해 확인해 보도록 하겠습니다.

image025

  • Spoke VPC A 의 Private Subnet 에 있는 EC2 인스턴스(0.1.40) 에서 Spoke VPC B의 Private Subnet 에 있는 EC2인스턴스(20.0.1.138)로 Ping 테스트
    image027
  • Spoke VPC A 의 Private Subnet 에 있는EC2인스턴스(0.1.40) 에서 HUB VPC의 Private Subnet에 있는 EC2인스턴스(100.64.127.231)로 Ping 테스트
    image029

이 글에서 우리는 Cloud HUB VPC 구성을 위한 몇 가지 옵션들과 주의점들을 살펴 보았습니다. 만약 여러분이 글로벌 어플리케이션 서비스 혹은 공유 서비스 기반의 멀티 테넌트 어플리케이션 서비스를 구축 하시고자 한다면, 이 글에 설명된 것처럼Cloud HUB VPC 디자인을 통해 IP SEC 터널 기반의 멀티 VPC연동을 통한 확장성 있는 네트워크 인프라를 구성하실 수 있습니다.

자세한 것은 차근 차근 순서대로 설정 방법을 담은 가이드 문서를 참고하시기 바랍니다.

더 자세히 알아보기

  1. Transit Network VPC (Cisco CSR 1000V 기반 아키텍쳐)
  2. Multiple VPC VPN Connection Sharing
  3. Single Data Center HA Network Connectivity
  4. Multiple Data Center HA Network Connectivity

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

AWS 솔루션 – Transit VPC 사용 방법 소개

AWS에서는 AWS Quick StartsAWS Solution이라는 가이드를 제공하고 있습니다. AWS를 이용하여 아키텍츠 설계자가 보안 및 가용성 등의 모범 사례를 활용할 수 있도록 구축한 해법 및 가이드를 제공하고 있습니다.

이 중 오늘은 Transit VPC Solution이라는 편리한 글로벌 네트워크 구축을 구현하는 방법을 소개해 드리겠습니다. 이 기능을 사용하면, 지리적으로 분산되어 있거나 별도의 AWS 계정에서 실행되는 가상 사설 클라우드 (VPC)를 글로벌 네트워크 전송 센터로서 동작하면서 일반적인 VPC와 연결할 수 있습니다. 본 네트워크 토폴로지는 네트워크 관리를 단순화하고 네트워크 설정 및 관리를 필요로하는 연결 숫자를 감소 할 수 있습니다. 또한, 구현 자체는 가상 네트워크로 만드는 것이기 때문에 실제 네트워크 장비는 불필요합니다.

실제 네트워크 디자인은 바로 아래와 같습니다.

이 그림에서는 transit VPC가 중앙에 있고 그 주위에 ‘스포크'(Spoke) VPC와 기업 데이터 센터 및 기타 네트워크가 배치되어 있습니다.

  • 사설망 – 2 개 이상의 AWS 지역에 걸친 개인 네트워크를 구축 할 수 있습니다.
  • 공유 연결 – 여러 VPC는 데이터 센터, 파트너 네트워크 및 기타 클라우드와 연결을 공유 할 수 있습니다.
  • 크로스 계정 AWS 사용량 – VPC와 AWS 리소스를 여러 AWS 계정에 저장할 수 있습니다.

본 솔루션은 AWS CloudFormation 스택을 사용하여, 모든 AWS 리소스를 시작하고 구성합니다. 500 Mbps에서 2 Gbps의 처리량 옵션 3 개를 제공하며, 고 가용성 연결 쌍으로 구현됩니다. AWS Marketplace에서 본 스택을 사용하는 Cisco Cloud Services Router (CSR)를  사용할 수 있습니다. 기존 CSR 라이센스 (BYOL 모델)을 사용하거나 CSR의 사용량을 시간 단위로 지불 할 수 있습니다. transit VPC의 실행에 드는 비용은 고객이 선택하신 처리량 옵션 및 라이센스 모델에 따라 다릅니다. 요금은 시간당 0.21 USD에서 8.40 USD에 각 스포크(Spoke) VPC 시간당 0.10 USD의 추가 요금 (AWS 리소스 용)이 적용됩니다. 고객 전용 AWS Key Management Service (KMS) 마스터 키에 매월 1 USD의 추가 요금이 적용됩니다.이 요금은 모든 네트워크 전송 요금에 포함되지 않습니다.

템플릿에는 AWS Lambda를 설치하거나 사용합니다.

VGW Poller 함수는 분당 실행됩니다. 계정에서 모든 AWS 지역을 검색하여 VPN 연결이 없는 스포크 VPC에서 가상 개인 게이트웨이를 찾습니다. 이것이 발견되면 (필요한 경우) 해당 고객 게이트웨이와 CSR에 대한 VPN 연결을 만들고 S3 버킷에 정보를 저장합니다.

버킷 Put 이벤트가 Cisco Configurator 기능을 실행합니다. VPN 연결 정보를 분석하여 필요한 설정 파일을 생성 한 후 SSH를 사용하여 CSR을 제공합니다. 이는 VPN 터널이 나타나 (BGP의 작용을 포함), 스포크 VPC에서 인근 관계를 설정합니다. 이 방법으로 Lambda를 사용하면 활용되지 않은 EC2 인스턴스를 실행할 필요 없이 새로운 스포크 VPC를 빠르게 활성화시킬 수 있습니다. 더 자세한 것은 솔루션 구현 가이드 문서를 참고하시기 바랍니다.

(역자 주: Transit VPC 방식을 서드 파티 솔루션을 활용하여 서울리전에서 설정하는 방법은 Transit VPC를 통한 Cloud HUB 디자인하기 – AWS 서드 파티 도구 기반를 참고하시기 바랍니다.)

Jeff;

이 글은 AWS Solution – Transit VPC의 한국어 번역입니다.

AWS Lambda기반 VPC 지원 활용하기

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

먼저 AWS Lambda 함수 설정시, 아래 그림과 같이 VPC 사용 여부를 정할 수 있습니다.

VPC 지원을 선택하면, VPC내 서브넷(Subnet)에 생성한 서비스, 예를 들어 RDS, Elasticache에 대해 접근이 가능하게 해주는 기능입니다. VPC 지원을 선택하면, 어떤 VPC를 선택할지 그 내부에 어떤 서브넷을 지원할 지를 선택할 수 있도록 해줄 수 있습니다. 이렇게 되면 선택된 서브넷에서는 람다를 위한 ENI가 생성되고 이를 통해 람다는 각 서브넷과 통신을 하게 됩니다.

본 기능이 만들어진 배경은 프라이빗 서브넷 안에 존재하는 리소스에 접근하기 위함입니다. 예를 들어, RDS나 Redshift 같은 서비스를 프라이빗 서브넷 안에 만들고 특정 작업을 하기 위해 람다를 이용해서 접근을 해야 한다고 생각해봅시다. 과거에는 불가능했기 때문에 RDS나 Redshift를 퍼블릭 서브넷에 두어야 했다. 이 경우 보안상의 문제로 인해서 문제가 될 수 있습니다.

그런데, 이렇게 VPC 를 지원하게 되면 람다는 VPC의 선택된 서브넷만 접근을 할 수 있게 됩니다. 사용자 입장에서는 하나의 람다 함수 안에서 RDS 나 Elasticache의 정보를 조회한 이후에 SNS에 메시지를 보낸다던가 S3에 특정 작업을 하고 싶을 수 있습니다. 이런 경우 프라이빗 서브넷에서 퍼블릭 망으로 접근 할 수 있는 기능이 존재해야 한합니다. 이를 위해 프라이빗 서브넷 안에 NAT 역할을 하는 인스턴스 혹은 NAT Gateway가 설정되어 있어야 합니다.

이번 글에서는 VPC 지원 활성과 퍼블릭 네트워크로 접근을 하는 기능 구현에 대해 알아보고자 아래 샘플 코드를 참고하겠습니다.

const AWS = require('aws-sdk');

exports.handler = (event, context, callback) => {
 console.log("\n\nLoading handler\n\n");
    var sns = new AWS.SNS();
    
    // req1();

    sns.publish({
        Message: 'Test publish to SNS from Lambda',
        TopicArn: 'arn:aws:sns:us-east-1:550622896891:crr-virginia-topic'
    }, function(err, data) {
        if (err) {
            console.log(err.stack);
            return;
        }
        console.log('push sent');
        console.log(data);
        context.done(null, 'Function Finished!');  
    });
};

var http = require('http');

function req1()
{
    var options = {
      host: 'amazon.com',
      path: '/',
      port: '80',
      //This is the only line that is neindew. `headers` is an object with the headers to request
      headers: {'custom': 'Custom Header Demo works'}
    };
    
    var req = http.request(options, function(response) {
      var str = ''
      response.on('data', function (chunk) {
        str += chunk;
      });
    
      response.on('end', function () {
        console.log(str);
      });
    });
    req.end();
};

우선 VPC 설정을 합니다. 아래 그림은 VPC와 서브넷의 설정 화면이다. 여러분이 원하는 대상을 지정하면 됩니다.

이제 다음으로 중요한 것은 프라이빗 서브넷에 NAT를 설정하는 것입니다. 손쉽게 설정하는 방법은 AWS의 NAT Gateway를 이용합니다. NAT Gateway는 VPC 메뉴 중에 존재하며, 아래 그림은 새롭게 NAT Gateway를 생성하는 화면입니다. 여기서 원하는 프라이빗 서브넷을 선택해서 생성합니다.

생성한 NAT Gateway를 활용하기 위해서 Route Tables에서 라우팅 정보를 추가하면 모든 설정은 끝납니다. 아래 그림은 라우팅 정보를 세팅한 모습입니다.

이제 테스트를 진행할 차례입니다. 람다 함수에도 테스트 기능이 존재하며, Req1() 함수만을 활성화 한 후에 테스트를 해봅시다. 람다 함수의 테스트 버튼을 눌러 하단의 Log output 화면에서 아래와 같은 결과가 나오면 성공한 것이다.

AWS Lambda의 VPC 지원 기능은 사용자에게 보안과 유연성이라는 두 장점을 같이 제공합니다. 더 자세한 사항은 Configuring a Lambda Function to Access Resources in an Amazon VPCVPC NAT Gateway 설명서를 참고하세요.

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

Amazon VPC Flow Logs 서울 리전 출시

네트워크 모니터링에서 로그 수집 기능을 향상을 위한 Amazon VPC Flow Logs를 오늘 부터 서울 리전에서 사용 가능합니다. 특정 VPC에서 Flow Logs를 사용하여 VPC 서브넷과 엘라스틱 네트워크 인터페이스(ENI)의 네트워크 트래픽이 CloudWatch Logs를 통해 저장된 후, 자신의 응용 프로그램이나 타사 프로그램에서 분석 할 수 있습니다.

특정 유형의 트래픽을 감지하여 알람을 만들거나 트래픽의 변화와 패턴을 파악하기위한 통계를 만들 수도 있습니다. 사용 방법은 VPC Flow Logs – 네트워크 트래픽 수집 및 활용 기능를 참고하시고, 기술 문서를 참고하시기 바랍니다.

– AWS 코리아 마케팅팀

Amazon VPC NAT 게이트웨이 서울 리전 출시

지난해 12월 처음 출시된 Network Address Translation (NAT) Gateway 서비스가 오늘 부터 서울 리전에서 사용 가능합니다.

AWS내 사설 네트워크(VPC)로 구성된 서비스와 외부를 연결하는 주소 변환(NAT)를 제공하기 위해 별도 EC2 인스턴스 설정, 모니터링 및 확장(고 가용성을 위해 적어도 2대는 있어야 함)을 고려하고 운영 하는 대신, 몇 번의 클릭 만으로 NAT 게이트웨이를 설정하고 AWS에 운영을 맡길 수 있는 완전 관리형 서비스입니다.

간단한 사용 방법은 AWS 신규 NAT 게이트웨이 서비스 출시! 블로그 글을 참고하시고, 더 자세한 사용법은 VPC NAT Gateway 한국어 도움말을 살펴 보시기 바랍니다.

서비스 요금은 NAT 게이트웨이 사용 시간 당 $0.059(서울 리전 기준)이며, 데이터 처리 및 전송 비용은 별도입니다. 데이터 처리 비용은 NAT 게이트웨이를 통과하는 양에 따라 달라지며, 데이터 전송 비용은 EC2 인스턴스와 인터넷 망 사이의 요금입니다. 더 자세한 것은 VPC 요금표를 참고하시기 바랍니다.

– AWS코리아 마케팅팀

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)를 편집하였습니다.