Today Keys : VPC, AWS, 아마존, Cloud, 클라우드, 서브넷, Subnet, 라우팅, Routing, NAT, Gateway, IGW


이번 포스팅은 예전 포스팅에서 마법사를 통해서 만들었던 VPC를 마법사를 통하지 않고

각 개별 항목 별로 생성해보는 실습 예제입니다. 

마법사를 통한 구성은 편리하지만, 직접 개별 항목으로 생성해 보는 작업을 통하면 실제 VPC의 구성이 어떻게 이뤄지는지

이해하는 데 많은 도움이 되리라 생각됩니다. 

관련 포스팅 : AWS - VPC : Part 3 [VPC 생성 및 테스트:마법사]


이번 포스팅에서 만들게 될 VPC 구성은 다음과 같습니다. 

하나의 VPC 내에 공인 서브넷과 사설 서브넷을 각각 1개씩 구성합니다.

VPC가 외부와 통신하기 위해서 Internet Gateway와 사설 서브넷이 외부와 통신하기 위한 NAT Gateway를

각각 만들고, 라우팅 테이블을 조정 합니다.

 

 

먼저 VPC를 생성합니다

VPC 생성 시에는 VPC에서 사용한 네트워크를 선언하는 데, 초기에 설정한 네트워크(CIDR)은

삭제나 변경이 불가하며, 초기 설정한 대역을 기준으로 추가 CIDR 설정도 영향을 받기 때문에 잘 설계하여 결정해야 합니다.

 

 

 

  생성된 VPC의 정보는 다음과 같이 확인 할 수 있습니다. 

 

  VPC가 만들어졌으며, 이제 VPC 내에서 사용할 서브넷을 생성합니다.

여기에서는 공인 서브넷과 사설 서브넷을 각각 1개씩 생성합니다. 서브넷에서도 네트워크 대역을 정해야 하는 데,

VPC 내의 서브넷의 네트워크 대역은 VPC의 네트워크 내에 포함되어야 합니다.  

 

  본 예제에서는 AZ는 1개로만 구성하였습니다. 

 

  생성된 서브넷 정보는 다음과 같이 확인 할 수 있습니다. 

 

  이제 외부와 통신하기 위한 Internet Gateway를 생성합니다.

 Internet Gateway를 생성 할 때는 별다른 정보없이 Name만 지정합니다. 

 

  생성된 Internet Gateway는 아직 어느 VPC에서 사용될지 결정된 상태가 아니기 때문에 상태 값이 detached 입니다.  

 

  이제 처음에 만들었던 VPC에서 사용하기 위해서 방금 만든 Internet Gateway를 VPC에 연결합니다. 

 

   VPC를 선택해서 Internet Gateway를 연결하고나면,

 

  Internet Gateway의 상태가 attached로 되고, 연결된 VPC의 정보가 뜹니다.  

 

 다음은 라우팅 테이블입니다. VPC 생성 시에 만들어진 라우팅 테이블에는 VPC의 네트워크(CIDR)이 Local로 되어 있으며,

추가적인 라우팅이 없습니다. (Local이기 때문에 VPC 내에서 설정한 서브넷 간에는 통신이 가능합니다.)

 

 

 인터넷을 나가기 위해서 라우팅 테이블의 Default Route(0.0.0.0/0)의 Target(Next Hop)을 앞에서 만들었던

Internet Gateway로 지정합니다.

 

다음은 Elastic IP를 생성합니다.

 

Elastic IP는 바로 할당 버튼을 누르면 별다른 정보 입력없이 다음과 같이 바로 할당이 됩니다.

 

Elastic IP를 만든 것은 사설 서브넷이 인터넷과 통신하기 위한 NAT Gateway를 만들기 위한 것이었습니다.

사설 서브넷이 인터넷과 통신하기 위해서 만들지만, NAT Gateway를 생성할 때 설정하는 서브넷은

사설 서브넷이 아니라, 공인 서브넷으로 설정하고, 방금 전에 할당받은 Elastic IP를 연결합니다.

 

 

실제  서브넷 정보를 보면 공인 서브넷으로 생성한 '~cefe1' 로 끝나는 ID임을 확인할 수 있습니다.

 

이제 사설 서브넷을 위한 라우팅 테이블을 추가로 만듭니다.

서브넷 별로 라우팅 테이블을 적용 할 수 있습니다.

 

라우팅 테이블 생성하고  라우팅 정보를 수정합니다.

사설 서브넷을 위한 라우팅 테이블이기 때문에 Default Route에 대한 Target(Next hop)을 NAT Gateway로 합니다.

 

이제 초기에 만든 사설 서브넷의 기본 라우팅 테이블을을 확인해서

 

 방금 전에 만든 사설 서브넷용 라우팅 테이블로 변경합니다.

서브넷에 대한 라우팅 테이블을 변경하면 해당 라우팅 테이블의 정보를 볼 수 있습니다.

 여기까지하면, VPC 마법사를 통해서 만든 VPC 구성을 직접 만드는 작업이 끝나게 됩니다.

이제 실제 EC2를 생성해서 여기서 만든 공인 서브넷과 사설 서브넷으로 할당해서 각각 외부와 통신이 되는지

사설 서브넷의 EC2의 경우 공인 IP 주소가 NAT Gateway에 할당된 Elastic IP로 보이는지 확인하면 됩니다.

 

앞서 얘기 했듯이 AWS에서 제공되는 VPC를 생성하는 마법사를 이용하면 좀 더 쉽고 빠르게

VPC를 구성 할 수 있지만, 직접 만드는 작업을 통해서 실제 VPC 구성에 대한 이해를 도울 수 있을 것 입니다.

 

그리고 이렇게 만들어진 VPC는 최소한의 통신을 위한 기본 구성이기 때문에 VPC 설계를 위한 다른 컴포넌트들은

추가로 적절하게 생성하여 연결해야 합니다.

 

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 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 네떡지기

티스토리 툴바