Virtual Private Cloud(VPC) 쉽게 이해하기 #4

앞서 VPC와 Network 쉽게 이해하기 #3 문서에서 VPC와 Subnet은 AWS 계정의 사설 네트워크를 구성하고 각종 서비스들을 탑재할 수 있다고 언급하였습니다. 서비스들의 트래픽이 지나다는 곳인 만큼 트래픽에 대한 제어와 통제, 확인이 반드시 필요합니다.

 

이번 문서에서는 VPC의 트래픽을 통제하고 제어하는 서비스들과 트래픽의 흐름을 기록하는 서비스에 대해 살펴보겠습니다. Security Group, Network ACL, VPC FLow Logs입니다. 이 3가지 요소는 VPC를 이해하는 데 있어 매우 중요한 요소들이므로 자세히 보시면 좋을 것 같습니다. 익숙해지면 매우 편리한 서비스이지만 처음 볼 땐 매우 헷갈려하는 요소이기 때문에 확실히 아는 것이 중요합니다.

 

아래 그림은 VPC를 도식화한 것입니다. 지난 문서에서 다루었던 Internet gateway, Route table, Subnet, VPC Router가 보이네요. 그런데 중간중간마다 자물쇠로 채워진 요소들이 보이시나요? 

<Network ACL과 Security Group(출처 : AWS 기술 설명서)>

 

Route table 아래 자물쇠가 채워진 첫 번째 상자는 Network ACL입니다. Subnet을 오가는 트래픽을 제어하는 역할을 합니다. 그렇기에 그림에서 Subnet 상자 위에 위치한 것을 볼 수 있습니다. 

 

두 번째 상자는 Subnet 내부에 위치한 Security Group입니다. Subnet 내 인스턴스의 트래픽을 제어할 수 있습니다. 왼쪽 Subnet과 오른쪽 Subnet의 Security Group이 모양이 조금 다릅니다. 다수의 인스턴스가 하나의 Securiy Group을 쓰거나, 각자의 Security group을 쓸 수 있음을 의미합니다.

 

세 번째로 그림에는 나와있지 않지만 VPC Flow Logs입니다. VPC 내에 있는 Resource들은 Elastic Network Interface(ENI), 네트워크 인터페이스를 가지는데요. Network Interface에 VPC Flow Logs를 설정하면 Elastic Network Interface(ENI)를 지나다니는 IP 트래픽을 수집할 수 있습니다. 

 

여기까지가 3가지 서비스의 개요입니다. 이제부터는 각 서비스의 특징에 대해 자세히 알아보도록 하겠습니다.

 

Security Group(보안그룹)

보안 그룹은 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽 역할을 합니다. VPC에서 인스턴스를 시작할 때 최대 5개의 보안 그룹에 인스턴스를 할당할 수 있습니다.

보안 그룹은 서브넷 수준이 아니라 인스턴스 수준에서 작동하므로 VPC에 있는 서브넷의 각 인스턴스를 서로 다른 보안 그룹 세트에 할당할 수 있습니다.

- 출처 : AWS VPC 설명서 - 

위의 설명처럼 Security Group은 인스턴스의 가상 방화벽 역할을 합니다. 여기서 말하는 인스턴스는 EC2 인스턴스뿐만 아니라 VPC 내에 탑재될 수 있는 수많은 가상 컴퓨터를 의미합니다. 그러므로 EC2, RDS, ELB, VPC Interface Endpoint 등도 포함될 수 있습니다. 다른 말로 표현하면 VPC 내에서 Elastic Network Inteface(ENI)를 갖는 모든 서비스라고 할 수 있습니다. 정확히 말하면 Security Group은 인스턴스의 ENI에 적용되는 것이기 때문입니다. 또한 인바운드 규칙(외부 - > 인스턴스)과 아웃바운드 규칙(인스턴스 - > 외부)으로 나뉘며 모든 트래픽은 규칙에 따라 제어됩니다.

 

<Security Group의 인바운드 규칙>

<Security Group의 아웃바운드 규칙>

 

위 두 사진은 제가 사용 중인 Public Subnet 내 EC2 인스턴스의 Security Group입니다. 프로토콜 유형과 포트, IP 등을 지정할 수 있습니다. Public Subnet 내의 EC2 인스턴스는 웹 서비스를 제공하기 때문에 HTTP와 HTTPS를 접속할 수 있도록 허용하였고, EC2 인스턴스로의 직접 접속을 위해 SSH도 열어두었습니다. 아웃바운드는 EC2에서 출발하는 모든 트래픽을 의미하므로 모두 허용해두었습니다. 제 EC2 인스턴스에는 HTTP/HTTPS/SSH 트래픽만 허용됩니다.

 

이를 기반으로 Security Group은 몇 가지 특징을 갖는데 열거해보면 다음과 같습니다.

 

1. 인바운드 규칙과 아웃바운드 규칙으로 나뉨
2. 허용 규칙만 생성 가능
3. 기본적으로 모든 Security Group의 아웃바운드 규칙은 모든 아웃바운드 트래픽 허용
4. 하나의 인스턴스에는 최대 5개의 Security Group 동시 적용 가능
5. 상태를 저장하여 한 번 인바운드를 통과하는 트래픽은 아웃바운드의 규칙 적용을 받지 않음(Stateful)
6. 상태를 저장하여 한 번 아웃바운드를 통과하는 트래픽은 인바운드의 규칙 적용을 받지 않음(Stateful)

 

5번과 6번이 Securiy Group의 가장 큰 특징이라고 할 수 있겠습니다. 이를 Stateful이라 합니다. 제가 사용 중인 Security Group을 보면 HTTP/HTTPS/SSH의 허용은 인바운드에만 적용되어있습니다. 외부에서 들어오는 트래픽은 아웃바운드의 규칙을 전혀 적용받지 않기 때문에 인바운드에만 허용시켜두면 3개 프로토콜 트래픽의 왕래는 전혀 문제가 없습니다.

 

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

네트워크 ACL(액세스 제어 목록)은 1개 이상의 서브넷 내부와 외부의 트래픽을 제어하기 위한 방화벽 역할을 하는 VPC를 위한 선택적 보안 계층입니다. 보안 그룹과 비슷한 규칙으로 네트워크 ACL을 설정하여 VPC에 보안 계층을 더 추가할 수 있습니다.

- 출처 : AWS VPC 설명서 -

위의 설명처럼 Network ACL은 Subnet의 Access List(접근 제어 목록)을 책임집니다. Cisco Network Device를 다루어보셨다면 익숙한 이름일겁니다. Subnet을 오고 가는 모든 트래픽을 제어하는 역할을 합니다. Network ACL은 Subnet 단위로 적용되기 때문에 Subnet 내의 모든 트래픽은 Network ACL의 규칙 적용을 받습니다. 

 

<Network ACL의 인바운드 규칙>

<Network ACL의 아웃바운드 규칙>

위 두 사진은 제가 사용중인 Public Subnet의 Network ACL입니다. Security Group과 달리 '규칙' 값이 존재하고 허용/거부 항목이 눈에 띕니다. Security Group과 달리 별다른 규칙을 정해두지 않았습니다. 저의 경우 서비스가 워낙 단순하기 때문에 이렇게 해두었지만 Network ACL의 다양한 특징을 갖고 있습니다. 이를 열거하면 다음과 같습니다.

 

1. 인바운드 규칙과 아웃바운드 규칙으로 나뉨
2. 허용 규칙뿐만 아니라 거부 규칙 생성 가능
3. 규칙에 값이 매겨져 가장 작은 값을 지니는 규칙이 우선적으로 적용됨
4. 하나의 Subnet에는 하나의 Network ACL만이 적용됨
5. 상태를 저장하지 않아 한 번 인바운드를 통과하는 트래픽은 아웃바운드의 규칙 적용을 받음(Stateless)
6. 상태를 저장하지 않아 한 번 아웃바운드를 통과하는 트래픽은 인바운드의 규칙 적용을 받음(Stateless)

 

Security Group처럼 5번과 6번이 Network ACL의 가장 큰 특징이라고 할 수 있겠습니다. Stateless라고 부릅니다. 인바운드 규칙을 적용받아 유입된 패킷이 다시 밖으로 나가기 위해서는 아웃바운드 규칙의 적용을 받아야 합니다. 또한 모든 규칙이 적용되는 Security Group과 달리 Network ACL은 규칙 순서가 있어 가장 작은 규칙 값을 갖는 규칙이 가장 먼저 적용되는 특징이 존재합니다.

 

어떻게 사용하는 것이 좋을까?

제 개인적 소견으로는 Security Group과 Network ACL은 다음과 같이 사용되는게 바람직하다고 봅니다.

1. Security Group을 사용해 각 인스턴스에 허용되어야 할 프로토콜과 포트를 각각 지정함(IP는 지정하지 않음)
2. Network ACL을 사용해 모든 트래픽을 허용하되, 차단할 필요가 있는 IP 차단

프로토콜과 포트 설정을 Security Group에 전적으로 맡겨 각 인스턴스에 필요한 규칙을 서비스 특성에 맞춰 설정하고, Network ACL은 프로토콜과 포트 설정에 관여하지 않고 트래픽을 허용하되, 악의적 트래픽이 의심되는 IP를 규칙 값을 이용해 우선적으로 차단하여 관리의 효율을 높인다고 생각합니다.

 

마지막으로 Security Group과 Network ACL을 비교한 AWS VPC 설명서의 표를 가져왔습니다.

 

<Security Group vs Network ACL>

 

VPC Flow Logs

VPC, 서브넷 또는 네트워크 인터페이스에 대한 흐름 로그를 생성할 수 있습니다. 서브넷이나 VPC에 대한 흐름 로그를 생성할 경우, VPC 또는 서브넷의 각 네트워크 인터페이스가 모니터링됩니다.

- 출처 : AWS VPC 설명서 -

VPC 내 Resource들은 Elastic Network Interface(ENI)를 갖는다고 위에서 설명하였습니다. 그리고 이 ENI를 통해 트래픽이 흐릅니다. VPC Flow Logs는 VPC, Subnet, ENI에 흐르는 IP 트래픽을 수집하는 역할을 하며 NAT Gateway, Internet Gateway에 대한 트래픽 수집도 가능합니다.

 

VPC Flow Logs 설정은 VPC 단위로 가능합니다. 트래픽을 선별적으로 수집할 수 있어 허용/거부/모든 트래픽을 지정할 수 있고 Cloudwatch Logs 혹은 S3로 전송이 가능합니다. 이 경우에는 요금이 발생할 수 있습니다.

 

<VPC Flow Logs의 예시>

저 같은 경우, 인스턴스에 제대로 트래픽이 들어오지 않는다고 의심되거나 Security Group이 제대로 적용되어있는지를 확인하기 위해 VPC Flow Logs를 사용합니다.  또한 다음과 같은 트래픽은 VPC Flow Logs에 기록되지 않으므로 주의해야 합니다.

 

1. 인스턴스가 Amazon DNS 서버에 연결할 때 생성한 트래픽
2. Amazon Windows 라이선스 인증을 위해 Windows 인스턴스에서 생성한 트래픽
3. 인스턴스 메타데이터를 위해 169.254.169.254와 주고받는 트래픽
4. Amazon Time Sync Service를 위해 169.254.169.123과 주고받는 트래픽
5. DHCP 트래픽
6. 기본 VPC 라우터의 예약된 IP 주소로 보내는 트래픽

 

VPC의 트래픽에 관여하는 3대장에 대해 알아보았습니다. VPC를 처음 접하는 분들이 가장 많이 실수하는 부분이 Security Group / Network ACL이니 확실히 알아두고 가는 것이 좋습니다. 다음 문서에서는 VPC Endpoint에 대해 알아보겠습니다!