우선 AWS의 격리형 클라우드 네트워크의 구조를 파악하는게 좋을거 같아서 간단한 비유를 준비했다.
1. VPC Structure
- 1. VPC와 서브넷: 네트워크의 기본 구조
- VPC: 자기자신의 가상 마을이라고 생각해라. 이 마을 안에는 여러 구역(서브넷)이 있을 수 있다.
- 서브넷: VPC 안의 각각의 구역이다. 예를 들어, 주거 구역(프라이빗 서브넷)과 상업 구역(퍼블릭 서브넷)으로 나눌 수 있다.
- 2. 인터넷 게이트웨이와 NAT 게이트웨이: 마을의 출입구
- 인터넷 게이트웨이: 마을의 주요 출입구이다. 외부 사람(인터넷)이 이 출입구를 통해 상업 구역(퍼블릭 서브넷)에 있는 상점(EC2 인스턴스 등)과 거래(통신)할 수 있다.
- NAT 게이트웨이: 보안이 필요한 마을 구역(프라이빗 서브넷)에서 외부로 나갈 때 사용하는 출입구다. 하지만 외부에서 이 출입구를 통해 마을 안으로 직접 들어올 수는 없다.
- 3. 라우트 테이블: 교통 신호
- 라우트 테이블: 마을 내에서 트래픽이 어디로 가야 하는지 정하는 교통 신호다. 서브넷에서 나가는 모든 트래픽이 라우트 테이블에 정의된 경로를 따라 이동한다.
- 4. 보안 그룹과 네트워크 ACL: 보안 경비와 울타리
- 보안 그룹: 각 집(EC2 인스턴스) 앞에 서 있는 경비원(방화벽)이다. 이 경비원은 들어오고 나가는 사람을 철저히 확인한다. "허용"된 사람만 들어올 수 있다.
- 네트워크 ACL: 서브넷 전체를 둘러싼 울타리다. 이 울타리는 구역(서브넷) 전체로 들어오는 사람들과 나가는 사람들을 제어한다. "허용"과 "거부" 모두 설정할 수 있다.
- 5. VPC 피어링과 Transit Gateway: 마을 간 연결
- VPC 피어링: 서로 다른 마을(VPC) 간에 다리를 놓는 것이다. 두 마을은 이 다리를 통해 서로 통신할 수 있다. 하지만 이 연결은 직접적이고, 각 마을 간에 별도로 설정해야 한다.
- Transit Gateway: 마을들 간의 중앙 버스 터미널이라고 생각해라. 여러 마을(VPC)과 외부 네트워크(온프레미스)를 한 번에 연결하는 중앙 허브 역할을 한다. 마을들 간에 복잡한 다리(피어링 연결) 없이도 트래픽을 쉽게 관리할 수 있다.
- 6. VPC 엔드포인트와 AWS Direct Connect: 마을 내부 서비스 및 전용 도로
- VPC 엔드포인트: 마을 안에서 필요한 서비스(S3, DynamoDB 등)를 이용할 수 있도록 하는 내부 서비스다. 마을 밖(인터넷)으로 나가지 않고도 내부에서 모든 것을 처리할 수 있다.
- AWS Direct Connect: 당신의 마을과 먼 곳에 있는 주요 도시(온프레미스 데이터 센터) 간에 직접 연결된 전용 고속도로다. 이 고속도로는 빠르고 안정적이며, 인터넷을 거치지 않아서 더 안전하다.
- 7. Elastic Load Balancer: 마을의 트래픽 관리 센터
- Elastic Load Balancer: 마을 내 여러 집(EC2 인스턴스)으로 몰리는 교통(트래픽)을 고르게 분산시키는 역할을 한다. 모든 집이 적절한 양의 방문자(요청)를 처리할 수 있게 해준다.
간단 정리
VPC는 마을 전체이고, 서브넷은 그 안의 구역들이다.
인터넷 게이트웨이와 NAT 게이트웨이는 외부와의 출입구 역할을 한다.
라우트 테이블은 트래픽의 경로를 정하는 교통 신호다.
보안 그룹과 네트워크 ACL은 마을의 보안 시스템이다.
VPC 피어링과 Transit Gateway는 여러 마을 간의 연결 방식이다.
VPC 엔드포인트와 AWS Direct Connect는 외부와의 연결을 관리하는 방법이다.
Elastic Load Balancer는 마을 내의 트래픽을 고르게 분산시키는 관리 센터다.
AWS 참고 블로그 - 해당 글을 참고하였다. 설명이 똑부러지니 참고하면 좋다.
네트워크 블로그 - 정리가 매우 잘 되어있어서 공부할 때 참고하면 도움이 될 것이다.
2. My AWS Settings
쓰다가 저장이 안돼서 다 날아갔다 하.. 임시 저장했다고 알림만 뜨고 왜 안됨..
1. VPC
기존에 있던 VPC는 삭제하고 다시 생성했다. 그리고 서브넷 4개, 라우팅 테이블 1개, 네트워크 연결(인터넷 게이트웨이) 1개를 생성 및 사용했다.
2. Subnet
사실 프리티어를 사용하면 단일 AZ 배포만 지원하기 때문에 서브넷이 4개나 필요가 없다. EC2 인스턴스, RDS 인스턴스를 하나씩 같은 서브넷에 생성하면 된다. 하지만 RDS를 생성할 때 추후 확장 및 관리를 위해서인지 Multi AZ배포를 위해 꼭 4개 이상의 서브넷 그룹을 생성하도록 강제하고 있다. 그래서 프리티어를 사용한다하더라도 RDS를 생성할 때 4개 이상의 서브넷 그룹이 있어야 생성할 수 있다.
3. Routing Table
모든 서브넷은 퍼블릭이기에 0.0.0.0/0 주소 즉, 모든 요청은 인터넷 게이트웨이를 통한다. 아래 172.31.0.0/16은 VPC local 주소이다.
4. EC2
남들이 하라는 대로 만들면 된다. 그 중에 중요한 것은 키페어 생성 및 보안 그룹이다. 키페어는 반드시 사용해야한다. 현재 필자의 인스턴스는 public이기 때문에 누구나 접근할 수 있기 때문에 보안상 좋은 환경은 아니다. 그래서 EC2에 접근할 때 키페어로 인증하도록 하여 보안을 강화한다.
필자는 EC2 인스턴스에 Nginx, Certbot, Spring Boot 컨테이너를 배포할 것이기 때문에 HTTP, HTTPS 요청은 모두 받도록 한다. 그리고 github runner에서 ssh 접속을 하여 배포하기 때문에 ssh도 열어준다. 그리고 탄력적 IP를 할당해서 인스턴스를 재실행하더라고 항상 동일한 ip로 접근할 수 있도록 한다.
5. RDS
EC2 인스턴스를 생성하면 RDS를 생성해서 연결하는 것을 추천하는 안내가 나올 것이다. 그렇게 RDS를 생성하면 보안그룹이 자동생성된다. 그럼 외부에서도 내부에서도 접근이 불가능하고 오직 연결된 EC2 인스턴스에서만 접근할 수 있다.
3. 결과
필자가 구성한 AWS의 구성은 이러하다 AWS 프리티어의 경우 public ip 하나를 750시간 무료로 제공하는데 public ip가 두개일 경우 시간이 두배로 차감된다. 그래서 RDS는 private로 설정하고 EC2에서만 접근할 수 있도록 했다. 이렇게 하면 프리티어 기간동안 무료로 계속 배포해둘 수 있다.
