Today Key :  AWS, VPC, Cloud, Network, Peering, region, 접속, 피어링


 이번 포스팅은 VPC 간의 연동을 해주는 VPC Peering에 대한 정리입니다.

 실제 VPC Peering을 연동하는 예제는 포스팅용으로 이미지를 정리해야해서.. 다음 포스팅에서 다뤄집니다. ^^

 혹시 수정이 필요한 내용이나, 보완해야 될 내용이 있으면 덧글로 남겨주세요! 



VPC Peering 

 · VPC 간의 인터넷을 통하지 않고 직접 통신 할 수 있도록 연결하는 기술

 · AWS 내에서 정의하는 정의하는 가상의 네트워크인 VPC는 논리적으로 독립적인 네트워크 망을 선언한 것이기 때문에

   기본적으로 VPC 간에는 서로 통신이 불가하여 VPC 간에 서로 영향을 미치지 않음.

 · VPC 간에 서로 통신을 하기 위해서는 VPC 내에서 인터넷을 통해서 다른 VPC로의 통신을 하는 구조였음.

 · 2014년에 VPC Peering 이라는 기술을 통해서 같은 리전 간의 VPC 네트워크를 서로 연결 할 수 있게 됨.

 · 2017년에 멀리 Region 간의 VPC Peering을 지원하도록 함.

 · 서울 Region에서의 VPC Peering은 2018년 중반부터 지원

 

 

VPC Peering 구성

 · 동일 Region 간의 Peering 예

 

 

  · 멀리 Region 간의 Peering 예

 

 

   · 공유 서비스를 이용하는 VPC Peering 예

 

 

VPC Peering 구성 관련

 · VPC Peering으로 연결 시에 VPC 간의 네트워크 대역이 겹치지 않도록 설계해야 함.

  · VPC Peering을 이용하면 Peering 된 VPC 네트워크은 AWS 백본을 통해서 통신하여 Pulbic 인터넷 망을 통과하지

   않기 때문에   보안적으로 보다 우수함.

   또한 내부 백본 네트워크를 통하기 때문에 이중화나 네트워크 병목에 대한 이슈도 없음.

 · VPC Peering은 단일 계정으로도 가능하며, 서로 다른 계정 간의 VPC Peering 구성도 가능

 

 VPC Peering 제한

· 멀티 Region 간의 VPC Peering 시에는 security group 참조 지원 안 함.

· 멀티 Region 간의 VPC Peering 시에는 DNS resolution 지원 안 함.

· IPv6와 Jumbo 프레임 지원 안 함.

·  VPC Peering을 통해서 외부 혹은 다른 VPC에서 VPC를 통해서 또 다른 VPC로 접근하는 Transit 기능은 지원하지 않음.

 

 

 

 

Posted by 네떡지기

Today Keys : AWS, outposts, on-premise, hybrid, 하이브리드, 클라우드, 온프레미스, azure, stack, re.Invent

 


이번 주에 진행 중인, AWS re.Invent 2018에서

On-premise에서 사용 가능한 AWS 버전인 AWS Outposts에 대한 내용이 발표되었다고 합니다. (실제 출시는 내년 하반기 이후?)

개인적으로 기존의 Azure의 강점 중의 하나가 On-Premise에서 사용 가능한 Azure Stack을 통해서

사용자에게 Public 과 동일한 Cloud 환경을 제공하는 것이라고 생각했는 데,

AWS에서도 Outposts를 통해서 진행하게 되는 것 같습니다.

이번 포스팅에서는 AWS의 Outposts에 대해서 아주 간략히(?) 정리해 봅니다.


 

AWS Outposts

AWS를 Public Cloud로써의 환경이 아닌 on-premise로 제공하기 위한 서비스

▪ AWS 디지안한 하드웨어로 구축된 컴퓨팅/스토리지랙을 사용하여 On-premise에서 구축

▪ AWS 클라우드에서 사용되는 동일한 native AWS API를 사용 가능

▪ 기존 AWS의 환경을 그대로 사용 할 수 있는 AWS native variant와 AWS에서 제공되던 VMware variant 환경을 제공

▪ AWS Outposts에 대해서도 AWS에서 관리 및 지원을 하며, public AWS region와 마찬가지로 자동으로 관리하고 업데이트

    - 인프라에 대한 업데이트나 패치에 대한 부분 지원

 

AWS Outposts에서 사용 가능한 옵션

▪ AWS native variant

  - AWS native variant 를 사용하는 경우에는 AWS에서 사용하는 것과 동일한 API 및 Control Plane을 사용

  - 초기에는 EC2, EBS에 대해서 지원하며, 향후 RDS, ECS, EKS, SageMaker, EMR 서비스 등을 추가 예정

VMware variant

   - 기존의  AWS에서 제공하던 'VMware Cloud on AWS'를 On-Premise에서 구축. 서비스 제공. AWS

   - VMware 의 API 및 Control Plane 사용 가능.

 

AWS Outposts에서 제공되는 Type 및 사이즈와 서비스

▪ 현재 EC2와 스토리지에 대해서 선택 가능한 옵션

   - EC2 : C5, M5, R5

   - 스토리지 : EBS, Local instance storage Local disk

▪ 단일 Outposts 서버로 시작해서, quarter, half, full Outposts 랙으로 증설 가능.

▪ 다양한 컴퓨팅, 메모리, 스토리지 옵션을 선택할 수 있음은 물론이고 최신의 하드웨어로 손쉽게 업그레이드 할 수 있음.

 

 

정리하고.

 이번 주에 발표된 내용이기도 하고, 아직 많은 내용의 자료도 공개된 게 없어서 큰 내용은 없습니다.

 기존의 Micro Azure Stack에 이어서 AWS Outposts까지... 좀 더 안정적인 Hybrid Cloud를 위한 Public과 동일한 환경의

 On-premise Cloud 솔루션들이 시장을 얼마나 차지할런지는 모르겠습니다.

 다만, 이러한 솔루션과 방향성이 결국 운영 입장에서는 On-premise와 Public 환경에서의

 Cloud 선택지에서 중요 선별 포인트가 되지 않을까 싶습니다.

 

 

 

 

Posted by 네떡지기
Today Keys : Hybrid, Direct, Connect, Direct Connect, 전용회선, AWS, VPC, VPN, VGW, BGP, DX, 클라우드, Cloud, 하이브리드



이번 포스팅은 AWS와 On-premise와 연결하는 Direct Connect에 대한 첫 번째 포스팅입니다.

기존에 포스팅 중이던 VPC와 함께 포스팅 될 예정입니다. 

최초에 작성하고 내용을 일부 수정하느라 크리스마스 이브 밤에 정식 포스팅을 시작합니다. 

아마도 기본 내용의 포스팅이라서 추가적으로 나중에 업데이트 되지 않을까 싶습니다. 



AWS와 On-Premise의 연결

 ▪ AWS와 On-Premise 와의 연결을 위한 방법으로는 다음의 3가지 방법으로 나눌 수 있음

    1. 일반 인터넷망

    2. VPN

          - Software VPN으로 구성 혹은 전용 하드웨어 VPN으로 구성

    3. Direct Connect




Direct Connect

 ▪ AWS와 On-Premise 데이터센터 간의 전용회선을 통해서 연결하는 구성

 ▪ 일반 인터넷망이나 VPN망에 비해서 망 대비 안정적인 성능을 제공할 수 있으며, 보안적으로도 우수

 ▪ 1G/10G 혹은 LAG를 통한 최대 40G 구성도 가능. 1G 이하의 속도도 제공하지만, 구성 방식이 다름

      - 아래의 'Direct Connect 구분' 참조

  VPN의 경우 연동 시에 Static Routing과 Dynamic Routing으로 BGP를 함께 지원하지만,  Direct Connect는 BGP만 지원

      - 단, Sub 1G를 사용하는 Hosted Direct Connect는 APN Partner를 통해서 BGP 구성하고 사용자는 Static으로 구성 가능.

 ▪ MTU 1500 & 9001 지원

     * 2018년 10월 11일부터 점보프레임(MTU 9001) 지원

 ▪ 별도의 SLA(서비스 수준 계약)는 제공하지 않음


Direct Connect 연결 지점

 ▪ Direct Connect를 사용하기 위해서는 On-Premise와의 전용선을 연결하기 위한 DX Location이란 지점이 필요

 ▪ 전 세계 16개 리전 80여개의 접속 지점이 존재(2018년 기준 - AWS Summit 자료)

 ▪ On-Premise 데이터센터의 라우터에서 직접 DX Location 내에 있는 AWS Direct Connect 라우터에 연결 할 수도 있고,
    DX Location에 상면을 임대하여, 로컬 구간만 케이블을 구성할 수도 있음.

 ▪ 한국 리전에는 KINX(서울 가산), LG U+(경기 평촌)에 DX-Location이 존재



Direct Connect 구분

 ▪ Dedicated 방식

   - 사용자 단 장비와 직접 AWS Direct Router 장비가 연결

   - Direct Connect 연결을 위한 Virtual Interface를 사용자 측에서 직접 생성

   - AWS Direct Connect 연결을 위한 BGP 설정을 사용자 단 장비에 설정

   - 1G 혹은 10G 속도 지원

   - Connection을 생성하여 요청하면 실제 케이블이 연결된 정보를 승인받아서 할당받고, Cross Connection 연결을 요청



  Hosted 방식

   - 사용자 단 장비는 APN Partner 장비와 전용선을 연결

   - Direct Connect 연결을 위한 Virtual Interface은 APN Partner에게 요청한 후 할당 받음.

   - APN Partner는 APN Partner 계정에서 VIF를 만들어서 사용자 계정에 할당하고 사용자가 이를 수락하는 방식

   - AWS Direct Router와는 APN Partner 장비가 연결된 상태이기 때문에 별도의 Cross Connection 연결 과정이 없음. 

   - AWS Direct Connect 연결을 위한 BGP 설정을 사용자 단 장비에 설정을 하지만,
     APN Partner에 요청하여 BGP 연동은 APN Partner 장비에서 하고, 사용자와의 연결은 

   - 1G 이하의 속도 연결 필요 시에 사용


  

 

 

Direct Connect 연결을 위한 장비 요건

 ▪ Singlemode 광 연결

 ▪ 802.1Q 지원
     - VIF에서 VLAN ID를 사용하여 구분

 ▪ BGP 지원
     -
VPN을 통한 연결은 Static Route와 BGP를 모두 지원하지만, Direct Connect는 BGP만 지원

 ▪ RFC 3021(Using 31-Bit Prefixes on IPv4 Point-to-Point Links) 지원
     - Public VIF에서 AWS의 Public IP 주소를 이용할 때만 필요

  


Direct Connect 구성

 Direct Connect는 Virtual Interface(VIF)를 생성하여 VGW(VPC)와 연결(Private VIF)하거나, 해당 Region의 직접 연결(Public VIF)

 VIF가 연결되는 VGW는 Direct Connect를 갖고 있는 계정이 아닌 다른 계정에도 연결 가능

    - 즉, 계정을 분리하여 관리하더라도 하나의 Direct Connect 구성 가능.

    - 하나의 회사에서 공용의 전용선을 구성하고, 회사 내의 구분 단위 별(팀,그룹,본부 등)로 별도 계정으로 공용 전용선 사용 가능.



Private VIF & Public VIF

 ▪ Private VIF

   - Private VIF 생성 시에 해당 VIF를 연결 할 VGW(VPC)를 선택 

   - AWS 내의 생성한 VPC 내의 네트워크를 Direct Connect를 통해서 연결하는 경우에 사용



  

 ▪ Public VIF

    - AWS의 VPC 내에 존재하는 것이 아닌 S3, API Gateway와 같은 Public Service를 인터넷망이 아닌 Direct Connect 연결 시 사용

    - Public VIF를 연결하게 되면 해당 리전의 Public Service를 위한 공인 대역을 BGP를 통해서 On-Premise로 광고

    - On-Premise로 광고된 대역에 대해서는 Longest match Rule에 의해서 기존의 인터넷망이 아니 Direct Connect 경로로 통신

    - 만약 AWS 내의 전체 Public Service가 아니라 특정 서비스에 대해서만 Direct Connect로 통신하고자 할 때에는 

       특정 서비스에 대한 CIDR을 확인하여, 해당 대역을 제외하고는 Filtering을 통해서 라우팅 광고를 제한적으로 수신

         * 각 서비스별 CIDR은 AWS에서 확인 가능



Direct Connect 한도


Posted by 네떡지기

Today Keys : AWS, VPC, CIDR, 대역 추역, 네트워크, 디자인, 설계, 중복, 블록, block, ipv4


이번 포스팅은 VPC의 Primary / Secondary CIDR에 대해서 간단히 정리했습니다.





VPC의 CIDR

· VPC를 생성할 때에는 AWS 내에서 사용하게 될 가상 네트워크에 대한 대역(CIDR)을 선언


· Public / Private 서브넷 모두 VPC의 CIDR 네트워크를 기반으로 한 네트워크 대역을 사용

· VPC를 생성하는 시점에 설정한 네트워크 대역(CIDR)은 수정 할 수 없음.

     - 삭제도 불가능하며, VPC 자체를 삭제해야만 함.


 · VPC의 CIDR은 서브넷은 16bit ~ 28bit로 설정 가능 

 · VPC를 생성 할 때에는 전체적인 AWS 내에서의 전체적인 네트워크 구성과 On-Premise와의 연동을 어떻게 할 것인지에 

   대한 디자인을 하는 과정이 매우 중요.

 · VPC 생성 시점에 만든 CIDR의 경우 수정이나 삭제가 불가능하지만, VPC 생성 이후에 추가적인 CIDR을 생성할 수 있음.

 · VPC 생성 시에 만들어진 CIDR을 'Primary CIDR' 이라고 하고, 추가로 만든 CIDR을 'Secondary CIDR'이라고 함.

 · Secondary CIDR를 만들기 위해서는 VPC 메뉴에서 'CIDR 편집'을 선택


 · CIDR 편집 화면으로 가면 다음과 같이 해당 VPC에서 사용할 CIDR을 관리할 수 있도록 제공.

 · Secondary CIDR 생성 시에는 VPC 내에서 기존에 생성한 CIDR의 네트워크 대역과 중첩되면 안 됨. 

     - 중첩으로 생성 시에 다음과 같이 오류 메시지가 발생하며, 생성되지 않음.



 · Secondary CIDR의 경우에는 추가로 4개까지 생성이 가능

    - 5개 이후(Primary CIDR 포함)에 CIDR을 추가로 생성하려고 하면 다음과 같은 오류 발생.


 · Primary CIDR이 수정 및 삭제가 불가능한 반면에 Secondary CIDR의 경우 수정은 동일하게 불가능하지만, 삭제는 가능.

 · VPC Peering 시에 CIDR 추가는 추가로 몇가지 규칙이 적용 됨. 

     - 이 부분은 VPC Peering 에서 다루겠습니다.





 ·

Posted by 네떡지기

Today Keys : VPC, 마법사, 생성, subnet, 게이트웨이, IGW, 라우팅테이블, Route tables, EIP, Elastic, Create



기존 포스팅 : AWS - VPC : Part 1  , AWS - VPC : Part 2


Last Updated : 2018.11.30

이번 포스팅에서는 AWS VPC를 마법사를 통해서 생성하여 간단하게 VPC와 관련된 컴포넌트를 구성하고, 

통신 테스트를 진행합니다.


 

먼저 VPC 대시보드로 들어가면, VPC에서 사용하는 다양한 컴포넌트가 있습니다.

'상단에 VPC 만들기'라는 파란 버튼을 클릭하면,

 

 

다음과 같이 VPC를 손쉽게 구성할 수 있도록 마법사 형태로 제공합니다.

VPC 구성 형태에 따라서 4가지 방식을 제공하는 데,

1. 단일 퍼블릭 서브넷이 있는 VPC

2. 퍼블릭 및 프라이빗 서브넷이 있는 VPC

3. 퍼블릭 및 프라이빗 서브넷이 있고 하드웨어 VPN 액세스를 제공하는 VPC

4. 프라이빗 서브넷만 있꼬 하드웨어 VPN 액세스를 제공하는 VPC

 

이 포스팅에서는 AWS에서 일반 인터넷과의 통신만 하는 간단한 네트워크 구조를 만들기 떄문에 별도의 VPN 액세스 제공하는 3,4번 대신에 1,2번 중의 Private과 Public이 함께 있는 2번째 마법사를 선택해서 진행합니다.

 

우선 마법사를 본격적으로 진행하기 전에 탄력적 IP(Elastic IP:EIP)를 먼저 생성합니다.

마법사로 Private 서브넷을 생성하게 될 경우에 NAT 게이트웨이도 함께 생성하는 데, NAT 게이트웨이에 할당 할 EIP가 필요합니다.

 

 

새 주소 할당에서 바로 '할당'을 클릭하면

다음과 같이 새로운 Elastic IP 주소가 생성됩니다.

 

이제 VPC 마법사를 이용해서 VPC 생성에 필요한 값을 입력합니다.

VPC 내에서 사용할 CIDR 블록을 먼저 지정합니다.

VPC 의 CIDR은 생성 이후 변경이 불가하기 때문에 VPC를 얼마나 확장성 있게 설계할 것인지에 따라서 크기를 잡아야 합니다.

다음은 Public과 Private 서브넷에 대한 CIDR을 지정하는 데, 여기서 사용되는 CIDR은 VPC CIDR 블록 내에 속해야 합니다.

예제에서는 Public 은 10.0.0.0/24, Private는 10.0.4.0/24로 선언합니다.

서브넷 생성 시에는 어떤 가용영역(AZ)에 속할지도 함께 선택합니다.

마법사 이용 시에는 각각 1개의 서브넷을 생성하지만, VPC 생성이 완료된 이후에 추가로 생성이 가능합니다.

서브넷 다음에는 Private 서브넷이 외부와 통신하기 위한 NAT 게이트웨이의 Elastic IP를 선택하는 데, 앞에서 만든 EIP를 지정합니다.

필요한 정보를 입력한 이후에 생성 버튼을 누르면, 몇 분 이내에 생성이 완료됩니다.

 

VPC 생성이 끝나면 다음과 같이 정상적으로 생성되었다고 나옵니다.

 

마법사를 이용해서 VPC를 생성하고 나면, VPC의 다양한 컴포넌트들이 생긴 것을 알 수 있습니다.

왼쪽은 기본 VPC 상태였고, 오른쪽이 VPC 마법사를 이용해서 VPC를 만든 이후의 컴포넌트입니다.

'서브넷 2개(Public/Private), 라우팅 테이블 2개, 인터넷 게이트웨이 1개, NAT 게이트웨이 1개, 네트워크 ACL 1개, 보안그룹 1개 '

가 추가로 생성된 것을 확인할 수 있습니다.

 

이제 새롭게 만든 VPC와 서브넷을 이용해서 EC2를 만듭니다.

EC2 생성 시에 Default VPC 대신에 새롭게 만든 Public/Private 서브넷을 가진 EC2를 생성합니다.

Public 서브넷을 가진 EC2를 생성할 때 Public IP를 자동할당 받을 수 있도록 설정합니다.

 

Private 서브넷을 가진 EC2를 생성할 때는 Public IP를 받을 필요가 없으며, 실제 생성하더라도 해당 IP로 접속이 불가합니다.
(물론 설정을 변경하면 가능하나, 설정을 변경하는 경우에는 실제 Private 서브넷이 아니라 Public 서브넷으로 동작합니다.)

 

Public 서브넷을 가진 EC2가 자동으로 할당받은 IP는 13.124.63.40 입니다.

13.124.63.40으로 EC2에 접속해서 IP 주소를 확인해보면, 10.0.0.247인 것을 확인할 수 있습니다.

앞서 Public 서브넷을 10.0.0.0/24으로 선언하였고, 해당 네트워크 대역에 속하는 인스턴스입니다.

 

Private 서브넷에 속한 EC2의 경우에는 직접 접근이 불가능하지만, Public 서브넷을 통해서 접근이 가능합니다.

VPC의 CIDR에 속한 모든 인스턴스는 상호 간의 모두 별도의 설정없이 통신이 가능합니다.

(라우팅 테이블에서 VPC의 CIDR이 Local 영역으로 설정)

Private 서브넷의 EC2도 외부(8.8.8.8)와 통신이 가능합니다.

왜냐면 Private 서브넷이 외부와 통신할 수 있도록 NAT 게이트웨이가 있기 때문입니다.

실제 확인을 위해서 자신의 공인 IP 확인을 위해서 ifconfig.me를 통해서 Private 서브넷 EC2의 공인 IP를 확인합니다.

 

ifconfig.me를 통해 확인한 공인 IP가 실제로 NAT 게이트웨이에 할당된 Elastic IP 주소인 13.125.4.205인 것을 확인할 수 있습니다.

 

마지막으로 Public과 Private 서브넷에 지정된 2개의 라우팅 테이블을 확인합니다.

Private 서브넷이 포함된 라우팅 테이블은 VPC CIDR이 Local로 선언되어 있고, Default 라우팅은 NAT 게이트웨이를 향합니다.

 

 

Public 서브넷이 포함된 라우팅 테이블은 Private 서브넷이 포함된 라우팅 테이블과 마찬가지로 VPC CIDR이 Local로 선언되어 있지만,

디폴트라우팅은 인터넷 게이트웨이(IGW)인 것을 확인 할 수 있습니다.

이상으로 VPC 마법사를 이용한 기본 VPC 생성 및 VPC를 이용한 인스턴스를 만들어서 통신하는 과정을 보았습니다.

이후에는 마법사 대신에 개별 컴포넌트 별로 생성하면서 어떻게 연결이 되는지 알아보도록 하겠습니다.

 

다음은 본 예제에 대한 구성입니다.



Posted by 네떡지기

Today Keys : AWS, VPC, Route, Table, IGW, Internet, Gateway, EIP, Elastic, IP address, NAT, 네트워크, 아마존



AWS VPC 대시보드를 보면 다음과 같이 VPC에서 사용되는 다양한 컴포넌트가 있습니다.

이번 포스팅에서는 VPC의 다양한 컴포넌트 중에서 라우팅 테이블과 인터넷 게이트웨이, 탄력적 IP, NAT 게이트웨이에 대해서 알아보겠습니다.

Last Updated : 2018.11.30 



 

라우팅 테이블(Route Tables)

 · 특정 네트워크 대역에 대해서 어떤 경로를 통해서 갈지에 대한 테이블 

 · 목적지 네트워크 대역을  '도착(Destination)'으로 표기하고, 목적지로 가기 위한 Next Hop을  '대상(Target)'이라고 나타냄

 · 라우팅 테이블은 서브넷 별로 적용 되기 때문에, 하나의 서브넷은 하나의 라우팅 테이블에만 속함.

 · 서브넷은 하나의 라우팅 테이블에 속하지만, 하나의 라우팅 테이블에는 다수의 서브넷이 속할 수 있음.

 · 라우팅 선언 시에 하나의 목적지 네트워크(Destination)에 대한 라우팅은 1개만 선언 가능하기 때문에 라우팅 테이블 선언으로 백업 경로 지정 불가

 · VPC의 CIDR로 선언한 네트워크 대역은 'Local'로 인식

 

 ·

 

인터넷 게이트웨이(IGW : Internet Gateways)

 · VPC 내부에 존재하는 인스턴스가 외부로 나가기 위한 관문

 · 공인 서브넷이 되기 위해서는 라우팅 테이블에서 Next-hop(Target)이 인터넷 게이트웨이(IGW)인 경우 임.

 · 사설 서브넷 인스턴스의 경우에도 외부와 통신하기 위해서는 NAT 게이트웨이를 통한 이후에 다시 인터넷 게이트웨이를 경유하는 데, 
   NAT 게이트웨이 자체가 공인 서브넷에 존재하기 때문에 결국 공인 서브넷의 라우팅 테이블을 적용 받아서 IGW를 지나기 때문.

 ·

 

탄력적 IP(Elastic IPs)

 · AWS 내에서 할당되는 Static한 공인 IP

 · EIP 생성 시점에는 Public EIP만 할당이 되지만, 해당 EIP를 바인딩하게 되면, 사설 IP와 1:1로  매핑 됨.

 

 

NAT 게이트웨이(NAT Gateways)

 · 사설 IP를 가진 인스턴스가 별도의 공인 IP를 할당받지 않은 상태에서 외부와 통신하기 위해서 사용하는 NAT 컴포넌트

 · NAT 게이트웨이에는 NAT를 Public 서브넷과 실제 NAT되는 EIP를 할당.

 · 특정 서브넷에 대한 NAT 기능을 수행하도록 사설 서브넷과 공인 IP가 매핑된 형태의 컴포넌트로 볼 수 있음.

 · 라우팅 테이블의 Next Hop을 NAT 게이트웨이로 지정하게 되면, NAT 동작을 수행.

 · 최대 1G 대역폭 지원




Posted by 네떡지기

 

Today Key :  AWS, VPC, Cloud, Network, region, subnet, CIDR, AZ


 Last Updated : 18.11.28



AWS VPC

 · AWS 내에서 정의하는 가상의 네트워크 환경 (논리적인 네트워크 구성)

 · 사내망(On-Promise)과 VPN이나 Direct Connect와 같은 서비스를 이용하여 연결 가능

 · VPC 내에는 Public 서브넷과 Private 서브넷을 구성 할 수 있음.

 

 

VPC 특징

 · VPC는 하나의 region 속함.

 · Region 내의 AZ 간에는 VPC를 같이 사용 가능.

 · 네트워크 주소와 라우팅을 직접 설정

 · 복수의 region 사용 시에는 네트워크 주소 설계 고려

 · VPC 생성 시 VPC에 속하는 하나의 CIDR을 생성

       - 최대 네트워크 : 16bit /  최소 네트워크 : 28bit

 · VPC 내에서 사용 할 서브넷은 추가로 설정해야 하고

  서브넷은 VPCCIDR 내에 속해야 하기 때문에 서브넷 크기를 고려하여 CIDR 크기를 결정해야 함.

 · VPC 생성 시에 만든 CIDR 은 변경이 불가능하기 때문에 초기 생성 시에 향후 만들어질 설계 방안을 고려해서 CIDR을 디자인해야 함. 

 · VPCCIDR 생성 시에는 사설 IP 대역을 사용 할 것을 권장

       - 10.0.0.0/8 , 172.16.0.0/12, 192.168.0.0/16

 · VPCCIDR은 생성 이후 변경이 불가하기 때문에 Region, On-Premise과의 연동을 고려하여 IP 중복이 되지 않도록 설계 필요.

 · VPC의 CIDR에서의 IP 중복은 On-Premise 뿐 아니라, 나중에 다뤄질 VPC 간의 연결을 하는 VPC Peering도 고려하여 
   각 VPC 간의 네트워크 대역도 중복되지 않도록 설계해야 함.

 · VPC 생성 시 입력이 필요한 항목

       - Name tag

       - CIDR block  : VPC에서 사용 할 네트워크 대역 선언

       - Tenancy  : 전용 물리 하드웨어를 사용 할 것인지에 대한 옵션

 · VPC 네트워크는 기본 설정으로는 폐쇄망 구성이기 때문에 외부와 통신 불가

 · VPC가 외부 네트워크와 통신하기 위해서는 Internet-Gateways가 필요

 · 하나의 VPC 내에 속한 서브넷은 Local Router를 통해서 서로 통신이 가능.

 

 

서브넷 특징

 · 하나의 VPC 내의 하나의 AZ에 속함 (AZ 간에는 서브넷이 다름)

 · 서브넷 생성 시 입력이 필요한 항목

      - Name tag

      - VPC

      - Availability Zone

      - CIDR block

 · VPC에 속하는 네트워크(CIDR)로 설정해야 하며, 해당 네트워크를 벗어나면  오류 발생(생성 불가)

 · 서브넷 설 정 시에 1~3번은 다음과 같은 목적으로 사용되기 때문에 사용 불가(네트워크 주소 및 브로드캐스트 주소 제외)

      - 1 : VPC 라우터용

      - 2 : AWS에서 예약한 DNS 주소

      - 3 : AWS에서 예약(향후 사용)

 

 

 

 


Posted by 네떡지기

티스토리 툴바