IP 주소의 범위
ex) WW.XX.YY.ZZ/32 => one IP
0.0.0.0/0 => All IPs
범위에 포함된 IP (XX.XX.XX.XX)
ex) 10.0.0.0, 192.168.0.0,...
: IP에서 변경 가능한 비트의 개수를 정의
ex) /0, /24, /32
/8 <-> 255.0.0.0
/16 <-> 255.255.0.0
/24 <-> 255.255.255.0
/32 <-> 255.255.255.255
IP주소/32 => 192.168.0.0 -> 한 개의 IP를 허락함 (2^0)
IP주소/31 => 192.168.0.0 ~ 192.168.0.1
-> 2개의 IP를 허락함 (2^1)
IP주소/30 => 192.168.0.0 ~ 192.168.0.3
4개의 IP를 허락함 (2^2)
IP주소/29 => 192.168.0.0 ~ 192.168.0.7
8개의 IP를 허락함 (2^3)
...
IP주소/24 => 192.168.0.0 ~ 192.168.0.255
256개의 IP를 허락함 (2^8)
...
IP주소/16 => 192.168.0.0 -> 192.168.255.255
65,536개의 IP를 허락함 (2^16)

그림을 보면서 이해해보자.
아이피는 3개의 점과 4개의 구역으로 이루어진다. Octets(=구역)
/32는 옥텟 변경 불가
/24는 마지막 옥텟 변경 가능
/16은 마지막 두 개 옥텟 변경 가능
/8은 마지막 세 개 옥텟 변경 가능
/0은 모든 옥텟 변경 가능
그 이유는 방금 작성한 서브넷 마스크 변경 과정을 통해 이해하도록 하자.
VPC 내부에 있는 IPv4 주소의 부분 범위.
CIDR를 정의하는 AZ에 연결된다.
Public Subnet, Private Subnet으로 구분된다.
AWS가 각각의 서브넷에 IP 주소 5개를 예약 함
(처음 4개 + 마지막 1개)
-> 이 IP들은 사용 못 함
ex) CIDR block 10.0.0.0/24
10.0.0.0 - Network Address
10.0.0.1 - reserved by AWS for the VPC router
10.0.0.2 - reserved by AWS for mapping to Amazon-provided DNS
10.0.0.3 - reserved by AWS for future use
10.0.0.255 - Network Broadcast Address
Tip : 인스턴스 서브넷에서 IP 주소 29가 필요할 때,사용 못 함
/27 IP 주소는 32개 , 32-5 = 27 -> 29개가 필요한데 그거보다 작음.
따라서 서브넷의 크기는 /26이어야 함
VPC의 리소스를 인터넷에 연결하도록 허용하는 EC2 인스턴스/람다 함수 등을 의미.
-> VPC 레벨에서 IPv4 & IPv6의 인터넷 접근을 제공해줌
수평으로 확장되고, 가용성과 중복성이 높음.
VPC는 인터넷 Gateway 하나에만 연결됨.
인터넷 게이트웨이 자체는 인터넷 액세스를 허용하지 않음.
또한 작동을 위해 라우팅 테이블을 수정해야 함

인터넷 게이트웨이 다는것만으로는 인터넷 통신이 안되고,
위의 그림처럼 공용 EC2 인스턴스를 만들고, 라우팅 테이블을 수정해서 EC2 인스턴스를 라우터에 연결하고 인터넷 Gateway에 연결해야 함 .
네트워크가 VPC 내에서 흐르도록 하는 키.
VPC 내에서 서브넷과 인터넷 게이트웨이, NAT 게이트웨이, VPC Peering 연결 등의 네트워크 트래픽 경로를 정의하는 구성 요소
관리자가 private Subnet의 SSH에 접속할 수 있게 해주는 퍼블릭 EC2 인스턴스

public subnet에 배포된 EC2 인스턴스.
private subnet의 EC2 인스턴스에게 인터넷 접근을 제공해줌
Source/Destination check flag 비활성화 해야 작동함.
(오래되어서 권장 X, but NAT Gateway보다 가격이 훨씬 저렴함)
AWS로 관리된다.
Private Ec2 인스턴스에 확장 가능한 인터넷 접근을 제공해줌.
IPv4 주소일 때만 사용 가능

서브넷 레벨에서 인바운드와 아웃바운드 접근을 정의하는 방화벽 규칙


-> 연결된 서브넷을 가지고 인바운드, 아웃바운드의 모든 요청을 허용하는 특수성을 가짐
Default NACL을 수정하지 않는 것을 추천
-> 대신에 NACLs를 커스텀해서 새로 만들어라


위의 그림을 살펴보자.
첫 번째 클라이언트 -> 서버로 보내는 요청의 아웃바운드, 인바운드 규칙은 어려울 게 딱히 없다.
NACL의 클라이언트 서브넷에서는 3306 아웃바운드 요청을 허용하고, DB 서브넷에서는 3306 인바운드 요청을 허용한다.
중요한 것은 서버 -> 클라이언트로 요청이 중요하다.
클라이언트는 정해진 포트가 없기 때문에 임시 포트가 만들어진다. 범위는 1024~65535 사이
그렇기에, 서버 -> 클라이언트로 갈 때 임시 포트를 담아서 보낸다.
임시 포트를 제대로 구성하는 것은 정말 중요하다

다중 NACL 및 서브넷이 있다면 각 NACL 조합이 NACL 내에서 허용되어야 함.
즉, 위의 사진처럼 CIDR 사용시, 서브넷이 고유의 CIDR을 갖기 때문에 연결 조합이 가능한 지 반드시 확인해야 한다.