Virtual Private Cloud

글쓴이 상배 윤 날짜

Virtual Private Cloud 개요

Amazon VPC(Virtual Private cloud)는 클라우드위에서 고객에게 논리적으로 격리된 네트워크를 제공하는 서비스다. 고객은 AWS로 부터 네트워크를 할당 받아서, 서브넷을 구성하고 라우터를 설정 할 수 있으며, IPSec 혹은 OpenVPN등의 가상사설망을 이용해서 VPC 네트워크에 배치된 자원에 접근 할 수 있다.

Amazon은 EC2 인스턴스를 퍼블릭 네트워크에 위치하거나 VPC 위치를 선택 할 수 있다. 하지만 특별한 이유가 없다면 VPC에 두는 걸 선호한다. 네트워크 격리에 따른 세분하된 제어를 통해서 더 높은 보안수준을 달성할 수 있기 때문이다. 물리적인 네트워크를 사용하던 가장 큰 이유 중 하나는 네트워크 격리에 따른 높은 보안 수준이었는데, VPC를 이용해서 동등한 수준의 보안수준을 가진 네트워크를 설계 할 수 있다.

Virtual Private cloud 구성요소

  • Virtual Private Cloud : AWS 클라우드에서 제공하는 가상 네트워크 서비스다. VPC는 고유의 16비트 규모 네트워크를 제공하며, 이 네트워크 안에서 서브넷을 관리 할 수 있다.
  • Subnet : 16비트 네트워크를 더 작은 네트워크로 나눠서 관리 할 수 있다. 각 서브넷은 라우터로 트래픽을 제어 할 수 있으며, ACL도 적용 할 수 있다.
  • Internet Gateway : VPC를 인터넷으로 연결하기 위한 관문이다. VPC에 만들어지는 기본적으로 인터넷으로 부터 격리된다. 이런 서브넷을 프라이빗 서브넷(Private subnet)이라고 한다. 라우터를 이용해서 서브넷의 트래픽을 IGW로 보낼 수 있는데, 이렇게 되면 해당 서브넷은 퍼블릭(public)서브넷이 되고 인터넷으로 연결된다.
  • NAT Gateway :프라이빗서브넷은 인터넷에서 접근 할 수 없다. 하지만 인터넷으로 접근이 필요할 때도 있다.
  • Hardware VPN Connection : 하드웨어 기반의 VPN 컨넥션이다. AWS VPC와 데이터센터(혹은 회사)네트워크를 연결할 수 있다.
  • Virtual Private Gateway : AWS VPC측의 VPN 연결점
  • Customer Gateway : 클라이언트측의 VPN 연결점
  • Peering Connection : 두개의 VPC를 연결해서 IP 통신이 가능하게 한다.
  • VPC Endpoint : AWS의 어떤 자원들은 AWS VPC를 초월해서 AWS 레벨에서 존재한다. 예를들어 EC2, RDS는 VPC에 존재하지만, DynamoDB, S3등은 리전단위로 존재한다. 여러분이 VPC내에 EC2를 전개했다고 가정해보자. 이 EC2가 DynamoDB에 접근하려면 EC2에 Public IP를 할당하거나 NAT Gateway를 이용해야만 접근 할 수 있다. 이러한 접근방식은 보안성을 깨드릴 수 있다. VPC Endpoint를 이용하면,  복잡한 과정을 거치지 않고도 AWS의 서비스들에 접근 할 수 있다.

AWS 네트워크

  • Cloud Concepts 의 Region과 가용영역을 참고한다. VPC는 AWS 리전에 만들어지는 가상 네트워크다.

VPC와 Subnet

IPv4 네트워크 & Subnet 개요

IPv4 네트워크는 32비트로 이루어져 있으며, 일련의 이진정보(0,1)의 블록들로 구성된다.

이진 형태닷 데시멀 노테이션IP 형태
IP 주소11000000.10101000.00000101.10000010192.168.5.13
서브넷 마스크11111111.11111111.11111111.00000000255.255.255.0
네트워크영역11000000.10101000.00000101.00000000192.168.5.0
호스트 영역00000000.00000000.00000000.100000100.0.0.130

IPv4 주소 정보는 네트워크 영역과 호스트영역으로 구성이된다. 네트워크 영역은 기관에 IPv4를 위임하기 위해서 사용한다. 위임받은 기관은 호스트영역의 주소를 이용해서 네트워크를 관리한다.

  • 만약 네트워크영역으로 16bit를 할당 했다면, 호스트영역이 16bit가 되므로 65536개의 호스트를 관리 할 수 있을 것이다.
  • 네트워크 영역으로 24bit가 할당 됐다면, 호스트영역으로 8bit 256개의 호스트를 관리 할 수 있을 것이다.

네트워크와 호스트영역으로 구분하는 것으로 IPv4는 위계를 가질 수 있다. 예를 들어 16bit 네트워크는 24 bit와 같은 더 작은 네트워크로 나눠서 사용 할 수 있다. 이런 네트워크를 서브넷(subnet, 부분망)이라고 한다.

VPC와 AZ(Availibility Zone)

  • VPC는 리전단위로 만들어진다.
  • 리전은 두 개 이상의 AZ으로 구성이된다. 따라서 VPC도 두 개 이상의 AZ으로 네트워크가 분산될 수 있다.
  • VPC의 최소 네트워크 단위는 서브넷으로 각 서브넷은 AZ를 선택 할 수 있다.

서브넷을 AZ로 분산하고, 서브넷에 애플리케이션을 분산해서 배치하는 것으로 애플리케이션의 가용성을 높일 수 있다.

Default VPC

유저가 계정을 만들면 AWS는 즉시 사용가능한 “Default VPC”를 제공한다. 유저는 다른 준비과정없이 Default VPC를 이용해서 빠르게 블로그나 웹 사이트등을 서비스 할 수 있다. Default VPC의 특징이다.

  • 172.31.0.0/16. 16비트 크기의 VPC를 만든다. 호스트영역으로 16비트를 사용 할 수 있으므로 총 2^16 = 65536개의 프라이빗 IPv4 주소를 사용 할 수 있다.
  • 각 AZ에 /20 크기의 기본 서브넷을 만든다. 서브넷당 2^12=4096개의 주소를 사용 할 수 있다.
  • 보통 Default VPC를 서비스 전개를 위한 네트워크로 사용하지는 않는다. AWS는 24bit 서브넷을 권장한다.
  • Default VPC는 삭제 할 수 있다.
  • 인터넷으로 향하는 모든 트래픽은 인터넷 게이트웨이로 향한다.

내 계정의 Default VPC  정보는 아래와 같다.

Subnet IDCIDRAvailability ZoneRoute table
subnet-9a1ancdb172.31.0.0/20ap-northeast-2crtv-892abkaji
subnet-9a2abcadk172.31.16.0/20ap-northeast-2a

Route Table rtv-892abkaji 의 설정은 아래와 같다.

DestinationTargetStatusPropagated
172.31.0.0/16localActiveNo
0.0.0.0/0igw-7abcdefgActiveNo
  • 172.31.0.0/16 으로 향하는 패킷은 local(VPC) 서브넷으로 향한다.
  • 0.0.0.0/0 으로 향하는 패킷은 인터넷 게이트웨이로 향한다.
  • Propagated : 경로전파가 비활성 상태다. 활성화되면 VPN에서 VPN 게이트웨이가 라우팅 테이블에 자동으로 설정되도록 전파한다. 지금은 VPN을 사용하지 않으므로 비활성화 상태다.

rtv-892abkaji 라우팅 테이블을 구성하는 Subnet Association 설정은 아래와 같다.

SubnetIPv4 CIDRIPv6 CIDR
subnet-9a1ancdb172.31.0.0/20
subnet-9a2bcadk172.31.16.0/20

인터넷 게이트웨이 igw-7abcdefg 의 상세정보다. VPC에 attached 된 상태를 확인 할 수 있다.

IDStateVPC
igw-7abcdefgattachedvpc-773ab91c

VPC Subnet & Private Subnet & Public Subnet

VPC는 인터넷으로 부터 격리된다. 여기에서 만들어지는 서브넷도 인터넷으로 부터 격리된다. 개발자는 10.1.0.0/16 과 같은 VPC를 만들 수 있다. 10.1.0.0/16 네트워크를 만들었다면 아래와 같이 네트워크를 구성할 수 있을 것이다.

  • 10.1.1.0/24 : 웹서버를 전개하기 위한 네트워크
  • 10.1.2.0/24 : WAS를 전개하기 위한 네트워크
  • 10.1.3.0/24 : 백앤드 배치잡을 전개하기 위한 네트워크

아래 그림에서 10.5.0.0/16 네트워크를 만들고, 10.5.0.0/24, 10.5.1.0/24 두 개의 서브넷을 만들었다. 각 서브넷은 Availability Zone A와 B에 배치했다. VPC 내부에 있는 서브넷은 서로 통신이 가능하다.

서브넷에 배치된 자원들은 VPC 안에서 자유롭게 통신 할 수 있지만, 인터넷으로 통신할 수는 없다. 인터넷으로 통신을 하기 위해서는 VPC에 IGW를 붙이고(attach)하고, 서브넷에서 인터넷(0.0.0.0/0)으로 나가는 패킷이 IGW로 향하도록 라우터 설정을 해야 한다. EC2는 Public IP 혹은 EIP를 붙일 수 있지만, IGW가 없는 상황에서는 인터넷에서 접근 할 수 없다.

VPC 생성 학습 – 기본

구성

  • 1개의 Public subnet
  • 1개의 Private subnet

vpc 생성

  • name tag : VPC name 태깅
  • IPv4 CID block : 10.10.0.0/16
  • IPv6 사용하지 않기로 했다.
  • Tenancy : Default와 dedicate 가 있다.

VPC Dashboard에서 확인 할 수 있다.

VPC를 만들면, Rout table, Network ACL이 자동으로 설정된다. Default VPC는 “no”다.

Subnet 생성

ap-northeast-2a에 두 개 서브넷을 모두 구성했다.

Name tagCIDRAvailability Zone비고
yundream-public10.10.0.0/24ap-northeast-2aPublic subnet
yundream-private10.10.1.0/24ap-northeast-2aPrivate subnet
Route Table

VPC를 만들면 기본 라우팅 테이블이 만들어진다. 이 라우팅 테이블은 main 라우팅 테이블이다. 유저는 새로운 라우팅 테이블을 만들 수 있는데 이 라우팅 테이블을 custom 라우팅 테이블이라고 한다.

아래는 현재 만들어진 main 라우팅 테이블을 보여주고 있다.

local 경로 설정하나만 있다. Subnet Associations에는 아직 subnet이 등록되지 않았다. Subnet Association에 앞서 만든 서브넷을 모두 등록하면, 해당 서브넷들은 “10.10.0.0/16 → local” 라우팅룰에 따라서 통신 할 수 있게 된다.

Internet gateway attach

인터넷에 연결하기 위해서 VPC Dash board > Internet Gateway > Create internet gateway 에서 “yundream-igw”로 만들었다.

yundream-igw는 “detached” 상태다. yundream-igw를 yundream-vpc에 attach 하자.

aws ec2 attach-internet-gateway –vpc-id “vpc-0700d43bd5ba9b0a4” –internet-gateway-id “igw-0dc27bdded12bcfd2” –region ap-northeast-2

이제 private subnet/public subnet을 만들기 위해서 라우팅 테이블을 조작하면 된다. 나는 main 라우팅 테이블을 private routing 테이블로 하고, public(인터넷)으로 라우팅하기 위한  custom routin 테이블을 만들기로 했다.

private routing table(main routing table)은 아래와 같은 라우팅룰을 가질 것이다.

Name TagDestinationTarget설명
Private-route-table10.10.0.0/16local10.10.0.0/16으로 향하는 패킷은 local vpc 서브넷으로 보낸다.인터넷으로 향하는 패킷은 라우팅룰이 없으므로 버려진다.

Public routing table(custom routing table)은 아래와 같은 라우팅룰을 가질 것이다.

Name TagDestinationTarget비고
Public-route-table10.10.0.0/16local10.10.0.0./16으로 향하는 패킷은 local vpc 서브넷으로 보낸다.
0.0.0.0/0igw-0dc27…인터넷으로 향하는 패킷은 이 룰에 따라서 인터넷 게이트웨이로 나간다.

테스트를 위해서 각 서브넷에 EC2 인스턴스를 할당했다.

Instance NamesubnetPublic IPssh 연결 여부
public.joinc.privyundream-publicOO
private.joinc.privyundream-privateOX

예상한대로 작동했다.

NAT Gateway

NAT Gateway 설정

일단 public.joinc.priv에 연결 한 다음, private.joinc.priv에 연결했다. private.joinc.priv는 IGW 라우팅 룰이 없기 때문에 인터넷으로 연결 할 수가 없다. 인터넷으로 연결하기 위해서 NAT gateway를 설치하기로 했다.

NAT Gateway가 속할 서브넷을 설정해줘야 한다. NAT Gateway는 인터넷으로 연결을 해야 하기 때문에 public subnet에 배치해야 한다. 그리고 private subnet에서 0.0.0.0/0 패킷을 NAT gateway로 보내면 된다.

NAT Gateway 특징

NAT Gateway는 아래와 같은 제약 사항이 있다.

  • 5Gbps의 대역폭을 지원하며 최대 45Gbps까지 자동 확장한다. 만약 이 이상으로 대역폭이 필요하다면, 서브넷을 분할하고 각 서브넷에 NAT 게이트웨이를 만들어서 워크로드를 분산해야 한다.
  • NAT Gateway에는 하나의 EIP만 연결 할 수 있다. 일단 연결된 EIP는 끊을 수 없다.
  • TCP, UDP, ICMP 를 지원한다.
  • NAT에는 Security group을 연결 할 수 없다. 인스턴스 security group을 이용해서 제어해야 한다.
  • Network ACL을 이용해서 트래픽을 제어 할 수 있다.
  • NAT 게이트웨이는 1024 – 65536까지의 포트를 사용한다.
  • NAT 게이트웨이는 각 고유 대상에 대해서 55,000개의 동시 연결을 지원한다. 55,000 이상의 연결을 만들 경우 “포트 할당 오류”가 발생 할 수 있다. 포트할당 오류는 ErrorPortAllocation CloudWatch 매트릭으로 모니터링 할 수 있다.

VPC 대시보드에서 NAT Gateway를 만들 수 있다.

NAT 게이트웨이를 배치할 서브넷을 선택한다. yundream-public 서브넷을 선택했다. 그리고 NAT가 사용할 EIP를 설정한다.

NAT 게이트웨이가 만들어지면 Edit route tables를 클릭해서 라우팅테이블 설정으로 넘어갈 수 있다.

0.0.0.0/0로 향하는 패킷을 NAT 게이트웨이로 향하도록 private-route-table를 설정했다.

Private subnet 인스턴스에서 인터넷으로 접근을 테스트해봤다.

$ curl http://www.google.co.kr -I HTTP/1.1 200 OK Date: Wed, 24 Oct 2018 13:51:36 GMT Expires: -1 Cache-Control: private, max-age=0 Content-Type: text/html; charset=EUC-KR P3P: CP=”This is not a P3P policy! See g.co/p3phelp for more info.” Server: gws X-XSS-Protection: 1; mode=block X-Frame-Options: SAMEORIGIN Set-Cookie: 1P_JAR=2018-10-24-13; expires=Fri, 23-Nov-2018 13:51:36 GMT; path=/; domain=.google.co.kr

구성

NAT 디바이스를 이용해서 Private Subnet의 인스턴스가 인터넷에 접근하도록 할 수 있다. 외부 API 호출, 파일 다운로드, 패키지 업데이트등의 목적으로 사용한다. EC2 인스턴스는 인터넷에 연결하는 한편, 인터넷에서는 인스턴스로 접근하지 못하도록 할 수 있다.

VPC 확장

앞서 만든 VPC는 하나의 Public subnet과 하나의 Private subnet으로 구성된다. 연습삼아서 만들어 볼 만한 구성이지만, “가용영역이 빠져있기 때문에” 실제 서비스에 권장할 구성은 아니다. 그래서 가용영역을 포함한 구성으로 확장하기로 했다.

새로운 구성

기존 public subnet과 private subnet 구성에 가용 영역을 추가해서 총 4개의 서브넷이 만들어졌다. 가용 영역은 물리적으로 분산된 데이터센터이므로 더 높은 가용성을 확보 할 수 있게 됐다. 아래와 같이 서브넷을 만들었다.

서브넷을 만들고 Name도 읽기 쉽게 수정했다. 마지막으로 라우팅 테이블을 수정했다.

앞서 만들어둔 라우트테이블에 새로만든 subnet을 목적에 맞게 설정하면 된다.

  • test-c.joinc.private를 private-route-table에추가한다.
  • test-c.joinc.public를 public-route-table에 추가한다.

VPC Peering

개요

두 개의 VPC를 연결해서, 트래픽을 라우틸 할 수 있게 하는 네트워크 서비스다. VPC Peering된 VPC는 같은 네트워크인 것 처럼 서토 통신 할 수 있다. 다른 계정에서 만든 VPC, 다른 리전에 있는 VPC도 peering 할 수 있다.

다른 유저의 VPC를 peering 하려면, 해당 유저에게 VPC Peering 생성 요청을 보내고 이를 수락해줘야 한다. 여기에서는 단일 계정에서 같은 리전에 있는 2개의 VPC를 연결 할 것이다. 앞서 만든 joinc-vpc와 (계정 생성시 기본으로 제공하는)Default-vpc를 연결한다.

VPC Peering 설정

VPC 대시보드에서 Peering Connections를 선택해서 VPC Peering 설정을 시작한다.

  • peering connection name tag : Peering 의 이름
  • Select a local VPC to peer with : 내가 연결할 VPC로 joinc-vpc 다.
  • Select another VPC to peer with : 상대편 VPC다. 같은 계정에 같은 리전이므로 My account, This region을 선택했다.
  • Create peering connection을 클릭하면 연결이 만들어진다.
  • 결과 적으로 10.10.0.0/16과 172.31.0.0/16을 연결하게 된다.

현재 상태는 아래와 같다.

  • Name : Peering connection 이름
  • Peering Connection : Peering Connection ID
  • Status : Pending Acceptance 상태. 상대가 연결을 허락하기를 기다리고 있다.
  • Requester VPC : 요청자의 VPC ID
  • Accepter VPC : 상대편 VPC ID

내 계정에서 테스트를 했으므로, Action > Accept Request 를 클릭해서 Accept 해주면 된다.

이제 라우팅 테이블을 수정한다. 아래와 같이 수정해야 할 것이다.

DestinationTarget
yundream-vpc10.10.0.0/16local
172.31.0.0/16aws-study-peering
0.0.0.0/0igw 혹은 nat-gateway
Default-vpc172.31.0.0/16local
10.10.0.0/16aws-study-peering
0.0.0.0/0igw

테스트를 위해서 각 VPC에 두 개의 인스턴스를 만들었다. 구조는 아래와 같다.

연걸 테스트를 수행했다.

[ec2-user@ip-10-10-0-9 ~]$ ssh 172.31.0.102 The authenticity of host ‘172.31.0.102 (172.31.0.102)’ can’t be established. ECDSA key fingerprint is SHA256:kIVeruqglLC9zPvC4uehzbRyYI69y6EYAdSemGjQndw. ECDSA key fingerprint is MD5:bc:0e:bd:af:21:2f:29:9e:fa:42:cf:f0:2f:1c:59:8e. Are you sure you want to continue connecting (yes/no)?

지원되지 않는 VPC 피어링

겹치는 CIDR 블럭

일치하거나 중첩되는 IPV4 CIDR 블럭이 있는 VPC 간에는 VPC 피어링 연결을 만들 수 없다.

VPC에 여러 개의 IPv4 CIDR 블럭이 있을 경우, 중첩되는 CIDR 블럭이 있어도 VPC 피어링 연결을 만들 수 없다.

전이적 피어링

VPC B와 VPC C가 VPC A를 거쳐서 라우팅 할 수 없다. 이 경우 VPC B와 VPC C간에 피어링을 해야 한다.

게이트웨이 또는 프라이빗 연결을 통한 엣지 간 라우팅

역시 지원하지 않는다. VPC Peering은 Peering으로 연결된 두 개 VPC 만 라우팅이 가능하다고 생각하면 된다.

Private Link

AWS PrivateLink를 이용하면, 퍼블릭 네트워크의 경유없이 다른 계정의 VPC의 서비스에 안전하게 접근 할 수 있다. 예를 들어 클라이언트는 다른 VPC에 있는 로드밸런서, 인스턴스, 컨테이너에 접근 할 수 있다.

이런 기능은 SaaS와 같은 파트너 서비스의 구현에 특히 유용하다. AWS 마켓플레이스의 경우 AWS PrivateLink로 서비스를 사용하도록 할 수 있으며, 특정 엔드포인트로오는 프라이빗 연결을 종료 할 수도 있다.

  • AWS PrivateLink를 이용해서 안전하게 VPC를 AWS의 서비스에 연결할 수 있다. 인터넷을 통과하지 않으므로 DDoS, 무작위 대입 공격 등의 위협이 감소된다. Private subnet을 이용해서 연결할 경우, 비공개네트워크를 통해서 호스팅한 것 처럼 작동한다.
  • 기존 온프레미스 애플리케이션을 클라우드에 호스팅된 SaaS 형태로 안전하고 쉽게 마이그레이션 할 수 있다. 이 애플리케이션은 인터넷으로 부터 완전히 격리시킬 수 있기 때문에 중요 데이터의 인터넷 노출에 대한 걱정을 할 필요가 없다.
  • 인터넷 게이트웨이나 VPC 피어링을 구성할 필요가 없다.
카테고리: AWS Cloud 기초

댓글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다

Bitnami