[AWS] 10. AWS_VPC 개념

AWS 개념

What is IP Address?

컴퓨터 사이에 통신을 하려면 컴퓨터의 위치값을 알아야 한다. 각 컴퓨터의 위치값(주소)을 IP 주소라고 지칭한다(IPV4).

172 . 16 . 254 . 1 라고 하면 8비트로 4번, 생성 될 수 있는 총 개수 = 2^32개다. 처음엔 충분할줄 알았는데... 인터넷 이용자가 폭발적으로 늘어나다 보니 부족하게 되었다. 이때문에 나온것이 "서브넷"이라는 개념이다. (추후에 다룬다.)

IP 주소를 효율적으로 다루기 위해 주소를 Network bit와 Host bit로 나누는데 다음과 같다.

호스트비트가 네트워크비트에 종속되는 형식이다.

a class는 하나의 네트워크 안에 2^24만큼의 ip를 보유하고 있으며,(2^24만큼의 호스트가 있다.) a로 갈수록 네트워크의 규모가 크고 c로 갈수록 네트워크의 규모가 작다.

c클래스는 세번째 옥텟까지 네트워크를 표현하고, 마지막 옥텟만이 호스트를 포함한다.

따라서 211.11.124.2가 c클래스라면, 211.11.124.0 ~ 211.11.124.255 만큼의 호스트 ip가 있음

---

What is Subnet?

서브넷은 네트워크를 나눠쓰는 것! 한사람이 하나의 네트워크를 보유한다면 낭비가 너무 심하다. 가뜩이나 부족한데... 여기서 싸이들이라는 개념이 나오는데 정리해보면 다음과 같다.

subnet (서브넷)
대규모 네트워크를 구성하는 개별 네트워크

CIDR(싸이들)
하나의 VPC 내에 있는 여러 IP 주소를 각각의 Subnet으로 분리/분배하는 방법

Ex)

Network 두개로 나누기 - CIDR

서브넷 A - 211.11.124.0/25

서브넷 B - 211.11.124.128/25

Network 네개로 나누기 - CIDR

서브넷 A - 211.11.124.0/26

서브넷 B - 211.11.124.64/26

서브넷 C - 211.11.124.128/26

서브넷 D - 211.11.124.192/26

---

What is VPC(Virtual Private Cloud)?

사용자가 정의한 가상 네트워크로 AWS 리소스를 관리할 수 있게 하는 것을 VPC라고 생각하자.

그럼 "가상" 네트워크가 아니라 진짜 네트워크는 뭐지?? 우리가 AWS없이 어떤 서비스를 구상하는 상상은 여러번 해봤을 것이다. 서버를 만들고 네트워크에 서버를 연결하고, 데이터베이스를 구축하고 데이터베이스랑 서버를 연결하고... 뭐 어쩌겠는가... 사람불러야지...

AWS의 VPC는 이런 복잡한 작업들을 미리 다 해두고 네트워크 전문가를 부를 필요없이 우리같은 서버 개발자들이 손쉽게 필요한 네트워크를 전부 가져다 쓸 수 있게 만들어 놨다. 그게 VPC의 가장 큰 장점이다.

VPC의 특징

• 계정 생성 시 default로 VPC를 만들어 줌
• EC2, RDS, S3 등의 서비스 활용 가능
• 서브넷 구성
• 보안 설정(IP block, inbound outbound 설정)
• VPC Peering(VPC 간의 연결)
• IP 대역 지정 가능
• VPC는 하나의 Region에만 속할 수 있음(다른 Region으로 확장 불가능)

VPC의 구성요소

• Availability Zone (AZ)
• Subnet(CIDR)
• Internet Gateway
• Route Table
• Network Access Control List/security group - NACL나클, 보안그룹, VPC보안 역할
• NAT(Network Address Translation) instance/NAT gateway
• VPC endpoint

1. Availability Zone (AZ)

각 계정의 AZ는 다른 계정의 AZ와 다른 아이디를 부여받는다고 한다. 보통 AZ A를 선택하니까, 얘네가 알아서 그거 무시하고 나눠준다는데... 그럴거면 애포에 랜덤으로 하지...(그니까 내가 보기에 A여도 아닐 수 있음)

2. Subnet(CIDR)

서브넷은 VPC의 하위 단위(sub+network)이다. 하나의 AZ에서만 생성이 가능하고, 하나의 AZ에는 여러 개의 subnet 생성 가능

• CIDR 블록을 통해 Subnet을 구분
• CIDR : 하나의 VPC 내에 있는 여러 IP 주소를 각각의 Subnet으로 분리/분배하는 방법
• 1번째 서브넷 : 211.11.124.0/26 (211.11.124.0 ~ 211.11.124.63)
• 2번째 서브넷 : 211.11.124.64/26 (211.11.124.64 ~ 211.11.124.127)
• 3번째 서브넷 : 211.11.124.128/26 (211.11.124.128 ~ 211.11.124.191)
• 4번째 서브넷 : 211.11.124.192/26 (211.11.124.192 ~ 211.11.124.255)

public subnet - vpc외부의 인터넷과의 소통이 가능
private subnet - vpc외부의 인터넷과의 소통이 불가능, vpc내부의 객체들과 소통만 가능함

3. Internet gateway(IGW)

인터넷으로 나가는 통로 (Private subnet은 IGW로 연결되어 있지 않다... 엄밀히 말하면 연결이 안되어있다기 보단... IGW로 가지 않게 설계되어있다!)

4. Route table

트래픽이 어디로 가야 할지 알려주는 테이블, VPC 생성 시 자동으로 만들어줌

10.0.0.0/16의 싸이들 표기는 10.0.0.0 ~ 10.0.255.255 이만큼의 범위를 의미하는데, 이 범위의 target은 local로 가라!
0.0.0.0/0은 나머지 모든 대역은 igw-ip로 가라!

Private subnet의 경우, Route table에서 target이 igw-id인 row가 없음

5. NACL(Network Access Control List) 과 Security Group(보안그룹)

둘은 다른개념인데,

NACL -> Stateless
SG->Stateful

Access Block은 NACL에서만 가능, 특정 IP대역의 inbound를 막고싶으면 NACL에서 설정

Security Group(보안그룹)은 VPC의 설정값이라고 생각하자

근데, Private subnet은 왜 만들까?? 생각해보니! Private 객체랑 느낌이 비슷하지 않은가?! DB를 만들때 사용하면 딱일거같다! 보안적으로 중요한 것을은 Private subnet내에 존재하는게 상당히 많다.

근데 이 Private subnet이라고 하더라고 인터넷과의 연결이 필요한 경우가 있다. (소프트웨어의 버전업 등) 이럴때는 또 다 방법을 만들어 놨다. 우회해서 사용하면 된다!

Private subnet에서 직접적으로 IGW로 트래픽을 쏠 수 없으니, Private subnet에서 Public subnet으로 트래픽을 쏴서 IGW로 연결한다.

Private subnet과 Public subnet은 트래픽을 주고받는 것이 가능하니까, Public subnet의 "NAT gateway와 NAT instance"를 대리인으로 사용하는 것!

이렇게 우회하여 데이터를 주고 받는 방식은 크게 두가지가 있는데, 다음과 같다.

1. Private subnet 안에 있는 private instance가 외부의 인터넷과 통신하기 위한 방법, NAT Instance는 단일 Instance(EC2), NAT Instance는 Public Subnet에 있어야 함

2. NAT Gateway는 aws에서 제공하는 서비스 (요새 이거 많이 씀)

그럼 외부의 사람(관리자)이 Private subnet에 접근하고 싶을땐 어떻게 해야할까? 일반적인 방법으론 불가능하다. Private subnet은 인터넷과의 연결이 안되니까. 이럴때 사용하는 서비스가 Bastion host이다.

Bastion host - 인터넷에서 Private subnet으로 접근하기 위한 방법, Private Instance에 접근하기 위한 수단, Public subnet 내에 위치하는 EC2

관리자가 Public subnet 내의 Bastion host로 접근, Bastion host에서 rivate subnet으로 접근

6. VPC endpoint

VPC endpoint는 Aws의 여러 서비스들과 VPC를 연결시켜주는 중간 매개체이다.AWS에서 VPC 바깥으로 트래픽이 나가지 않고 AWS의 여러 서비스를 사용하게끔 만들어주는 서비스라고 생각하자. (VPC내에서 AWS에 access하기 위해 사용하는 서비스)

Private subnet 같은 경우는 격리된 공간인데, 그 상황에서도 AWS의 다양한 서비스들에(S3, dynamodb 등) 연결할 수 있도록 지원하는 서비스이다.

Interface Endpoint : Private ip를 만들어 서비스로 연결해줌(SQS, SNS, Kinesis, Sagemaker 등 지원)
Gateway Endpoint : 라우팅 테이블에서 경로의 대상으로 지정하여 사용(S3, Dynamodb 지원)

---

vpc 생성 실습

vpc 생성

vpc > vpc 생성

• 이름태그: 적당히 입력 (FC-custom-vpc)
• IPv4 CIDR 블록: 10.0.0.0/16 입력
• IPv6 CIDR 블록: 없음
• 테넌시: 기본값, 로컬 기기에서 사용할 것인지

vpc를 만들면,
서브넷은 자동생성 X
라우딩 테이블은 자동생성 O
인터넷 게이트웨이 X
엔드포인트 X
넷게이트웨이 X
네트워크 ACL O

서브넷 생성

서브넷 > 서브넷 생성

Public과 Private 서브넷을 하나씩 만들어 보자

원하는 vpc선택 (FC-custom-vpc)

Public

• 서브넷 이름: FC-public-subnet
• 가용 영역: 하나의 서브넷은 하나의 가용영역 선택 (ap-northeast-2a)
• IPv4 CIDR 블록: 10.0.0.0/24

Private

• 서브넷 이름: FC-private-subnet
• 가용 영역: 하나의 서브넷은 하나의 가용영역 선택 (ap-northeast-2c)
• IPv4 CIDR 블록: 10.0.1.0/24

인터넷 게이트웨이 생성

인터넷 게이트웨이 > 인터넷 게이트웨이 생성

• 이름 태그: 적당히 입력 (FC-igw)

끝... 간단하다. 이렇게 생성하고 나면 해당 igw의 상태는 Detached이다. 어떤 vpc에도 연결이 되어있지않다. 연결 방법은 다음과 같다.

원하는 igw선택 > 작업 > vpc에 연결 > 원하는 VPC선택 > 인터넷 게이트웨이에 연결

이제 vpc와 igw를 연결했다. 근데 각 서브넷에서 인터넷에 연결하려면 라우팅 테이블을 설정해줘야한다.

라우팅 테이블 > 해당 vpc의 라우팅 테이블 이름 클릭

해당 라우팅 테이블은 vpc를 만들때 기본적으로 생성되는 라우팅 테이블이며 우리가 만든 두 서브넷이 연결되어있다. 우리는 퍼블릭과 프라이빗 서브넷을 각각 만들고 관리를 해야하는 위와 같은 상황은 원치않는다. 따라서 라우팅 테이블을 만들어주자.

라우팅 테이블 > 라우팅 테이블 생성

우선 public 라우팅 테이블부터 만들어보자.

• 이름: FC-public-rtb
• VPC: 원하는 vpc (FC-custom-vpc)

이렇게 간단하게 설정해주면 된다. 기본으로 생성된 라우팅 테이블은 이름을 FC-private-rtb로 설정해주자.

이제 각각의 라우팅 테이블을 서브넷에 연결해보자

원하는 라우팅 테이블 클릭 > 서브넷 연결 > 서브넷 연결 편집에서 원하는 서브넷 선택

사실 퍼블릭만 연결해주면 됨, 왜냐면 기본 라우팅 테이블을 프라이빗으로 바꿧고 프라이빗 서브넷은 기본 라우팅 테이블에 연결되어있음.

이제 라우팅 테이블을 편집해주자.

라우팅 테이블 > FC-public-rtb의 라우팅 테이블 ID클릭 > 하단의 라우팅편집 클릭

라우팅 추가 클릭

대상: 0.0.0.0/0
대상: igw-02.... (FC-igw)

(왜 둘다 대상이야...)

라우팅 테이블은 순서대로 적용되니까 10.0.0.0/16는 로컬로 가고 10.0.0.0/16를 제외한 모든 트래픽은 igw로 간다.

프라이빗은 그냥 둬도 됨
0.0.0.0/0이 없으면 나머지는 차단한다고 생각