Transit VPC Network 구성가이드 (Vyatta 기반 ) 2016. 8 Kevin Kim (kevkim@amazon.com) 페이지 1
본 Guide 에대하여 본구성가이드는 AWS클라우드에서 Transit(HUB) VPC를구성하는방법및고려사항들을다루고있습니다. Amazon VPC는 Peering 기능을통해동일리전내에서 VPC간손쉬운연동기능을제공하지만, VPC간직접연결및동일리전내의 VPC간연결만이지원됩니다. 이러한 VPC의제약을넘어 Cross 리전 VPC연결, Transitive 라우팅 ( 직접연결되지않은 VPC간통신 ) 구현을위해서는 AWS Marketplace의파트너솔루션을활용하는방법이있는데, 엔터프라이즈급솔루션인 Cisco CSR 1000V 와같은제품이대표적이며오픈소스기반의 Vyatta 제품으로도유사한구성을할수있습니다. 본가이드는 Vyatta를기반으로만들어진 Cloud Formation 템플릿을포함하고있으며, Transit VPC Networking 구성을위한데모, PoC (Proof of Concept) 및테스트환경을쉽고빠르게구성하실수있도록만들어졌습니다. 본구성가이드를수행하기위해서는 AWS Cloud 환경구성경험및 VPC에대한사전지식이필요하며, 기존에 Vyatta 설정에익숙하지않은사용자라도 Step-by-Step으로손쉽게따라구성하실수있도록준비되었습니다. Overview Amazon Virtual Private Cloud (Amazon VPC) 는고객들에게원하는만큼많은수의가상네트워크환경을만들수있도록해줄뿐만아니라 AWS가아닌다른환경도 AWS에연동할수있는다양한옵션을제공하고있습니다. 지리적으로분산된 VPC 및원격네트워크들을연결하기위한좋은방법중의하나는글로벌네트워크의경유지로동작하는 Transit VPC를구성하는것입니다. Transit VPC는네트워크관리를단순화시키고복수의 VPC및원격네트워크를연결하는데필요한연결수를최소화해줍니다. 이러한구성은가상환경으로구성되기때문에기존의전통적인물리적환경구성대비더욱쉽고빠르면서도저렴한비용으로구성할수있습니다. 본가이드는왼쪽그림과같이 Transit VPC구성을위한계획단계부터실제구성에필요한다양한부분을단계별로설명합니다. 이디자인에서, Spoke VPC들은 Transit VPC를경유하여서로자유롭게통신할수있으며, 이때연결되는 VPC는리전에상관없이연결구성이가능합니다. 본가이드에나와있는정보들은여러분이기본적인 HA의개념및원격네트워크연결, 페이지 2
IPSEC VPN, 네트워크주소 (IP Addressing), 서브넷팅그리고라우팅에대한지식을 가지고있다는것을기본전제로하고있습니다. 비용및라이선스 본가이드에설명된 Vyatta 제품을활용하여 Hub and Spoke VPC 구성을했을때소요되는대략적인비용을아래와같이산정해보았습니다. 현재 AWS Marketplace에등록된 Vyatta제품은 BYOL 버전은없고, 라이선스가포함된버전만등록되어있습니다. 비용상의특이점은현재해당제품이이용가능한모든리전에서동일한라이선스비용을부과하고있으며, 인스턴스사이즈에상관없이동일한사용비용이부과됩니다. VPN 인스턴스크기시간당 S/W 사용료년간 S/W 사용료 모든인스턴스 $0.03 $262.8 Transit VPC(Hub) 에는 VGW가사용되며, VGW에대한사용요금은시간당 $0.05 이부과됩니다. 또한, IPSEC VPN은인터넷기반의통신이므로 Data Transfer Out 비용이추가적으로발생합니다. 동일리전내 VPC통신과 Cross 리전 VPC통신의요금이상이하므로자세한비용정보는비용페이지에서확인하시기바랍니다. Architecture Overview 본가이드에제시된 Cloud Formation 템플릿을실행하면 Transit VPC (Hub) 가하나생성되고, 2개의 Spoke VPC 가동일리전내에생성됩니다. Transit VPC의역할은모든 Spoke VPC들의트래픽라우팅을위한경유지역할을하고, Spoke VPC는공용서비스 VPC 혹은개개의단독서비스들을호스팅하는 VPC로서, 추가적인 VPC 연결을원하실경우해당템플릿을수정하시거나, 기존구성을참고하여수동으로 VPC를네트워크에추가해주실수있습니다. VPC를추가할때는기존과구성과동일리전뿐만아니라타리전의 VPC를연동하실수도있습니다. 템플릿을통해구성되는 Transit VPC는 VGW로구성되는데, 이는기본적으로이중화를위한두개의터널엔드포인트가제공되며, 만약하나의엔드포인트에장애발생시자동으로다른터널로페일오버가되는고가용성디자인속성을지니고있어, 모든 Spoke VPC들의트래픽경유지로서높은안정성을제공합니다. Spoke VPC는여러분의원하시는가용성목표에따라구성을하실수있는데, 만약높은가용성을원하시면두개의 Vyatta 인스턴스를각각다른 AZ 에구성하고, 이상유무를확인해가며, 하나의인스턴스에장애발생시페일오버되도록설정페이지 3
하실수도있고, 하나의인스턴스만을구축하고 Cloud Watch를통해인스턴스장애발생시 EC2 Auto recovery기능을구동시켜자동으로인스턴스를복구시키는 FT (Fault Tolerant) 디자인을구성하실수도있으며, 두가지를다혼용하는구성도가능합니다. 본가이드에서제공하는템플릿은하나의 Vyatta 인스턴스를구성하고 Cloud Watch 모니터링을통한 ec2 recovery 기능연동의구성으로준비하였습니다. Spoke VPC는 Transit VPC와같은리전내에구성할수도있고, 타리전의 VPC도연동할수있지만, 리전간트래픽비용등의차이가있음은감안하시기바립니다. Spoke VPC에서사용되는 Vyatta 인스턴스는인터넷통신이필요하므로기본적으로 Public Subnet에설치되어야하는데서비스를위한 Public Subnet과의분리를위해 Public VPN Subnet이라는이름으로별도의서브넷을생성하여관리및운영상의편의를제공합니다. < Transit VPC Network 레퍼런스아키텍쳐 > 페이지 4
데모아키텍쳐 솔루션특징 제공되는 Cloud Formation 템플릿을실행하면위와같은아키텍쳐가기본구성되며, Vyatta 인스턴스에접속하여 IPSEC 설정을완료하면손쉽게 IPSEC 기반 Spoke to Spoke, Spoke to Hub 통신을테스트해보실수있습니다. AWS 네트워크연결 : 본솔루션을활용하면, AWS리전, 계정에구애받지않고어떠한 VPC이든서로연동하여구성할수있습니다. 원격네트워크연결 : 표준 IPSEC 프로토콜을사용하므로, AWS Cloud 환경뿐만아니라, 여러분의실제데이터센터및타 Cloud 환경과도손쉽게연동할수있습니다. 페이지 5
솔루션실행절차 Step 1. Accept the Vyatta Software Terms AWS Marketplace의 Vyatta (Community Edition) AMI를사용하기위해서는먼저해당 Software에대한사용에대한동의절차를수행하셔야합니다. AWS Marketplace에서 Vyatta를검색하거나아래의링크를클릭하여해당페이지로이동합니다. Vyatta (Community Edition)(HVM): https://aws.amazon.com/marketplace/pp/b00zc4mhcs 1. 먼저 Pricing Details에서본솔루션을구성할리전을선택하고, 비용에대한부분을확인한다음 Continue 버튼을누릅니다. 2. Manual Launch 를선택합니다. End User License Agreement (EULA) 와 AWS Customer Agreement를읽고동의하시면 Accept Software Terms 를누릅니다. 위의과정을마치면아래와같이 subscription 에대한안내메시지를확인하실수있으 며, 또한이메일을통해 Subscription 에대한안내를받게됩니다. AWS Marketplace 에서한눈에여러분이현재사용중인제품, 수량에대해아래와같이 확인할수있으며, 실제사용중 (Running) 인인스턴스에한해과금됩니다. 페이지 6
Step 2. Launch the Stack 제공되는 AWS CloudFormation 템플릿을실행하면트래픽 Hub 역할을하는 Transit VPC 하나와 2 개의 Spoke VPC 및 Subnet, 인스턴스구성, VGW 등과관은세부설정들이자동으로생성됩니다. 다만, 본템플릿을실행전에반드시 Step 1 을완료하셔야합니다. 1. AWS Management Console 에로그인후아래의버튼을클릭하거나, 링크에서템플릿을 다운로드받아직접 Cloud Formation 을실행합니다. (Template 은 Master 템플릿이외에 개별적으로 Hub 와 Spoke 템플릿이 Nested Stack 으로구성되어있습니다.) CloudFormation 템플릿실행 (Seoul) CloudFormation 템플릿실행 (Tokyo) 2. 템플릿이실행되는리전으로서울리전과도쿄리전을선택할수있도록구성하였고, 타 리전에서수행을원하실경우 AWS관리콘솔우측상단에서간단히설치를원하는리전으로 선택하시면됩니다. 3. Select Template 페이지에서, 올바른템플릿이선택되었는지를확인하고 Next를누릅니다. 4. Specify Details 페이지에서, 임의의 Stack Name 을입력합니다. 5. Parameters 항목에서구성을원하시는네트워크정보를입력합니다. ( 간단한테스트를원하실경우기본적으로채워져있는값을그대로사용하실수있는데, 기존에 구성된 VPC와 IP Address 에대한중복이없어야하며, EIP, VPC개수등의자원을추가로생성 가능한상태여야합니다.) 파라미터 기본값 설명 TransitVpcCIDR 200.200.0.0/16 Hub VPC의 CIDR로서, 기본값은잘사용되지 않는 200. 대역으로임의적용 : 원하시는 CIDR블록으로수정가능 TransitPrivateSubnet 200.200.0.0/24 Hub VPC의내부 Private Subnet CIDR : Spoke로가는라우팅경로가자동으로 Routing Table에채워짐 (VGW Route Propagation) Spoke1VPC 10.0.0.0/16 Spoke VPC 1번의 CIDR 블록 : 원하시는 CIDR블록으로수정가능 Spoke1VPCPrivateSubnet 10.0.1.0/24 Spoke VPC 1번의 Private Subnet CIDR 블록 : 원하시는 CIDR블록으로수정가능 페이지 7
Spoke1VPCPublicSubnet 10.0.0.0/24 Spoke VPC 1번의 Public Subnet CIDR 블록 : 원하시는 CIDR블록으로수정가능 Spoke2VPC 30.0.0.0/16 Spoke VPC 2번의 CIDR 블록 : 원하시는 CIDR블록으로수정가능 Spoke2VPCPrivateSubnet 30.0.1.0/24 Spoke VPC 2번의 Private Subnet CIDR 블록 : 원하시는 CIDR블록으로수정가능 Spoke2VPCPublicSubnet 30.0.0.0/24 Spoke VPC 2번의 Public Subnet CIDR 블록 : 원하시는 CIDR블록으로수정가능 VpnInstanceType t2.large Vyatta 인스턴스타입선정 : 기본으로 t2.large가선택되어있으나더높은대역의인스턴스필요시변경 (* 각리전별지원인스턴스타입이상이할수있음 ) VpnKeyPair 선택필요 Vyatta인스턴스가사용할 Keypair선택 : Keypairrk 없는리전사용시수동으로사전생성이필요함 6. 모든파라미터가원하는값으로채워졌으면 Next 를클릭합니다. 7. 옵션페이지에서해당스택에 Tag 추가를원할경우입력합니다. 8. 다음 Review 페이지에서, 파라미터세팅정보확인후화면하단의 IAM 자원이생성에따른동의체크박스체크후 Create 버튼을클릭하면설치가시작됩니다. 9. 스택구성진행상황은 CloudFormation 콘솔을통해확인할수있으며, Event 탭을통해상세진행상황및이슈발생시원인등을파악할수있습니다. 10. 스택이완료까지걸리는시간은 6 분정도이고, 완료되면 State 창에 Create Complete 이라는초록색메시지가뜨며, 만약실패시먼저생성된자원들이모두삭제되고 ROLLBACK_COMPLETE 라는메시지가표시됩니다. 제공되는 Template 은 Master 와두개의 Sub Stack 으로구성되어있으므로, 총 3 개의항목이표시되며 3 개모두 Create Complete 메시지가표시되어야설치가완료된것입니다. ( 스택이완료되어도실제인스턴스구성까지는시간이조금더걸릴수있습니다.) 페이지 8
11. 설치가완료되면아래화면과같이 Events 탭에각 Spoke VPC 의 Vyatta 인스턴스가 사용하는 EIP 가표시됩니다. 추후 IPSEC 설정을위해해당 IP 주소를메모해두시기 바랍니다. 12. 아래체크리스트를통해템플릿이생성해준자원을확인해보세요. 항목 설명 확인 Hub VPC Transit VPC Transit VPC가생성된것을확인 Private Subnet Private Subnet 생성확인 Route Propagation Private Subnet의라우트테이블에 Route Propagation 체크박스체크상태확인 Customer Gateway Spoke VPC라는이름의 2개의 CGW 생성확인 Virtual Private G/W Transit VPC에 Attach된하나의 VGW 생성확인 VPN Connections Spoke VPC라는이름의두개의 Connection 생성확인 Spoke VPC (VPC1, VPC2 동일 ) Spoke VPC Spoke VPC가생성된것을확인 Public Subnet Public Subnet 생성확인 Private Subnet Private Subnet 생성확인 Route Table (Private Subnet) Route table에서다른 Spoke VPC 의 Private Subnet으로가는경로확인 Vyatta Instance Vyatta 인스턴스정상구성확인 Cloudwatch Alarm Vyatta인스턴스에대하여 Cloudwatch를통한장애발생시알람구성상태확인 Elastic IP Address Vyatta인스턴스가사용하는 EIP할당상태확인 Source/dest check Vyatta인스턴스선택 ->Actions->Networking -> Src/dst check의상태가 disabled 임을확인 페이지 9
< IPSEC VPN 설정 > 13. AWS콘솔에서 VPC 메뉴내부의 VPN Connections 선택합니다. 14. Spoke VPC1 을선택하고, Download Configuration 선택한후 Vyatta 를선택하고설정파일을다운로드받습니다. 15. Vyatta 설정파일을열고필요한부분을수정합니다. 페이지 10
수정이필요한부분 :! #1: Internet Key Exchange (IKE) Configuration set vpn ipsec site-to-site peer 52.74.117.53 local-address '52.76.65.223' >10.0.0.201.. set protocols bgp 65000 network 0.0.0.0/0 BGP 설정부분에서 Spoke VPC 의 Private Subnet 으로라우팅이가능하도록아래와같이 구성 : 예시의 10.0.1.0/24 는해당 Spoke VPC 의 Private Subnet 주소이며, Next hop 으로 해당서브넷에 x.x.x.1 로변경 set protocols static route 10.0.1.0/24 next-hop 10.0.0.1 distance 10 set protocols bgp 65001 network 10.0.1.0/24 하나의설정파일에는터널 1 번, 터널 2 번의설정파일이있으며, 각각독립적입니다. 설정파일중상기구성부분의 local-address 를 Vyatta 인스턴스의 Private IP로대체합니다. Private IP로대체하는이유는 EC2 기반의 Vyatta에설치하기때문이며, 온프리미스기반어플라이언스상의 Vyatta설정시에는다운로드받은파일그대로설정하시면됩니다. 16. Spoke 1 VPN Vyatta 인스턴스에 ssh로접속합니다. (IP주소는 EC2콘솔또는 CloudFormation 실행후 Output에서확인가능합니다.) $ ssh i keypair.pem vyatta@vyatta_ip_address kevkim$ ssh -i firewizsingapore.pem vyatta@52.76.65.223 The authenticity of host '52.76.65.223 (52.76.65.223)' can't be established. RSA key fingerprint is SHA256:5Vbu4iBkUCrAZ4zwF5amuqJ+rVqEY2uoCiIpVNHfTH8. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '52.76.65.223' (RSA) to the list of known hosts. Welcome to Vyatta Linux vyatta-64bit 3.3.8-1-amd64-vyatta #1 SMP Mon Feb 17 14:46:16 PST 2014 x86_64 Welcome to Vyatta. This system is open-source software. The exact distribution terms for each module comprising the full system are described in the individual files in /usr/share/doc/*/copyright. Last login: Mon Feb 17 23:44:05 2014 vyatta@vyatta-64bit:~$ config [edit] vyatta@vyatta-64bit# 페이지 11
* Vyatta 인스턴스설정을위해서는기본적인콘솔의사용법을숙지하시는게좋습니다. Linux기반이긴하지만, Network Appliance 의콘솔을차용하고있으며, 이에따라전용명령어들을통해설정상황을확인해볼수있습니다. 또한, 각명령어의옵션을확인하시려면기본적인명령입력후 Tab 키를치시면가용한옵션들이나옵니다. 처음로그인하면운영모드 ($) 로들어가며, 다양한설정상황들을확인 (show) 하는명령어들을주로사용하실수있습니다. $show config : 현재설정된모든사항들을표시 $show interface : 인터페이스 (NIC 또는터널 ) 정보표시 $show interface tunnel : 터널정보확인 $show ip route : 라우팅테이블확인 ( 전체라우팅 ) $show ip bgp : BPG 라우팅테이블확인 $show vpn ike sa : IPSEC 터널구성정보확인 실제라우터구성을위해서는 $config 라는명령어를통해설정모드로들어가야합니다. 설정모드로들어가게되면 ($) 에서 (#) 으로변경되며다양한설정을수행할수있습니다. 다시운영모드로나가려면 exit를입력하면됩니다. #set interface : set으로시작하는명령은설정을의미하며, 인터페이스설정 #set route bgp : bgp라우팅설정명령 16. 설정모드에서 IPSEC 성정을 Copy/Paste하여적용후, 마지막엔 #commit 명령으로실제입력된명령문실행 ( 중략 ).. vyatta@vyatta-64bit# set protocols bgp 65000 neighbor 169.254.29.109 timers keepalive '30' [edit] vyatta@vyatta-64bit# set protocols bgp 65000 network 0.0.0.0/0 [edit] vyatta@vyatta-64bit# delete protocols bgp 65000 network 0.0.0.0/0 [edit] vyatta@vyatta-64bit# set protocols static route 10.0.1.0/24 next-hop 10.0.0.1 distance 10 [edit] vyatta@vyatta-64bit# set protocols bgp 65000 network 10.0.1.0/24 [edit] vyatta@vyatta-64bit# [edit] vyatta@vyatta-64bit# commit # 실제명령적용을위해 Commit 수행 [edit] vyatta@vyatta-64bit# #commit 후이상없이적용되면아무런메시지가뜨지않음페이지 12
17. 설정완료후 IPSEC Tunnel 이제대로설정되었는지아래와같이확인해봅니다. (1) Spoke 1 Vyatta 인스턴스에서확인 vyatta@vyatta-64bit# show vpn ike sa # 설정모드에서 show 명령을쓰면에러발생 Configuration path: vpn [ike] is not valid Show failed [edit] vyatta@vyatta-64bit# run sh vpn ike sa # 설정모드에선앞에 run을붙이면 show 명령사용가능 Peer ID / IP Local ID / IP ------------ ------------- 52.74.117.53 10.0.0.201 Description: VPC tunnel 1 State Encrypt Hash D-H Grp NAT-T A-Time L-Time ----- ------- ---- ------- ----- ------ ------ up aes128 sha1 2 no 1007 28800 #Tunnel 의상태가 up 으로올라와있는것을확인 (2) Transit 에서 VPN Connection 의 Spoke 1 터널상태확인 18. 하나의 VPN Connection은두개의 Tunnel 엔드포인트를제공하는데, 현재하나의터널만연결이되었으며, Tunnel이중화를위해, 다운로드받은설정파일에서같은방식으로 Tunnel 2번도설정합니다. (Tunnel #2 설정시 Tunnel#1에서사용되는명령중중복된명령은생략가능합니다.) 페이지 13
(1) Spoke 1 Vyatta 인스턴스에서확인 vyatta@vyatta-64bit# run sh vpn ike sa # 두번째터널설정후확인 Peer ID / IP Local ID / IP ------------ ------------- 52.74.117.53 10.0.0.201 Description: VPC tunnel 1 State Encrypt Hash D-H Grp NAT-T A-Time L-Time ----- ------- ---- ------- ----- ------ ------ up aes128 sha1 2 no 2485 28800 Peer ID / IP Local ID / IP ------------ ------------- 52.77.169.62 10.0.0.201 Description: VPC tunnel 2 State Encrypt Hash D-H Grp NAT-T A-Time L-Time ----- ------- ---- ------- ----- ------ ------ up aes128 sha1 2 no 985 28800 (2) Transit 에서 VPN Connection 의 Spoke 1 터널 2 개 UP 상태확인 페이지 14
19. 모든 Spoke VPC 의 IPSEC 터널구성이끝나면, VPN Connections 의 Tunnel Details 에서모든터널의상태가 UP 이된것을확인하실수있습니다. 20. Transit VPC 가가진 Private Subnet 의라우팅테이블에서아래와같이각 Spoke VPC 의 Private Subnet 대역으로경로가설정되어있음을확인합니다. 200.x.x.x/16 -> Transit VPC 10.0.1.0/24 -> Spoke 1 VPC 의 Private Subnet 30.0.1.0/24 -> Spoke 2 VPC 의 Private Subnet 21. 각 Spoke VPC 의 Vyatta 인스턴스에서 BGP 라우팅테이블확인 Spoke 1 VPC 의 Vyatta 인스턴스 (10.0.0.0/16) vyatta@vyatta-64bit:~$ show ip bgp BGP table version is 0, local router ID is 10.0.0.201 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP,? - incomplete Network Next Hop Metric LocPrf Weight Path *> 10.0.1.0/24 10.0.0.1 0 32768 i *> 30.0.1.0/24 169.254.28.181 100 0 17493 65001 i * 169.254.29.109 200 0 17493 65001 i *> 200.200.0.0/16 169.254.28.181 100 0 17493 i * 169.254.29.109 200 0 17493 i Total number of prefixes 3 페이지 15
Spoke 2 VPC 의 Vyatta 인스턴스 (30.0.0.0/16) vyatta@vyatta-64bit:~$ sh ip bgp BGP table version is 0, local router ID is 30.0.0.248 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP,? - incomplete Network Next Hop Metric LocPrf Weight Path * 10.0.1.0/24 169.254.29.101 200 0 17493 65000 i *> 169.254.29.149 100 0 17493 65000 i *> 30.0.1.0/24 30.0.0.1 0 32768 i * 200.200.0.0/16 169.254.29.101 200 0 17493 i *> 169.254.29.149 100 0 17493 i Total number of prefixes 3 22. IPSEC 에대한설정이마무리되었으면, Vyatta 인스턴스에 Auto Recovery 를위한 Alarm 이제대로설정되어있는지확인합니다. 설정된알람의역할은 Vyatta 인스턴스에대한 Status Check 가 1 분간 15 번이상 Fail 하면 하드웨어장애로인지하고 EC2 Auto recovery 기능을통해해당인스턴스를복구합니다. 페이지 16
< Transit VPC Network 테스트 동일리전 VPC 간연동 > 1) Hub 및 Spoke VPC 의 Private Subnet 에테스트를위한 ec2 인스턴스를각각생성하고 Security Group 의 Inbound 룰에 ICMP 를 Allow 합니다. 2) Spoke A VPC 를통신테스트를위한 Source 로지정하고, Private Subnet 의대상서버에접속을위해 Public Subnet 에추가로 Bastion Host 용인스턴스를생성합니다. (1) Spoke VPC A 대상서버 -> Transit VPC 대상서버로 Ping 테스트 [ec2-user@ip-10-0-1-96 ~]$ ping 200.200.1.8 PING 200.200.1.8 (200.200.1.8) 56(84) bytes of data. 64 bytes from 200.200.1.8: icmp_seq=167 ttl=253 time=3.00 ms 64 bytes from 200.200.1.8: icmp_seq=168 ttl=253 time=3.07 ms 64 bytes from 200.200.1.8: icmp_seq=169 ttl=253 time=2.93 ms 64 bytes from 200.200.1.8: icmp_seq=170 ttl=253 time=3.10 ms 64 bytes from 200.200.1.8: icmp_seq=171 ttl=253 time=3.01 ms --- 200.200.1.8 ping statistics --- 176 packets transmitted, 10 received, 94% packet loss, time 176339ms rtt min/avg/max/mdev = 2.932/3.031/3.105/0.067 ms 페이지 17
(2) Spoke VPC A 대상서버 -> Spoke VPC B 대상서버로 Ping 테스트 [root@ip-10-0-1-218 ec2-user]# ping 30.0.1.51 PING 30.0.1.51 (30.0.1.51) 56(84) bytes of data. 64 bytes from 30.0.1.51: icmp_seq=153 ttl=253 time=3.57 ms 64 bytes from 30.0.1.51: icmp_seq=154 ttl=253 time=3.39 ms 64 bytes from 30.0.1.51: icmp_seq=155 ttl=253 time=3.44 ms 64 bytes from 30.0.1.51: icmp_seq=156 ttl=253 time=3.47 ms 64 bytes from 30.0.1.51: icmp_seq=157 ttl=253 time=3.33 ms 64 bytes from 30.0.1.51: icmp_seq=158 ttl=253 time=3.40 ms 64 bytes from 30.0.1.51: icmp_seq=159 ttl=253 time=3.56 ms ^C --- 30.0.1.51 ping statistics --- 159 packets transmitted, 7 received, 95% packet loss, time 159226ms rtt min/avg/max/mdev = 3.339/3.457/3.573/0.080 ms [root@ip-10-0-1-218 ec2-user]# ping 200.200.0.247 PING 200.200.0.247 (200.200.0.247) 56(84) bytes of data. ^C --- 200.200.0.247 ping statistics --- 136 packets transmitted, 0 received, 100% packet loss, time 136078ms [root@ip-10-0-1-218 ec2-user]# < Transit VPC Network 테스트 타 AWS 리전 VPC 연동 > 제공되는 CF 템플릿은동일 AWS 리전내의 VPC 간 Hub and Spoke Network 를구성해주지만, 이를참고하여타리전의 VPC 도수동설정으로추가연동하시면, Transit VPC 를통해타 VPC 들과손쉽게하나의네트워크로연결할수있습니다. Spoke VPC A 대상서버 -> Spoke VPC D 대상서버로 Ping 테스트 ec2-user@ip-10-0-1-96 ~]$ ping 20.0.1.135 PING 20.0.1.135 (20.0.1.135) 56(84) bytes of data. 64 bytes from 20.0.1.135: icmp_seq=1 ttl=253 time=74.1 ms 64 bytes from 20.0.1.135: icmp_seq=2 ttl=253 time=74.1 ms 페이지 18
64 bytes from 20.0.1.135: icmp_seq=3 ttl=253 time=73.9 ms 64 bytes from 20.0.1.135: icmp_seq=4 ttl=253 time=73.8 ms 64 bytes from 20.0.1.135: icmp_seq=5 ttl=253 time=74.1 ms --- 20.0.1.135 ping statistics --- 7 packets transmitted, 7 received, 0% packet loss, time 6008ms rtt min/avg/max/mdev = 73.893/74.075/74.163/0.093 ms * 크로스리전 Hub and Spoke 구성에서는물리적거리로인해 Network Latency 가증가하므로어플리케이션서비스구성시사전에충분한테스트가필요합니다. < Advanced Topic Transit 전용 VGW > 만약 Transit 역할을하는 VPC C 에서 VGW 를 Detach 하면어떻게될까요? < VPC 와분리된 VGW [ec2-user@ip-10-0-1-96 ~]$ ping 20.0.1.135 PING 20.0.1.135 (20.0.1.135) 56(84) bytes of data. 64 bytes from 20.0.1.135: icmp_seq=1 ttl=253 time=78.2 ms 64 bytes from 20.0.1.135: icmp_seq=2 ttl=253 time=78.4 ms 64 bytes from 20.0.1.135: icmp_seq=3 ttl=253 time=78.1 ms 64 bytes from 20.0.1.135: icmp_seq=4 ttl=253 time=78.5 ms --- 20.0.1.135 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 78.133/78.368/78.570/0.173 ms 위의테스트결과와같이필요에따라 VGW 를 VPC 와분리하여 Transit 전용라우터 (VGW) 만으로도 Hub and Spoke VPC 디자인을구성할수있습니다. 페이지 19