AWS SAA : VPC

AWS 자격증 공부/AWS SAA-C03

AWS SAA : VPC

sseldne0 2024. 12. 21. 20:44

CIDR

클래스 없는 도메인간 라우팅

IP주소 할당 방법 → 단순한 IP 범위를 정의하는데 도움을 줌

구성 요소

Base IP : 기본 IP → 범위에 포함된 IP
Subnet Mask : IP에서 변경 가능한 비트 개수
- /0 : 0.0.0.0 ⇒ 모든 옥텟 변경
- /8 : 255.0.0.0 ⇒ 마지막 3개 옥텟 변경
- /16 : 255.255.0.0 ⇒ 마지막 2개 옥텟 변경
- /24 : 255.255.255.0 ⇒ 마지막 옥텟만 변경
- /32 : 255.255.255.255 ⇒ 옥텟 변경 X

Public vs Private IP (IPv4)

IANA에서 발급한 IPv4 주소 → private, public 주소임

private IP : 특정 값만 허용
- 10.0.0.0 - 10.255.255.255 = 10.0.0.0/8 ← big network
- 172.16.0.0 - 172.31.255.255 = 172.16.0.0/12 ← AWS default VPC
- 192.168.0.0 - 192.168.255.255 = 192.168.0.0/16 ← home
public IP : private을 제외한, 인터넷상의 모든 IP

Default VPC

새로운 AWS 계정 : 모두 default VPC가 있음
새로운 EC2 instance : 서브넷 지정안하면 default VPC에 실행됨
기본적으로 public 인터넷 연결이 되어있음
public / private IPv4 DNS 이름을 가짐

VPC in AWS - IP4

VPC = Virtual Private Cloud
단일 AWS 리전에 여러 VPC 가질 수 있음
VPC 하나당 CIDR는 최대 5개지만 유연하게 조정 가능
Private IPv4 범위만 허용
- 10.0.0.0 - 10.255.255.255 (10.0.0.0/8)
- 172.16.0.0 - 172.31.255.255 (172.16.0.0/12)
- 192.168.0.0 - 192.168.255.255 (192.168.0.0/16)
VPC CIDR가 다른 VPC나 네트워크, 기업 네트워크와 겹치지 않도록 함

Subnet

VPC 내부에 있는 IP 주소의 부분 범위
서브넷마다 IP 주소 5개 예약 : first 4, last 1 → 사용불가한 부분
- ex. CIDR = 10.0.0.0/24
  - 10.0.0.0 : 네트워크 주소
  - 10.0.0.1 : VPC router
  - 10.0.0.2 : Amazon-provided DNS
  - 10.0.0.3 : 나중을 위해 예약
  - 10.0.0.255 : Network Broadcast : AWS 는 VPC 브로드캐스트 지원 안하기 때문에 예약은 가능, 사용은 불가능
EC2 인스턴스 서브넷에서 IP주소가 29개 필요할 때, /27은 사용하지 못함
- /27은 불가능함 = 2^5 = 32 IP주소 - 5개 예약 = 27개
- /26은 가능함 = 2^6 = 64 IP주소 - 5개 예약 = 59개

Internet Gateway (IGW)

VPC resource를 인터넷에 연결하도록 허용
수평 확장, 가용성과 중복성이 높음
VPC와는 별개로 생성해야 함
VPC : IGW = 1 : 1
IGW 자체는 인터넷 액세스를 허용 X
라우팅 테이블 수정 필요

Bastion Hosts

public internet의 사용자가 private subnet에 없는 EC2 인스턴스에 액세스하고자 할 때 사용
public subnet에 있는 bastion hosts를 통해 private EC2 instance에 SSH로 액세스
Bastion Host Security group : 인터넷 액세스 허용 but, 보안상 위험이 있으므로, 기업의 public CIDR 액세스나 사용자의 인터넷 액세스만 허용하도록 함
EC2 instance Security group : SSH 액세스 허용 ← Bastion Host의 보안 그룹 / Bastion Host의 private IP

NAT Instance

Network Address Translation
Allows EC2 instance in private subnet to connect to internet
public subnet에서 실행되어야 함
비활성화해야할 세팅 : Source / destination check
NAT Instance에는 고정된 탄력 IP가 연결되어야 함
Bastion Host 사용 O, 보안 그룹 사용 O
작동방식
- Private Subnet에 존재하는 EC2 Instance가 Server에 연결하고 싶을 때, Public Subnet에 존재하는 NAT Instance에 요청을 보냄. 이때, Route Table에 해당 관계가 명시되어 있어야 함.
- NAT Instance에 달려있는 Elastic IP를 활용하여 Server에 접근하고, Server에서는 답변을 다시 Elastic IP로 보냄.
- Elastic IP는 다시 요청을 보낸 EC2 instance로 답변을 보냄.
NAT Instance 보다는 NAT Gateway 사용을 권장함

NAT Gateway

관리형 NAT Instance, 높은 대역폭을 가짐, 가용성이 높음, 관리 필요 X
사용량, 대역폭에 따라 가격 청구됨
특정 AZ에서 생성되고, 탄력IP를 이어받음
다른 서브넷에서 액세스할 때만 도움됨
IGW가 있어야 함. (Private Subnet → NATGW → IGW)
보안 그룹 관리 X, Bastion Host 사용 X
작동방식
- Private Subnet에 존재하는 EC2 Instance가 Internet에 연결하고 싶을 때, Public Subnet에 존재하는 NAT Gateway에 요청을 보냄. 이때, Route Table에 해당 관계가 명시되어 있어야 함.
- 이미 NAT Gateway와 Internet Gateway는 연결되어있으므로, 바로 연결 가능

Security Groups & NACLs

NACL : 네트워크 ACL , 무상태 (Stateless)

서브넷 레벨에서 작동함
allow, deny rule 모두 가능
인바운드, 아웃바운드 모두 규칙을 평가함 → 들어갔어도 나갈 수 없을 수도 있음
서브넷을 오가는 트래픽을 제어하는 방화벽과 비슷함
서브넷마다 하나의 NACL이 붙어있음
NACL 규칙 : 숫자가 낮을수록 우선순위가 높음. 별 (*) 표시를 통해 일치하는 규칙이 없으면 모든 요청을 거부함.

Default NACL

연결된 서브넷을 가지고 인바운드와 아웃바운드의 모든 요청을 허용
매우 개방적이고, 이를 수정하지 않는 것을 권장함

Ephemeral Ports 임시 포트

클라이언트와 서버를 연결하려면 포트를 사용함
클라이언트는 기본적으로 개방된 포트가 없어서, 클라이언트가 서버에 접속할 때 자체적으로 특정 포트를 열게 됨. 이 포트는 임시라서, 클라이언트와 서버간 연결이 유지되는동안만 열려있음.
임시 포트 : Connection Life (연결 수명)을 위해서만 할당되는 무작위 포트로, OS에 따라 포트 범위가 달라짐.

Security Group : 상태 유지 (Stateful)

인바운드 규칙 평가 O, 아웃바운드 규칙 평가 X → 들어간 요청은 전부 다시 나올 수 있음
인스턴스 레벨에서 작동함
allow 규칙만 적용됨

Incoming Request 작동 방식 : 외부에서 EC2로 접근

외부 요청이 Subnet 내 EC2 instance로 접근하고 싶음. 그렇기 위해서는 NACL에 요청을 보내야함. NACL에는 몇가지 인바운드 규칙이 적용되어있으므로, 허용되면 Subnet으로 들어감.
Subnet으로 들어가면, EC2 instance의 Security Group의 보안규칙에 따라, 허용될 경우 EC2 instance로 들어갈 수 있음.
EC2 instance의 결과값을 외부로 다시 보낼 때, SG는 Stateful이므로 그냥 나갈 수 있음.
Subnet에서 NACL 통해 외부로 보낼 때, NACL은 Stateless이므로 아웃바운드 규칙을 평가한 뒤, 허용되어야 나갈 수 있음.

Outgoing Request 작동 방식 : EC2에서 외부로 접근

Subnet 내 EC2 instance가 외부로 접근하고 싶음. 그렇기 위해서는 SG Outbound rule을 통과해야 함. 규칙이 적절하고 요청이 허가되면, NACL 아웃바운드 규칙을 통과해 외부로 접근할 수 있음.
외부에서 다시 들어올 때, NACL 인바운드 규칙을 통과해야 Subnet 내부로 들어올 수 있음.
Subnet에서 SG 통해 EC2 instance에 들어올 때, SG 인바운드 규칙은 위에서 통과했기 때문에 별도의 규칙 검사 없이 들어갈 수 있음.

VPC Peering

AWS network 를 사용하여 여러 VPC를 private하게 연결
같은 네트워크에 있는 것처럼 행동하게 만들고 싶을 때 사용
NOT Transitive : 서로 통신하려는 각 VPC에 VPC Peering이 활성화되어 있어야 함
- ex. A - B 연결, B - C 연결되어있어도 A - C 자동으로 연결 X. A - C 연결 따로 해줘야 함.
VPC가 쌍을 이루고 있더라도, 서로 다른 VPC의 EC2 인스턴스가 서로 통신할 수 있도록 각 VPC subnet의 route table을 업데이트해줘야 함.
다른 AWS 계정 / 리전의 VPC끼리도 연결할 수 있음.

VPC Endpoint

모든 AWS 서비스는 공개적으로 노출되어있음 (public URL)
만약 private하게 접근하고 싶다면, AWS 서비스에 VPC Endpoint를 추가하여 private network를 이용 가능
중복, 수평 확장이 가능함
IGW, NATGW 없이도 AWS 서비스에 접근 가능
Endpoint 종류
- Interface Endpoint (powered by privatelink)
  - Entry point로 ENI (private IP 주소) 프로비저닝
  - 대부분의 AWS 서비스 지원
  - 요금은 시간, 처리데이터 단위로 청구됨
  - 온프레미스와 같은 상황에서 선호되는 엔드포인트
- Gateway Endpoint
  - Gateway를 프로비저닝, SG 사용하지 않고, route table의 타겟이 되어야 함.
  - S3, DynamoDB에서만 지원됨
  - 무료 요금
  - 자동 확장 가능
  - 대부분 S3, DynamoDB에서는 Gateway Endpoint가 선호됨

VPC Flow Logs

인터페이스로 들어오는 IP 트래픽에서 정보 포착 가능
- VPC Flow Logs
- Subnet Flow Logs
- Elastic Network Interface (ENI) Flow Logs
VPC에서 일어나는 연결 문제를 모니터링하고, 트러블슈팅 가능
- Action 필드 확인 : NACL, 서브넷에 유입되는 통상적인 요청 확인
  - Incoming Requests
    - Inbound REJECT : NACL, SG 문제
    - Inbound ACCEPT, Outbound REJECT : NACL 문제
  - Outgoing Requests
    - Outbound REJECT : NACL, SG 문제
    - Outbound ACCEPT, Inbound REJECT : NACL 문제
Syntax
- srcaddr & dstaddr : 문제가 있는 IP 식별 가능
- srcport & dstport : 문제가 있는 port 식별 가능
- Action : 보안그룹, NACL 수준에서 성공 실패 식별 가능
Query : Athena on S3, CloudWatch Logs Insights 통해 쿼리 가능

AWS Site-to-Site VPN

VGW : Virtual Private Gateway
- VPN 연결에서 AWS 측에 있는 VPN concentrator
- VPC에 연결됨
CGW : Customer Gateway
- VPN 연결에서의 데이터 센터 : 소프트웨어 혹은 물리적 장치
Corporate Data Center ↔ VPC Site-to-Site VPN
- CGW : Public → 인터넷 라우팅 가능한 IP주소가 고객 게이트웨이 장치에 저장되어있고, 이를 이용해 VGW, CGW 연결
- CGW : Private → NAT-T를 활성화하는 NAT 장치 뒤에 있는 공용 IP를 사용해 VGW, CGW 연결
- Subnet의 VPC에서 Route Table의 Route Propagation을 활성화해야만, Site-to-Site VPN 연결 실제로 작동
- 온프레미스에서 AWS로 EC2 인스턴스 상태를 진단할 때, SG 인바운드 ICMP 프로토콜이 활성화됐는지 확인
AWS VPN CloudHub
- VGW를 갖춘 VPC가 있고, 고객 네트워크마다 CGW가 있을 때, 여러 VPN 연결을 통해 모든 사이트간 안전한 소통 보장
- 비용이 적게드는 허브 및 스포크 모델로 VPN만을 활용해 서로 다른 지역 사이 기본 및 보조 네트워크 연결성에 사용함
- public internet을 통하지만 보안을 유지할 수 있음
- dynamic routing 활성화, route table 구성

Direct Connect (DX)

원격 네트워크로부터 VPC로의 전용 private connection
VPC에 virtual private gateway 설치, 전용 연결 생성
같은 연결상에서 public resource와 private resource에 액세스
암호화는 되지 않지만, private하다는 점. 추가로 보안을 더하고 싶다면, Direct Connect와 VPN 함께 설치해서 IPsec으로 암호화된 프라이빗 연결 가능
Direct Connect 복원력 Resiliency
- High Resiliency for Critical Workloads
  - DX Location을 여러 개 만들고 그 안에는 각각 1개의 DX를 구성
- Maximum Resiliency for Critical Workloads
  - DX Location을 여러 개 만들고, 그 안에도 여러개의 DX를 구성
  - 여러 독립적인 연결을 하나 이상의 로케이션에서 각 장치에 연결
작동 방식
- AWS DX Location에 AWS Cage (AWS Direct Connect Endpoint), Customer Cage (Customer Router)가 존재함.
- Corporate Date Center 내 Customer Network 에는 Customer router, firewall이 존재함.
- 이때, Corporate에서 AWS Private Subnet의 EC2 Instance에 연결하고 싶다면, AWS DX를 private하게 거친다음, Subnet VGW에 접속해서 연결 가능.
- 혹은, Corporate에서 AWS Public Service (Glacier, S3..)에 연결하고 싶다면, AWS DX를 public하게 거친다음, Public VIF를 설치하여 바로 연결 가능.
Direct Connect Gateway : 다른 리전에 있는 하나 이상의 VPC와 연결하고 싶을 때 사용. 온프레미스 데이터 센터를 양쪽 VPC에 연결하기 전, Direct Connect Connection 생성한 뒤 private VIF를 통해 Gateway 연결해서 양쪽으로 모두 접근 가능하도록 만듬

Site-to-Site VPN Connection as a backup

Corporate Data Center에서 AWS VPC 로 연결할 때,
Direct Connect (DX)를 primary connection으로 사용
Site-to-Site VPN을 Backup connection으로 사용

Transit Gateway

VPC, On-premise, hub-and-spoke star connection 사이 연결
Transit Gateway를 통해 여러 VPC를 전이적으로 연결 → 모든 VPC가 서로 통신
Direct Connect Gateway를 Transit Gateway에 연결하여 Direct Connect를 VPC에 직접 연결할 수 있음
Site-to-site VPN과 VPN 연결을 선호한다면, 고객 게이트웨이와 VPN 연결을 Transit Gateway 에 연결하여 모든 VPC에 연결 가능
리전 리소스이며, cross-region에서도 작동
RAM (Resource Access Manager)를 통해 cross-account share
region간 Transit Gateway 피어링 가능
Transit Gateway에 라우팅 테이블을 생성해서 액세스 권한 제한 → Transit Gateway 내 모든 트래픽 경로를 제어해 네트워크 보안 제공
IP Multicast를 지원하는 유일한 서비스
Site-to-Site VPN ECMP
- ECMP : Equal-cost multi-path routing : 여러 최적 경로를 통해 패킷을 전달하는 라우팅 전략
- Site-to-Site VPN 연결을 많이 생성해서 AWS로의 연결 대역폭을 늘릴 때 사용
Throughput with ECMP
- Virtual Private Gateway에 VPN 연결 : VPC마다 연결이 하나씩 생기고, 최대 처리량은 제한됨
- Transit Gateway에 VPN 연결 : Site-to-Site VPN 하나가 여러 VPC에 생성됨 → 연결 대역폭이 1개에 2.5Gbps, 2개에 5Gbps.. 기본 VPG에 VPN 연결보다 훨씬 대역폭을 늘려 활용할 수 있음
Share Direct Connect between multiple accounts
- 기업 데이터 센터에 Customer router, firewall을 생성하고, Direct Connect Location에 Direct Connect를 생성
- AWS에서 다른 계정에 생성되어있는 VPC들을 Transit Gateway로 묶고, Transit Gateway와 Direct Connect Gateway를 연결한 다음, 여러 계정과 VPC사이에 Direct Connect 연결 공유 가능

VPC Traffic Mirroring

네트워크 트래픽을 수집하고 검사하되 방해되지 않는 방식으로 실행
관리중인 보안 어플라이언스로 트래픽을 라우팅
트래픽을 수집해, 수집하려는 트래픽이 있는 소스 ENI를 정의하고 어디로 트래픽을 보낼지 대상을 정의 (ENI, NLB 등) → 소스의 트래픽을 모두 수집해서 대상으로 보냄
동일한 VPC에 소스와 대상이 있어야 하지만, VPC 피어링이 활성화되어있으면 다른 VPC에 걸쳐있기도 함

IPv6

x.x.x.x.x.x.x.x (x: 16진수, 0000 - ffff)
VPC에서 IPv6 지원 활성화 가능
IPv4는 VPC, subnet에서 절대 비활성화될 수 없음
트러블슈팅 : ex. IPv6 지원 VPC가 있는데, 서브넷에서 EC2 인스턴스를 생성할 수 없는 경우는 subnet에 사용 가능한 IPv4가 없기 때문임. 따라서, subnet에 IPv4 CIDR 생성해 해결함

Egress-only Internet Gateway

NAT Gateway와 비슷하지만 IPv6 전용
VPC 인스턴스에서 IPv6상 아웃바운드 (인터넷) 연결을 허용하지만, 동시에 인터넷이 인스턴스로는 들어오지 못하게 막음
라우팅 테이블 업데이트해야 함

AWS Network Firewall

VPC 전체를 보호하는 방화벽 : 계층3부터 계층 7까지 보호
모든 방향에서 들어오는 모든 트래픽을 검사
AWS Gateway Load Balancer 를 활용하여 트래픽을 관리하므로, 자체 규칙을 갖추고 있음. 이는 중앙 집중식으로 관리되며 여러 계정과 VPC에 적용됨

Networking Costs

Public IP보다는 Private IP가 저렴함
같은 AZ 내에 인스턴스를 여러개 만드는 것이 AZ를 여러개 두는 것보다 저렴함. 하지만 이는 가용성이 떨어질 수 있으므로 둘 사이의 균형을 맞춰야 함

총정리

CIDR : IP 범위
VPC : Virtual Private Cloud ← IPv4, IPv6 에서 작동
Subnet : CIDR를 정의하는 AZ에 연결됨
- public : internet gateway 연결, 인터넷 접근 제공
- private
Route Table : 네트워크가 VPC 내에서 흐르도록 만드는 중요한 요소로, 이를 수정해서 경로들이나 연결 요소들을 관리할 수 있음
Bastion Host : SSH에 들어갈 수 있는 public EC2 instance
NAT Instance : private subnet의 EC2 instance에게 인터넷 접근 제공 → 오래된 기술로 source / destination 정의 등이 필요함
NAT Gateway : AWS 완전 관리형 서비스로, private EC2 instance에 확장 가능한 인터넷 접근을 제공하고, 요청 타겟이 IPv4 주소일 때 사용
NACL : Network ACL → Subnet Level에서 인바운드와 아웃바운드 접근을 정의하는 방화벽 규칙. Stateless이므로, 인바운드와 아웃바운드 규칙은 각각 따로 평가되며, Ephemeral Port를 사용함
Security Group : Statefull이므로, 인바운드가 통과되면 아웃바운드도 통과됨.
VPC Peering : CIDR 가 오버래핑되지 않는 2개의 VPC를 연결함
VPC Endpoint : VPC 내 서비스에 Private Access를 제공함
VPC Flow Logs : VPC 내 모든 패킷에 관련된 로그 레벨의 메타데이터를 가짐. 허용과 비허용 트래픽 관련 정보를 가짐.
Site-to-Site VPN : public Internet을 통한 VPN 연결이므로, AWS에 Virtual Private Gateway를 생성하고, Data Center에 Customer Gateway를 설치한 뒤 연결
AWS VPN CloudHub : 같은 Virtual Private Gateway를 사용하여 여러개의 VPN 연결 시, CloudHub를 사용해 hub-and-spoke VPN 모델 만들어 쉽게 연결 가능
Direct Connect : Virtual Private Gateway 로, AWS Direct Connect Location에 private하게 연결 가능
Direct Connect Gateway : 다른 리전의 많은 VPC와 Direct Connect를 만들기 위함
AWS PrivateLink / VPC Endpoint Services : 고객 VPC에 직접 생성한 VPC 내에서 서비스로 비공개적으로 연결하기 위한 것. VPC 피어링이나 공공 인터넷, NAT Gateway, Route Table를 요구하지 않음. NLB, ENI를 함께 사용
ClassicLink : EC2-Classic Instance를 VPC로 비공개 연결하기 위함
Transit Gateway : VPC, VPN, Direct Connect를 위한 피어링 연결
Traffic Monitoring : ENI로부터 네트워크 트래픽을 복사해서 미러링
Egress-only Internet Gateway : IPv6 트래픽만을 위한 게이트웨이