[AWS] VPC 생성하기 전 알아야 할 내용들
클라우드 인프라 운영 1주차
VPN(Virtual Private Network)
인터넷을 통해 디바이스 간에 사설 네트워크 연결을 생성.
VPN 의 기본적인 역할은 멀리 떨어진 네트워크 환경을 하나의 안전한 네트워크로 만드는 것.
왜 사용할까?
VPN 서비스는 주로 인터넷을 통해 데이터를 안전하게 전송하는 데 사용된다.
- 개인정보 처리방침
가상 사설 네트워크가 없으면 암호, 신용 카드 정보 및 검색 기록과 같은 개인 데이터가 기록되고 서드 파티에서 판매될 수 있습니다.
VPN은 암호화를 사용하여 특히 퍼블릭 Wi-Fi 네트워크를 통해 연결할 때 이 기밀 정보를 프라이빗으로 유지합니다.
- 익명
VPN 연결은 인터넷에서 익명을 유지하기 위해 IP 주소를 숨깁니다.
- 보안
VPN 서비스는 암호화를 사용하여 무단 액세스로부터 인터넷 연결을 보호합니다.
웹 활동이 퍼블릭 Wi-Fi를 통해 이루어지기 때문에 이러한 유형의 인터넷 연결은 해킹에 취약합니다.
보안되지 않은 퍼블릭 Wi-Fi 핫스팟에 연결할 때 VPN 서비스를 사용하면 데이터와 디바이스를 모두 안전하게 보호할 수 있습니다.
기업에서 특히 VPN 을 사용하는 이유
VPN은 원격 사용자를 사무실 네트워크에 연결하는 효율적이고 빠르고 안전한 방법입니다.
VPN 연결은 값비싼 전용 LAN 또는 WAN 링크 또는 장거리 원격 전화 접속 링크와 비교하여 고대역폭의 프라이빗 인터넷 액세스를 회사에 제공합니다.
VPC(Amazon Virtual Private Cloud)
사용자가 정의한 가상 네트워크로 AWS 리소스를 시작 할 수 있게 해준다.
또한 의심스러운 인터넷 활동이 있을 경우 미리 선택된 프로그램을 끝내는 종료 메커니즘 역할을 할 수도 있습니다.
VPC 를 사용하는 이유
- VPC 별로 네트워크를 구성할 수 있다. VPC 별로 필요한 설정을 통해 인스턴스에 네트워크 설정을 적용할 수 있다
VPC 를 만들지 않고 인스턴스를 생성하는 경우 AWS 에서 제공하는 Default VPC 를 사용하게 된다.
결국, VPC를 통해 인스턴스가 속하는 네트워크를 구분하여 각 네트워크에 맞는 설정을 부여할 수 있다.
일반적으로 보안을위해 AWS 리소스간 허용을 최소화하고 그룹별로 손쉽게 네트워크를 구성하기위해 많이 사용.
VPC 생성하기 전 알아야 할 사전 지식
CIDR (Classless Inter-Domain Routing)
-
>172.16.0.0/16
Subnet
하나의 네트워크가 분할되어 나눠진 작은 네트워크
네트워크를 운영중인 서비스의 규모에 맞게 분할 하여, 낭비되는 IP주소 자원을 최소화하려는 것이 주된 목적.
각각의 서브넷은 가용영역안에 존재하며 서브넷안에 RDS, EC2와같은 리소스들을 위치시킬 수 있습니다.
- public subnet
Internet Gateway 연결을 통해서 외부와 통신 가능하다.
- private subnet
기본적으로 외부와 차단. 다른 서브넷 끼리의 통신만 가능.
AWS 에서 subnet 이용할때 주의점 (예약 되어 있는 IP)
https://memory-hub.tistory.com/11 참조.
라우팅
- VPC 내부 에서의 네트워크 통신은 라우터가 담당.
- 하지만, 그 외의 외부로 통하는 트래픽을 처리할 수 없다.
- 이때 인터넷 게이트웨이를 사용.
인터넷 게이트웨이
VPC 와 인터넷을 연결해주는 하나의 관문.
- 서브넷 B 라우팅 테이블을 보면, 모든 트래픽에 한해서 IGA A 로 향하라고 되어있다.
- 먼저 172.31.0.0 에 매칭되는지 확인 후, 안될경우 IGA A 로 보냄.
- private subnet 은 당연하지만 연결 X.
네트워크 ACL 과 보안그룹
ACL (Access Control List) : 서브넷 내부와 외부의 트래픽을 제어하기 위한 방화벽 역활을 하는 VPC 선택적 보안 계층.
규칙 목록은 번호가 낮은 거 부터 우선순위로 적용.
연결된 서브넷의 모든 인스턴스에 자동 적용.
ACL과 보안그룹이 충돌한다면 보안그룹이 더 높은 우선순위를 갖음.
보안그룹 : 인스턴스에 대한 인바운드, 아웃바운드 제어하는 가상의 방화벽 역할.
서브넷 수준이 아닌 인스턴스 수준에서 작동 (각각의 인스턴스 별로 적용 가능.)
상태 저장
NAT Gateway
프라이빗 서브넷의 인스턴스가 VPC 외부의 서비스에 연결할 수 있지만 외부 서비스에서 이러한 인스턴스와의 연결을 시작할 수 없도록 NAT 게이트웨이를 사용.
- public 방식 (기본값)
- 퍼블릭 서브넷에서 퍼블릭 NAT 게이트웨이를 생성하고 생성 시 탄력적 IP 주소를 NAT 게이트웨이와 연결
- NAT 게이트웨이에서 VPC용 인터넷 게이트웨이로 라우팅
- private 방식
- 프라이빗 NAT 게이트웨이를 통해 다른 VPC 또는 온프레미스 네트워크에 연결
- 트래픽을 NAT 게이트웨이에서 Transit Gateway 또는 가상 프라이빗 게이트웨이를 통해 트래픽을 라우팅.
- 프라이빗 NAT 게이트웨이를 사용하여 VPC에 인터넷 게이트웨이를 연결할 수 있지만 프라이빗 NAT 게이트웨이에서 인터넷 게이트웨이로 트래픽을 라우팅하는 경우 인터넷 게이트웨이가 트래픽을 삭제합니다.
NAT 게이트웨이는 인스턴스의 소스 IP 주소를 NAT 게이트웨이의 IP 주소로 바꿉니다.
퍼블릭 NAT 게이트웨이의 경우 이것은 NAT 게이트웨이의 탄력적 IP 주소입니다.
프라이빗 NAT 게이트웨이의 경우 이것은 NAT 게이트웨이의 프라이빗 IP 주소입니다.
인스턴스에 응답 트래픽을 전송할 때 NAT 디바이스는 주소를 원래 소스 IP 주소로 다시 변환합니다.
VPC 엔드포인트
VPC 내 리소스 들이 VPC 외부의 AWS 서비스 (S3, Dynamo DB, CloudWatch) 등에 접근 할때,
InternetGateway 나 NAT Gateway 등의 외부 전송 서비스를 타지 않고도 아마존의 백본 네트워크를 통해 접근 할 수 있도록 지원하는 서비스.엔드포인트는 VPC에서 S3에 직접 액세스하여 NAT 게이트웨이 요금을 줄이고 보안을 강화할 수 있습니다. 기본적으로 모든 액세스 정책이 사용됩니다. 언제든지 이 정책을 사용자 지정할 수 있습니다.
테넌시
- 멀티 테넌시
여러 AWS 계정이 동일한 물리적 하드웨어를 공유하는 방식.
- 전용 테넌시
하드웨어 A에 사용자 A의 인스턴스만 들어가는 방식. 사용자 B의 인스턴스는 들어올 수 없음. 물리적으로 분리됨.
질문
- 프라이빗 NAT 게이트웨이를 사용하여 VPC에 인터넷 게이트웨이를 연결할 수 있지만 프라이빗 NAT 게이트웨이에서 인터넷 게이트웨이로 트래픽을 라우팅하는 경우 인터넷 게이트웨이가 트래픽을 삭제합니다.
결국 private NAT Gateway 를 사용하면, 인터넷 게이트웨이를 통해서는 외부로 나갈수 없는 것인가?’
-
가용영역과 서브넷수의 상관관계 ??
- 전용테넌시 를 굳이 사용하는 이유?
성능, 보안 등의 차이가 없다고 알고 있다.
Leave a comment