포스트

[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와 연결되면, 외부와 단방향 통신할 수 있다.

image.png

Route Table

공식 문서

  • 정의: 네트워크 트래픽이 어디로 가야할지 알려주는 규칙 집합.
  • 역할: 각 서브넷에서 발생하는 트래픽을 목적지로 안내한다. 즉 서브넷에서 나가는 트래픽만 인도한다.
  • 사용 이유: 트래픽 흐름을 관리하기 위하여.
    • 따라서 Route Table은 subnet마다 존재한다.
      • Public subnet에서 외부(0.0.0.0/0)으로 발생하는 트래픽은 IGW를 향한다.
      • Private subnet에서 외부(0.0.0.0/0)으로 발생하는 트래픽은 NAT을 향한다.
    • 라우트 테이블 규칙에 따라 서브넷이 public, private이 될지 결정된다.

IGW (Internet GateWay)

공식 문서

  • 정의: VPC와 외부 인터넷 간의 양방향 통신을 가능하게 하는 관문
  • 역할: Public Subnet과 연결돼, 내부 자원을 외부에 공개하고, 외부 자원을 받는다.
  • 사용 이유: VPC 내에 자원이 인터넷에 공개되어야 할 때 사용된다.

NAT Gateway (Network Address Translation Gateway)

공식 문서

  • 정의: Private Subnet에 있는 자원이 외부 인터넷으로 나갈 수는 있지만, 외부에서 들어오게는 못하게 하는 단방향 통신 관문.
  • 역할: Private Subnet의 인스턴스가 외부 api를 호출하거나, 업데이트를 위해 접속해야 할 때 사용.
  • 사용 이유: 보안을 유지하면서 외부 리소스에 접근해야 할 필요가 있을 때 사용.

image.png

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)
    1. Nginx/WAS(10.0.2.50:80) -> ALB(10.0.1.100:1024)
    2. ALB(myDomain.com:443) -> Client(1.2.3.4:54321)
  • 보안 그룹은 상태 저장(Stateful) 속성을 가지므로, 인바운드 요청이 허용되었다면 아웃바운드 응답을 위한 포트(예: 클라이언트의 54321 임시 포트)는 별도로 열어주지 않아도 무사 통과한다. 즉, 아웃바운트 응답도 보안 그룹을 통과한다.


이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.