[AWS-Security] 5.4. 프라이빗 네트워크 분리

1. 네트워크 격리를 위한 멀티 VPC 사용

1.1. 멀티 VPC를 사용하는 이유: 논리적 분리

• 단일 계정이나 단일 VPC 안에서 IAM 정책과 Security Group만으로 모든 접근을 완벽하게 통제하려다 보면, 정책이 너무 복잡해서 실수하기가 쉽다.
• 관련 없는 네트워킹 리소스에 대해 멀티 VPC를 사용하는 것도 동일하다.

1.2. 폭발 반경(Blast Radius) 축소

• 별도의 VPC에 있는 인스턴스 간에는 기본적으로 네트워크 트래픽이 완전히 차단된다.
• 보안 이점 : 해커가 인스턴스 A를 해킹하는 데 성공하더라도, 인스턴스 B로 넘어갈 수 있는 ‘네트워크 길’ 자체가 없기 때문에 추가적인 공격을 시도하기 어렵다.

1.3. Security Group vs 멀티 VPC

인스턴스가 2개뿐이라면 굳이 VPC를 나누지 않고 Security Group만으로 트래픽을 차단하는게 더 효율적일 수 있다.
하지만 네트워크가 커질수록 멀티 VPC가 주는 안정감은 압도적이다.

• Security Group만 사용한 경우 (단일 VPC)
  • Security Group 규칙에 전적으로 의존한다.
  • 관리자가 실수로 잘못 구성하면 인스턴스 간 원치 않는 연결이 허용되는 보안 사고가 발생할 수 있다.
• 멀티 VPC 사용
  • 인스턴스 간 연결이 근본적인 네트워크 경계에 의해 차단된다.
  • 관리자가 실수로 Security Group 규칙을 허용하더라도, VPC 간 연결이 없으므로 통신이 되지 않는다.

2. VPC 간 연결: VPC 피어링

2.1. Public Internet 경유의 문제점

• 방식 : 각 VPC에 Internet Gateway(IGW)를 달고, Public Internet 망을 통해 데이터를 주고 받는 방식이다.
• 단점
  • 방화벽(Security Group, NACL) 설정에 작은 실수만으로도 모든 사용자에게 리소스가 노출될 위험이 있다.
  • 트래픽이 안전한 AWS 내부망을 벗어나, 외부 인터넷을 타기 때문에 보안 및 가용성의 문제가 발생한다.

2.2. VPC 피어링 연결

• Public Internet으로 나갈 필요 없이, 두 개의 VPC를 마치 ‘하나의 VPC 네트워크에 있는 것처럼’ 비공개로 직접 연결해 주는 서비스이다.
• 핵심 전제 조건 : 두 VPC의 IP 주소 범위 (CIDR)가 겹치지 않아야 한다.

2.3. VPC 피어링 설정 단계

1. 피어링 연결 요청 생성 : A VPC에서 B VPC를 향해 피어링 연결을 요청한다.
2. 피어링 연결 수락 : B VPC의 관리자가 요청을 수락(Accept)해야 연결이 활성화된다.
3. 라우팅 테이블 업데이트 : 양쪽 VPC의 라우팅 테이블에 서로를 향하는 경로를 추가한다.
   1. A VPC 라우팅 : 10.0.1.0/24 (B VPC 대역)으로 가는 트래픽은 대상 pcx-1234(피어링 연결 ID)로 보냄
   2. B VPC 라우팅 : 10.0.0.0/24 (A VPC 대역)으로 가는 트래픽은 대상 pcx-1234(피어링 연결 ID)로 보냄

2.4. VPC 피어링

1. 사전 리소스 생성

    # 겹치지 않는 CIDR를 갖는 VPC 2개 생성
    aws ec2 create-vpc \
        --cidr-block 10.0.0.0/24   # 첫 번째 VPC (예: vpc-1234)
   		
    aws ec2 create-vpc \
        --cidr-block 10.0.1.0/24   # 두 번째 VPC (예: vpc-5678)
   		
    # 피어링할 두 VPC 각각에 서브넷 생성
    aws ec2 create-subnet \
        --vpc-id vpc-1234 \
        --cidr-block 10.0.0.0/24
   		
    aws ec2 create-subnet \
        --vpc-id vpc-5678 \
        --cidr-block 10.0.1.0/24
   		
    # 신규 생성된 두 서브넷에 각각의 EC2 인스턴스 생성
    aws ec2 run-instances \
        --instance-type t2.micro \
        --vpc-id vpc-1234 \
        --subnet-id subnet-1234
   	
    aws ec2 run-instances \
        --instance-type t2.micro \
        --vpc-id vpc-5678 \
        --subnet-id subnet-5678
   

2. VPC 피어링 연결 요청 생성 (A VPC)
   • AWS Console 및 AWSCLI를 통해 구성
3. 피어링 연결 요청 수락 (B VPC)
   • AWS Console 및 AWSCLI를 통해 구성

4. 라우팅 테이블 업데이트

   라우팅 테이블	대상 (Target)	목적지 (Destination)
   첫 번째 VPC의 기본 라우팅 테이블	pcx-1234	10.0.1.0/24
   두 번째 VPC의 기본 라우팅 테이블	pcx-1234	10.0.0.0/24

2.4. 리전 간/계정 간 피어링

• VPC 피어링은 서로 다른 리전(inter-region peering)이나 아예 서로 다른 AWS 계정에 있는 VPC끼리도 연결이 가능하다.
• 이렇게 연결해도 트래픽은 여전히 안전한 AWS 내부 글로벌 네트워크 안에서만 이동한다.

3. 프라이빗 네트워크에 VPC 연결

3.1. AWS Site-to-Site VPN

• 개념 : AWS에 위치하지 않은 외부 네트워크(On-premise)와 AWS VPC 사이에 암호화된 VPN 터널을 생성하는 서비스이다.
• 핵심 구성 요소
  • 가상 프라이빗 게이트 웨이 (Virtual Private Gateway) : AWS VPC 측에 설치되는 게이트웨이이다. Internet Gateway와 비슷하지만, 오직 VPC Tunnel을 통해서만 트래픽이 이동하도록 제한한다.
  • 고객 게이트웨이 (Customer Gateway) : 온프레미스 네트워크 측에 설치되는 물리적 라우터 장치이다.
• 작동 방식 : 양쪽에 게이트웨이를 설정하여 VPN Tunnel을 뚫은 뒤, VPC 라우팅 테이블에 “On-premise로 갈 트래픽은 가상 프라이빗 게이트웨이(VPG)로 가라”로 경로를 지정해 줘야 한다.
  (Security Group과 NACL은 동일하게 적용 받음)

3.2. AWS Direct Connect (전용 회선)

• 개념 : Public Internet 망을 아예 타지 않고, On-premise 네트워크와 AWS 네트워크 사이에 직접적인 물리적 전용 회선을 꽂는 서비스이다.
• VPN과의 차이점
  • 안정성 : VPN은 암호화를 하더라도 Public 망을 타고 흐르지만, Direct Connect는 중간에 거치는 단계(hop) 없이 AWS로 트래픽이 바로 직행한다.
  • 단점 : Site-to-Site VPN에 비해 물리적 회선을 끌어와야 하므로 설정이 어렵고 비용이 비싸다.
• 사용 시기 : 비용이 들더라도 많은 양의 데이터를 빠르게 전송해야 하거나, 일반 인터넷 기반 VPN의 대역폭 한계(속도 저하)를 피해야 하는 대규모 엔터프라이즈 환경에서 애용되는 옵션이다.