VPC

박진선·2024년 5월 26일
0

Subent

VPC의 IP 주소를 나누어 리소스가 배치되는 물리적인 주소 범위를 뜻한다.

VPC가 논리적인 범위를 의미한다면, 서브넷은 VPC안에서 실제로 리소스가 생성될 수 있는 네트워크 영역이라고 생각하면 되며 EC2, RDS같은 리소스를 생성 할 수 있다.

하나의 VPC에 N개의 서브넷을 가질 수 있으며 하나의 AZ에만 생성이 가능하다.

CIDR 10.0.0.0/24 인 경우
10.0.0.0 네트워크 주소 (Network ID)
10.0.0.1 AWS에서 VPC 라우터용으로 예약 (Default Gateway)
10.0.0.2 DNS 서버 주소 DNS 서버의 IP 주소는 기본 VPC 네트워크 범위에 2를 더한 주소이다.CIDR 블록이 여러 개인 VPC의 경우, DNS 서버의 IP 주소가 기본 CIDR에 위치하게 된다.
10.0.0.3 AWS에서 앞으로 사용하려고 예약한 주소
10.0.0.255 네트워크 브로드캐스트 주소

서브넷은 다시 Public Subnet과 Private Subnet으로 나뉠 수 있다.
Private Subnet : 인터넷에 접근 불가능한 subnet (VPC 내부에서만 통신)
Public Subnet : 인터넷에 접근 가능한 Subnet (VPC 외부/내부와 통신)

public subnet에 존재하는 인스턴스는 Public IP와 Elastic IP를 보유하여 인터넷에 연결되어 아웃바운드, 인바운드 트래픽을 주고받을 수 있는 반면, private subnet은 외부에 노출이 되어 있지 않기 때문에 접근할 수 없다.

이처럼 Private 서브넷 내부의 인스턴스들은 오직 다른 서브넷과만 연결이 가능한데
인터넷 연결이 필요할 경우 NAT instance를 통해서 인터넷 연결이 가능하다.

VPC 엔드 포인트(End Point)

VPC 내 Resource들이 VPC 외부의 서비스(S3, Dynamo DB, Cloudwatch) 등에 접근할 때 Internet Gateway, NAT Gateway 등의 외부 인터넷 전송 서비스를 타지 않고 내부 네트워크를 통해 접근할 수 있도록 지원하는 서비스이다.

VPC 내부에 EC2, RDS, ELB 등을 탑재하고 ENI(Elastic Network Interface)에 사설 IP 혹은 공인 IP를 부여하여 사용한다.

그러면 다른 서비스는 어떨까? S3, Cloudwatch, Cloudfront, Dynamo DB, API Gateway ..등은 설정한 AWS의 Region 내에 존재하지만, VPC 내부에 설치하는 서비스들이 아니고 따로 공인 IP를 가지고 외부에서 접근하는 서비스들이다.

그렇다면 VPC 내의 Private Subnet에 위치한 EC2 인스턴스에서 S3에 대한 api를 호출하게 될 경우 흐름은 EC2(Private Subnet) → NAT Gateway → Router → Internet Gateway → 외부 인터넷 → S3 이와 같을 것이다.

통신에는 문제가 없어 보이지만 결국 VPC 내부 Resource와 기타 AWS Service Endpoint(EC2 API 호출, S3 접속 등)와 통신 시 외부 인터넷에 공개적으로 연결되며 트래픽이 노출된다.

즉 VPC Endpoint는 AWS 여러 서비스들과 VPC를 연결시켜주는 중간 매개체로서, AWS에서 VPC 바깥으로 트래픽이 나가지않고 AWS의 여러 서비스들을 사용할수있게 만들어주는 서비스 이다.

VPC 엔드포인트는 Interface Endpoint와 라우팅 테이블 기반의 Gateway Endpoint 두가지 종류로 나뉜다.
2개 유형의 차이점은 Interface Endpoint가 ENI(Elastic Network Interface)를 이용하여 IP가 할당되고 해당 IP로 Access를 하는 방식이라면, Gateway Endpoint는 Route Table을 이용하여 Endpoint에 Access한다는 점이다.

Interface Endpoint

ENI(Elastic Network Interface)을 기반으로 하여, private ip를 만들어 서비스를 연결한다.
프라이빗 서브넷 내부에 위치한다. SQS, SNS, Kinesis, Sagemaker, Athena등의 다양한 서비스를 지원한다.

Gateway Endpoint

Route Table을 이용하여 Endpoint에 Access한다.
라우팅 테이블에서 경로의 대상으로 지정하여 사용하고 VPC 내부에 위치한다.
S3, DynamoDB 만 지원한다.

통신과정 : Private Subnet에 위치한 EC2에서 만일 S3에 대한 api 호출 -> 라우팅 테이블을 보고 라우터로 가서 Gateway Endpoints 쪽으로 전송 -> Gateway Endpoints는 트래픽을 받고 S3로 전송

보안그룹(Security Group)

인스턴스에 대한 인바운드(외부 - > 인스턴스) & 아웃바운드(인스턴스 - > 외부) 트래픽을 제어하는 가상 방화벽 역할을 한다.

인스턴스는 EC2 인스턴스뿐만 아니라 VPC 내에 탑재될 수 있는 수많은 가상 컴퓨터를 의미하는데 정확히는 VPC 내에서 Elastic Network Inteface(ENI)를 갖는 모든 서비스에 탑재될 수 있다. Security Group은 인스턴스의 ENI에 적용되는 것이기 때문이다. RDS, ELB, VPC Interface Endpoint 등도 포함 가능

특정 정리

  • 보안 그룹은 인바운드 규칙과 아웃바운드 규칙으로 나뉜다.
  • 허용 규칙만 생성 가능하다.
    블랙 리스트 처럼 몇몇을 골라 특정 차단(Deny)이 불가능. 일부 허용을 통해서 간접 차단으로 구성은 가능(무언가를 차단하는 규칙은 Network ACL)
  • 기본적으로 모든 Security Group의 아웃바운드 규칙은 모든 아웃바운드 트래픽을 허용한다.
  • Security Group은 인스턴스 단위로 설정한다. 하나의 인스턴스에는 하나 이상의 Security Group 설정 가능하며 최대 5개 동시 적용 가능하다.
  • 상태를 저장하여 한 번 인바운드를 통과하는 트래픽은 아웃바운드의 규칙 적용을 받지 않는다.
  • 상태를 저장하여 한 번 아웃바운드를 통과하는 트래픽은 인바운드의 규칙 적용을 받지 않는다.

마지막 두 부분이 Securiy Group의 가장 큰 특징이라고 할 수 있는데
즉, 인바운드를 통해 온 트래픽이라는 소리는 문제없는 허용된 트래픽이라는 것이고 이를 보안 그룹에서 기억하고 있다가, 트래픽이 빠져 나갈때 이 트래픽은 문제없는 놈인걸 기억하기 때문에 아웃바운드 규칙에 구애 받지않고 나가는 것이다.

Network ACL (네트워크 액세스 제어)

Subnet 수준에서 특정 인바운드 또는 아웃바운드 트래픽을 허용하거나 거부하여 트래픽을 제어하는 역할을 한다.

Subnet 단위로 적용되기 때문에 Subnet 내의 모든 트래픽은 Network ACL의 규칙 적용을 받게 된다.

특정 정리

  • 인바운드 규칙과 아웃바운드 규칙으로 나뉜다.
  • 네트워크 ACL을 사용해도 추가 요금이 부과되지 않는다.
  • NACL은 여러 서브넷에 적용이 가능하다. 하지만 서브넷은 한개의 NACL만 연결이 가능하다.
  • 허용 규칙뿐만 아니라 거부 규칙 생성 가능하다. 누군가를 블럭하는건 NACL만 가능하다.
  • 규칙에 숫자가 매겨져 가장 작은 숫자값을 지니는 규칙이 우선적으로 적용된다.
  • NACL 규칙 목록은 인바운드, 아웃바운드 최대 20개까지 지정 가능하다.
  • 상태를 저장하지 않아 한 번 인바운드를 통과하는 트래픽은 아웃바운드의 규칙 적용을 받는다. (Stateless)
  • 상태를 저장하지 않아 한 번 아웃바운드를 통과하는 트래픽은 인바운드의 규칙 적용을 받는다. (Stateless)

Security Group처럼 마지막 두가지 특징이 중요한데 인바운드 규칙을 적용받아 유입된 패킷이 다시 밖으로 나가기 위해서는 아웃바운드 규칙의 적용을 받아야 한다.
규칙 순서의 경우 예를들어 100번 규칙은 80번 포트를 Allow하고 101번 규칙은 Deny 했을 경우 숫자가 작은 100번 규칙에서 80번 포트를 Allow 했기 때문에 101번 규칙 80번 포트를 Deny 는 무시된다.

관리형 접두사 목록 (Managed prefix lists)

하나 이상의 CIDR 블록 세트이다. 접두사 목록을 사용하면 보안 그룹과 라우팅 테이블을 보다 쉽게 구성하고 유지 관리할 수 있다.

두 가지 유형이 존재한다.

고객 관리형 접두사 목록

  • 사용자가 정의하고 관리하는 IP 주소 범위 세트이다.
  • 접두사 목록을 다른 AWS 계정과 공유하여 해당 계정이 자체 리소스의 접두사 목록을 참조하도록 할 수 있다.
  • 단일 IP 주소 지정 유형(IPv4 또는 IPv6)만 지원한다. IPv4 및 IPv6 CIDR 블록을 하나의 접두사 목록에 결합할 수 없다.
  • 해당 목록을 생성한 리전에만 적용된다.
  • 접두사 목록을 생성할 때 접두사 목록에서 지원할 수 있는 최대 항목 수를 지정해야하는데 예를 들어, 최대 항목이 20개인 접두사 목록을 만들고 보안 그룹 규칙에서 해당 접두사 목록을 참조하는 경우, 20개의 보안 그룹 규칙이 있는 것으로 계산된다.

AWS 관리형 접두사 목록

  • AWS 서비스의 IP 주소 범위 세트이다.
  • AWS 관리형 접두사 목록은 사용자가 직접 생성, 수정, 공유 또는 삭제할 수 없다.
profile
주니어 개발자 입니다

0개의 댓글