AWS | [실습] VPC 생성하기
모듈 6 - 가이드 랩: Virtual Private Cloud(VPC) 생성
자신만의 Virtual Private Cloud(VPC)를 만들어, 리소스를 배포하고, VPC 간 프라이빗 피어링 연결을 생성하는 방법을 배워봅니다.
이 실습이 끝나면 볼 수 있는 아키텍처입니다.
태스크 1: VPC 생성
먼저 Amazon VPC를 사용하여 새로운 Virtual Private Cloud(VPC)를 생성합니다.
실습 뒷부분에서 사용하게 될 Shared VPC도 있습니다. 하지만 이 실습에서는 자체 Lab VPC를 생성합니다
이 VPC의 Classless Inter-Domain Routing(CIDR) 범위는 10.0.0.0/16으로, 여기에는 10.0.x.x로 시작하는 모든 IP 주소가 포함됩니다. 따라서 65,000개 이상의 주소를 포함합니다. 나중에 이 주소를 별도의 서브넷으로 나눕니다.
CIDR(Classless Inter-Domain Routing)
클래스 없는 도메인간 라우팅 기법
클래스가 없다는 뜻은 네트워크 구분을 아래와 같이 Class로 하지 않는다는 것
위 Intra-Domain과 같이 각 네트워크 대역을 구분 짓고 Inter-Domain 과 같이 구분된 네트워크간 통신을 위한 주소 체계
192.168.10.0/24 이런식으로 "/24"와 같은 표기가 CIDR!
다음과 같이 Lab VPC를 생성한다.
페이지 하단에서 Tags 탭을 선택(태그는 리소스를 식별하는 데 유용)
DNS hostnames를 활성화 시킨다. VPC에서 실행되는 모든 EC2 인스턴스는 자동으로 DNS 호스트 이름을 받는다. 나중에 Amazon Route 53을 사용하여 더 의미 있는 DNS 이름(예: app.example.com)을 추가할 수도 있다.
태스크 2: 서브넷 생성
서브넷은 VPC에 있는 IP 주소의 하위 범위입니다. AWS 리소스는 지정된 서브넷에서 시작할 수 있습니다. 인터넷에 연결해야 하는 리소스에는 퍼블릭 서브넷을 사용하고 인터넷과 격리된 상태로 유지되어야 하는 리소스에는 프라이빗 서브넷을 사용합니다.
이 태스크에서는 다음과 같은 퍼블릭 서브넷과 프라이빗 서브넷을 생성합니다.
퍼블릭 서브넷 생성 -> 인터넷과 연결되는 리소스에 사용
다음과 같이 서브넷을 구성한다.
VPC의 CIDR 블록은 10.0.0.0/16이며, 여기에는 모든 10.0.x.x IP 주소가 포함된다. 방금 만든 서브넷의 CIDR 블록은 10.0.0.0/24이며, 여기에는 모든 10.0.0.x IP 주소가 포함됩니다. 비슷하게 보일 수도 있지만 서브넷은 CIDR 범위의 1/24이기 때문에 VPC보다 작다.
서브넷에서 시작되는 모든 인스턴스에 퍼블릭 IP 주소가 자동으로 할당되도록 서브넷을 구성한다.
Modify auto-assign IP settings를 선택한 후 Auto-assign IPv4 선택
이 서브넷의 이름은 Public Subnet이지만 아직 퍼블릭 서브넷이 아니다. 퍼블릭 서브넷에는 다음 태스크에서 연결할 인터넷 게이트웨이가 필요함
프라이빗 서브넷 생성
프라이빗 서브넷은 인터넷과 격리된 상태를 유지해야 하는 리소스에 사용된다.
다음 설정으로 다른 서브넷을 생성
CIDR 블록 10.0.2.0/23에는 10.0.2.x와 10.0.3.x로 시작하는 모든 IP 주소가 포함됩니다. 인터넷에서 액세스할 수 있어야 하는 특별한 경우를 제외하고 프라이빗 서브넷은 대부분의 리소스를 프라이빗으로 유지해야 하기 때문에 크기가 퍼블릭 서브넷의 두 배이다.
VPC에 2개의 서브넷이 있습니다. 하지만 퍼블릭 서브넷이 완전히 격리되어 있으며 VPC 외부의 리소스와 통신할 수 없습니다. 다음으로, 인터넷 게이트웨이를 통해 인터넷에 연결되도록 퍼블릿 서브넷을 구성해야한다.
태스크 3: 인터넷 게이트웨이 생성
인터넷 게이트웨이는 수평적으로 확장되며 이중화된 고가용성 VPC 구성 요소로, VPC의 인스턴스와 인터넷 간의 통신을 지원합니다. 네트워크 트래픽의 가용성을 저해하거나 대역폭을 제한하지 않습니다.
인터넷 게이트웨이를 사용하는 목적
- 라우팅 테이블에서 인터넷에 연결할 대상 제공
- 퍼블릭 IPv4 주소가 할당된 인스턴스에 네트워크 주소 변환(NAT) 실행
Name tag: Lab IGW 이름으로 인터넷 게이트웨이를 생성한다.
Actions를 선택한 다음 Attach to VPC를 선택
인터넷 게이트웨이가 Lab VPC에 연결됩니다. 인터넷 게이트웨이를 만들어 VPC에 연결했더라도, 인터넷 게이트웨이를 사용하도록 퍼블릭 서브넷 라우팅 테이블도 구성해야 한다.
태스크 4: 라우팅 테이블 구성
라우팅 테이블에는 네트워크 트래픽을 전달할 위치를 결정하는 데 사용되는 경로라는 일련의 규칙이 포함되어 있습니다. VPC의 각 서브넷은 라우팅 테이블에 연결되어 있어야 합니다. 이 테이블이 서브넷에 대한 라우팅을 제어하기 때문입니다. 서브넷을 한 번에 하나의 라우팅 테이블에만 연결할 수 있지만, 여러 서브넷을 동일한 라우팅 테이블에 연결할 수 있습니다.
인터넷 게이트웨이를 사용하려면 서브넷의 라우팅 테이블에 인터넷에 바인딩된 트래픽을 인터넷 게이트웨이로 향하도록 지시하는 경로가 포함되어야 합니다. 인터넷 게이트웨이로 가는 경로가 있는 라우팅 테이블에 연결된 서브넷을 퍼블릭 서브넷이라고 합니다.
다음을 수행해야 한다.
- 인터넷에 바인딩된 트래픽용 퍼블릭 라우팅 테이블 생성
- 인터넷 게이트웨이로 인터넷에 바인딩된 트래픽을 보내는 라우팅 테이블에 경로 추가
- 퍼블릭 서브넷을 새 라우팅 테이블에 연결
우선 VPC ID 열에서 Lab VPC라고 표시된 라우팅 테이블을 선택한 뒤 Name 열에서 을(를) 선택한 후 Private Route Table을 입력한다. 페이지 하단에 Routes 탭을 선택하면 경로가 하나뿐이다. 이는 10.0.0.0/16(Lab VPC의 범위)으로 전송되는 모든 트래픽이 로컬로 라우팅되는 것을 볼 수 있다. 이 경로를 통해 VPC의 모든 서브넷이 서로 통신이 가능하다.
퍼블릭 트래픽을 인터넷 게이트웨이로 전송할 새 퍼블릭 라우팅 테이블을 생성해야한다.
Routes 탭에서 Edit routes를 선택한 뒤, 이제 인터넷에 바인딩된 트래픽(0.0.0.0/0)을 인터넷 게이트웨이로 보내는 경로를 추가한다.
마지막 단계는 이 새 라우팅 테이블을 퍼블릭 서브넷에 연결하는 것이다.
Edit subnet associations를 클릭
Public Subnet이 있는 행을 선택
이 퍼블릭 서브넷은 인터넷 게이트웨이를 통해 인터넷으로 트래픽을 전송하는 라우팅 테이블 항목이 있기 때문에 이제 퍼블릭 서브넷이다.
다음 단계에 따라 퍼블릭 서브넷을 생성할 수 있다.
- 인터넷 게이트웨이 생성
- 라우팅 테이블 생성
- 0.0.0.0/0 트래픽을 인터넷 게이트웨이로 보내는 라우팅 테이블에 경로 추가
- 라우팅 테이블을 서브넷에 연결(이에 따라 퍼블릿 서브넷이 됨)
태스크 5: 애플리케이션 서버용 보안 그룹 생성
보안 그룹은 인스턴스의 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽 역할을 합니다. 보안 그룹은 인스턴스의 탄력적 네트워크 인터페이스 수준에서 작동합니다. 보안 그룹은 서브넷 수준에서 작동하지 않습니다. 따라서 각 인스턴스는 트래픽을 제어하는 자체 방화벽을 가질 수 있습니다. 시작할 때 특정 보안 그룹을 지정하지 않으면 VPC의 기본 보안 그룹에 인스턴스가 자동으로 할당됩니다.
이 태스크에서는 HTTP를 통해 애플리케이션 서버에 액세스할 수 있게 해주는 보안 그룹을 생성한다.
App-SG를 선택 후, Inbound Rules 탭을 선택한다.
Inbound Rules 설정에 따라 인스턴스에 연결할 수 있는 트래픽이 결정된다. 인터넷상의 모든 위치에서 수신되는 HTTP(포트 80) 트래픽을 허용하도록 구성한다(0.0.0/0)
태스크 6: 퍼블릭 서브넷에서 애플리케이션 서버 시작
VPC가 올바르게 구성되었는지 테스트하기 위해, 이제 EC2 인스턴스를 퍼블릭 서브넷에서 시작합니다. 또한 인터넷에서 EC2 인스턴스에 액세스할 수 있는지 확인합니다.
실행한 인스턴스에서 IPv4 Public IP 주소를 복사하여 탭을 열어보면 Inventory 애플리케이션과 Please configure settings to connect to database라는 메시지가 나타난다.
task 완료!