1. 강의 내용

학습 범위

  • 26. AWS 보안 및 암호화: KMS, SSM Parameter Store, CloudHSM, Shield, WAF
  • 27. 네트워킹 - VPC

 

2. 강의 정리

1) VPC

: VPC(Virtual Private Cloud)는 논리적으로 격리된 가상 네트워크이다.

사용자가 직접 IP 주소 범위, 서브넷, 라우팅 테이블, 인터넷 게이트웨이 등을 직접 설정할 수 있다.

 

 

📝 구성 요소

 

1) CIDR (Classless Inter-Domain Routing)

  • VPC는 기본적으로 하나의 IP 주소 범위를 갖는데, 이것을 CIDR 블록이라고 한다.
  • CIDR 블록 안에서 서브넷을 나누고, 각 리소스에 IP 주소를 할당한다. 
    • ex. 10.0.0.0/16

 

 

2) 서브넷 (Subnet)

  • VPC 내에서 IP 주소 범위를 더 작은 단위로 나눈 것이다.
  • 각 서브넷은 특정 AZ에 속하며, 고가용성을 위해 여러 AZ에 걸쳐 배치 가능하다.
  • 퍼블릭 서브넷: 인터넷 게이트웨이와 연결되어 외부 접근이 가능한 서브넷
  • 프라이빗 서브넷: 인터넷에 직접 연결되지 않아 외부 접근이 불가능한 서브넷

 

  • AWS 각 서브넷에서 5개의 예약 IP 주소는 사용할 수 없다.
    • ex. CIDR 블록이 `10.0.0.0/24`일 경우
예약 IP 주소설명
10.0.0.0 네트워크 주소(Network Address)
10.0.0.1 VPC 라우터 주소 – AWS가 VPC 라우팅용으로 예약
10.0.0.2 Amazon DNS 매핑용 주소
10.0.0.3 AWS 예약 – 향후 기능 확장을 위한 용도
10.0.0.255 브로드캐스트 주소 – AWS VPC는 브로드캐스트 미지원, 예약됨

 

 

 

3) 인터넷 게이트웨이 (IGW, Internet GateWay)

  • VPC 내 리소스와 인터넷 간의 연결을 가능하게 하는 요소이다.
  • 퍼블릭 서브넷의 리소스가 인터넷에 접근하거나 외부에서 접근하기 위해서는 IGW가 필요하다.
    • 단, IGW만 있다고 해서 인터넷 연결이 가능한 것이 아니다.
    • 공용 서브넷에 연결된 라우팅 테이블에 경로를 추가해야 인터넷 연결이 가능하다.
      • 아래와 같이 라우팅 설정을 추가해야 한다.
      • `10.0.0.0/16` → Local (들어오는 트래픽)
      • `0.0.0.0 → IGW` (나가는 트래픽)
  • 1개의 VPC에는 1개의 IGW만 연결이 가능하다.
  • IPv4 통신의 경우 IGW가 NAT도 수행하여, Public IP와 Private IP 간의 주소 변환을 처리해 VPC 내 리소스가 인터넷과 통신할 수 있게 한다.

 

 

 

4) 라우팅 테이블 (Route Tables)

  • 네트워크 트래픽을 어디로 전달할 지 결정하는 테이블
  • 인터넷 게이트웨이로 가는 트래픽(0.0.0.0/0)을 설정하거나, VPC 내 다른 서브넷 간 통신을 정의한다.

 

 

5) NAT 게이트웨이 (Network Address Translation Gateway)

  • 프라이빗 서브넷의 인스턴스가 인터넷에 나갈 수 있도록 해주는 요소이다.
  • 외부에서 프라이빗 서브넷으로의 접근은 차단한다.

 

 

 

6) 보안 그룹 & NACL (Network Access Control List)

  • 보안 그룹
    • 인스턴스 수준에서 동작하며, 트래픽 허용 규칙만 정의 가능 (화이트리스트)
    • inbound를 허용하면 outbound는 자동으로 허용하는 stateful 방식으로 동작한다.
  • 네트워크 ACL
    • 서브넷 수준에서 동작하며, 트래픽 허용 / 거부 규칙 정의 가능 (블랙리스트 포함)
    • inbound를 허용하더라도, outbound를 허용하지 않으면 차단되는 stateless 방식으로 동작한다.
  • 임시 포트(Ephemeral Port)
    • 클라이언트와 서버가 연결할 때, 일시적으로 사용되는 포트이다.
    • NACL은 stateless 하기 때문에, 임시 포트를 허용하도록 규칙을 작성해야 한다.

 

 

 

7) VPC Peering

  • 서로 다른 VPC 간에 프라이빗 IP 주소를 사용해 통신할 수 있도록 하는 기능이다.
    • 공인 IP나 IGW를 사용하지 않고, 사설 IP로만 통신한다.
  • 동일 리전, 다른 리전, 다른 계정 모두 지원한다.
  • 직접 연결된 두 개의 VPC 간에만 유효하다. (비전이성)
  • CIDR 블록이 겹치지 않아야 한다.
  • 각 VPC 서브넷의 라우팅 테이블에서 상대 VPC CIDR 블록을 추가해주어야 한다.

 

 

 

8) VPC Endpoint

  • VPC 내 리소스가 인터넷을 거치지 않고 AWS 서비스에 프라이빗 네트워크를 통해 접근할 수 있게 해주는 기능이다.
    • Public Subnet, IGW, NAT Gateway, Public IP 없이도 AWS 서비스에 접근이 가능함

 

1️⃣ Gateway Endpoint

  • `Amazon S3`, `DynamoDB` 서비스만 지원한다.
    • VPC 내에서 프라이빗 하게 접근할 때 효율적
  • VPC의 라우팅 테이블에 대상 경로를 추가해서, 트래픽을 라우팅 하는 방식이다.
    • 보안 그룹 불필요
    • 별도의 네트워크 인터페이스 없이 동작
  • 무료로 제공되는 서비스이다.

 

 

 

2️⃣ Interface Endpoint

  • 대부분의 AWS 서비스를 지원한다.
    • 일반적으로 다른 VPC, Reigon, 온프레미스 등 외부에서 AWS 서비스에 접근할 때 사용
  • VPC 내에서 ENI를 생성하고, 프라이빗 IP를 할당하여 트래픽을 라우팅 하는 방식이다.
    • 보안 그룹 필요
  • 시간당 요금과 데이터 전송 비용이 발생한다.

 

 

 

9) VPC Flow Logs

  • VPC 내(VPC, 서브넷, ENI)에서의 네트워크 트래픽을 모니터링 하는 기능이다.
    • 보안 분석, 네트워크 문제 해결, 트래픽 패턴 모니터링 등 다양한 용도로 활용됨
  • Amazon S3, CloudWatch Logs, Kinesis Data Firehose 

 

 

온프레미스 - AWS 간 네트워크 연결

 

1) Site-to-Site VPN

  • 온프레미스 네트워크와 AWS VPC 간에 암호화 된 연결을 할 수 있게 하는 서비스이다.
    • 이는 일반적으로 애플리케이션이나 CLI에서 IAM Credential을 사용하여 퍼블릭 API를 호출하는 방식과는 다르다.
    • AWS VPC의 사설 네트워크에 직접 접근할 수 있는 네트워크 경로를 확보하여, VPC 내 EC2, RDS, EFS 등 내부 리소스에 사설 IP로 직접 접근할 수 있게 한다.
  • 주로 회사 네트워크 전체를 AWS와 연결하고자 할 때 사용된다.

 

 

2) Direct Connect (DX)

  • 온프레미스와 AWS 간에 물리적인 회선을 설치해 직접 연결할 수 있게 하는 서비스이다.
    • 인터넷을 거치지 않고 전용 회선으로 연결하기 때문에, 높은 보안성과 안정성을 제공한다.
    • 다른 VPC에 있는 리소스에 온프레미스에서 직접 접근하려면, Direct Connect Gateway를 사용해 연결할 수 있다.
      (VPC Peering: VPC 간 통신만 가능하며, Direct Connect 트래픽이 peering 되어 있는 다른 VPC로 전파되지는 않는다.)
  • 금융권, 대기업과 같은 대규모 데이터 이동 환경에서 사용된다.

 

 

3) Client VPN

  • 개별 사용자의 단말과 AWS VPC 간에 SSL 기반의 암호화 된 연결을 할 수 있게 하는 서비스이다.
    • Site-to-Site VPN과 달리 전체 사내망이 아닌 사용자 단위로 VPC 접근 권한을 부여할 수 있다.
    • AWS에서 제공하는 OpenVPN 설정 파일을 통해 VPN 클라이언트를 실행하고 연결하며, 연결 이후에는 VPC 내부 리소스에 직접 접근할 수 있다.
  • 원격 근무 환경에서 사용될 수 있다.

 

 

VPC 연결을 단순하게

 

- Transit Gateway (TGW)

  • 여러 VPC와 온프레미스 네트워크 간의 트래픽을 중앙에서 라우팅하고 관리할 수 있도록 해주는 서비스이다.
    • VPC Peering은 VPC 간의 1:1 직접 연결 방식이기 때문에, VPC 수가 많아질수록 연결 관리가 복잡해지고 Peering 개수도 기하급수적으로 늘어난다. 또한 온프레미스와 여러 VPC에 간의 연결을 위해 Site-to-Site VPN이나  Direct Connect Gateway에 대한 각각의 개별 설정이 필요하다. 
    • Transit Gateway를 사용하면 여러 VPC 간의 연결을 하나의 중앙 허브를 두고, 각 네트워크 트래픽을 라우팅하여 vpc 관리와 확장을 쉽게 가능하도록 한다.
    • IP 멀티캐스트 기능을 지원해, 여러 VPC 리소스에 동시에 전송할 수 있다.

 

 

 

운영 관점에서의 비용 절감

 

1) Public IP 대신 Private IP를 사용하자

 

동일한 가용 영역(AZ) 내에 리소스를 배치하면, AZ 내부 인스턴스 간의 트래픽은 무료이기 때문에 네트워크 비용을 아낄 수 있다. 하지만 가용성을 높이기 위해 다중 AZ에 리소스를 분산 배치할 경우, AZ 간 전송 비용이 발생하게 된다. 이때는 가능한 한 public ip 대신 private ip를 사용하여 통신하는 것이 좋다.

Aws 내 리소스끼리 통신할 때, public ip를 사용하여 전송하면 더 높은 요금을 내고, 대역폭 측면에서도 인터넷 통신이다 보니 성능이 더 낮을 수 있다. 따라서 되도록이면 VPC 내부의 private ip를 사용해 aws 내부 네트워크로 통신하여 낮은 요금과 높은 대역폭을 지원받는 게 좋다.

 

 

2) S3에서 데이터 전송 시, CloudFront를 고려해보자

 

우선 외부에서 S3로 업로드하는 트래픽은 무료이다.

반면, S3에서 데이터를 다운로드 받을 때는 전송되는 데이터 용량에 따라 요금이 발생한다.

 

이 때 S3 파일을 CloundFront로의 전송은 무료여서, CloundFront에 캐싱하고 이를 통해 다운로드하는 아키텍처로 구성을 하면, S3에서 직접 다운로드할 때보다 요금을 더 아낄 수도 있다. 성능 측면에서도 CloundFront는 사용자와 가장 가까운 엣지 로케이션에 캐싱을 하기 때문에 더 빠르게 데이터를 응답받을 수 있다.

 

단순히 '데이터 전송 요금'만 고려하면 CloudFront를 통해 데이터 전송을 받는 것이 유리할 수 있다.

다만, S3와 CloudFront에서 HTTP 요청당 요금이 부과되므로 요청 패턴에 따라 오히려 비용이 증가할 수도 있다.

예를 들어:

  • S3 (서울 리전 기준)
    • PUT, COPY, POST, LIST 요청: 1,000건당 $0.0045
    • GET, SELECT, 기타 요청: 1,000건당 $0.00035
  • CloudFront (서울 리전 기준)
    • 모든 HTTP 메서드: 1,000건당 $0.00090

따라서 GET 요청이 많다면 S3가, POST 요청이 많다면 CloudFront가 더 저렴할 수 있다.

요금은 리전별로 다를 수 있으므로, 데이터의 특성, 요청 빈도, 요청 방식 등을 종합적으로 고려해서 아키텍처를 설계하는 필요가 있다.

 

 

 

3) Private Subnet의 EC2 인스턴스가 S3 접근 시, VPC Gateway Endpoint를 사용하자

 

인터넷에 접근하는 경우라면 NAT Gateway가 필요하지만, 시간당 요금과 별도의 데이터 처리 요금이 별도로 발생하게 된다.

따라서 단순히 EC2 → S3 통신만 필요할 경우, VPC Gateway EndPoinrt를 사용하는 것이 훨씬 경제적으로 운영할 수 있다.

 

 

 

 

 

2) VPC에서 사용자 요청을 처리하는 과정

VPC 내용을 정리하고, 사용자 요청이 AWS 내에서 어떻게 처리되는지 간략히 정리해보았다 💭

 

 

[요청]

1. 사용자가 google.com 에 접속을 한다.

 

2. 클라이언트는 DNS 서버에 google.com 의 Public IP 주소를 요청하고, 이를 응답받는다.

 

3. 클라이언트는 Public IP로 요청을 보낸다.

 

4. 이 요청은 AWS 클라우드로 전달되고, Public IP와 연결된 인스턴스가 속한 VPC의 IGW가 수신한다.

 

5. Public IP는 VPC 내부에서 관리되고 있는 ENI IP 매핑 정보를 바탕으로 Private IP로 변환한다.

 

6. Private IP가 속한 서브넷의 라우팅 테이블을 조회하고, 해당 경로로 라우팅한다.

ex: 10.0.0.0/16 → local
로컬 경로를 통해 라우팅

 

6. 서브넷의 NACL과 인스턴스의 보안 그룹에서 트래픽이 허용되면, 해당 요청이 EC2 인스턴스에 도달한다.

 

7. EC2 인스턴스에서 요청을 처리하고 응답을 보낸다.

 

 

[응답]

8. 서브넷의 라우팅 테이블에 따라 IGW로 라우팅 된다.

 

9. EC2에서 나온 응답 패킷의 출발지 주소를 Pirvate IP 에서 Public IP로 변환 후 클라이언트로 보낸다.

저작자표시 (새창열림)

'DevOps > AWS' 카테고리의 다른 글

AWS SAA 5주차  (0) 2025.03.24
AWS SAA 4주차 (2)  (0) 2025.03.15
AWS SAA 4주차 (1)  (0) 2025.03.14
AWS SAA 3주차  (0) 2025.03.08
AWS SAA 2주차  (0) 2025.03.01

티스토리툴바