AWS의 VPC에 대해 알아보자

VPC를 이해하기 위한 선수 지식

📌

초기 VPC 관련 내용은 모두 IPv4 기준으로 설명함을 인지하고 들어가자.

IP 주소는 32자리 2진수 이며, 총 개수는 약 40억개 정도 된다.

네트워크 주소 + 호스트 주소로 구성이 된다

IP를 8비트 기준 4등분 하게 된다면 각각 옥탯이라고 부른다.

옥탯 별로 IP의 클래스를 A, B, C로 나눌 수 있다.

1 0 1 0 1 1 0 0	1 0 1 0 1 0 0 0	0 0 0 0 1 0 1 0	0 0 0 0 0 0 0 1
172	168	10	1
Octet 1	Octet 2	Octet 3	Octet 4

A 클래스는 Octet1이 네트워크 아이디 이고, 나머지 옥탯들을 호스트의 아이디로 사용

B 클래스는 Octet2 까지를 네트워크 아이디로 사용

C 클래스는 Octet3 까지를 네트워크 아이디로 사용

C를 쓰기에는 네트워크 아이디 하나 당 사용할 수 있는 아이피가 적고, B는 많기 때문에 이 방법은 예전에 없어졌다.

이후 서브넷 마스크를 사용하게 됨

( A ⇒ /8, B ⇒ /16, C ⇒ /24 )

CIDR ( Classless Inter-Domain Routing )

📌

클래스 없는 도메인간 라우팅 기법 ( /XX 방식. 0~32 까지 표현이 가능 )

CIDR은 급격히 부족해지는 IPv4 주소를 보다 효율적으로 사용하게 한다.

표현형식은 xxx.xxx.xxx.xxx/yy 형태이며 맨 뒤의 yy는 서브넷 마스크를 2진수로 바꾸었을 때 1의 개수.

192.168.0.0/24 라면 옥텟 3까지가 24일테니, 그 이후부터인 25~32 비트를 사용할 수 있다는 것이다.

( 192.168.0.0 ~ 192.168.0.255 )

EXAMPLE

IP	FROM	TO
143.7.65.203/16	143.7.0.0	143.7.255.255
143.7.65.203/24	143.7.65.0	143.7.65.255
143.7.65.203/23	143.7.64.0	143.7.65.255

각 네트워크 대역을 구분 짓고, Inter-Domain과 같이 구분된 네트워크간통신을 위한 주소 체계라고 이해하면 좋다고 한다..

VPC의 작동 방식

📌

VPC는 사용자 AWS 계정 전용 가상 네트워크. IP 범위 주소는 서브넷이다. 이 둘은 CIDR 표기법을 따른다.

block 설정은 /16 ~ /28 이다.

각 Subnet CIDR block에서 첫 4개의 IP 주소와 마지막 IP 주소는 사용자가 사용할 수 없으므로 인스턴스에 할당할 수 없다.

10.0.0.0:네트워크 주소
10.0.0.1:AWS에서 VPC 라우터용으로 예약한 주소
10.0.0.2:AWS에서 예약한 주소 DNS 서버의 IP 주소
10.0.0.3:AWS에서 앞으로 사용하려고 예약한 주소
10.0.0.255:네트워크 브로드캐스트 주소. VPC에서는 브로드캐스트를 지원하지 않고 이 주소를 예약

AWS에서는 private IP의 사용을 추천하고 있기 때문에

10/8 prefix 172.16/12 prefix 192.168/16 prefix

세가지 대역을 최대한 사용하자

기본 VPC 구성 요소 단계

IPv4 CIDR /16 블록에 해당하는 VPC를 만든다. → xxx.xxx.0.0 ~ xxx.xxx.255.255 이기 때문에 총 2^16 = 65535개의 프라이빗 IPv4 주소를 제공 받는다

각 가용영역에 크기 /20의 기본 서브넷을 설정

인터넷 게이트웨이를 만들어 기본 VPC에 연결

네트워크 엑세스제어목록 (ACL)을 생성하여 기본 VPC에 연결

AWS 계정에서 설정된 기본 DHCP 옵션을 기본 VPC에 연결

가용 영역 ( AZ ) ?

우리는 각 지역. 즉 리전에 대한 개념을 알고 있다.

리전 안에서 가용 영역이라는 격리된 위치가 여러개 존재하는데, 그렇게 때문에 각 리전에서도 한쪽 영역이 문제가 생겼을 때 다른 한쪽의 도움을 받을 수 있는 구조가 가능하다. ELB를 붙여서 각 가용영역으로 트래픽을 분배해줄 수도 있다고 한다.

인터넷 게이트웨이

인터넷 게이트웨이는 VPC의 인스턴스와 인터넷간에 통신을 할 수 있게 해준다.

인터넷으로 데이터를 보내야 한다면, 당연히 인터넷 게이트웨이로 트래픽을 전달해야 한다.

이 라우팅을 서브넷의 라우팅 테이블에 추가해야 하는데, 서브넷이 인터넷 게이트웨이로 향하는 라우팅이 있는 경우를 퍼블릭 서브넷이라고 부른다.

어떤 서브넷이 인터넷 연결을 할 필요가 없다면 이 서브넷은 프라이빗 서브넷 이라고 한다.

NAT를 쓰게되면 프라이빗 서브넷의 인스턴스를 인터넷에 연결을 시킬 수 있지만 인터넷에서 해당 인스턴스로 접근하지 못하게 할 수 있다.

NAT 게이트웨이를 만드려면 이 게이트웨이가 속할 퍼블릭 서브넷을 만들어야 한다.

그리고 NAT 게이트웨이와 연결할 Elastic IP ( 탄력적 IP ) 도 지정해야 한다. 그리고 프라이빗 서브넷과 연결된 라우팅 테이블을 NAT 게이트웨이를 바라보게 해야 한다.

참고로 여러 가용영역에 NAT 게이트웨이를 하나를 공유하게 되면 NAT 게이트웨이 가용영역이 문제가 생겼을 때 다른쪽도 영향을 받는다. 이에 따라 가용영역 당 NAT 게이트웨이를 만들어야 한다.

위 그림에서, Private Subnet에서 yum repository 접근을 위해 해당 서브넷의 ACL의 경우 80포트의 NAT Gateway IP인 198.51.100.4 (source IP)가 아닌 Private IP를 Allow 시켜야 할 것 이다. ( private IP 써라 )

추가적으로 더 알아보자면, 데이터 센터를 디자인 할 때 네트워크 단에서 반드시 고려 하는 것이 Public / Private network 존을 나누는 것이라고 한다.

Public 존

외부와 통신이 직접적으로 필요
Web Server와 같은 Front-end layer

Private

외부와의 통신이 직접적으로 필요하지 않음
Back-end, DB ( RDS도 이래서 여기에 있어야겠지..? )

논외…!

조금 검색을 해보니, NAT gateway와 Bastion host 라는 친구가 조금 뜻이 겹치는 것으로 이해 되어, 정리를 조금 해놓고 넘어가려 한다.

NAT gateway

private subnet에 위치한 instance가 다른 AWS 서비스에 연결해야 하는 경우 ( 이것이 바로 VPC 피어링 이겠지…? )
인터넷에서 Private instance에 접근 불가 조건은 유지하면서 반대로 instance에서 외부 인터넷으로 연결이 필요한 경우

Bastion Host

Private Subnet에 배포된 instance의 경우 외부에서 접근이 차단되어 있기 때문에 ( ACL ), SSH로 접근할 수 있는 방법이 없다. ⇒ Bastion host
Proxy 역할의 서버

Bastion host도 Public Subnet에 위치를 하게 하여 EC2 instance에 생성하는 듯 하다..

인바운드 규칙을 통해 특정 IP만 열어두고 사용할 수 있도록 ACL, 보안그룹을 설정한다

Bastion host를 통해 Private Subnet에 상주한 instance로 접근

추가로 SSH Tunneling을 이용해서 외부에서 Private instnace에 접속하는 방법또한 있다고 한다.

-L 을 사용해서 SSH를 접속해놓은 상태로 터미널을 하나 더 열어 접속하는 방법이 있다고 하는데, 나중에 알아보도록 하자..

네트워크 액세스 ( ACL ) 제어 목록

📌

1개 이상의 서브넷 내부와 외부 트래픽을 제어하기 위한 방화벽 역할

NAT Gateway 통신을 위해서 Network ACL 을 설정해야 한다고 한다.

EC2에서 보안그룹을 생성할 수 있듯, VPC 에서도 보안을 생성할 수 있다. 이것이 바로 ACL 이다.

보안 그룹

인스턴스 레벨에서 운영

허용 규칙만 지원 ( 어떤 ip 대역을 허용할지 )

인스턴스 시작시 지정하거나 보안그룹을 나중에 인스턴스와 연결해야 적용 됨

네트워크 ACL

서브넷 레벨에서 운영

허용 규칙과 거부 규칙 지원

연결된 서브넷의 모든 인스턴스에 자동 적용

위 이미지에서 ACL부터 보자. 172.31.1.2/32 라는 특정 ip만 제외하고 다른 모든 트래픽은 막아져있다.

그러므로 저 서브넷은 한 ip만이 접근 가능하다. 아웃바운드 규칙 또한 마찬가지이다.

인스턴스의 보안 그룹 규칙을 보면, SSH 연결은 ACL 에서 허용 된 ip가 허용 되어있고, 모든 트래픽이 허용되어있다. 즉 서브넷 안에서는 자유롭게 통신이 가능하며 외부는 172.31.1.2/32 ip를 제외하고 모두 차단하는 형태이다.

DHCP ( Dynamic Host Configuration Protocol )

동적 호스트 설정 프로토콜. IP를 필요로 하는 컴퓨터에게 자동으로 할당해주고, 사용하지 않으면 반환해서 다른 컴퓨터가 사용할 수 있게 해줌

AWS 에서는 최대 4개의 자체 DNS 서버를 사용할 수 있다. 그렇게 하려면 VPC와 함께 사용할 DHCP 옵션을 지정해야 한다.

지정할 수 있는 옵션 값

domain-name-servers

domain-name

ntp-servers

netbios-name-servers

netbios-note-type

Flow log

VPC 내 트래픽에 대한 로그 정보를 수집하는 기능이라고 한다.

instance에 유입되는 트래픽을 모니터링

ACL로 인해 예기치 않은 통신 두절 상황에서 Trouble shooting 도구로 사용이 가능

⇒ CloudWatch Log를 사용하여 저장하게 된다.

TODO

VPC Flow log를 위한 CloudWatch의 Log group 생성

생성한 Log group에 log stream을 사용할 수 있는 IAM role 권한 지정

VPC 피어링 ( Peering )

피어링 개본 개념

VPC 간에 트래픽을 라우팅할 수 있도록 한다.

게이트웨이 / VPN 커넥션과 상관이 전혀 없으며 Single Point of Failure나 대역폭 병목도 문제가 없음

AWS 계정이 두 개 이상인 경우 두 계정 리소스간 통신이 필요한 경우 사용할 수 있다.

요청자 VPC가 수락자 VPC에게 피어링 연결을 요청

요청자 VPC의 CIDR 블럭과 중첩되는 CIDR 블럭은 사용할 수 없음

수락자 VPC의 소유자가 피어링 연결을 수락

프라이빗 IP 주소를 사용해서 피어링 하는 경우 각 VPC 소유자가 다른 VPC의 IP 를 가리키는 경로를 하나 이상의 VPC 라우팅 테이블에 수동으로 추가해야 한다.

VPC에서 주고받는 트래픽이 제한이 되는경우 인스턴스의 보안그룹(Security Group)을 업데이트합니다.

피어링 연결 수명 주기

initiating request - 피어링 연결 요청

실패 or pending acceptance

Pending acceptance - 승인 대기

보내는 사람이나 받는 사람이 취소할 수 있음. 조치를 취하지 않으면 7일 후 expired

Provisioning - 수락자가 수락한 경우

Active - 아무나 연결을 끊을 수 있음

피어링을 통해서 연결 다리 용도로는 사용할 수 없음

IPv6 서브넷

이건 추후에 더 알아보는 것으로 하자..

IPv6 주소 지정을 지원하는 VPC - Amazon Virtual Private Cloud

Amazon VPC를 사용하여 AWS 클라우드에서 논리적으로 격리된 영역인 가상 네트워크에서 AWS 리소스를 시작할 수 있습니다.

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/get-started-ipv6.html

References

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/VPC_Scenario2.html