y-log

네트워크 구성하기

VPC, Subnet, Route Table, Internet Gateway, EndPoint 그리고 IaC

AWS VPC (Virtual Private Cloud)란?

AWS Cloud 내부에서 구성되는 사용자의 AWS 계정 전용 가상 네트워크로 이곳에서 AWS 리소스를 시작할 수 있다.

AWS에서는 디폴트로 Amazon EC2-VPC를 제공하지만 Amazon VPC는 AWS의 확장 가능한 인프라를 사용한다는 이점과 함께 고객의 자체 데이터 센터에서 운영하는 기존 네트워크와 매우 유사하다.

또한 AWS VPC는 AWS 클라우드에서 다른 가상 네트워크와 논리적으로 분리되어 있다. IP 주소 범위와 VPC 범위를 설정하고 서브넷을 추가하고 보안 그룹을 연결한 다음 라우팅 테이블을 구성한다.

VPC는 Amazon 콘솔에서 생성된다. 또한 하나의 VPC는 하나의 Region내에서만 생성이 가능하지만 두개 이상의 리전에 걸치는 것은 불가능하다. 하지만 하나의 VPC는 여러 개의 AZ에 걸쳐서 생성될 수 있고 가질 수 있는 IP 주소의 range는 2^16으로 제한된다.

VPC는 독립된 하나의 네트워크를 구성하기 위한 가장 큰 단위이다. 각 region에 종속되며 [RFC1918](https://tools.ietf.org/html/rfc1918)이라는 사설 IP 대역에 맞추어 설계해야 한다. VPC에서 사용하는 사설 IP 대역은 아래와 같다.

1️⃣ 10.0.0.0 ~ 10.255.255.255(10/8 prefix)

2️⃣ 172.16.0.0 ~ 172.31.255.255(182.16/12 prefix)

3️⃣ 192.168.0.0 ~ 192.168.255.255(192.168/16 prefix)

각 대역폭마다 고정되어있는 prefix가 다르다. IPv4 주소인 xxx.xxx.xxx.xxx에서 .으로 구분된 xxx은 0~255 사이의 숫자이며 이는 8bits로 표현할 수 있다. 즉 1번은 00001010~, 2번은 0101100.0001~, 3번은 11000000.10101000~가 앞에 고정되어 있고 나머지 주소 범위에 해당하는 IP 주소를 할당할 수 있다. 아래와 같이 10.0.0.0/16으로 설정된 IP 대역폭은 총 65,536개의 프라이빗 IPv4 주소를 가진다.

VPC에서 한번 설정된 IP 대역은 수정할 수 없으며 각각의 VPC는 독립적이기 때문에 서로 통신할 수 없다. 만일 통신을 원한다면 VPC 피어링 서비스를 통해 VPC 간에 트래픽을 라우팅할 수 있도록 설정할 수 있다.

public / private Subnet이란?

서브넷은 VPC의 IP 주소를 나누어 리소스가 배치되는 물리적인 주소 범위를 뜻한다. VPC를 잘게 나눈 것이 서브넷이기 때문에 VPC보다 대역폭이 낮으며 하나의 AZ(Availability Zone)에 하나의 서브넷이 연결되기 때문에 region의 AZ 수를 미리 확인하고 설정해야한다.

서브넷은 다시 Public Subnet과 Private Subnet으로 나뉠 수 있다. 인터넷과 연결되어있는 서브넷을 public subnet이라고 하고 인터넷과 연결되어있지 않은 서브넷을 private subnet이라고 한다. 이처럼 인터넷 연결 여부로 subnet을 구분하는 이유는 보안을 강화하기 위함이다. public subnet에 존재하는 인스턴스는 인터넷에 연결되어 아웃바운드, 인바운드 트래픽을 주고받을 수 있다. 반면 private subnet은 외부에 노출이 되어 있지 않기 때문에 접근할 수 없다. 즉 인터넷과 연결되어 외부에 노출되어 있는 면적을 최소화함으로써 네트워크 망에 함부로 접근하는 것을 막기 위함이다.

VPC 내에는 보통 public subnet과 private subnet으로 구성되어 있다.

• public subnet
  • internet gateway, ELB, public IP/Elastic IP를 가진 인스턴스를 내부에 가지고 있다.
  • 특히 Public subnet 내에 있는 nat instance를 통해서 private subnet 내에 있는 instances이 인터넷이 가능하게 한다.
• private subnet
  • 기본적으로 외부와 차단되어 있다.
  • private subnet 내의 인스턴스들은 private ip만을 가지고 있고 internet inbound/outbound가 불가능 하고 오직 다른 서브넷과의 연결만이 가능하다.

Router

라우터는 VPC 안에서 발생한 네트워크 요청을 처리하기 위해 어디로 트래픽을 전송해야 하는지 알려주는 표지판 역할을 수행한다. 각각의 서브넷은 네트워크 트래픽 전달 규칙에 해당하는 라우팅 테이블을 가지고 있으며 요청이 발생하면 가장 먼저 라우터로 트래픽을 전송한다. 일반적으로 VPC 내부 네트워크에 해당하는 주소는 local로 향하도록 한다

Routing Table

네트워크상의 특정 목적지까지의 거리와 가는 방법등을 명시하고 있는 테이블로 라우터는 어떤 목저지를 찾아갈 때 이 라우팅 테이블을 보고 찾아가게 된다. 쉽게 말하면 라우터가 여러 가지 정보를 종합해서 얻어낸 네트워크에 대한 지도를 라우팅 테이블이라고 한다.

ip address에 routing 경로를 정의하여 subnet에서 밖으로 나가는 outbound traffic에 대한 routing 경로를 설정하는 것

VPC 내에는 subnet이 있고 각 subnet은 각기 다른 네트워크 대역을 가지고 있고 한 subnet에서 다른 한쪽 subnet으로 가기 위해서는 라우팅이 필요하다.

VPC 내부에 대해서는 자동으로 라우팅이 생성되기 때문에 별다른 설정 없이 한 subnet에서 다른 subnet으로 통신이 가능하다. 이는 보이지 않는 암시적 라우터인 vpc router를 통해 가능하게 되는 것이다. subnet으로 리소스를 보낼 때 이 vpc router를 거쳐야 한다.

AWS에서의 라우팅 테이블은 subnet이 라우터를 통해 보내는 네트워크 트래픽이 전달되는 위치를 제어하는 역할을 한다. 귐게 말해 라우팅에 대한 하나의 규칙을 정의하는 것이다.

Internet Gateway

VPC와 인터넷이 통신할 수 있도록 도와주는 VPC 컴포넌트

단순히 인터넷과의 통로 역할을 할 뿐 아니라 NAT의 역할도 수행한다.

인터넷 게이트웨이는 VPC 리소스와 인터넷 간 통신을 활성화하기 위해 VPC에 연결하는 게이트웨이이다. 앞서 설명했듯 public subnet만 외부와 통신해야 하므로 public subnet의 라우팅 테이블에만 인터넷 게이트웨이로 향하는 규칙을 포함한다. 아래 그림과 같이 라우팅 규칙을 설정하면 네트워크 요청 발생 시 목적지의 IP 주소가 10.0.0.0/16(VPC 내부)에 해당하는지 확인한다. 해당하지 않는 모든 트래픽은 인터넷 게이트웨이를 통해 외부로 전송되어 목적지를 찾는다.

NAT Gateway

public subnet만 인터넷 게이트웨이를 통해 외부와 트래픽을 주고받을 수 있다면 private subnet의 트래픽은 무조건 VPC 안에서만 처리된다는 뜻일까?

그렇지 않다. private subent 역시 마찬가지로 인터넷과 통신할 수 있다. 하지만 private subnet에서 직접하는 것은 불가능하므로 트래픽을 public subnet에 속한 인스턴스에 전송해서 인터넷과 통신을 해야 한다.

NAT 게이트웨이가 이 역할을 수행한다. private subent에서 발생하는 네트워크 요청이 VPC 내부의 주소를 목적지로 하는 것이 아니라면 public subnet에 존재하는 NAT로 트래픽을 전송한다. 트래픽을 받은 NAT는 public subnet의 라우팅 규칙에 따라 처리함으로써 private subnet이 인터넷과 통신할 수 있도록 한다.

VPC EndPoint (private Link, VPC 엔드 포인트)

VPC 엔드포인트는 인터넷 게이트웨이나 NAT 게이트웨이와 같은 다른 게이트웨이 없이 AWS 서비스와 연결하여 통신할 수 있는 private connection을 제공하는 서비스이다. Private link를 통해 AWS 서비스와 연결함으로써 데이터를 인터넷에 노출하지 않고 바로 접근할 수 있다.

또한 연결하는 서비스의 IP 주소를 바꾸는 등 네트워크 정보의 변경 등의 작업에서 불필요하게 발생하는 비용을 줄일 수 있다.

코드형 인프라 IaC

수동 프로세스가 아닌 코드를 통해 인프라를 관리하고 프로비저닝하는 것을 말함

IaC를 사용하면 인프라 사양을 담은 구성 파일이 생성되므로 구성을 편집하고 배포하기 더 쉬워진다. 또한 IaC는 매번 동일한 환경을 프로비저닝하도록 보장한다.

IaC는 구성 사양을 코드화하고 문서화 함으로써 구성 관리를 지원하며, 따라서 구성 변경 사항을 문서화하지 않고 임시로 변경하는 일을 막을 수 있다.

버전 제어는 IaC의 가장 중요한 부분이고다른 소프트웨어 소스 코드 파일과 마찬가지로 구성 파일도 소스 제어가 필요하다.

코드로 인프라를 배포한다는 것은 인프라를 모듈식 구성 요소로 분할하고 자동화를 통해 다양한 방식으로 결합할 수 있다는 뜻이기도 하다.

IaC로 인프라 프로비저닝을 자동화하면 애플리케이션을 개발하거나 배포할 때 마다 개발자가 직접 서버, 운영 체제, 스토리지, 기타 인프라 구성 요소를 수동으로 프로비저닝하고 관리할 필요가 없어진다.

인프라를 코드화하여 템플릿을 만들고 프로비저닝할 때 이 템플릿을 사용하면 된다. 이러한 작업은 수동으로 진행할 수 도 있고 자동화 툴을 사용할 수 도 있다.

reference.

link

기본적으로 프라이빗 클라우드, 퍼블릭 클라우드, 하이브리드 클라우드, 멀티클라우드로 4가지의 유형으로 나눌 수 있다.

퍼블릭 클라우드

일반적으로 최종 사용자가 소유하지 않은 IT 인프라에서 생성되는 클라우드 환경

전통적으로 오프프레미스에서 구동되었지만, 오늘날 퍼블릭 클라우드 제공업체는 클라이언트의 온프레미스 데이터 센터에서 클라우드 서비스를 구동하기 시작했다. 이로 인해 위치와 소유권을 통한 구분은 사라지게 되었다.

환경이 멀티플 테넌트로 파티셔닝 또는 재배포되는 클라우드를 모두 퍼블릭 클라우드라고 볼 수 있다.

멀티 테넌시는 단일 소프트웨어 인스턴스로 서로 다른 여러 사용자 그룹에 서비스를 제공할 수 있는 소프트웨어 아키텍처로 SaaS 제품이 그 예이다.

서로 다른 고객이 서버 리소스를 나누어 사용하는 공유 호스팅을 멀티 테넌시라고 부르기도 한다.

반대의 의미인 단일 테넌시에서는 소프트웨어 인스턴스 또는 컴퓨터 시스템 하나에 최종 사용자 또는 사용자 그룹이 하나만 있다.

• 대표적인 퍼블릭 클라우드 제공업체
  • AWS
  • Google Cloud
  • Microsoft Azure
  • etc

프라이빗 클라우드

단일 최종 사용자 또는 그룹의 전용 클라우드 환경으로, 실행 시 대개 해당 사용자 또는 그룹의 방화벽으로 보호된다.

완전히 독립적인 액세스 권한이 있는 단일 고객만 기반 IT 인프라를 독점적으로 사용하는 경우 이러한 모든 클라우드를 프라이빗 클라우드라고 정의할 수 있다.

그러나 이제는 프라이빗 클라우드라고 해서 온프레미스 IT 인프라에서만 구동할 수 있는 것은 아니다. 또 오프 프레미스에 위치한 벤더 소유의 임대한 데이터 센터에 프라이빗 클라우드를 구축하는 조직도 있기 때문에 위치와 소유권은 더이상 차별화 요소가 아니다.

이로 인해 프라이빗 클라우드의 하위 유형도 여러 가지가 생겨났다.

• 관리형 프라이빗 클라우드

고객은 타사 공급 업체가 배포, 설정 및 관리하는 프라이빗 클라우드를 구축하고 사용

관리형 프라이빗 클라우드는 IT 팀의 인력이나 기술이 부족한 경우 보다 나은 프라이빗 클라우드 서비스와 인프라를 제공할 수 있도록 기업을 지원하는 클라우드 제공옵션이다.

• 전용 클라우드

다른 클라우드 내에 있는 클라우드

퍼블릭 클라우드 또는 프라이빗 클라우드에 전용 클라우드를 구축할 수 있다.

예를 들어, 회계 부서에서는 조직의 프라이빗 클라우드 내에 전용 클라우드를 보유할 수 있다.

하이브리드 클라우드

단일 IT 환경 처럼 보이지만, 실제로는 여러 환경이 LAN, WAN, VPN 및/또는 API를 통해 연결된 형태다.

하이브리드 클라우드는 복잡하고 어떤 상황인지에 따라 요건 또한 다르다.

예를 들어 하이브리드 클라우드에는 다음이 포함될 수 있다.

• 1개 이상의 프라이빗 클라우드와 1개 이상의 퍼블릭 클라우드
• 2개 이상의 프라이빗 클라우드
• 2개 이상의 퍼블릭 클라우드
• 1개 이상의 퍼블릭 클라우드 또는 프라이빗 클라우드에 연결되는 베어메탈 또는 가상 환경

애플리케이션을 개별적이지만 연결되어있는 다중 환경 내외로 이동할 수 있는 경우 하이브리드 클라우드라고 볼 수 있으며, 사실상 거의 모든 IT 시스템이 이러한 추세다.

적어도 이러한 환경 중 일부는 온디맨드로 확장할 수 있는 통합 IT 리소스에서 제공되어야 하고, 모든 환경이 통합 관리 및 오케스트레이션 플랫폼을 사용해 단일 환경처럼 관리되어야 한다.

멀티클라우드

2곳 이상의 클라우드 공급업체가 제공하는 2개 이상의 퍼블릭 또는 프라이빗 클라우드로 구성된 클라우드 접근 방식

모든 하이브리드 클라우드는 멀티 클라우드이지만, 모든 멀티클라우드가 하이브리드 클라우드인 것은 아니다.

멀티 클라우드가 어떤 형태로든 통합 또는 오케스트레이션되어 연결되면 하이브리드 클라우드가 된다.

명확한 목적, 즉 중요 데이터를 더 효과적으로 제어하기 위해 또는 더 강력한 재해 복구를 위한 이중 스토리지 공간으로서 멀티클라우드 환경을 구축하거나 우연히 멀티 클라우드의 형태가 될 수 도 있다. 어느 쪽이든 확장된 환경 포트폴리오를 통해 보안과 성능을 강화하려는 기업들 사이에서 멀티 클라우드가 보편화되고 있다.