AWS VPC (Virtual Private Cloud)
VPC란?
- AWS VPC(Virtual Private Cloud)는 가상 사설 클라우드로, 사용자가 AWS 클라우드에서 고유한 가상 네트워크를 구성하고 관리할 수 있는 환경을 제공한다.
- AWS 클라우드에서 논리적으로 분리된 네트워크.
- 사용자는 이 네트워크 안에서 자신만의 리소스(서버, 데이터베이스 등)를 배포하고 관리 가능.
- 다른 사용자의 네트워크와 완전히 격리됨.
- VPC의 역할:
- 클라우드 리소스를 배포하고 실행하는 기본 네트워크 환경.
- 사용자는 네트워크를 구성할 수 있는 완전한 제어권을 가진다.
- 보안 설정, IP 주소 범위, 서브넷, 라우팅 등을 직접 정의할 수 있다.
- VPC의 위치:
- VPC는 특정 AWS 지역(Region) 내에서만 존재하며, 지역 간 확장되지 않는다.
- VPC는 한 지역 내에서만 작동.
- 다른 지역에 리소스를 배포하려면 별도의 VPC를 생성해야 함.
- VPC는 특정 AWS 지역(Region) 내에서만 존재하며, 지역 간 확장되지 않는다.
VPC 구성 요소
CIDR 블록
CIDR이란?
- "Classless Inter-Domain Routing"의 약자로, 네트워크의 IP 주소 범위를 정의.
- 예)
10.0.0.0/16은 65,536개의 IP 주소를 포함.
- 예)
- CIDR 블록의 역할:
- VPC의 전체 IP 주소 범위를 설정.
- 이 범위 안에서 서브넷을 생성하고 리소스에 IP 주소를 할당.
- CIDR 블록 설계:
- CIDR 블록 크기가 너무 작으면 리소스 추가가 어렵고, 너무 크면 비효율적일 수 있으므로 신중하게 설계하여 네트워크를 최적화해야 한다.

- 예를 들어 CIDR 블록이
10.0.0.0/24인 VPC를 만들 경우 256개의 IP 주소를 지원한다. - 이 CIDR 블록을 각각 128개의 IP 주소를 지원하는 2개의 서브넷으로 나눌 수 있다.
- 한 서브넷은
10.0.0.0/25CIDR 블록을, (10.0.0.0~10.0.0.127사이의 주소) - 다른 서브넷은
10.0.0.128/25CIDR 블록을 사용한다. (10.0.0.128~10.0.0.255사이의 주소)
- 한 서브넷은
서브넷 (Subnet)
서브넷이란?
- VPC의 네트워크를 더 작은 단위로 나눈 하위 네트워크.
- 각 서브넷은 특정 가용성 영역(AZ) 에 할당된다.
서브넷 유형:
- 공용 서브넷:
- 인터넷 게이트웨이를 통해 외부와 연결 가능.
- 일반적으로 웹 서버, API 게이트웨이 등을 배포.
- 사설 서브넷:
- 외부와 직접 연결되지 않음.
- 데이터베이스, 내부 애플리케이션 등 민감한 데이터를 처리.
서브넷 설계:
- 하나의 AZ에 여러 서브넷을 생성 가능.
- 특정 서브넷에 리소스를 배포할 때, 서브넷의 역할에 따라 공용 또는 사설로 설정.
인터넷 게이트웨이 (Internet Gateway, IGW)
역할:
- VPC와 인터넷 간의 트래픽 송수신을 가능하게 하는 네트워크 컴포넌트.
- 퍼블릭 서브넷에 위치하며, VPC 내부의 리소스가 인터넷에 접근하거나 인터넷에서 VPC로 접근할 수 있도록 지원한다.
- 한 VPC에 하나의 IGW 만 연결 가능.
특징:
- 퍼블릭 서브넷 연결:
인터넷 게이트웨이는 퍼블릭 서브넷과 외부 인터넷 간의 연결을 제공한다.- 퍼블릭 서브넷의 리소스(예: 웹 서버, API 게이트웨이 등)는 IGW를 통해 인터넷과 직접 통신할 수 있다.
- 인그레스(Ingress) 및 이그레스(Egress) 트래픽:
- 인그레스(Ingress): 인터넷에서 VPC로 들어오는 트래픽.
- 이그레스(Egress): VPC에서 인터넷으로 나가는 트래픽.
- 라우팅 테이블 필요:
- 인터넷 게이트웨이를 통해 트래픽을 송수신하려면, 퍼블릭 서브넷의 라우팅 테이블에 인터넷 게이트웨이로 가는 경로를 설정해야 한다.
- 예:
0.0.0.0/0(모든 트래픽)을 IGW로 전달하도록 라우팅 테이블에 설정.
NAT 게이트웨이 (Network Address Translation Gateway)
역할:
- NAT 게이트웨이는 사설 서브넷에 위치한 리소스가 인터넷에 접근할 수 있도록 지원한다.
- 인그레스(들어오는 트래픽)는 차단하고, 이그레스(나가는 트래픽)만 가능하게 하여 보안을 강화한다.
특징:
- 프라이빗 서브넷 연결:
NAT 게이트웨이는 프라이빗 서브넷과 외부 인터넷 간의 연결을 제공한다.- NAT 게이트웨이를 통해 프라이빗 서브넷의 리소스(예: 데이터베이스 서버, 내부 애플리케이션 등)는 인터넷에 접근할 수 있지만, 외부에서 프라이빗 서브넷의 리소스로 접근할 수는 없다.
- NAT 게이트웨이를 통해 프라이빗 서브넷의 리소스가 외부 API 데이터 가져오기, 소프트웨어 업데이트 다운로드 등 인터넷 연결이 필요한 작업을 수행할 수 있다.
- 라우팅 테이블 필요:
- NAT 게이트웨이를 통해 인터넷에 연결하려면 프라이빗 서브넷의 라우팅 테이블에 NAT 게이트웨이로 가는 경로를 설정해야 한다.
- 예:
0.0.0.0/0(모든 트래픽)을 NAT 게이트웨이로 전달하도록 라우팅 테이블에 설정.

VPC 피어링 (Peering)
역할:
- 두 개의 VPC(Virtual Private Cloud) 간의 네트워크 연결을 설정하여, 사설 IPv4/IPv6 주소를 사용해 서로 통신할 수 있게 하는 기능
- 인터넷을 거치지 않고 AWS 글로벌 네트워크를 통해 데이터를 전달하므로, 보안과 성능 면에서 유리하다.
- 지역 간 연결 시 트래픽은 자동으로 암호화된다.

특징:
- Private 연결: 트래픽이 AWS 내부 네트워크에서만 이동하며, 인터넷을 사용하지 않음.
- CIDR 블록 제한:
- 피어링하려는 두 VPC의 CIDR 블록은 겹칠 수 없음.
- CIDR 블록이 겹치면 라우팅 충돌 발생.
- Non-transitive:
- VPC A가 VPC B와 피어링, VPC B가 VPC C와 피어링되어 있어도, VPC A와 VPC C는 직접 통신할 수 없음. (전이 X)
- 모든 VPC 간 통신을 원할 경우, 각 VPC 간 직접적인 피어링 연결이 필요.
VPC Peering 구성 절차
- 피어링 요청 생성:
- VPC Peering Connection을 생성하고 요청을 전송.
- 요청은 같은 계정 또는 다른 AWS 계정의 VPC로 보낼 수 있음.
- 피어링 요청 승인:
- 대상 VPC 소유자가 요청을 승인해야 연결이 활성화됨.
- 라우트 테이블 구성:
- 피어링 연결을 통해 트래픽을 전달하도록 라우트 테이블에 경로 추가.
- 대상 CIDR 블록과 VPC Peering ID를 경로로 지정.
- 보안 그룹 및 네트워크 ACL 업데이트:
- ICMP, TCP, UDP 등의 프로토콜로 통신하려면 보안 그룹과 네트워크 ACL 규칙을 업데이트.
- 상대 VPC의 CIDR 블록을 허용하도록 설정
VPC 엔드포인트
역할:
- VPC 내부에서 AWS 서비스에 안전하게 연결할 수 있게 해주는 기능
- 인터넷을 거치지 않고 AWS 네트워크 내부를 통해 서비스에 접속하도록 설계되었다.
- 공용 IP 주소나 인터넷 게이트웨이 없이도 AWS 서비스(S3, DynamoDB 등)에 연결 가능.

VPC Endpoint의 두 가지 유형
인터페이스 엔드포인트 (Interface Endpoint)
- AWS 서비스(예: CloudFormation, CloudWatch, Systems Manager 등) 또는 프라이빗 링크 서비스와 연결할 때 사용된다.
- ENI(탄력 네트워크 인터페이스)를 생성하고, 사설 IP 주소를 통해 통신한다.
- 특징:
- 트래픽은 DNS 항목을 통해 서비스로 라우팅된다.
- 보안 그룹 규칙을 통해 트래픽을 제어할 수 있다.
- 사용 사례:
- 사설 서브넷의 EC2 인스턴스가 인터넷 없이 CloudWatch 로그를 기록하거나, Systems Manager를 통해 관리 작업을 수행.
- 게이트웨이 엔드포인트 (Gateway Endpoint)
- Amazon S3와 DynamoDB 전용으로 설계된 엔드포인트
- 라우트 테이블에 경로를 추가해 트래픽을 해당 서비스로 직접 라우팅한다.
- 특징:
- 인터넷 게이트웨이 없이 S3 또는 DynamoDB로 데이터를 안전하게 전송할 수 있다.
- 정책을 사용하여 접근을 제한할 수 있다.(예: 특정 VPC 엔드포인트만 허용)
- 사용 사례:
- 사설 서브넷의 EC2 인스턴스가 S3에 파일을 저장하거나 DynamoDB에서 데이터를 검색할 때 사용
- S3 버킷 정책을 설정해 VPC 엔드포인트를 통해서만 접근하도록 제한
Interface Endpoint vs Gateway Endpoint
| Interface Endpoint | Gateway Endpoint | |
|---|---|---|
| 지원 서비스 | 대부분의 AWS 서비스 (CloudWatch, SNS 등) | S3, DynamoDB 전용 |
| 트래픽 라우팅 방식 | DNS 항목을 사용해 트래픽 라우팅 | 라우트 테이블을 통해 트래픽 라우팅 |
| 보안 | 보안 그룹 규칙을 사용 | VPC Endpoint 정책 및 S3 버킷 정책 사용 |
| 트래픽 전달 | ENI를 통해 연결 (사설 IP 사용) | 라우트 테이블을 통한 접두사 목록과 게이트웨이 ID |
| 구성 요소 | 탄력 네트워크 인터페이스(ENI) | 게이트웨이 및 접두사 목록 |
보안 그룹(Security Groups) 과 네트워크 ACL(Network ACLs)
AWS에서는 VPC 안에서 리소스를 보호하기 위해 두 가지 주요 방화벽 유형을 제공한다. 이 두 가지는 서로 다른 수준과 방식으로 트래픽을 제어한다.
- 보안 그룹(SG)
- 네트워크 ACL(NACL)
상태풀(Stateful)과 상태비저장(Stateless) 방화벽의 차이
- 상태풀 방화벽:
- 인바운드 트래픽을 허용하면 해당 트래픽의 응답 트래픽도 자동으로 허용.
- 두 트래픽 흐름(요청과 응답)을 연결된 상태로 간주.
- 보안 그룹(SG)은 상태풀 방화벽에 속함.
- 상태비저장 방화벽:
- 인바운드와 아웃바운드 트래픽을 개별적으로 관리.
- 요청 트래픽과 응답 트래픽을 별도로 허용해야 함.
- 네트워크 ACL(NACL)은 상태비저장 방화벽에 속함.
보안 그룹(SG)
정의
- EC2 인스턴스에 연결된 네트워크 인터페이스(NIC) 수준에서 작동하는 방화벽.
- 특정 인스턴스 또는 특정 ENI(탄력 네트워크 인터페이스)에 적용.
작동 방식
- 상태풀 방화벽: 인바운드 트래픽이 허용되면 응답 트래픽은 자동으로 허용.
- 규칙은 허용만 가능(트래픽 거부 규칙 없음).
특징
- 레벨: 인스턴스 수준 방화벽.
- 필터링: 같은 서브넷 내 인스턴스 간 트래픽도 필터링 가능.
- 규칙:
- 기본적으로 모든 트래픽을 차단(deny all).
- 트래픽 허용을 위해 명시적인 규칙을 추가해야 함.
- 적용 대상: 하나의 인스턴스에 여러 보안 그룹을 연결 가능.
- 순서: 규칙의 순서와 무관하게 모든 규칙을 평가.
네트워크 ACL(NACL)
1) 정의
- 서브넷 수준에서 작동하는 방화벽.
- VPC 내 서브넷에 대한 모든 인바운드 및 아웃바운드 트래픽을 제어.
2) 작동 방식
- 상태비저장 방화벽: 요청 트래픽과 응답 트래픽을 개별적으로 허용해야 함.
- 허용과 거부 규칙을 모두 정의 가능.
3) 특징
- 레벨: 서브넷 수준 방화벽.
- 필터링: 서브넷을 드나드는 트래픽만 필터링. 서브넷 내 인스턴스 간 트래픽은 제어하지 않음.
- 규칙:
- 허용 및 거부 규칙 모두 작성 가능.
- 기본적으로 모든 트래픽을 허용(기본 NACL).
- 사용자 정의 NACL을 만들면 기본적으로 모든 트래픽을 차단.
- 순서:
- 규칙에 숫자로 우선순위 지정(작은 숫자부터 평가).
- 첫 번째로 매칭된 규칙에서 처리 종료.
- 적용 대상:
- 서브넷에 연결된 모든 리소스(인스턴스 포함)에 적용.
보안 그룹과 네트워크 ACL 비교
| 보안 그룹(SG) | 네트워크 ACL(NACL) | |
|---|---|---|
| 적용 범위 | 인스턴스 수준 | 서브넷 수준 |
| 필터링 대상 | 인스턴스 간 트래픽 포함 | 서브넷을 드나드는 트래픽만 |
| 방화벽 유형 | 상태풀(Stateful) | 상태비저장(Stateless) |
| 규칙 종류 | 허용 규칙만 가능 | 허용 및 거부 규칙 가능 |
| 기본 동작 | 모든 트래픽 거부(deny all) | 기본적으로 모든 트래픽 허용 |
| 규칙 처리 순서 | 모든 규칙을 평가 | 우선순위가 높은 규칙부터 평가 |
| 적용 리소스 | 하나의 인스턴스에 여러 보안 그룹 연결 가능 | 하나의 서브넷에 하나의 NACL만 연결 가능 |
| 응답 트래픽 처리 | 요청 트래픽 허용 시 응답 트래픽 자동 허용 | 요청 트래픽 허용 시 응답 트래픽은 별도로 허용 필요 |
활용 사례
- 보안 그룹 사용:
- 애플리케이션 서버, 데이터베이스 등 개별 리소스에 세부 보안 설정 필요.
- 상태풀 동작이 유리한 경우.
- 네트워크 ACL 사용:
- 서브넷 전체 트래픽을 관리해야 할 때.
- 허용과 거부 규칙을 명확히 정의해야 할 때.
- 서브넷에 적용되는 기본 보안 계층으로 사용.
보안 그룹(SG)과 네트워크 ACL(NACL)은 AWS VPC의 필수 보안 구성 요소이다.
SG는 인스턴스 수준에서 세부적으로 트래픽을 제어하며, NACL은 서브넷 수준에서 전반적인 트래픽 흐름을 관리한다.
두 방화벽을 조합하여 AWS 리소스의 보안을 강화할 수 있다.
AWS Client VPN
: 고객의 컴퓨터(Windows, Mac, Linux)를 AWS VPC에 연결하는 가상 사설 네트워크(VPN) 서비스
- 암호화된 네트워크 연결을 통해 인터넷을 거쳐 안전하게 VPC 내부 리소스와 통신할 수 있다.
- VPC 내부의 사설 IP 주소를 사용하여 EC2 인스턴스나 다른 리소스와 직접 연결 가능.
주요 구성 요소
1. VPN 엔드포인트 (VPN Endpoint)
- 역할:
클라이언트와 VPC 간의 연결을 설정하는 접속 지점으로, VPC 내부 리소스와의 통신을 가능하게 한다. - 서브넷 연결:
- VPN Endpoint는 VPC 내의 특정 서브넷과 연결되며, 이 서브넷에서 네트워크 인터페이스(Network Interface)가 생성된다.
- 클라이언트는 이 인터페이스를 통해 VPC 리소스(예: EC2 인스턴스)와 통신한다.
- 암호화된 연결:
- SSL/TLS(포트 443)를 통해 암호화된 연결을 생성하여 안전한 통신을 보장한다.
- 클라이언트의 네트워크 주소를 VPC CIDR 블록으로 변환해 NAT(Network Address Translation)를 수행, VPC 리소스에 접근을 가능하게 한다.
2. 클라이언트 소프트웨어
- 역할:
- 사용자가 VPN 연결을 설정하기 위해 설치하는 소프트웨어
- AWS에서 소프트웨어를 제공하지 않으므로, 오픈 소스 또는 무료 VPN 클라이언트 소프트웨어를 사용해야 한다.
- 작동 방식:
- 클라이언트 소프트웨어는 VPN Endpoint와 SSL/TLS 암호화된 연결을 설정하며, 이를 통해 안전하게 VPC 내부 리소스에 접근할 수 있다.
3. 서브넷 (Subnet)
- VPN 네트워크 인터페이스:
- VPN Endpoint는 연결된 서브넷에서 네트워크 인터페이스를 생성한다.
- 이 인터페이스를 통해 클라이언트와 VPC 리소스(EC2, RDS 등)가 통신하게 된다.
- 라우팅:
- 서브넷의 라우트 테이블을 설정하여 클라이언트 트래픽을 허용하고, VPC 리소스로 올바르게 전달되도록 구성해야 한다.
- 클라이언트는 사설 IP 주소를 통해 서브넷 내 리소스와 안전하게 통신한다.
4. CIDR 블록
- 역할:
- 클라이언트 VPN의 네트워크 주소(CIDR 블록)와 VPC 내부 네트워크(CIDR 블록)를 정의해야 한다.
- 클라이언트 VPN의 사설 네트워크 주소는 VPC CIDR 블록과 겹치지 않아야 하며, NAT를 통해 변환된다.
작동 흐름
- VPN Endpoint 생성: VPC 내 서브넷과 연결되어 클라이언트의 접속 지점 역할을 한다.
- 클라이언트 소프트웨어 설정: 사용자는 VPN 클라이언트를 설치하고, 암호화된 SSL/TLS 연결을 설정해 VPN Endpoint와 통신한다.
- 네트워크 주소 변환 (NAT): 클라이언트의 CIDR 블록 주소가 VPC CIDR 블록 주소로 변환되어 리소스에 접근할 수 있다.
- 라우트 테이블 구성: 서브넷 내 라우트 테이블이 클라이언트와 VPC 리소스 간의 트래픽을 허용하도록 설정된다.

사용 사례
- 온프레미스와 AWS 간의 연결: 온프레미스 환경에서 AWS VPC 내부의 사설 리소스(EC2 인스턴스나 RDS 데이터베이스)
에 접근할 때 사용. - 원격 근무 환경: 원격 근무자가 인터넷을 통해 VPC 내부의 사내 네트워크 리소스에 안전하게 접근할 수 있도록 제공.
- 보안이 중요한 데이터 통신: 인터넷을 통해 AWS에 연결하면서도 데이터를 암호화하여 민감한 정보를 보호.
AWS Client VPN은 인터넷을 통해 안전하고 암호화된 연결을 제공하여 원격 사용자가 VPC 내부 리소스에 접근할 수 있도록 돕는다.
VPN Endpoint, 클라이언트 소프트웨어, CIDR 블록, 라우트 테이블 등을 통해 VPC 내부 리소스와 안전하게 연결하는 강력한 솔루션이다.
AWS Site-to-Site VPN
: 고객의 데이터 센터(또는 사무실)와 AWS VPC를 암호화된 VPN 터널을 통해 안전하게 연결하는 서비스
- IPSec 기반 암호화를 사용하여 인터넷을 통해 트래픽을 보호하며, 사설 네트워크와의 안전한 통신을 제공한다.
주요 구성 요소
- Virtual Private Gateway (VGW)
- AWS 측의 게이트웨이로, VPC에 배포되어 고객 데이터 센터와의 암호화된 트래픽을 처리한다.
- VPN 연결의 끝점 역할을 하며, 데이터를 VPC로 전달한다.
- Customer Gateway (CGW)
- 고객 데이터 센터 또는 사무실에 배치된 장치(하드웨어 또는 소프트웨어).
- VGW와 함께 VPN 연결을 설정하고 암호화된 트래픽을 주고받는다.
- VPN Connection
- VGW와 CGW 간에 설정되는 암호화된 터널
- 인터넷을 통해 트래픽을 안전하게 전송하며, 두 터널(Active/Standby)로 구성되어 장애 대비를 지원한다.
- 라우트 테이블
- 트래픽 경로를 정의하여 VPC와 데이터 센터 간 통신을 설정한다.
- 데이터 센터의 CIDR 블록과 VGW ID를 연결하여 트래픽이 올바른 터널을 통해 이동하도록 구성된다.
작동 흐름
- VPN 설정
- AWS에서 Virtual Private Gateway(VGW)를 생성하고 VPC에 연결한다.
- 고객 데이터 센터 측에서 Customer Gateway(CGW)를 설정하여 AWS와 통신할 준비를 한다.
- VPN 연결 생성
- VGW와 CGW 간에 IPSec 암호화 터널을 생성한다.
- 인터넷을 통해 데이터를 안전하게 주고받는 터널을 두 개 생성(Active/Standby)하여 가용성을 확보한다.
- 라우팅 구성
- AWS 라우트 테이블에 데이터 센터의 CIDR 블록을 목적지로 추가한다.
- 트래픽이 VPN 터널을 통해 VPC로 라우팅되도록 설정한다.
- 트래픽 터널링
- 고객의 데이터 센터와 AWS VPC 간 사설 IP 주소를 사용하여 암호화된 연결을 통해 안전하게 통신한다.
- 트래픽은 터널을 통해 인터넷을 거치면서도 암호화되므로 보안이 유지된다.

사용 사례
- 데이터 센터와 VPC 연결
- 고객의 데이터 센터 또는 사무실 네트워크를 AWS VPC와 안전하게 연결한다.
- 인터넷을 통한 트래픽은 암호화된 VPN 터널로 보호되며, 온프레미스 리소스와 클라우드 리소스 간 통신이 가능하다다.
- 백업 연결
- AWS Direct Connect를 사용 중인 환경에서 Site-to-Site VPN을 백업 연결로 활용하여 네트워크 가용성을 높일 수 있다.
- Direct Connect 장애 시 VPN으로 트래픽을 전환해 서비스 중단을 방지한다.
- 하이브리드 클라우드 환경
- 온프레미스 데이터 센터와 AWS 클라우드를 통합하여 하이브리드 인프라를 구축한다.
AWS Direct Connect (DX)
: 고객의 데이터 센터(또는 사무실)와 AWS 간의 전용 네트워크 연결을 제공하는 서비스
- 공용 인터넷을 우회해 대역폭 제약, 네트워크 지연, 혼잡을 방지하며 안정적이고 빠른 연결을 보장한다.
주요 구성 요소
- 물리적 연결
- AWS와 고객 데이터 센터 간에 전용 광섬유 연결을 설정한다.
- 고객의 네트워크 장비와 AWS Direct Connect 로케이션 장비를 Cross Connect로 연결한다.
- Virtual Interface (VIF)
- AWS 리소스와의 연결을 위한 가상 인터페이스
- 유형:
- Private VIF: VPC와의 연결.
- Public VIF: S3, DynamoDB 같은 AWS 공용 서비스와의 연결.
- Hosted VIF: AWS 파트너를 통해 설정하며 낮은 속도 옵션 제공(50Mbps~500Mbps).
- Virtual Private Gateway (VGW)
- Private VIF를 통해 Direct Connect와 AWS VPC를 연결한다.
- 데이터를 AWS VPC 내 리소스로 전달하는 중계 역할을 한다.
- Customer Gateway (CGW)
- 고객 측 네트워크 장비로, AWS와의 Direct Connect 연결을 관리한다.
- 라우팅 및 트래픽 제어를 담당한다.

작동 흐름
- 물리적 연결 설정
- 고객의 네트워크 장비와 AWS Direct Connect 로케이션의 장비를 Cross Connect로 연결한다.
- 이 물리적 연결을 통해 AWS와 고객 데이터 센터 간 네트워크 통신이 가능해진다.
- Virtual Gateway 생성
- AWS에서 Virtual Private Gateway (VGW)를 생성하고, 이를 VPC에 연결한다.
- VPC와 Direct Connect 간의 통신 경로를 설정한다.
- Virtual Interface (VIF) 생성
- Private VIF: AWS VPC와 연결하여 내부 리소스와 통신.
- Public VIF: AWS의 공용 서비스(S3, DynamoDB 등)와 연결.
- 고객의 요구에 따라 VIF 유형을 선택해 설정한다.
- 라우팅 구성
- 라우트 테이블을 설정해 Direct Connect를 통해 트래픽을 AWS 리소스로 전송한다.
- 정적 라우팅 또는 동적 라우팅(BGP)을 사용할 수 있다.
- 데이터 송수신
- 설정된 네트워크를 통해 데이터 센터와 AWS 간 데이터를 안정적이고 빠르게 전송한다.
사용 사례
- 대량 데이터 전송
- 대규모 데이터를 AWS로 이전하거나 정기적으로 백업할 때.
- 예: 빅데이터 분석, 클라우드 스토리지로 데이터 마이그레이션.
- 하이브리드 클라우드 환경
- 온프레미스 데이터 센터와 AWS를 연결해 하이브리드 클라우드 인프라를 구축한다.
- 성능이 중요한 애플리케이션
- 짧은 네트워크 지연이 필수적인 실시간 데이터 처리 애플리케이션에 적합합니다.
- 예: 금융 트랜잭션, 온라인 게임, 실시간 분석 애플리케이션.
AWS Direct Connect는 안정성, 성능, 일관성이 중요한 워크로드에 적합하며, 대량 데이터 전송 및 하이브리드 클라우드 환경 구축에서 강력한 솔루션을 제공한다.
Direct Connect vs Site-to-Site VPN
| Direct Connect | Site-to-Site VPN | |
|---|---|---|
| 연결 유형 | 전용 물리적 연결 | 인터넷 기반 암호화된 연결 |
| 암호화 | 제공되지 않음 (VPN 필요) | 기본적으로 IPSec 암호화 지원 |
| 속도 | 최대 100Gbps (고속) | 인터넷 기반 (일반적으로 느림) |
| 비용 | 초기 설정 비용 높음, 데이터 송신 비용 절감 | 비용 효율적 (인터넷 기반) |
실제 비즈니스 시나리오: Lambda 함수와 온프레미스 데이터베이스 통신
한 회사는 AWS Direct Connect를 통해 온프레미스 데이터 센터와 AWS 간의 네트워크 연결을 보유하고 있다. 이 회사는 AWS Lambda 함수가 온프레미스 데이터 센터의 프라이빗 서브넷에 위치한 데이터베이스에 접근해야 하는 요구 사항이 있다.
- 요구사항:
- Lambda 함수와 온프레미스 데이터베이스 통신
- Lambda 함수가 실행 중인 AWS VPC에서 온프레미스 데이터 센터의 프라이빗 네트워크로 트래픽을 안정적으로 라우팅할 수 있어야 한다.
- Lambda 함수는 VPC에 통합되어야 하며, 보안 그룹을 사용해 데이터베이스 접근 권한을 제어해야 한다.
- Lambda 함수와 온프레미스 데이터베이스 통신
- 솔루션:
- Lambda 함수 VPC 통합 설정:
- Lambda 함수를 VPC 내 서브넷에서 실행되도록 설정한다.
- VPC에 통합된 Lambda 함수는 VPC의 네트워크 환경을 사용하여 온프레미스 데이터 센터와 연결된다.
- 보안 그룹 설정:
- Lambda 함수에 적절한 보안 그룹을 적용하여 데이터베이스 트래픽을 허용한다.
- 보안 그룹에서 온프레미스 데이터 센터의 IP 범위와 데이터베이스 포트(예: MySQL의 경우 TCP 3306)를 허용하도록 규칙을 설정한다.
- Lambda 함수 VPC 통합 설정:
기본적으로 AWS Lambda 함수는 AWS 네트워크에서 실행되며, 별도의 VPC 설정이 없는 경우 인터넷을 통해 리소스에 접근한다.
그러나 Lambda 함수를 VPC 내에서 실행되도록 설정하면, Lambda 함수가 VPC의 네트워크 환경에 통합된다.
이렇게 설정하면 Lambda 함수가 VPC 내부의 서브넷과 연결되어 Direct Connect를 통해 온프레미스 데이터 센터와 연결될 수 있다.
'AWS' 카테고리의 다른 글
| AWS 데이터 분석: Athena, Glue, Redshift, EMR (2) | 2024.12.18 |
|---|---|
| AWS 실시간 데이터 처리: Amazon Kinesis (1) | 2024.12.17 |
| AWS EC2 Auto Scaling & Load Balancing (3) | 2024.12.16 |
| AWS EC2(Elastic Compute Cloud) (2) | 2024.12.16 |
| AWS IAM (Identity and Access Management) (2) | 2024.12.13 |