VPC + 서브넷 생성
- 아키텍처 개요 (링크)
- CodeBuild + ECR 생성 (링크)
- VPC + 서브넷 생성 (현재 글)
- 인터넷 게이트웨이 + NAT 게이트웨이 생성 및 라우트 테이블 설정 (링크)
- 로드밸런서(ALB) + 보안 그룹(Security Group) + 대상 그룹(Target Group) 생성 (링크)
- ECS 클러스터 생성 + 태스크 정의 + 서비스 생성 (링크)
- S3 버킷 생성 + CodePipeline 설정 및 최종 배포 (링크)
VPC란?
Virtual Private Cloud의 약자로, 프라이빗 네트워크를 활용하여 네트워크 망을 구성하고 내부에 각종 리소스를 탑재할 수 있게 해주는 서비스를 의미한다. 이를 통해 클라우드 환경을 퍼블릭과 프라이빗의 논리적으로 독립된 네트워크 영역으로 분리가 가능하다. 어떤 리소스라도 논리적으로 분리된 영역에 격리할 수 있으며, 사용자가 네트워크 환경 설정에 대한 완전한 통제권을 가질 수 있는 서비스이다.
Amazon VPC를 통해 만든 네트워크에서 사용자는 자체 IP 주소, 퍼블릭 및 프라이빗 서브넷, 라우트 테이블, 네트워크 게이트웨이 등 모든 기능을 활용할 수 있다. 즉, Amazon VPC를 활용하면 온프레미스 데이터 센터에서 직접 네트워크 환경을 만드는 것과 같은 방식으로 클라우드 환경에서도 네트워크를 구축할 수 있다.
VPC의 탄생 배경
Amazon VPC는 AWS에서 처음부터 제공하는 서비스가 아니었기에 기존 AWS는 클라우드에 있는 리소스를 격리할 수 있는 방법이 없었다. → 수천 대의 서버를 클라우드에 배포한 경우 IP 네임스페이스를 정확히 관리해야 하며, IP 주소 간에 중첩되는 부분이 없어야만 온프레미스에서 구동되는 리소스에 빈틈없이 접근할 수 있었던 것
문제점
- 클라우드에서 어떻게 네트워크를 분리할 것인가?
- 어떻게 애플리케이션 중 일부는 인터넷을 통해 퍼블릭하게 연결하고, 일부는 프라이빗하게 연결할 것인가?
- 동일한 IP 범위를 클라우도 확장하는 방법이 있는가?
- EC2 인스턴스를 생성하면 32비트 랜덤 IP 주소 체계와 비슷하게 유지할 수 있는 방법이 있는가?
위와 같은 문제점을 해결하이 위해 Amazon VPC가 등장하게 되었다. 이러한 Amazon VPC 서비스에서 제공하는 기능을 통해 다음과 같은 일들을 클라우드 환경에서 할 수 있다.
- 애플리케이션 중 일부는 VPC 내 클라우드에서 실행하고, 일부는 온프레미스에서 실행할 수 있다.
- VPC 내에서 인터넷으로부터 접근을 허용하는 퍼블릭 서브넷과 한정된 접근만을 위한 프라이빗 서브넷을 생성할 수 있다.
- Direct Connect를 이용해 기업 데이터 센터와 VPN을 전용 회선으로 연결할 수 있다.
- 하나 이상의 VPC가 필요하다면 다수의 VPC를 생성한 뒤 VPC 피어링을 통해 서로 연결할 수 있다.
VPC 생성
서브넷과 추가 설정은 추후에 해주기 위해 VPC만 먼저 생성해 주었다.
VPC 이름 태그는 juice-shop-scp로 정해주었다. 이는 그저 관련 리소스를 식별하고 관리하기 쉽게 이용되는 메타데이터이다.
IPv4 CIDR 블록은 수동 입력으로 10.0.0.0/16으로 설정해 주었다.
IPv6 CIDR 블록은 사용하지 않기 때문에 블록 없음을 선택해 주었다.
💡 CIDR이란?
VPC는 하나 이상의 연속적인 IP 주소인 CIDR(Classless Inter Domain Routing) 블록으로 표시한다. 이러한 CIDR 블록은 VPC 내의 인스턴스 및 리소스에 할당되는 IP 주소를 결정한다.
보통 VPC를 만들 때 기본 CIDR 블록을 할당해야 하며, VPC 생성 후에는 기본 VPC CIDR 블록을 AWS 인프라에 따라 서브넷으로 나누어서 사용하게 된다.
IP 주소 범위를 나타내는 여러 방법 중 가장 짧게 표현하는 방법이 빗금 문자 표기법(slash notation)이라 불리는 CIDR 표기법이다. 예를 들어, CIDR 172.17.0.0/16이라는 표기법은 172.17.0.0 ~ 172.17.255.255의 총 65,536(2의 16승) 개의 주소를 포함하는 것이다. 이 CIDR 블록에서 /16의 의미는 IP의 길이를 나타내는 프리픽스(Prefix)이며, 이는 서브넷 마스크의 길이를 나타내고, VPC CIDR 범위는 /16에서 /28까지 가능하다. CIDR 표기법에서 길이 프리픽스와 IP 주소의 수는 역의 관계로, 길이 프리픽스가 작을수록 CIDR에 존재하는 IP 주소의 수는 많아진다. 유요한 IPv4 프리픽스의 길이는 /0부터 /32까지인데, 다른 퍼블릭 인터넷 주소와 충돌을 피하기 위해 RFC 1918의 범위를 사용하는 것이 권장된다.
위와 같이 VPC를 생성해 주면 기본적으로 라우팅 테이블이 하나가 생성된다. 이러한 라우팅 테이블이 생성되는 이유는 VPC 내부에서 서브넷을 생성하거나 리소스를 배치하려면 트래픽 경로가 필요한데, 이 네트워크 트래픽을 처리하기 위한 것이다. 이러한 기본 라우팅 테이블은 VPC 내부 트래픽에 대한 경로가 자동으로 설정되어 있다. 필요에 따라 이를 수정하고 새로운 라우팅 테이블을 생성하게 된다.
서브넷 생성
만들어둔 VPC를 선택 후 4개의 서브넷을 만들어주었다.
- 이름은 프라이빗과 퍼블릭의 차이를 주었다. 또한 프라이빗끼리, 퍼블릭끼리의 차이도 숫자를 통해 구분했다.
- 리전은 서울로 지정해 주고 서울의 4개의 가용영역 중 2a, 2c를 선택하였다.
- 가용 영역 2개에 프라이빗 하나, 퍼블릭 하나씩 총 4개의 서브넷을 생성해 주었다.
- 퍼블릭 하나와 프라이빗 하나를 하나의 가용 영역에 배치해 주었다.
- 총 2개의 서브넷이 하나의 가용 영역에 존재하게 된다.
서브넷이란?
서브넷(subnet)은 서브네트워크(subnetwork)의 줄임말로 IP 네트워크의 논리적인 영역을 부분적으로 나눈 하위 망을 말한다. 이를 통해 VPC에서 네트워크를 분리할 수 있다.
서브넷은 크게 퍼블릭 서브넷과 프라이빗 서브넷으로 나눌 수 있다.
- 퍼블릭 서브넷 (Public subnet)은 공인 네트워크 개념으로 외부 인터넷 구간과 직접적으로 통신을 할 수 있는 공공 네트워크다.
- 프라이빗 서브넷 (Private subnet)은 사설 네트워크 개념으로 외부 인터넷 구간과 직접적인 통신을 할 수 없는 폐쇄적인 네트워크 망이다.
VPC를 이용하면 필요에 따라 다양한 서브넷을 생성할 수 있다.
3 티어 구조를 예로 들면 웹 티어(프론트엔드 서버 및 백엔드 API 서버)는 퍼블릭 서브넷, 데이터베이스 티어는 프라이빗 서브넷에 위치하는 것이 적합하다.
위와 같이 VPC 내에 서브넷을 통해 네트워크망을 분리할 수 있는다.
- VPC의 IP 대역은 10.0.0.0/16이며, 퍼블릭 서브넷, 프라이빗 서브넷의 IP 대역은 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24, 10.0.4.0/24이다.
- VPC의 IP 대역을 10.0.0.0/16으로 설정하겠다는 것은 프릭스가 /16이므로 10.0. 이 네트워크 주소를 의미하며 나머지 16bit로 호스트 주소를 정할 수 있다는 의미다. 즉, 10.0.0.0 ~ 10.0.255.255 IP 범위가 같은 네트워크에 속한다는 의미다.
- 퍼블릭 서브넷의 IP 대역을 10.0.1.0/24와 10.0.2.0/24로 설정한다는 것은 24bit(10.0.1. 과 10.0.2.)를 네트워크 주소로 사용하겠다는 의미이며 나머지 8bit를 사용해 호스트 주소를 정할 수 있다는 의미다. 즉, 10.0.1.0 ~ 10.0.1.255와 10.0.2.0 ~ 10.0.2.255 IP 범위가 각각 같은 퍼블릭 서브넷에 속한다는 의미다.
- 프라이빗 서브넷의 IP 대역을 10.0.3.0/24와 10.0.4.0/24로 설정한다는 것은 24bit(10.0.3. 과 10.0.4.)를 네트워크 주소로 사용하겠다는 의미이며 나머지 8bit를 사용해서 호스트 주소를 정할 수 있다는 의미다. 즉, 10.0.3.0 ~ 10.0.3.255와 10.0.4.0 ~ 10.0.4.255 IP 범위가 각각 같은 프라이빗 서브넷에 속한다는 의미다.
서브넷의 IP 대역은 VPC의 IP 대역에 속해 있어야 하며, 서브넷은 1개의 가용 영역에 종속되어야 한다. 또한 AWS에서는 서브넷에 할당할 수 있는 IP 대역에서 미리 예약되어 있는 IP 주소가 있는데, 이러한 예약된 IP 주소들은 AWS 자원에게 할당할 수 없다. 서브넷 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를 더한 주소이다.
- 네 번째 주소 : 10.0.0.3 ⇒ 향후 새로운 기능에 활용할 주소
- 마지막 주소 : 10.0.0.255 ⇒ 네트워크 브로드캐스트 주소
참고 문헌
https://velog.io/@yenicall/AWS-VPC의-개념
https://aws-hyoh.tistory.com/49
https://inpa.tistory.com/entry/AWS-📚-VPC-개념-사용-보안-설정-Security-Group-NACL
https://uchupura.tistory.com/48
https://habitus92.tistory.com/22
'Project > Cloud' 카테고리의 다른 글
| 파이프라인 Security에 집중한 DevOps 구현 - 로드밸런서(ALB) + 보안 그룹(Security Group) + 대상 그룹(Target Group) 생성 (5) (0) | 2025.01.27 |
|---|---|
| 파이프라인 Security에 집중한 DevOps 구현 - 인터넷 게이트웨이 + NAT 게이트웨이 생성 및 라우트 테이블 설정 (4) (0) | 2025.01.27 |
| 파이프라인 Security에 집중한 DevOps 구현 - CodeBuild + ECR 생성 (2) (0) | 2025.01.27 |
| 파이프라인 Security에 집중한 DevOps 구현 - 아키텍처 개요 (1) (1) | 2025.01.26 |
| 무중단 배포란? (0) | 2025.01.12 |