AWS가 제공해주는 VPC 서비스에 대해서 알아보자.
VPC란 무엇인가?
VPC 는 Amazon Virtual Private Cloud 의 약자로, aws 계정 사용자 전용 네트워크입니다.
컴퓨터 공학에서 Virtual 이라는 의미는 하드웨어를 소프트웨어로 가상화한것을 의미합니다.
계정 사용자는 본인이 원하는대로 네트워크를 설정할 수 있는데, 이 때 실제 물리적인 장비들을 조절하는게 아니라 소프트웨어로 가상화된 장비들을 조절함으로써 본인이 원하는 네트워크를 만들 수 있도록 추상화되어있습니다.
또한 여러개의 VPC를 구성함으로써 네트워크 대역들을 손쉽게 나눌 수 있습니다.
VPC로 네트워크 대역을 나누지 않는다면, 모든 인스턴스들이 거미줄처럼 엮여있어 복잡도가 매우 높을 것 입니다. 그러나 VPC가 도입된 이후로 VPC별로 필요한 설정을 적용함으로써 네트워크를 단순화할 수 있게 되었습니다.
아래 그림은 VPC가 없어서 인스턴스간의 강하게 엮여있는 그림입니다. 
출처
아래 그림은 VPC으로 인해 단순화된 네트워크를 나타내는 그림입니다. 
출처
CIDR
이제 VPC가 왜 필요한지는 알게되었고, 본격적으로 알아가기 이전에 CIDR에 대해서 간단하게 상기해봅니다.
CIDR이란 IP주소를 효율적으로 할당하고 관리하기 위한 방식입니다.
기본적으로 IP주소/CIDR 접두사 길이와 같이 표현됩니다.
192.168.32.1/24 를 예시로 설명하면 /24 가 CIDR 인데, ipv4 에서 32비트중에 24비트가 네트워크 주소를 나타내고, 나머지 8비트 만큼을 호스트 주소로 사용하겠다는 의미입니다.
즉 해당 예시에서는 192.168.32.0 ~ 192.168.32.255 네트워크 대역을 의미합니다.
기본 VPC
VPC의 네트워크 대역은 기본적으로 private 입니다. VPC를 생성할 때 CIDR 블록을 설정하며 private IP주소의 범위를 지정합니다.
이렇게 설정된 IP주소들은 VPC내에서만 유효하며, 외부 인터넷과는 직접 통신할 수 없습니다.
인터넷과 통신하기 위해서는 internet gateway 필수적으로 필요합니다.
VPC안에서도 CIDR 블록을 이용해 서브넷이라는 네트워크 대역을 생성합니다.
EC2와 같은 서비스들은 서브넷에 존재하는데, private ip를 할당받아서 서로 통신합니다. 이 때, 라우팅 테이블을 통해서 서로 다른 subnet의 ec2간에도 통신이 가능합니다.
VPC 안이 아니라, 아래 그림의 AWS Cloud 안쪽이나, 외부에 존재하는 시스템에는 전부 인터넷을 통해서 접근해야합니다.
즉 subnet A의 인스턴스가 S3에 접근하려면 라우팅테이블을 통해서 IGW로 갔다가 VPC를 나가서 인터넷을 거쳐 S3에 도달해야합니다.
VPC 내부 구성요소
VPC 내부를 조금 더 자세하게 살펴봅니다.
위 그림을 보면, VPC에서 CIDR를 통해서 분배된 subnet 2개가 보입니다. 참고로 subnet들은 서로 네트워크 대역이 겹칠 수 없습니다.
ENI라는 네트워크 인터페이스를 가상화한 엔티티가 subnet의 ip를 부여받고 EC2가 여기에 매핑됩니다. 앞서서 말씀드렸지만, 가상화란 하드웨어를 소프트웨어로 만든것이라고 이해하면 됩니다.
그리고 ENI는 보안그룹에 매핑됩니다. 이 보안그룹은 특정 요청만 허용을 해주는 필터 역할을 하는데, stateful하기 때문에 인바운드 또는 아웃바운드에서 하나가 통과되면 나머지는 자동으로 통과됩니다.
그리고 subnet에서 나와 라우팅 테이블 사이에 NACL이라는 방화벽이 존재합니다. NACL은 stateless하기 때문에 인바운드와 아웃바운드 둘 다 통과해야합니다.
다음으로 라우팅 테이블은 VPC 내부의 요청을 local로 보내고, 그 이외에는 인터넷게이트웨이 보내도록 레코드를 설정하면, public 인스턴스는 인터넷에서 접근이 가능하지만 private 인스턴스는 내부망에서만 요청이 보낼 수 있습니다.
vpc 네트워크 대역이 172.31.0.0/16 이라고하면 아래처럼 됩니다. 인터넷에서 들어오는 요청은 IGW로 보내고, 인터넷으로 나가는 요청도 IGW로 보내게됩니다. 
추가적으로 private 인스턴스가 인터넷에서 들어오는 요청은 거부하고, 인터넷으로 나가는 아웃바운드 요청만 보낼 수 있게 설정하고싶다면 NAT 게이트웨이를 설정하면 됩니다.
VPC Security Group & NACL
VPC에서 특정 네트워크에서 오는 트래픽을 제어할 수 있는 방화벽이 대표적으로 Security Group / Network ACL 2가지 있습니다.
subnet에 매핑된게 NACL이며 instance에 바로 매핑된게 Security Group 입니다. 
Security Group 은 stateful하기 때문에 인바운드에서 통과된다면 아웃바운드는 자동적으로 통과됩니다. 반대의 경우도 마찬가지입니다.
하지만 NACL은 stateless하기 때문에 양쪽에서 전부 통과되어야합니다.
우리가 자바 프로세스와 같은 애플리케이션을 실행하면 보통 8080 포트를 리슨하고 있는데, 아웃바운드로 요청이 나갈때는 8080 포트를 사용하는게 아니라 운영체제가 휘발성 포트를 랜덤하게 설정해줍니다.
그렇기 때문에 NAT를 통해서 private subnet에서 아웃바운드 요청을 보내려고한다면, 보안그룹과 NACL 둘 다 아웃바운드 규칙에서 모든 포트를 열어주어야합니다.
기본적으로 보안그룹과 NACL을 만들면 기본 셋팅이 아웃바운드 요청은 전부 허용되어있습니다.
VPC Internet Gateway
기본적으로 AWS 의 IGW는 자동으로 수평 확장되므로 트래픽이 늘어난다고해서 IGW에 대한 걱정은 하지 않아도됩니다.
인터넷 게이트웨이는 NAT도 수행합니다. 여기서의 NAT는 VPC 내부에서는 private IP로만 통신하기 때문에, 인터넷에서 인스턴스의 public 또는 탄력적 IP로 접근할 때 private IP로 라우팅해주는 역할을 합니다.
참고로 IPv6의 경우 모든 IP가 public이므로 해당 NAT가 필요없습니다.
VPC NAT Gateway
NAT 게이트웨이는 NAT 서비스입니다. 프라이빗 서브넷의 인스턴스가 VPC 외부의 서비스에 연결할 수 있지만, 외부 서비스에서 해당 인스턴스에 연결을 시작할 수 없도록 NAT 게이트웨이를 사용할 수 있습니다.
VPC Peering
VPC간에는 기본적으로 통신이 불가능합니다. VPC 피어링이란 두 VPC간에 트래픽을 라우팅할 수 있도록 하기 위한 VPC 사이의 네트워킹 연결입니다.
피어링된 VPC의 리소스는 동일한 네트워크 내에 있는 것 처럼 서로 통신할 수 있습니다. 제약사항으로는 일대일로 통신만 가능합니다. 즉 A와 B가 통신하고 A와 C가 통신한다고 했을 때, B는 C와 통신할 수 없습니다.
이 때, VPC 피어링을 통한 트래픽은 인터넷을 통과하지않고 프라이빗 IP주소를 사용하여 서로 통신합니다.
AWS PrivateLink
VPC간에 연결하는 기술은 VPC Peering 이고 VPC와 다른 서비스를 연결하는 기술은 AWS PrivateLink 입니다.
위에서 설명한것과 같이, VPC 내부의 인스턴스가 S3와 같은 VPC 외부의 AWS 서비스와 통신하려면 인터넷을 꼭 거쳐야했습니다.
하지만, AWS PrivateLink는 인터넷이 아니라 private 하게 통신이 가능하도록 합니다.
AWS PrivateLink가 기술 이름이고, 기술을 구현한 서비스 종류가 2가지 존재합니다.
하나는 VPC endpoint이고, 하나는 endpoint service 입니다.
VPC endpoint
실제로 AWS PrivateLink 보다 VPC Endpoint라는 이름으로 주로 불립니다.
VPC endpoint 종류 중 하나인 Gateway endpoint에 대해서 먼저 알아보겠습니다.
- VPC endpoint
- AWS 서비스나 엔드포인트 서비스에 접근하기 위한것으로 아래 종류가 3가지 존재합니다.
- gateway endpoint
- interface endpoint
- gateway load balancer endpoint
- AWS 서비스나 엔드포인트 서비스에 접근하기 위한것으로 아래 종류가 3가지 존재합니다.
Gateway endpoint는 s3와 dynamodb에만 접근할 수 있습니다.
기존에는 ec2가 s3에 접근하기 위해서는, 라우팅 테이블을 통해서 IGW에서 인터넷으로 요청이 나갔다가 S3로 들어가야했습니다.
하지만 Gateway endpoint를 사용하고, 라우팅 테이블에 s3로 요청을 보낼때 Gateway endpoint 로 라우팅하는 레코드를 추가하면 내부망에서 접근할 수 있습니다.
아래 사진에서 라우팅 테이블 레코드의 pi-id for S3 vpce-id 가 s3로 접근할때 vpc endpoint를 경유해서 s3에 접근하도록 라우팅합니다. 
다음으로는 Interface Endpoint입니다. Gateway endpoint와 다르게 Interface endpoint는 지원하는 여러 AWS서비스들에 접근이 가능합니다.(그렇다고 모든 서비스는 아닙니다)
그리고 라우팅 테이블을 통해서 트래픽을 라우팅하는게 아니라 서브넷에 eni를 생성하고 이를 통해서 라우팅합니다.
그렇다면 둘 다 S3나 DynamoDB에 인터넷을 거치지않고 접근할 수 있도록 도와주는데, 어떤 차이점이 있을까요?
| Gateway endpoint | Interface endpoint |
|---|---|
| s3의 public ip 로 요청을 보내고 routing table을 통해서 해당 요청이 인터넷이 아니라 endpoint를 경유해서 가도록 라우팅합니다. | eni를 하나 서브넷안에 생성해서 ec2가 해당 eni에 요청을 보내기만하면 나머지는 aws가 알아서 s3로 라우팅해줍니다. |
| s3, dynamodb로의 요청만 사용할수 있습니다. | 온프레미스와 AWS의 다양한 서비스들에게 사용 가능합니다. 다만 AWS가 지원하는 서비스에 제한되며, 모든 서비스는 아닙니다. |
| VPC Peering을 통해 다른 리전의 리소스와 통신할 수는 있습니다만, 기본 설정에서는 그렇지 않습니다. | 다른 리전도 접근 가능합니다. |
| 무료입니다. 따라서 s3 private 연결은 대부분 Gateway endpoint를 사용합니다. | 유로입니다. 추가적인 ENI를 만드는것이므로 비용이 발생합니다. 온프레미스로 데이터를 전송하는데에는 추가적인 비용이 듭니다. |
Endpoint Service
자 다시 돌아와서 AWS privatelink 기술에 2가지가 있다고 말씀드렸는데, VPC endpoint외에 나머지 하나인 endpoint service에 대해서 살펴보겠습니다.
- Endpoint service(얘를 privatelink 라고 부르기도 한다)
- 주로 서비스 제공자 입장에서 사용합니다.
- 제공하고자 하는 서비스에 대한 엔드포인트를 만들어서 다른 vpc나 네트워크에서 접근할 수 있게 해주는 서비스입니다.
- 예를 들어서 개발자가 자신이 만든 API를 다른 고객들이 프라이빗하게 사용할 수 있도록 하려면 엔드포인트 서비스를 구성합니다.
특정 서비스를 만들어서 고객에게 private 네트워크 망에서 통신하도록 제공해준다고 가정해봅니다.
아래 그림에서 왼쪽이 고객의 ec2이고 오른쪽이 우리가 만든 특정 서비스를 운영하는 ec2입니다.
인터넷을 통한 트래픽은 보안상의 위험이 있기 때문에 불가하다면 어떻게 해야할까요?
위 그림처럼 VPC peering을 사용할수도 있을 것 같습니다.
하지만 점점 많은 고객들이 생겨난다면 서비스제공해주는 입장에서는 VPC peering을 계속해서 만들어야합니다.
고객이 1000명이 된다면 1000개의 vpc peering을 만들어야합니다. 이는 유지보수 관점에서 매우 비효율적입니다.
이런 경우에 endpoint service를 사용하게 됩니다.
서비스 제공업체는 ec2 인스턴스 앞에 로드밸런서를 생성한뒤, 로드밸런서를 endpoint service로 만듭니다.
그러면 고객들은 각자 vpc에 interface endpoint를 만들고, 해당 인터페이스를 통해서 서비스 제공업체의 endpoint service에 접근하면 됩니다. (참고로 고객과 제공업체의 리전이 같아야합니다) 
종합해보면 AWS PrivateLink 는 아래 그림처럼 표현할 수 있습니다. ProviderVPC의 로드밸런서는 endpoint service로 설정된것입니다.
AWS VPN
VPN이란 인터넷을 통해 가상의 사설망을 구성하는것입니다.
실제로 사설망을 구현한것은 아니고, 데이터를 암호화하여 도착 호스트가 아닌곳에서는 해당 데이터를 볼 수 없도록 만드는것입니다.
어찌됐건 목적은 두 네트워크의 안전한 통신을 만들어주는것입니다.
AWS 에서 제공해주는 VPN 서비스의 옵션은 2가지가 존재합니다.
- site to site vpn
- client vpn
그렇다면 간략하게 먼저 site to site vpn에 대해서 알아보겠습니다.
먼저 각 네트워크의 라우터는 서로 통신하여 어떤 알고리즘을 사용할지 결정하고 키를 교환합니다.
그리고 IPSec과 같은 프로토콜을 통해서 암호화된 데이터를 전송합니다. 이때 암호화, 복호화는 vpn gateway가 수행합니다.
vpn은 ssl과는 다르게 ip계층에서 동작하며 ip layer의 데이터까지 암호화합니다. 헤더의 도착지 ip주소는 라우팅되어야하므로 암호화하지않거나, vpn gateway 주소로 바꾸기도 합니다. 주로 네트워크간의 vpn을 사용할때 이용됩니다.
먼저 VPC에 VGW(virtual private gateway)가 존재합니다. virtual private gateway는 VPC안에ㅔ서 외부 네트워크(온프레미스) 사이의 VPN 연결을 가능하게 하는 엔드포인트입니다.
그리고 외부 네트워크의 VPN 엔드포인트는 Custmer gateway입니다. 이것은 고객의 실제 라우터 또는 VPN 장비에 대한 AWS에서 사용하는 인터페이스입니다. 그래서 생성시에 고객의 실제 VPN 장비 주소를 적어줘야합니다. 그래야 고객의 VPN 장비로의 트래픽을 전달할 수 있습니다.
그리고 AWS Customer Gateway는 가상의 게이트웨이로 VPN 연결을 수립할 때 이용됩니다. 
이번에는 client vpn에 대해서 알아보겠습니다.
client vpn은 네트워크간의 사설망을 가상화하는게 아니라, 개인 디바이스와의 사설망을 가상화합니다.
또한 개인 AWS가 제공해주는 client vpn은 프로토콜이 ssl이기 때문에 전송계층에서 동작하며, ip 출발지까지 암호화해주지는 않습니다.
client는 vpn 접속을 위한 vpn 구성 파일이 담긴 소프트웨어를 설치해야합니다. 그리고 VPC의 Client VPN Endpoint와 통신합니다. 
AWS Direct Connect
AWS Direct Connect는 AWS와 온프레미스간에 전용선을 통해 프라이빗 네트워크 연결을 생성하는것 입니다.
VPN은 인터넷을 통해서 사설 네트워크망을 가상화하는것이었지만, Direct Connect는 실제 사설 네트워크망을 구축하는것입니다.
아래 사진에서 Direct Connect Location은 KT, SKT, LG와 같은 통신사입니다. 왼쪽 부분은 AWS가 관리를하고 오른쪽 부분은 고객과 통신사가 관리합니다.
먼저 AWS 서버실에서 AWS Direct Connect 접속 지점으로 트래픽을 보냅니다. AWS Direct Connect 접속 지점은 전 세계의 다양한 데이터 센터에 설치되어 있습니다. 리전의 데이터센터보다 더 많이 존재합니다.
그리고 AWS Direct Connect은 통신사까지 전용망으로 연결되어있습니다. 그리고 통신사는 다시 고객에게 전용선으로 트래픽을 전달합니다.
안정적인 내부망을 이용할 수 있다는 장점도 있지만, 단점으로는 물리적인 설치를 해야하므로 오랜 시간이 걸리며 가격도 vpn보다 비쌉니다. 그리고 기본적으로 암호화를 제공하지 않습니다. 
AWS Transit GateWay
위에서 VPC Peering에서는 일대일로만 통신이 가능하다고 알아봤습니다.
아래 그림을 통해서 VPC Peering의 한계에 대해서 알아보면, 먼저 VPC C에만 VPN이 설정되어 있으므로 VPC A, VPC B는 따로 VPN을 설치하거나 VPC C를 통해서만이 온프레미스와 통신이 가능합니다.
그리고 VPC A,C는 VPC D,E와 통신이 불가능합니다. VPC들이 VPC Peering으로 전부 통신이 가능하도록 하려면 매우 복잡한 구성이 필요합니다. 
이를 위해서 AWS Transit GateWay를 사용합니다. 아래 그림과 같이 앞단에서 api gateway와 같이 transit gateway를 설정해두면 모든 VPC들이 온프레미스로 VPN을 통해서 통신이 가능합니다.
또한 transit gateway들간에도 통신이 가능합니다. 
