[AWS] AWS 인프라 정리
0. 주의
AWS 인프라를 공부하면서 정리한 글 입니다. 정확하지 않은 정보가 포함되었을 수도 있으니, 만약 틀린 점이 있다면 댓글로 알려주시면 감사하겠습니다.
Rigion
- 정의: 전 세계에서 데이터 센터를 클러스터링하는 물리적 위치. 각 Rigion은 물리적으로 격리되어 있으며, 최소 3개의 AZ를 포함한다.
- 한국의 경우 Asia Pacific (Seoul) Region
ap-northeast-2이 있다.
AZ (Avaliability Zone, 가용 영역)
- 정의: AWS 리전에서 독립적이고 중복된 전원 인프라, 네트워킹 연결을 갖춘 하나 이상의 데이터센터
- AZ 끼리는 서로 영향을 줄 수 없음.
VPC (Virtual Private Cloud)
- 정의: 클라우드 환경에서 논리적으로 격리된 사용자 전용 가상 네트워크 공간
- VPC에 배정된 IP는 한정되어 있음. IP대역이 정해짐.
- CIDR(Classless Inter-Domain Routing) 표기법은 IP 주소 및 네트워크 마스크를 나타내는 방법이다.
- VPC 안에서 할 수 있는 것들
- IP 주소 범위 지정
- 서브넷 나누기
- 라우팅 및 보안 설정
- 모든 네트워크 활동이 VPC 안에서 이루어짐
- 사용 이유: 보안과 통제권 확보.
VPC는 특정 리전에 만들어지는 논리적 네트워크임. 리전은 여러개의 가용 영역으로 나뉘기 때문에 여러 AZ에 걸쳐있을 수 있다.
Subnet
- 정의: VPC 내부를 나눈 공간. VPC의 부분 집합. IP 주소 범위
- 하나의 서브넷은 반드시 하나의 AZ에 속한다. (왜? 서브넷도 VPC처럼 논리적 정의가 아닌가? 왜 물리적 실체인 AZ에 종속되어야 하는거지?)
- 실제 AZ에 존재하는 장비에 subnet의 IP 대역이 매핑되어야 한다.
- 만약 subnet이 여러 AZ에 존재한다면?
- AZ는 기본적으로 수십 km씩 떨어져 있음. 따라서 만약 매 패킷마다 어느 AZ에 존재하는지 확인하면 성능 오버헤드가 발생한다.
- (사견) 즉 성능적인 문제를 해결하려고 1:1 매핑했다고 생각했다.
- 역할: Public Subnet, Private Subnet으로 나눠서 보안 요구사항을 따른다.
- Public Subnet: 인터넷 통신이 가능한 서브넷. IGW와 직접적으로 연결되어 있다.
- Private Subnet: 외부에서 접근할 수 없는 리소스가 위치해야 하는 공간. NAT와 연결되면, 외부와 단방향 통신할 수 있다.
Route Table
- 정의: 네트워크 트래픽이 어디로 가야할지 알려주는 규칙 집합.
- 역할: 각 서브넷에서 발생하는 트래픽을 목적지로 안내한다. 즉 서브넷에서 나가는 트래픽만 인도한다.
- 사용 이유: 트래픽 흐름을 관리하기 위하여.
- 따라서 Route Table은 subnet마다 존재한다.
- Public subnet에서 외부(0.0.0.0/0)으로 발생하는 트래픽은 IGW를 향한다.
- Private subnet에서 외부(0.0.0.0/0)으로 발생하는 트래픽은 NAT을 향한다.
- 라우트 테이블 규칙에 따라 서브넷이 public, private이 될지 결정된다.
- 따라서 Route Table은 subnet마다 존재한다.
IGW (Internet GateWay)
- 정의: VPC와 외부 인터넷 간의 양방향 통신을 가능하게 하는 관문
- 역할: Public Subnet과 연결돼, 내부 자원을 외부에 공개하고, 외부 자원을 받는다.
- 사용 이유: VPC 내에 자원이 인터넷에 공개되어야 할 때 사용된다.
NAT Gateway (Network Address Translation Gateway)
- 정의: Private Subnet에 있는 자원이 외부 인터넷으로 나갈 수는 있지만, 외부에서 들어오게는 못하게 하는 단방향 통신 관문.
- 역할: Private Subnet의 인스턴스가 외부 api를 호출하거나, 업데이트를 위해 접속해야 할 때 사용.
- 사용 이유: 보안을 유지하면서 외부 리소스에 접근해야 할 필요가 있을 때 사용.
Security Group(SG, 보안그룹)
정의: 연결된 리소스에 도달하고 나가는 트래픽을 제어하는 규칙
역할: 외부에서 오는 트래픽을 인바운드 규칙으로 관리하고, 내부에서 나가는 트래픽을 아웃바운드 규칙으로 관리한다.
SG를 적용할 수 있는 리소스
- 컴퓨팅 리소스: EC2, ECS/EKS, VPC 내부 람다함수
- DB: RDS, EC, Redshift
- 네트워크 접근 지점: ALB, NLB
통신 흐름 분석
인바운드 흐름 분석 (요청)
1단계: 클라이언트 -> ALB (퍼블릭 영역 진입)
- 흐름: Client(
1.2.3.4:54321) -> IGW -> Public Subnet -> ALB(myDomain.com:443) - 분석: 외부 사용자가 HTTPS(443)로 접근한다. 이 트래픽은 IGW를 거쳐 Public Subnet에 위치한 ALB로 들어옵니다. 이때 ALB에 연결된 보안 그룹(Security Group)이 443 포트를 열어주어 트래픽을 허용한다.
2단계: ALB -> EC2 (프라이빗 영역 진입)
- 흐름: ALB(
10.0.1.100:1024) -> Routing Table -> Private Subnet 1 -> EC2 Nginx(10.0.2.50:80) - 분석: ALB는 외부 트래픽을 받아 내부의 EC2로 전달한다. 이때 출발지 IP가 클라이언트 IP가 아닌 ALB의 사설 IP(
10.0.1.100)로 변경된다. 타겟 포트는 웹 서버용 80 포트이며, 출발지 포트는 1024(임시 포트)가 동적으로 할당된다. 트래픽은 내부적으로 이동하기 때문에 local route 규칙을 통해 이동한다.
3단계: EC2 내부 통신 (Nginx -> WAS)
- 흐름: Nginx -> WAS(
localhost:8080) - 분석: 80 포트로 요청을 받은 Nginx가 리버스 프록시 역할을 하여, 같은 EC2 인스턴스 내에서 실행 중인 WAS(Spring Boot 등, 8080 포트)로 요청을 넘긴다.
4단계: WAS -> RDS (데이터베이스 통신)
- 흐름: WAS(
10.0.2.50:1234) -> Routing Table -> Private Subnet 2 -> RDS(10.0.3.200:3306) - 분석: 비즈니스 로직 처리를 위해 WAS가 DB에 연결한다. WAS의 사설 IP에서 임시 포트(1234)를 열고, RDS의 MySQL/MariaDB 기본 포트인 3306으로 요청을 보낸다. RDS의 보안 그룹은 오직 EC2(또는 특정 IP/보안그룹)에서 오는 3306 포트만 허용하도록 닫혀 있다.
2. 아웃바운드 흐름 분석 (응답)
- 요청이 끝난 후 응답은 역순으로 돌아갑니다. 다이어그램의 파란색 실선 화살표들이 이를 나타낸다.
- 흐름 역순: 1. RDS(
10.0.3.200:3306) -> WAS(10.0.2.50:1234)- Nginx/WAS(
10.0.2.50:80) -> ALB(10.0.1.100:1024) - ALB(
myDomain.com:443) -> Client(1.2.3.4:54321)
- Nginx/WAS(
- 보안 그룹은 상태 저장(Stateful) 속성을 가지므로, 인바운드 요청이 허용되었다면 아웃바운드 응답을 위한 포트(예: 클라이언트의 54321 임시 포트)는 별도로 열어주지 않아도 무사 통과한다. 즉, 아웃바운트 응답도 보안 그룹을 통과한다.


