본문 바로가기

AWS

VPC 네트워크

728x90

인터넷 게이트웨이는 확장 가능하며 이중화를 지원하는 고가용성 VPC 구성 요소로서 VPC의 인스턴스와 퍼블릭 인터넷 간 통신이 가능한 이유이다

즉, VPC와 퍼블릭 인터넷을 연결해주는 역할이라고 생각하면 됨

 

게이트웨이

게이트웨이 사용 이유

1. 인터넷 트래픽에 대해 VPC 라우팅 테이블의 대상을 제공

2. 퍼블릭 IPv4 주소가 할당된 인스턴스의 네트워크 주소 변환 수행

 

서브넷을 퍼블릭으로 구성하려면, VPC에 인터넷 게이트웨이 연결, 서브넷과 연결된 라우팅 테이블에 라우팅 항목 추가

NAT(네트워크 주소 변환) 게이트웨이를 사용하면 프라이빗 서브넷의 인스턴스가 인터넷이나 다른 AWS 서비스에 연결할 수 있다

하지만 NAT 게이트웨이는 퍼블릭 인터넷이 이런 인스턴스와의 연결을 못하게 한다. 그래서 NAT 게이트웨이가 상주할 퍼블릭 서브넷을 지정해야 한다. NAT 게이트웨이를 생성할 때 이와 연결할 탄력적 IP주소도 생성해야 한다

NAT 게이트웨이를 생성하면 인터넷 바운드 트래픽이 NAT 게이트웨이를 가리키도록 하나 이상의 프라이빗 서브넷과 연결된 라우팅 테이블을 업데이트 해야한다

=> 프라이빗 서브넷의 인스턴스가 인터넷과 통신할 수 있게 됨!

정리) NAT 게이트웨이로 서브넷의 인스턴스가 인터넷과 연결시키기 위해 NAT 게이트웨이가 자리 잡고 있어야 할 퍼블릭 서브넷과 탄력적 IP주소를 만든다. 그리고 프라이빗 서브넷과 연결된 라우팅 테이블을 업데이트 하면 된다

https://medium.com/@me.sanjeev3d/amazon-vpc-3934510aa74a

바운드 트래픽 : 인바운드와 아웃바운드로 나뉘는데, 인바운드는 외부에서 가상서버 내부로 데이터가 유입될 때 발생하는 트래픽. 아웃바운드는 인바운드 트래픽과 반대로, 가상서버 내에서 외부로 데이터가 전송되었을 때의 트래픽

트래픽은? 서버와 스위치 등 네트워크 장치에서 일정 시간 내에 흐르는 데이터의 양

 

 

VPC 공유

VPC 공유를 하면 여러 AWS 계정에서 EC2 인스턴스, RDS, Lambda 함수와 같은 애플리케이션 리소스를 중앙 관리형 공유 VPC로 생성 가능하다

VPC 소유 계정은 다른 계정과 서브넷을 공유한다 -> 공유된 서브넷의 해당 애플리케이션의 리소스를 보고, 생성, 수정, 삭제를 참여자가 할 수 있다

 

 

VPC 피어링

두 VPC 간에 트래픽을 프라이빗으로 라우팅할 수 있다. 

https://docs.aws.amazon.com/ko_kr/vpc/latest/peering/what-is-vpc-peering.html

양쪽 VPC의 인스턴스가 동일한 네트워크에 있는 것처럼 서로 통신할 수 있다

자체 VPC 간에 VPC 피어링 연결을 생성하거나 다른 AWS 계정에 속한 VPC나 다른 리전에 있는 VPC와도 가능

VPC 피어링을 연결할 때는 서로 통신할 수 있도록 라우팅 테이블에 규칙을 생성함

 

VPC A의 라우팅 테이블에서 대상 위치를 VPC B의 IP주소로 설정한다. 대상은 피어링 연결 리소스 ID로 설정.

VPC A의 라우팅 테이블
대상 위치 대상
10.0.0.0/16 로컬
172.31.0.0/16 피어링 연결 리소스 ID

VPC B도 마찬가지.

VPC B의 라우팅 테이블
대상 위치 대상
172.31.0.0/16 로컬
10.0.0.0/16 피어링 연결 리소스 ID

제한 사항

1. IP 주소 범위 중첩 X

https://docs.aws.amazon.com/ko_kr/vpc/latest/peering/invalid-peering-configurations.html

2. 동일한 두 VPC 간에는 하나의 피어링 리소스만 설정 가능

https://docs.aws.amazon.com/ko_kr/vpc/latest/peering/invalid-peering-configurations.html

3. 전이적 피어링 지원X

https://docs.aws.amazon.com/ko_kr/vpc/latest/peering/invalid-peering-configurations.html

전이적 피어링이 뭔 말인진 모르겠지만, B와 C 사이에 VPC 피어링 연결이 없는데 A를 통해서 B에서 C로 직접 패킷을 라우팅할 수 없다는 이야기

 

 

AWS 사이트 간 VPC

Amazon VPC로 시작하는 인스턴스는 자체 원격 네트워크와 통신 불가

-> VPC에 가상 프라이빗 게이트웨이를 연결하고, 사용자 지정 라우팅 테이블을 생성, 보안 그룹 규칙 업데이트, AWS 사이트 간 VPN 연결을 생성하고 연결에 트래픽을 전달하도록 라우팅을 구성하여 VPC에서 원격 네트워크에 액세스하도록 할 수 있다

 

 

AWS Direct Connect

네트워크 성능은 중요!

데이터 센터가 AWS 리전에서 멀리 떨어져 있으면 성능이 좋지 못할 수도 -> 그래서 AWS Direct Connect

AWS Direct Connect를 사용하면 네트워크와 Direct Connect 로케이션 중 하나 간에 전용 프라이빗 연결을 설정할 수 있음

이 프라이빗 연결은 대역폭 처리량을 높이고 인터넷 기반 연결이나 VPN 연결보다 일관된 네트워크 환경을 제공

802.1q 가상 로컬 영역 네트워크 사용

 

 

VPC 엔드포인트

VPC를 DynamoDB나 S3 등 서비스에 연결해야 할 때 사용하는 가상 디바이스

VPC 게이트웨이 엔드포인트는 S3나 DynamoDB로 전달되는 트래픽(위에서 말했쥬?!)에 대한 라우팅 테이블에서 경로의 대상으로 지정하는 게이트웨이

트래픽은 비공개

VPC PrivateLink는 VPC 인터페이스 엔드포인트가 필요. 퍼블릭 인터넷에 데이터가 노출되지 않도록 클라우드 기반 애플리케이션과 공유된 데이터 보안을 간소화함. 비공개 연결 제공. 여러 계정과 VPC에 걸쳐 쉽게 서비스에 연결해 네트워크 아키텍처가 간소화됨

 

 

수백 개의 VPC를 서로 어떻게 연결할까? 그럴 때 사용하는

AWS Transit Gateway

가상 사설 클라우드를 상호 연결하는 데 사용하는 네트워크 전송 허브

온프레미스 네트워크 연결 가능

VPC, AWS Direct Connect, 게이트웨이, VPN이 연결 가능

필요한 연결 수와 구현의 복잡성이 줄어듦

 

 

 

728x90

'AWS' 카테고리의 다른 글

Amazon Route 53는 뭐야?  (0) 2022.07.12
VPC 보안그룹 | 네트워크 ACL  (0) 2022.07.12
Amazon VPC  (0) 2022.07.12
네트워크 개념정리  (0) 2022.07.11
AWS 데이터 보안 | 규정 준수  (0) 2022.07.11