Amazon VPC(Virtual Private Cloud)생성하기

Cloud Computing/AWS 2020. 1. 23. 18:00

VPC는 Virtual Private Cloud의 약어로 아마존 클라우드 내에서 Private IP를 사용하는, 일종의 가상 Private network를 만들게 해주는 서비스이다. 아마존 웹사이트에서는 아래와 같이 설명한다.

 

Amazon Virtual Private Cloud(Amazon VPC)에서는 사용자가 정의한 가상 네트워크로 AWS 리소스를 시작할 수 있습니다. 이 가상 네트워크는 AWS의 확장 가능한 인프라를 사용한다는 이점과 함께 고객의 자체 데이터 센터에서 운영하는 기존 네트워크와 매우 유사합니다.

 

VPC 핵심 개념은 다음과 같다.

  • VPC는 사용자의 AWS계정 전용 가상 네트워크이다.
  • 서브넷(Subnet)은 VPC의 IP주소 범위이다.(=네트웍크 주소공간을 분할 = IP Group)
  • 라우팅테이블(Routing table)에는 네트워크 트래픽을 전달할 위치를 결정하는데 사용하는 라우팅이라는 규칙 집합이 포함되어 있다.
  • 인터넷 게이트웨이(Internet gateway)는 수평 확장되고 가용성이 높은 중복 VPC구성 요소로, VPC의 인스턴스와 인터넷과 통신할 수 있게 해주므로 네트워크 트래픽에 가용성 위험이나 대역폭 제약 조건이 발생하지 않는다.
  • VPC 엔드포인트(End point)를 통해 인터넷 게이트웨이, NAT디바이스, VPN연결 또는 AWS Direct Connect연결을 필요로 하지 않고 Private link 구동 지원AWS서비스 및 VPC 엔드포인트 서비스에 비공개로 연결할 수 있습니다. VPC인스턴스는 서비스 리소스와 통신하는데 퍼블릭 IP주소가 필요하지 않다. VPC와 기타 서비스 간 트래픽은 Amazon 네트워크를 벗어나지 않는다.

VPC

VPC는 아마존 콘솔에서 생성하고, VPC범위는, 하나의 VPC는 하나의 region내에서만 생성이 가능하다. 즉 VPC를 두 개 이상의 region에 걸쳐 사용이 불가능하다. 단 하나의 VPC는 여러개의 Amazon Availibilty Zone(이하 AZ)을 가질 수 있다. 또한 하나의 VPC가 가질 수 있는 IP주소의 range는 2^16=65535로 제한된다.

CIDR표현으로 10.0.0.0/16(10.0.0.0 ~ 10.0.255.255) 범위가 된다. CIDR에 대한 개념과 계산법은 아래 사이트에서 계산할 수 있다.

http://www.subnet-calculator.com/cidr.php

 

Subnet

VPC를 생성했으면 각각의 Subnet을 생성해야한다. Subnet의 범위를 다시 한번 살펴보면,

VPC는 앞서 설명한 것 처럼, 하나의 region내에서 여러개의 AZ에 걸쳐서 생성이 가능하다. VPC안에서는 여러개의 subnet을 생성할 수 있는데, 하나의 subnet은 VPC안에서 하나의 AZ에만 생성이 가능하다.

 

 

 

Route Table

각 Subnet에는 default로 subnet과 밖을 연결해주는 router가 생성되고, 이 router는 route table을 가지고 있다.

대상 IP Address에 routing경로를 정의하는 것으로 subnet에서 밖으로 나가는 outbound traffic에 대한 routing경로를 정의한다. 이 route table은 AWS콘솔에서 설정이 가능하고, routing경로는 target의 타입에 따라서 크게 3가지로 구분할 수 있다.

  • Local: VPC내의 다른 subnet으로 traffic을 routing한다.
  • Internet gateway: Internet gateway를 통해서 외부 인터넷으로 traffic을 routing한다.
  • Virtual  private gateway: 관리자가 임의로 정의한 destination으로 traffic을 routing한다. VPN연결을 위한 VPN gateway등이 그 예가 된다.

아래와 같이 설정해 놓으면 10.0.0.0 ~ 10.0.255.255는 VPC 내부로 routing되고, 이외의 모든 traffic은 igw-06eb1f727711c1d09(Internet gateway로 정의)라고 정의한 router로 routing된다.

 

모든 Subnet은 1개의 Routing table을 가져야 하며, 하나의 Routing table은 여러개의 subnet에 중복되서 적용될 수 있다.

 

Public subnet & Internet gateway

VPC내에 생성되는 EC2 Instance는 10.0.x.x와 같은 private IP이외에 Elastic IP(이하 EIP)를 통해서 일반 인터넷 주소인 Public IP까지 총 2개의 IP를 가질 수 있다.

Subnet 내의 EC2 Instance들이 직접 인터넷 EIP를 통해서 in/out bound connection이 연결 가능한 subnet을 public subnet이라고 정의 하는데, 이 in/out bound traffic은 internet gateway(이하 IGW)를 통해서 이루어지며, 콘솔 설정으로 만들 수 있고, 생성 후 VPC에 attach한 후, 사용하고자 하는 subnet의 routing table에 설정을 해주면 된다.

위 그림과 같이 subnet에서 인터넷으로, traffic은 EC2의 EIP를 통해서 router를 타고 router에 의해 정의된 routing경로를 따라 internet gateway를 거쳐서 인터넷에 연결된다.

 

Private subnet & NAT

Public subnet이 있으면 당연히 Private subnet도 있다. Private subnet은 EIP를 가지지 않고 private IP만 가지고 있으며, Internet으로 in/out bound연결이 불가능하며, 단지 다른 subnet으로만 연결이 가능하다.

보통 일반적인 회사에서 private network구성을 할 때 많이 사용하는 방법인데, private IP를 쓴다 하더라도 외부 시스템으로의 접속이 필요한 경우가 있다. 예를 들어 다른 서버와 connection을 하거나 patch를 읽어오는 것과 같은 outbound connection은 사용되는 경우가 많다. 일반 private network의 경우에는 outbound connection에 대해서 public IP를 binding하여 연결을 제공하는 방식으로 NAT(Network Address Translator)라는 장비를 사용하는데, Amazon에서도 마찬가지로 이러한 NAT를 이용해서 Private subnet 내의 instance가 Internet으로 나가는 outbound traffic이 지원될 수 있도록 한다.

NAT를 이용한다고 해서 특별한 기능을 Amazon이 제공하는 것이 아니고, Software기반의 NAT를 public subnet에 설치한 후에 private subnet에서 Internet으로 나가는 outbound traffic에 대한 routing경로를 이 NAT를 통하게 하는 것이다.

조금 사용을 편리하게 하기 위해서 Amazon에서는 AMI이미지 형태로 미리 NAT EC2이미지를 제공하고 있기 때문에, 별도의 선호 제품이 없을 경우에는 이 이미지를 사용하면 된다.

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html

보통 이 NAT를 사용할 경우, 전체 VPC에 대해서 한 두 개의 NAT만 사용하는 경우가 있는데, 애플리케이션이 private subnet에서 밖으로 나가는 outbound protocol이 많을 경우에 이 NAT자체가 병목 구간이 될 수 있기 때문에 NAT에 대한 traffic을 수시로 확인하고 알맞은 용량으로 운영을 해야 한다. 또한 Amazon 내부 서비스라 하더라도 Private IP가 아니고 Public IP를 사용하는 경우가 많고, 이 경우 private subnet에 있는 EC2인스턴스들은 NAT를 거치기 때문에 Amazon서비스에 대한 호출도 NAT를 사용함을 인지하고 NAT용량을 체크해야 한다. (예, S3는 public IP만 제공한다. 그래서 private subnet에서 S3로 traffic은 모두 NAT를 거치게 된다.)

 

VPN

VPN은 Virtual Private Network의 약자로 Public(인터넷)망을 통해서 회사의 Private network망에 연결하게 해주는 서비스이다. 예를 들어 회사가 10.0.1.xx 대역의 네트웍을 쓰고 있고, 내가 집에서 노트북으로 회사의 네트웍에 접속하고자 한다고 하자. 내 IP는 Public IP로 198.12.x.x를 사용한다고 하자. 회사 네트워크는 private망이기 때문에 접속이 불가능하다. 그래서 VPN gateway를 회사 네트워크와 내 PC에 설치해 놓으면 가상으로 내 PC를 회사 네트워크와 연결하여 같은 네트워크 대역으로 사용할 수 있게 해준다. 개인 PC와 회사 private 네트워크 뿐만 아니라, 물리적으로 분리되어 있는 지역간 사무실이나 네트워크까지 이 VPN 네트워크를 사용하면 하나의 private network으로 묶을 수 있다.

Amazon에서도 역시 VPN을 사용할 수 있는데, VPN을 사용하기 위해서는 VPN gateway를 설치해야 한다. 직접 소프트웨어 기반의 VPN을 설치할 수 도 있지만, Amazon에서 제공하는 VPN을 사용할 수 도 있다. VPN은 그 보안 및 암호화 방법에 따라 IPESC, IKE 등 여러가지 방법을 제공하는데, Amazon에서 제공하는 VPN의 경우에도 상당히 다양한 방법의 VPN프로토콜을 지원한다.(IPSEC, IKE, SHA-1방식의 Hashing, BGP peering 등) 자세한 내용은 아래 링크 참고.

http://docs.aws.amazon.com/AmazonVPC/latest/NetworkAdminGuide/Introduction.html

VPN을 통해서 VPC에서 할 수 있는 것은 region간 서로 다른 VPC를 같은 subnet으로 묶거나, 또는 회사 데이터 센터의 subnet을 VPN을 통해서 VPC와 같은 네트워크 대역으로 묶을 수 있다.

VPN을 구성할 때 고려해야 할 점은, VPC를 구성할 때 VPN을 통해서 다른 region이나 데이터 센터(회사)와 연결할 가능성이 있다면, subnet의 IP주소를 이에 맞게 구성해야 한다는 것이다. 만약에 vpc를 구성할 때 처음부터 10.0.0.0/16으로 Full range를 다 사용해 버리면 나중에 다른 데이터 센터와 VPC로 연결할 때 IP가 겹칠 수 있고, 이를 바꾸어야 하는 대 작업이 생길 수 있기 때문에 VPC디자인 시 먼저 subnet의 IP대역을 적절하게 분할하여 설계할 필요가 있다.

 

Security Group

Security Group은 VPC안에서 일종의 방화벽 처럼 사용된다. VPC가 아니더라도 Security group은 AWS에서 필수적으로 사용되는데, Security group은 inbound 또는 outbound traffic에 대해서 port별로 접근을 제어할 수 있는 기능을 제공한다. 마치 방화벽과 같은 기능을 하는 서비스라고 생각하면 된다. VPC안에서의 Security group의 차이점은 VPC를 사용하지 않는 경우 Security group에서는 inbound traffic에 대해서만 접근 제어가 가능한데, VPC내의 Security group의 경우에는 in/outbound traffic 모두에 대해서 접근 제어가 가능하다. 그 외에도 접근할 수 있는 Security group수나 지원하는 프로토콜의 종류가 차이가 있는데, 자세한 내용은 아래 링크를 참고하기 바란다.

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html#VPC_Security_Group_Differences

Security group을 이용하면, Hosting환경에서 사용하는 DMZ와 같은 개념을 구현할 수 있다. 아래 아키텍처는 Web, REST API, DBMS 세 가지 계층으로 이루어진 시스템이다.

Web layer는 public subnet으로 구성하고, 인터넷으로 부터 들어오는 모든 TCP 80(HTTP) traffic을 받도록 Security group을 구성한다. REST API를 제공하는 subnet은 Web server들이 위치한 subnet으로 부터 들어오는 TCP 8080 traffic만 받도록 하고, DB들이 위치한 subnet은 API server용 subnet에서 들어오는 DB연결용 3306포트만 받도록 한다. 이런식으로 네트워크를 구성하면 조금 더 높은 수준의 보안을 제공할 수 있다.

 

Bastion

VPC를 사용하면, private subnet의 경우에는 외부에서 telnet이나 SSH로 접근 할 수 있는 방법이 없다.(Public IP가 없기 때문에) 또한 Public subnet에 있는 EC2 instance의 경우에도 모든 인스턴스에 SSH연결을 열어 놓게 되면 보안상으로 문제가 발생할 수 있는 가능성이 있다. 그래서 Bastion이라는 개념을 사용하는데, 일종의 Telnet접속 콘솔이라고 생각하면 된다.

VPC내의 모든 Instance들은 이 Bastion으로부터 Telnet 또는 SSH접속만을 허용하도록 Security group을 설정하고, 이 Bastion역시 SSH접속을 운영자나 PC운영센터(회사)의 IP대역을 통해서 SSH접속만을 할 수 있도록 Security group을 설정해 놓으면 VPC로의 접근을 안전하게 통제할 수 있으며, 단일 접속 지점만을 제공하기 때문에 모든 사용자의 접근 내용을 한군데로 logging해서 감시할 수 있는 장점이 있다. Bastion은 단일 접속 지점인 만큼 하나의 Instance로 운영하는 것보다는 HA를 사용하거나 일반적인 접속을 위한 Bastion과 Super user(Admin)만을 위한 별도의 Bastion을 포함하여 2개 이상을 운영하는 것이 좋다.

 

VPC Scenarios

지금까지 간략하게 VPC의 기능에 대해서 알아보았다. VPC를 제대로 사용하면 상당히 다양한 구조의 network을 구성할 수 있다. 반대로 얘기하면, 모르면 구성이나 사용이 매우 어렵다는 이야기가 된다. Amazon에서는 VPC에 대한 주요 사용 패턴에 따른 약 4가지 시나리오를 이미 준비해 놓고, VPC Wizard에서 지원하고 있다.

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenarios.html를 보면 Amazon에서 제공하는 주요4가지 시나리오에 대한 설명과 설정 방법을 참고할 수 있다.

 

 

이 문서는 아래 조대협님 글을 기준으로 작성하였습니다.

https://bcho.tistory.com/779

Trackbacks 0 : Comments 0

Write a comment