sehee

VPC Components Diagram

Understanding CIDR - IPv4

클래스 없는 도메인 간 라우팅: Classless Inter-Domain Routing

IP address range
1) ww.xx.yy.zz/32 : one IP
2) 0.0.0.0/0 : all IPs
3) we can define 192.168.0.0/26 : 192.168.0.0 - 192.168.0.63 (64 IP addresses)

octets: 1st . 2nd . 3rd . 4th
/32: no octet can change, /24: last octet can change

https://www.ipaddressguide.com/cidr

Public vs. Private IP (IPv4)

10.0.0.0 - 10.255.255.255 (10.0.0.0/8) <- in big networks
172.16.0.0 - 172.31.255.255 (172.16.0.0/12) <- AWS default VPC in that range
192.168.0.0 - 192.168.255.255 (192.168.0.0/16) <- e.g., home networks

Default VPC Walkthrough

새로운 AWS 계정은 모두 기본 VPC가 있음, 새로운 EC2 인스턴스는 서브넷을 지정하지 않으면 기본 VPC에 실행됨

VPC in AWS - IPv4

단일 AWS 리전에 여러 VPC를 둘 수 있음, 리전 당 최대 5개까지 가능(늘릴 수 있음), VPC마다 할당된 CIDR는 다섯 개
각 CIDR의 최소 크기는 /28, IP 주소는 최소 16개(2^4), 최대 크기는 /16, IP 주소는 최대 65,536개
VPC가 사설 리소스이기 때문에 사설 IPv4 범위만 허용됨
VPC CIDR가 다른 VPC나 네트워크 혹은 기업 네트워크와 겹치지 않도록 주의할 것

VPC - Subnet (IPv4)

서브넷이란: VPC 내부에 있는 IPv4 주소의 부분 범위
범위 내 AWS가 IP 주소 다섯 개를 예약함

Example: if CIDR block 10.0.0.0/24, then reserved IP addresses are:
.0: network address
.1: reserved by AWS for the VPC router
.2: reserved by AWS for mapping to Amazon-provided DNS
.3: reserved by AWS for future use
.255: network broadcast address. AWS does not support broadcast in a VPC, therefore the address is reserved

EC2 인스턴스 서브넷에서 IP 주소 29개가 필요할 때, /27 서브넷은 사용할 수 없음 (32 - 5 = 27 < 29)

Hands-on#01 - Adding Subnets

1) VPC 생성
2) Public/Private Subnet 생성

Internet Gateway (IGW)

인터넷 Gateway는 VPC의 리소스를 인터넷에 연결하도록 하는 EC2 인스턴스나 람다 함수 등
수평 확장, VPC와 별개로 생성해야 함
VPC는 인터넷 Gateway 하나에만 연결됨
VPC에 인터넷 Gateway를 만드는 정도로는 서브넷에 인터넷 액세스를 제공하지 못함, 라우팅 테이블도 수정해야 함

∴ 공용 서브넷에 공용 EC2 인스턴스 만들기 -> 라우팅 테이블을 수정 -> EC2 인스턴스를 라우터에 연결 -> 인터넷 Gateway에 연결

Hands-on#02 - Adding Internet Gateway & Editing Route Tables

1) launch instance (BastionHost)
- 퍼블릭 서브넷을 위한 자동 할당 퍼블릭 IPv4 주소 활성화 시 Network settings에서 Auto-assign public IP 활성화(enable)된 상태
2) Internet gateways 생성 및 attach to VPC
- VPC에 인터넷 액세스 제공
3) public/private route table 생성
- subnet associations 추가
- routes 0.0.0.0/0 target Internet GW 추가

4) Instance connect

Bastion Hosts

사용자가 프라이빗 서브넷에 없는 EC2 인스턴스에 액세스하고자 함, 이 때 배스천 호스트를 통해 프라이빗 EC2 인스턴스에 SSH로 액세스할 수 있으며 배스천 호스트는 반드시 퍼블릭 서브넷에 있어야 함

배스천 호스트를 위해서는, 
- 보안 그룹이 반드시 인터넷 액세스를 허용해야 함(기업의 퍼블릭 CIDR 액세스, 사용자 인터넷 액세스만 허용하는 등 EC2 보안 그룹을 제한하여 인프라 보안상 위험 방지)
- 프라이빗 서브넷의 EC2 인스턴스 보안 그룹에서는 반드시 SSH 액세스를 허용해야 함(포트 22번이 배스천호스트의 프라이빗 IP가 되거나 배스천 호스트의 보안 그룹이 되는 셈)

Hands-on#03 - NAT Instance

1) launch instance (PrivateInstance)
- private, network settings - Inbound Security Group Rules custom (Allow SSH from the Bastion Host)

- 프라이빗 서브넷에 위치하므로 EC2 인스턴스로 연결할 수 없음 (∵ 인터넷 게이트웨이 라우팅 테이블을 수정하면 이 서브넷이 공개되기 때문)

2) public instance 실행 후 SSH

# copy + paste
vi EC2KeyPair.pem

chmod 0400 EC2KeyPair.pem
ssh ec2-user@(private IP) -i EC2KeyPair.pem

# doesn't work
ping google.com

- private subnet의 Amazon Linux 2 AMI에 SSH 액세스 실행

NAT Instance (outddated, but still at the exam)

NAT: 네트워크 주소 변환, 사설 서브넷 EC2 인스턴스가 인터넷에 연결되도록 허용함
NAT 인스턴스에는 고정된 탄력적 IP가 연결되어야 함

NAT 인스턴스의 작동 방식: 공용 서브넷에 NAT 인스턴스를 생성하고, 거기에 탄력적 IP를 연결, 그리고 라우팅 테이블을 통해 사설 인스턴스가 NAT 인스턴스에서 인터넷 Gateway까지 통신하도록 함

Hands-on#03 - NAT Instance

3) launch instance (NAT Instance)

- Community AMIs - architectures: x86_64bit, vpc-nat

- Security group name: nat-instance-sg
- Security group rule: add HTTP, HTTPS
4) Change source/destination check
- Stop to allow your instance to send and receive traffic when the source or destination is not itself.

- NAT 인스턴스 자체가 소스 및 목적지가 아니라면 트래픽을 송수신할 수 있어야 함

5) private Route Table 인터넷 통신하기 위한 인스턴스 추가
- routes: 0.0.0.0/0 NAT Instance
6) NAT Instance 포트 추가
- All ICMP
7) PrivateInstance ping google.com
- BistionHost SSH connect > ssh Private

NAT Gateway

AWS-managed NAT, 높은 대역폭, 가용성이 높고 관리할 필요가 없음

특정 AZ에서 생성되고 탄력적 IP를 이어 받음

NAT Gateway with High Availabiltiy

AZ가 중지될 경우를 위해 다중 NAT Gateway를 여러 AZ에 두면 결함 허용을 할 수 있음

Hands-on#04 - NAT Gateway

1) create NAT gateway
- subnet: public subnet A
- Elastic IP allocation

2) edit private routes
- 기존 NAT Instance stop/terminal 시 status: Blackhole로 변경됨
- NAT Instance network interface -> NAT Gateway로 변경

Security Groups & NACLs

NACL: 요청이 EC2 인스턴스 내부로 이동하는 것

Network Access Control List (NACL)

서브넷을 오가는 트래픽을 제어하는 방화벽
서브넷마다 하나의 NACL이 있고, 새로운 서브넷에는 기본 NACL이 할당됨

1-32766번 (우선순위가 제일 높은 것은 1)
newly created NACLs will deny everything

Default NACL

연결된 서브넷을 가지고 inbound/outbound의 모든 요청을 허용하는 특수성을 가짐
기본 NACL을 수정하지 않는 것을 추천
기본적으로 NACL이 서브넷과 연결된다면 모든 것이 드나들도록 허용된다는 뜻

Ephemeral Ports

클라이언트와 서버가 연결되면 포트를 사용해야 함

Create NACL rules for each target subnets CIDR

다중 NACL 및 서브넷이 있다면 각 NACL 조합이 NACL 내에서 허용되어야 함, CIDR 사용 시 서브넷이 고유의 CIDR를 갖기 때문

NACL에 서브넷을 추가하면 NACL 규칙도 업데이트해서 연결 조합이 가능한지 확인해야 함

Hands-on#04 - NACLs

3) BastionHost ssh 연결

sudo yum install -y httpd
sudo systemctl enable httpd
sudo systemctl start httpd
echo "hello world" > /var/www/html/index.html
# 이전 명령을 sudo로 실행
sudo !!

# if permission denied
sudo su
echo "hello world" > /var/www/html/index.html

4) add security group HTTP

- public IP 접속 허용

5) edit Network ACLs inbound/outbound rules (for test)

- inbound rule: 80, type: http, source: 0.0.0.0/0, Deny
or outbound rules 100 Deny

- public IP 접속 차단

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03, Section 27