[AWS 클라우드 Discovery] 04. 독립적인 나만의 가상 네트워크 공간 만들기 (VPC,Public Subnet, Private Subnet, VPC Peering)

📡 Network

네트워크란 net이라는 단어 + work (일)이라는 합성어로 연결해서 서로가 가지고 있는 정보를 결합하여 생산적인 가치를 만드는 일을 말한다.
간략하게 말해서, 네트워킹을 한다라는 말은 서로 통신을 한다라는 말로 이해하면 될 것 같다.

서로 통신을 하기 위해서는 반드시 지켜야 하는 약속들이 있다.
예를 들면, 회사와 회사가 거래를 할 때에는 서로 간의 지켜야하는 조항 및 합의에 대한 내용을 담은 계약서를 작성하여 양쪽에서 교환하고 거래를 성립하는 것처럼 서로 간의 통신을 하기 위해 지켜야 하는 약속들을 준수하고, 교환함으로써 통신이 성립된다.

이렇게 통신을 위해 지켜야하는 약속들을 프로토콜(protocol)이라고 한다.

📡 VPN(Virtual Private Network)

VPN은 Virtual Private Network 의 약자로 큰 규모의 조직이 여러 곳에 분산되어 있는 컴퓨터들을 연결하는 보안성이 높은 사설 네트워크(private network)를 만들거나, 인터넷을 활용하여 원격지 간의 네트워크를 서로 연결하고, 암호화 기술을 적용하여 보다 안정적이며, 보안성 높은 통신 서비스를 제공하는 것을 일컫는다. (가상 사설 통신망, 가상 사설 네트워크)

참고로, 기존 IDC에서 서비스 하던 모든 시스템을 클라우드로 100% 이전하는 것은 어렵기 때문에, 통상적으로 대부분의 기업이 하이브리드 클라우드 환경을 운영하고 있다.

AWS에서 VPC와 VPC gateway를 통해, 온프레미스의 VPN 장비와 AWS의 VPN 장비를 연결하고, 이를 통해 보안성 높은 하이브리드 클라우드 환경을 구현하여, 원활한 클라우드 컴퓨팅 서비스를 지원할 수 있다.

📡 VPC

VPC는 뭘까?
Virtual Private Cloud의 약자로, 클라우드 환경에서의 VPN이라고 생각하면 쉽겠다.

AWS 클라우드에서 논리적으로 격리된 네트워크 공간을 할당하여 가상 네트워크에서 AWS 리소스를 이용할 수 있는 서비스를 제공한다.

Amazon VPC 자체 IP 주소 범위, 서브넷 생성, 라우팅 테이블 및 네트워크 게이트 웨이 구성 선택 등 가상 네트워킹 환경을 완벽하게 제어할 수 있으며, VPC에서 IPv4와 IPv6를 모두 사용하여 리소스와 앱에 안전하고 쉽게 액세스할 수 있다.

주요특징
AWS에서 사설 네트워크 구축
회사와 AWS 간 VPN을 연결하거나, 가상 네트워킹 구현
기존 데이터센터와의 연결을 통해 하이브리드 환경 구성
AWS를 회사 인프라의 일부처럼 사용할 수 있으며, 내부 시스템 소프트웨어의 연동이 매우 쉬운 편
(메일이나, 그룹웨어와 같은 업무 시스템, 파일 서버 등)
세심한 네트워크 설정 가능
모든 리전에서 사용 가능
프리티어 가능 (VPC 자체는 비용이 발생하지 않지만, VPN 연결 시에, 네트워크 송/수신에 따른 종량제 비용 청구 가능)

📡 VPC의 구성요소

Private IP & Public IP (사설 & 공공 IP 주소)

Private IP주소는 인터넷을 통해 연결할 수 없는, VPC 내부에서만 사용할 수 있는 IP 주소이다.
Private IP는 VPC에서 시작된 인스턴스 서브넷의 범위에서 자동으로 할당되며, 동일 네트워크에서 인스턴스 간 통신에 사용할 수 있다.

기본 Private IP 와 별도로 보조 Private IP라는 추가 Private IP도 할당할 수 있다.

Public IP 는, 인터넷을 통해 연결할 수 있는 IP 주소로, 인스턴스와 인터넷 간의 통신을 위해 사용할 수 있다. EC2 생성 시 옵션으로, Public IP 의 사용 여부를 선택할 수 있으며, 인스턴스에서 Public IP 를 수동으로 연결하거나 해제할 수 없다. 또한 인스턴스가 재부팅되면 새로운 Public IP 가 할당된다.

쉬운 이해를 위한 비유를 든 예시

ex. 우리 집 주소는 "서울시 강남구 테헤란로 130번지"(public ip)이다.
우리 가족 및 친적은 우리 집 주소를 "서울시 강남구 테헤란로 130번지" 라고 부르지 않고,
"역삼동 레니네 집(private ip)"이라고 한다.
하지만, 다른 사람들에게 "역삼동 레니네 집(private ip)"라고 말하면, 어디인지 위치를 정확하게 알지 못한다.

즉, 내부에서만 네트워킹을 하기 위해 고안된 주소를 private ip, 그리고 외부와 연결(인터넷)을 하여 네트워킹하기 위해 고안된 주소를 public ip라고 한다.

Elastic IP (탄성 IP 주소)

Elastic IP는 동적 컴퓨팅을 위해 고안된 고정 public IP 이다. (인터넷 통신을 위한 공공 IP)

VPC의 모든 인스턴스와 네트워크 인터페이스에 대해서 Elastic IP를 할당할 수 있으며,
다른 인스턴스에 주소를 신속하게 다시 매칭하여, 인스턴스 장애조치를 수행할 수도 있다.

Elastic IP의 효율적인 활용을 위해,
Elastic IP가 실행 중인 인스턴스와 연결되어 있지 않거나, 중지된 인스턴스 또는 분리된 네트워크 인터페이스와 연결되어 잇는 경우, 시간 당 요금이 부과된다.

사용 가능한 Elastic IP 주소는 5개로 제한이 되며, 이를 절약하기 위해 NAT Device를 사용할 수 도 있다.

VPC & Subnet

VPC는 사용자의 AWS 계정을 위한 "전용의 가상 네트워크" 를 말한다.
이러한 VPC는 AWS 클라우드에서 다른 가상 네트워크와 논리적으로 분리되어 있으며, Amazon EC2 인스턴스와 같은 AWS 리소스를 VPC에서 실행할 수 있다.

VPC 내부의 네트워크에서도 서비스 목적에 따라 IP Block으로 나눠서, 구분할 수도 있다.
우리는 이렇게 분리된 IP Block 의 모음을 서브넷이라고 한다.

한마디로 , IP주소를 나눈 것을 서브넷이라고 하고, IP주소를 나누는 작업을 서브넷팅(subnetting)이라고 한다.

VPC는 리전(region)의 모든 가용영역(AZ,Availability Zone)에서 적용되며, 각 가용영역에 하나 이상의 서브넷을 추가할 수 있다. 하지만 서브넷은 singe AZ에서만 생성할 수 있으며, 여러개의 AZ 으로 확장할 수 없다.

VPC(Virtual Private Cloud)와 Subnet 사이즈

VPC를 생성할 때, VPC에서 사용하게 될 IP주소의 범위를 지정하게 되는데, 범위를 CIDR 블록 형태로 지정해야 한다. 이때 사용하게 될 CIDR 표기법에 대해 처음 접하는 경우, 어려울 수도 있지만, 한번 이해하면 쉽다!

VPC를 생성하는 경우, 10.0.0.0/24로 VPC를 생성하게 되면, 256개의 IP주소를 지원하게 되고, CIDR 블록을 각각 128개의 IP 주소를 지원하는 2개의 서브넷으로 나눌 수 있다.

한 서브넷은 10.0.0~/25 CIDR(10.0.0.0~10.0.0.127)과,
다른 서브넷은 10.0.0.128/25 CIDR 블록(10.0.0.0~128~10.0.0.255)을 사용하도록 구성할 수 있다.

사이더 주소(CIDR) ?

Routing Table

각 서브넷은 서브넷 외부로 나가는 아웃바운드(outbound 트래픽에 대해 허용된 경로를 지정하는 라우팅 테이블(routing table)이 연결되어 있어야 한다.
생성된 서브넷은 자동으로 vpc의 기본 라우팅 테이블과 연결되며, 테이블의 내용을 변경할 수 있다.

이러한 라우팅 테이블은 VPC의 서브넷 내에서 생성된 네트워크 패킷이 목적지 주소로 이동하기 위해 어떤 경로로 이동되어야 하는지 알려주는 나침반과 같은 역할을 한다고 이해하면 쉽다.

그래서 서브넷 간의 통신이나 vpc간의 원활한 통신을 위해 라우팅테이블을 이용한다.

즉, 길안내 지도(guide map) 같은 것이다.

📡 VPC의 주요 서비스

보안 그룹(security group)과 네트워크 액세스 제어(Network Access Control List, Network ACL)목록

VPC의 보안 그룹과 ACL를 통해서, AWS 상에서는 방화벽과 동일한 기능을 사용할 수 있다.
아래 표(테이블)을 통해 보안그룹과 네트워크 ACL을 비교해보았다.

VPC Peering 연결

피어링 연결은 비공개적으로 두 VPC 간에 트래픽을 라우팅할 수 있게 하기 위해 서로 다른 VPC간의 네트워크 연결을 제공한다. VPC Peering 을 통해서, 동일한 네트워크에 속한 것과 같이 서로 다른 VPC의 인스턴스 간에 통신이 가능하다.

일반적으로 엔터프라이즈 규모의 글로벌 기업에서 전세계 임직원을 대상으로 이메일 서비스를 제공하는 경우, 보다 빠른 메일 서비스를 제공하기 위해 거점별로 메일 서버를 별도로 구축하고, 안전한 메일 송수신을 위해 고가의 글로벌 전용회선 서비스를 이용한다.

AWS는 2017년 11우러 다른 리전 간의 VPC Peering 지원을 발표했으며, 2018년 7월부터는 글로벌 백본망을 활용하여 빠르고 보안성 높은 데이터 통신을 지원하게 되었다. 이를 통해 엔터프라이즈 기업의 글로벌 시스템을 구축하는 경우에도 저렴한 비용으로 안전성과 보안성 높은 네트워크 인프라를 활용할 수 있다.

NAT(Network Address Translation) 게이트웨이

NAT는 Network Address Translation의 약자로, 외부 네트워크에 알려진 것과 다른 IP 주소를 사용하는 내부 네트워크에서, 내부 IP 주소를 외부 IP주소로 변환하는 작업을 수행하는 서비스 이다.

NAT 게이트웨이는 Privete Subnet 내에 있는 인스턴스를,
인터넷 또는 다른 AWS 서비스에 연결하고,
외부망 또는 인터넷에서 해당 인스턴스에 연결하지 못하도록 구성하는데 사용한다.

외부에 공개될 필요가 없거나, 보안상 중요한 서비스이지만 윈도우 패치나, 보안 업데이트, 소프트웨어 업데이트를 인터넷을 통해 받아야 하는 경우 NAT 게이트웨이나 NAT 인스턴스를 사용하게 된다.

NAT 게이트웨이를 구성하기 위해서는 아래의 세 가지 조건을 충족해야 한다.

1. NAT 게이트웨이를 생성하기 위해 public subnet 지정
2. NAT 게이트웨이와 연결할 Elastic IP 필요
3. NAT 게이트웨이를 만든 후, 인터넷 트래픽이 NAT 게이트웨이로 통신이 가능하도록 Private Subnet과 연결된 라우팅 테이블 (routing table) 업데이트

VPC Endpoint

Amazon S3는 인터넷망에 연결된 서비스로 인터넷 기반의 IP주소와 연결된 정보를 가지고 있다. 이러한 공용 리소스에 대해 Public Subnet에 위치한 인스턴스는 인터넷을 통해 문제 없이 연결이 가능하다.

하지만, private subnet에 위치한 인스턴스는 인터넷과 연결되어 있는 S3과 같은 공용 리소스를 연결할 수 없다.

이러한 경우, S3에 연결하기 위해서는 NAT 게이트웨이나 NAT 인스턴스가 필요하다.
하지만, VPC Endpoint를 이용하면, 빠르고 손쉽게 S3나 DynamoDB에 연결할 수 있다.

VPN 연결

기본적으로 Amazon VPC에서 서비스되는 인스턴스는,
on-premise에 있는 서버나 IDC 내의 시스템과 통신할 수 없다. 물론 인터넷을 통해 강제로 통신하도록 구성할 수 있으나, 보안을 필요로 하는 중요한 데이터를 송수신하기에는 보안적으로 매우 취약하다.

Lab1. VPC 마법사를 통해 퍼블릭 서브넷과 프라이빗 서브넷 만들기

탄력적 IP 주소 할당을 클릭하여, NAT 게이트웨이에 사용할 탄력적 IP 을 제공받는다.

상단의 [VPC 대시보드] 에서 [VPC 마법사 시작] 버튼을 클릭한다.

[VPC with Public and Private Subnets] 을 클릭한다.

VPC 구성을 아래와 같이 설정하여 생성한다.

아래와 같이 tutorial-VPC가 정상적으로 생성되었음을 확인 가능하다.

Lab2. 리전 간 VPC Peering으로 글로벌 통합 네트워크 환경 구축하기

london 리전에서 VPC 마법사를 시작한다. > single public sunbet이 있는 VPC를 생성한다.

VPC 구성을 위해 아래와 같이 입력하고 생성을 진행한다.

생성이 완료되었다.

vpc 항목에서 정상적으로 생성되어 available 한 status를 확인할 수 있다.

이제 피어링 연결을 해보자(다른 리전간의 피어링 생성을 하여, 동일한 네트워크에 속한 것과 같이 서로 다른 VPC간의 인스턴스 끼리 통신을 하게끔 하는 액션을 해볼 것이다)

우선, 다시 서울리전으로 돌아가서 VPC section으로 넘어가서,
피어링 연결 생성을 아래의 옵션들과 같이 동일하게 구성해서 진행하자.

vpc 연결이 정상적으로 생성되고, 이후 피어링 연결 승인을 위해 런던 리전으로 이동한다.
요청 수락을 한다.

런던 리전의 라우팅 테이블 페이지에 들어가서, 바로 전에 생성된 라우팅 테이블을 다음의 옵션과 같이 편집한다.
(10.0.0.0/16 이라는 서울의 vpc 대역을 입력해준다.)

이번에는 반대로, 서울 리전의 라우팅 테이블 페이지에 들어가서, 바로 전에 생성된 라우팅테이블을 다음의 옵션과 같이 편집해준다. (런던 리전의 vpc 대역인 20.0.0.0/16 을 입력하고, peering connection 을 선택)

다시, 런던 리전의 ec2 생성 페이지로 이동한 후에, 아래의 옵션과 같이 옵션들을 선택한 후에, 인스턴스를 생성한다.

인스턴스 세부 정보 구성은 아래의 옵션과 같이 동일하게 생성해준다.

보안 그룹을 아래의 옵션과 같이 설정해준다. 런던 리전의 vpc 대역을 추가해주는 과정이다.

Key를 발급한다. (peering-test.pem)

Putty를 이용하여, 서울 리전의 인스턴스에 접속한 후에 런던 리전에 생성된 인스턴스의 private ip로 ping 명령어를 실행하여 정상적으로 커뮤니케이팅이 됨을 확인한다.

-끝-