1. Virtual Private Cloud (VPC) 개념
✅ Amazon VPC
AWS(Amazon Web Services)의 전체 인프라스트럭처는 보안 시설로서 클라우드에서 실행되는 사용자의 모든 자원은 높은 보안성을 보장받을 수 있다. 이는 기본적으로 AWS를 사용하는 모든 기업들이 보장받을 수 있는 안정성이다. 이에 Amazon VPC를 구축해서 사용자 수준에서 보안의 수준을 높일 수 있다.
VPC(Virtual Private Cloud)는 클라우드 환경을 퍼블릭과 프라이빗의 논리적으로 독립된 네트워크 영역으로 분리할 수 있게 해준다. 어떤 리소스라도 논리적으로 분리된 영역에 격리할 수 있으며, 사용자가 네트워크 환경 설정에 대한 완전한 통제권을 가질 수 있다.
이는 사용자가 Amazon VPC를 통해 만든 네트워크에서 자체 IP 주소, 퍼블릭 및 프라이빗 서브넷, 라우트 테이블, 네트워크 게이트웨이 등 모든 기능을 활용할 수 있는 것을 의미한다. 즉, Amazon VPC를 활용하면 온프레미스 데이터 센터에서 직접 네트워크 환경을 만드는 것과 같은 방식으로 클라우드 환경에서도 네트워크를 구축할 수 있다.
AWS의 네트워크 서비스를 활용하기 위해서는 네트워크 기본 개념에 대한 학습이 선행되어야 한다.
✅ VPC가 만들어진 배경
Amazon VPC는 AWS에서 처음부터 제공하는 서비스는 아니었다. Amazon VPC가 없었을 때는 클라우드에 있는 리소스를 격리할 수 있는 방법이 없었다. 예를 들어, 수천 대의 서버를 클라우드에 배포한 경우 IP 네임스페이스를 정확히 관리해야 했으며, IP 주소 간에 중첩되는 부분이 없어야만 온프레미스에서 구동되는 리소스에 빈틈없이 접근할 수 있었다. 따라서 다음과 같은 문제가 있었다.
- 클라우드에서 어떻게 네트워크를 분리할 것인가?
- 어떻게 애플리케이션 중 일부는 인터넷을 통해 퍼블릭하게 연결하고, 일부는 프라이빗하게 연결할 것인가?
- 동일한 IP 범위를 클라우드로 확장하는 방법이 있는가?
- EC2 인스턴스를 생성하면 32비트 랜덤 IP 주소 체계와 비슷하게 유지할 수 있는 방법이 있는가?
Amazon VPC는 이러한 기존 클라우드 환경이 갖는 문제점을 해결하기 위한 솔루션으로 등장하게 되었다. 앞서 언급한 모든 문제를 해결할 수 있으며, 클라우드에서의 애플리케이션 호스팅, 데이터 센터에서 구동 중인 애플리케이션과 클라우드 자원의 긴밀한 연결을 가능하게 해준다. 3 Tier(Client Tier, Application Tier, Database Tier) 애플리케이션의 경우 Amazon VPC의 퍼블릭 서브넷으로 Client Tier(Web Tier)를 실행하고, 동일한 또는 새롭게 생성한 VPC에서 프라이빗 서브넷으로 Application Tier와 Database Tier를 실행할 수 있게 되었다.
✅ VPC로 클라우드 환경에서 할 수 있는 일
Amazon VPC 서비스에서 제공하는 여러가지 기능으로 클라우드 환경에서 다음과 같은 일들을 할 수 있다.
- 애플리케이션 중 일부는 VPC 내 클라우드에서 실행하고, 일부는 온프레미스에서 실행할 수 있다.
- VPC 내에서 인터넷으로부터의 접근을 허용하는 퍼블릭 서브넷과 한정된 접근만을 위한 프라이빗 서브넷을 생성할 수 있다.
- Direct Connect를 이용해 기업 데이터 센터와 VPN을 전용 회선으로 연결할 수 있다.
- 하나 이상의 VPC가 필요하다면 다수의 VPC를 생성한 뒤 VPC 피어링을 통해 서로 연결할 수 있다.
2. Amazon VPC 구성 요소 (1) - 서브넷
✅ 서브넷
서브넷(Subnet)은 서브네트워크(Subnetwork)의 줄임말로 IP 네트워크의 논리적인 영역을 부분적으로 나눈 하위 망을 말한다. AWS의 VPC에서도 서브넷을 통해 네트워크를 분리할 수 있다.
[그림1] VPC(10.0.0.0/16) 내에 퍼블릭 서브넷과 프라이빗 서브넷
[그림1]과 같이 VPC 내에 서브넷을 통해 네트워크망을 분리할 수 있다. VPC의 IP 대역인 10.0.0.0/16과 퍼블릭 서브넷, 프라이빗 서브넷의 IP 대역인 10.0.0.0/24와 10.0.1.0/24이 의미하는 것은 다음과 같다.
- VPC의 IP 대역을 10.0.0.0/16으로 설정하겠다는 것은 prefix가 /16이므로 앞의 10.0. 이 네트워크 주소를 의미하며 나머지 16bit로 호스트 주소를 정할 수 있다는 의미다. 즉 10.0.0.0~10.0.255.255 IP 범위가 같은 네트워크에 속한다는 의미다.
- 퍼블릭 서브넷의 IP 대역을 10.0.0.0/24로 설정한다는 것은 24bit(10.0.0.)를 네트워크 주소로 사용하겠다는 의미이며 나머지 8bit를 사용해서 호스트 주소를 정할 수 있다는 의미다. 즉 10.0.0.0~10.0.0.255 IP 범위가 같은 퍼블릭 서브넷에 속한다는 의미다.
- 프라이빗 서브넷의 IP 대역을 10.0.1.0/24로 설정한다는 것은 24bit(10.0.1.)를 네트워크 주소로 사용하겠다는 의미이며 나머지 8bit를 사용해서 호스트 주소를 정할 수 있다는 의미다. 즉 10.0.1.0 ~ 10.0.1.255 IP 범위가 같은 퍼블릭 서브넷에 속한다는 의미다.
서브넷의 IP 대역은 VPC의 IP 대역에 속해 있어야 하며, 서브넷은 1개의 가용 영역(AZ)에 종속되어야 한다. 또한 AWS에서는 서브넷에 할당할 수 있는 IP 대역에서 미리 예약되어 있는 IP 주소가 있는데 이러한 예약된 IP 주소들은 AWS 자원에게 할당할 수 없다.
✅ AWS에서 서브넷의 IP 대역마다 예약된 IP 주소
서브넷 IP 대역에서 첫번째에서 네번째까지 그리고 마지막 IP 주소는 예약되어 있다. 예를 들어 VPC의 IP 대역이 10.0.0.0/16이고, 해당 VPC에 존재하는 서브넷에 할당된 IP 대역이 10.0.0.0/24라면 서브넷의 IP 대역인 10.0.0.0 ~ 10.0.0.255 중에서 아래와 같이 5개의 IP 주소는 예약되어 있다.
- 첫번째 주소 : 10.0.0.0 → 네트워크 주소
- 두번째 주소 : 10.0.0.1 → AWS VPC 가상 라우터 주소
- 세번째 주소 : 10.0.0.2 → AWS DNS 서버 주소
- DNS 서버의 IP 주소는 해당 VPC의 IP 범위에 2를 더한 주소다. 지금처럼 CIDR 블록이 여러 개인 VPC, 즉 서브넷을 가지고 있는 VPC의 경우 DNS 서버의 IP 주소를 제외하고도 각 서브넷 IP 대역 범위에 2를 더한 모든 주소가 예약되어 있다.
- 네번째 주소 : 10.0.0.3 → 향후 새로운 기능에 활용할 주소
- 마지막 주소 : 10.0.0.255 → 네트워크 브로드캐스트 주소
기본적으로 서브넷을 생성할 때 예약된 IP 주소를 고려하여 생성해야 한다. 특정 서비스에 대해 IP 주소가 부족하면 문제가 발생할 수 있기 때문이다.
✅ 퍼블릭 서브넷과 프라이빗 서브넷
서브넷은 크게 퍼블릭 서브넷과 프라이빗 서브넷으로 나눌 수 있다.
퍼블릭 서브넷(Public subnet)은 공인 네트워크 개념으로 외부 인터넷 구간과 직접적으로 통신을 할 수 있는 공공 네트워크다. 반면에 프라이빗 서브넷(Private subnet)은 사설 네트워크 개념으로 외부 인터넷 구간과 직접적인 통신을 할 수 없는 폐쇄적인 네트워크 망이다.
VPC를 이용하면 Public subnet, Private subnet, VPN only subnet 등 필요에 따라 다양한 서브넷을 생성할 수 있다.
- Public subnet : 인터넷을 통해 연결할 수 있는 리소스를 배치하기 위한 네트워크
- Private subnet : 인터넷으로 연결하지 않고 보안 유지를 위한 배타적인 연결에 사용되는 네트워크
- VPN only subnet : 기업의 데이터 센터와 VPC를 연결하는 데 사용되는 네트워크
3 티어 구조를 예로 들면 웹 티어(프론트엔드 서버 및 백엔드 API 서버)는 퍼블릭 서브넷, 데이터베이스 티어는 프라이빗 서브넷에 위치하는 것이 적합하다.
3. Amazon VPC 구성 요소 (2) - 가상 라우터와 라우트 테이블
VPC를 생성하면 자동으로 가상 라우터가 생성된다. 이 가상 라우터는 라우트 테이블(route table)을 가지고 있는데, 라우트 테이블은 트래픽의 전송 방향을 결정하는 라우트와 관련된 규칙을 담고 있는 테이블이며, 목적지를 향한 최적의 경로로 데이터 패킷을 전송하기 위한 모든 정보를 담고 있다.
가상 라우터는 최초에 기본 라우트 테이블을 보유하고 있으며 로컬 네트워크에 대한 라우트 경로만 설정되어 있다. 여기서 로컬 네트워크는 VPC의 자체 IP 대역으로 VPC 내에 생성된 서브넷은 라우트 테이블의 로컬 네트워크에 의해 통신이 가능하다. [그림2] , [그림3] 과 같이 가상 라우터에서는 서브넷별로 라우트 테이블을 생성하고 매핑하여 서브넷 당 개별적인 라우트 테이블을 가질 수 있다.
✅ Public subnet 매핑 라우트 테이블
Destination(10.0.0.0/16)은 10.0.0.0~10.0.255.255까지의 트래픽을 Targe(local)로 보내고 다른 모든 대역들(0.0.0.0/0, ::/0)에 대해서는 트래픽을 Target(Internet Gate Way)으로 보내라는 정보가 저장되어 있다. 만약 10.0.0.1 안에 있는 서버에서 10.0.0.2로 트래픽을 보내면, 라우트 테이블을 거쳐서 로컬로 보내지게 된다.
✅ Private subnet 매핑 라우트 테이블
프라이빗 서브넷이 맵핑되어 있는 라우트 테이블에는 인터넷 게이트웨이(IGW) 설정이 없기 때문에, 해당 서브넷과 연결된 서버로는 인터넷에 접근할 수 없다. Destination(10.0.0.0/16)은10.0.0.0~10.0.255.255까지의 트래픽을 Target(local)로 보내는 것은 동일하다.
아래 [그림2]는 지금까의 내용을 정리해서 VPC(10.0.0.0/16)를 퍼블릭 서브넷(10.0.0.0/24)과 프라이빗 서브넷(10.0.0.1/24)으로 나누고 각각의 라우트 테이블을 생성해서 매핑한 그림이다. public route table을 보면 아직 10.0.0.0/16의 트래픽만 로컬로 보내주는 설정밖에 없다. 그러므로 퍼블릭 서브넷에 위치한 서버가 인터넷으로 트래픽을 보낼 수 없는 구조다. 여기서, 인터넷에 연결하기 위해서는 인터넷 게이트웨이(IGW)가 필요하다.
[그림2] VPC 내에 퍼블릭, 프라이빗 서브넷을 생성하고 각각의 라우트 테이블이 생성된 구조
4. Amazon VPC 구성 요소 (3) - Internet Gateway (IGW)
인터넷 게이트웨이(IGW)는 VPC와 Internet 간의 논리적인 연결이다. 간략하게 VPC에서 인터넷으로 나가는 관문이라고 생각할 수 있다. 이러한 인터넷 게이트웨이는 VPC 당 1개만 연결 가능하다.
IGW를 통해 외부 인터넷으로 통신할 수 있는 대상은 퍼블릭 IP를 사용하는 퍼블릭 서브넷 내의 자원뿐이다. 이러한 퍼블릭 서브넷은 자신의 라우트 테이블에 외부 인터넷으로 나가는 Target을 인터넷 게이트웨이로 지정해주어야 한다.
[그림3] VPC에 Internet Gateway가 연결된 구조
[그림3]과 같이 퍼블릭 서브넷 내의 인스턴스가 외부 인터넷과 통신하기 위하여 인터넷 게이트웨이가 관문이 되어 이를 통해 통신이 되고 있다. 인터넷 게이트웨이는 양방향으로 연결을 지원하기 때문에 외부 인터넷에서 퍼블릭 서브넷의 퍼블릭 IP로도 정상적인 통신이 가능하다. 퍼블릭 서브넷 안에서 통신 흐름은 다음과 같이 정리할 수 있다.
- 퍼블릭 서브넷의 퍼블릭 EC2 인스턴스가 외부 인터넷 구간과 통신하기 위해서 데이터를 가상 라우터로 전달. (퍼블릭 IP 사용)
- 가상 라우터는 퍼블릭 라우트 테이블을 참고하여 인터넷 게이트웨이로 향하는 라우트 경로를 확인.
- 가상 라우터는 인터넷 게이트웨이로 데이터를 전달하고 인터넷 구간으로 넘어간다.
- 인터넷 구간을 통해 결국 사용자에게 전달. 이때 반대로 외부 사용자에서 내부 퍼블릭 서브넷의 EC2 인스턴스에 접근하는 경우 퍼블릭 IP를 타깃으로 정상적인 통신이 가능.
5. Amazon VPC 구성 요소 (4) - NAT Gateway
NAT 게이트웨이도 인터넷 게이트웨이처럼 외부 인터넷과 연결하는 관문 역할을 하고 있다. 차이점은 NAT 이라는 명칭에서 알아볼 수 있는데, NAT은 Network Address Translation의 약자로 네트워크 주소 즉, IP 주소를 변환해 주는 기술이다.
인터넷은 공공 네트워크 구간으로 퍼블릭 IP를 통해 통신이 이루어진다. 그러므로 프라이빗 IP로는 인터넷에 접근할 수 없는데, 이때 NAT 게이트웨이가 프라이빗 IP를 퍼블릭 IP로 변환하여 통신을 도울 수 있다.
[그림4] Private subnet 내 자원의 인터넷 통신을 위해서 NAT Gateway가 추가된 구조
인터넷 게이트웨이는 퍼블릭 서브넷의 외부 인터넷 구간을 연결하는 반면에 NAT 게이트웨이는 [그림4]와 같이 프라이빗 서브넷 내에 인스턴스가 가지고 있는 프라이빗 IP를 퍼블릭 IP로 변환하여 외부 인터넷 구간으로 연결할 수 있다. 여기서, NAT 게이트웨이는 한쪽 방향으로만 동작한다는 것에 주의해야 한다. 프라이빗 서브넷에서 외부 인터넷으로 통신이 가능하지만 반대로 외부 인터넷에서 프라이빗 서브넷으로 통신은 불가능하다.
이러한 구조를 갖는 이유는 외부에서의 접근은 막고, 서브넷 내에 배치된 자원이 외부에서 패키지를 설치받는 경우에 인터넷에 접근이 필요하기 때문이다.
프라이빗 서브넷의 통신 흐름은 다음과 같이 정리할 수 있다.
- 프라이빗 서브넷의 프라이빗 EC2 인스턴스가 외부 인터넷 구간과 통신하기 위해 데이터를 가상 라우터로 전달. (프라이빗 IP 사용)
- 가상 라우터는 프라이빗 라우트 테이블을 참고하여 NAT 게이트웨이로 향하는 라우트 경로를 확인.
- 가상 라우터는 NAT 게이트웨이로 데이터를 전달하고, NAT 게이트웨이에서 프라이빗 IP를 퍼블릭 IP로 전환.
- NAT 게이트웨이에서 인터넷 구간을 넘어가기 위해 인터넷 게이트웨이를 거쳐 사용자에게 전달. 이때 사용자는 NAT 게이트웨이에서 변환한 퍼블릭 IP로 전달받는다.
6. Amazon VPC 구성 요소 (5) - NACL, Security Group
VPC에서는 인스턴스 레벨과 서브넷 레벨에서 대상을 필터링 할 수 있는 보안 기술을 사용할 수 있다. 인스턴스 레벨의 보안 기술은 보안 그룹(Security Group)이며, 서브넷 레벨에서의 보안 기술은 NACL(Network Access Control List)다. 이러한 보안 기술들은 인바운드(Inbound) 및 아웃바운드(Outbound)되는 데이터에 대해 허용 규칙과 거부 규칙을 수립하여, 원하는 요청만 수용할 수 있게 보안을 강화할 수 있다.
✅ 접근 제어(Access Control)
NACL, Security Group을 이해하기 전에 접근 제어라는 개념에 대해서 알아야 한다. 접근 제어(Access Control)란 보안상 위협으로부터 제반 시설 및 환경을 보호하기 위한 보안 정책으로 인가된 대상은 접근에 허용하고, 인가되지 않은 대상은 접근을 거부하여 보안을 강화할 수 있다.
접근 제어 절차는 식별(Identity), 인증(Authentication), 권한(Authorization) 순서로 진행된다. 먼저 대상을 식별하는 작업이 선행되는데 일반적으로 IP주소를 통해 대상을 식별하거나 프로토콜과 포트 번호를 통해 서비스를 식별할 수 있다. 이후에 식별된 대상에 대한 인증을 수행하여 적합한 대상인지 판단한다. 정책에 따라 허용, 거부, 제한적인 허용 등의 권한을 부여하여 접근에 대한 제어를 수행한다.
[그림5] 네트워크에 접근하는 대상에 대한 접근 제어
[그림5]와 같이 접근 대상의 IP 주소와 프로토콜 그리고 포트 번호를 통해 대상을 식별하여, 허용 대상은 접근 권한을 부여하고 거부 대상은 접근을 제한한다.
✅ 보안 그룹과 네트워크 ACL
AWS에서 네트워크 인프라 보호를 위해서 인스턴스 레벨과 서브넷 레벨에서 접근 제어(Access Control) 역할을 해주는 것이 보안 그룹과 네트워크 ACL이다.
[그림6] 보안 그룹과 네트워크 ACL이 적용된 이미지
보안 그룹(Security Group)과 네트워크 ACL(Network Access Control List)은 IP 주소와 프로토콜 그리고 포트 번호를 통해 대상을 식별하고 제어 정책에 따라 대상의 허용 여부를 판단한다.
이러한 보안 그룹과 네트워크 ACL은 트래픽의 방향성에 따라 인바운드 규칙(Inbound Rule)과 아웃바운드 규칙(Outbound Rule)으로 나뉘어 진다. 여기서 방향의 기준은 AWS 인프라 입장이기 때문에 외부 대상(User)에서 AWS 인프라로 들어오는 방향을 인바운드 규칙이라고 하고, AWS 인프라에서 외부 대상으로 나가는 방향을 아웃바운드 규칙이라고 한다. 자주 헷갈릴 수 있는 개념이기에 이 기준을 기억해야 한다.
그런데 여기까지 설명으로 봤을 때는 네트워크 ACL과 보안 그룹 모두 인바운드 규칙과 아웃바운드 규칙을 가지며 IP 주소와 프로토콜 그리고 포트 번호를 통해 대상을 식별하고 허용 여부를 판단하는 동일한 기능을 하는 것 처럼 보인다.
Security Group과 Network ACL의 차이점은 다음과 같다.
[그림7] 보안 그룹의 Stateful 동작과 네트워크 ACL의 Stateless 동작
✔️ Security Group (보안 그룹)
- 트래픽 제어 대상이 인스턴스 레벨(EC2, Application Load Balancer.. 등)이다.
- 보안 그룹은 Stateful하다. 보안 그룹은 이전 상태 정보를 기억하고 있다가 다음 단계에서 그 상태 정보를 활용할 수 있다.
[그림7]의 오른쪽 이미지와 같이 인바운드로 들어오는 트래픽에 대해 인바운드 규칙 확인후 대상의 인스턴스 접근이 허용 된다면, 그 상태 정보를 기억하고 있어서 아웃바운드로 되돌아갈 때(return traffic) 아웃바운드 규칙과 상관 없이 허용됩니다. 즉, 보안 그룹은 허용 규칙만 존재하며 그 대상이 아닌 트래픽은 자동으로 거부된다.
✔️ 네트워크 ACL
- 트래픽 제어 대상이 VPC 내부에 생성한 서브넷 레벨이다.
- 네트워크 ALC은 Stateless하다. 네트워크 ACL이 이전 상태 정보를 기억하지 않아 다음 단계에 관여하지 않는다.
[그림7]의 왼쪽 이미지와 같이 인바운드로 들어오는 트래픽에 대해 인바운드 규칙 확인 후에 대상이 허용된다고 해도 그 상태 정보를 기억하고 있지 않기 때문에 아웃바운드로 되돌아갈 때 아웃바운드 규칙에 따라 허용할지 거부할지를 결정한다. 즉, 허용 규칙과 거부 규칙이 둘 다 존재한다.
[그림8] 네트워크 ACL 규칙 리스트
7. Summary
- VPC(Virtual Private Cloud)는 클라우드 환경을 퍼블릭과 프라이빗의 논리적으로 독립된 네트워크 영역으로 분리할 수 있게 해준다.
- VPC 서비스를 활용해서 할 수 있는 일 중에 하나는 VPC 내에서 다수의 인터넷 접근을 위한 퍼블릭 서브넷을 생성하고, 격리된 접근을 위한 프라이빗 서브넷을 생성할 수 있다.
- 서브넷(Subnet)은 서브네트워크(Subnetwork)의 줄임말로 IP 네트워크의 논리적인 영역을 부분적으로 나눈 하위 망을 말한다.
- 가상 라우터는 라우트 테이블(route table)을 가지고 있는데, 라우트 테이블은 트래픽의 전송 방향을 결정하는 라우트와 관련된 규칙을 담고 있는 테이블이며, 목적지를 향한 최적의 경로로 데이터 패킷을 전송하기 위한 모든 정보를 담고 있다.
- 인터넷 게이트웨이(IGW)는 VPC와 Internet 간의 논리적인 연결이다.
- NAT은 Network Address Translation의 약자로 네트워크 주소 즉, IP 주소를 변환해 주는 기술이다.
- 보안 그룹(Security Group)과 네트워크 ACL(Network Access Control List)은 IP 주소와 프로토콜 그리고 포트 번호를 통해 대상을 식별하고 제어 정책에 따라 대상의 허용 여부를 판단한다.
낯선 단어들을 쉽게 설명해 주셔서 도움이 많이 되었습니다!