AWS VPC & Route53

2023년 10월 30일 작성

AWS VPCRoute53AWS Cloud Club

본 내용은 제가 ACC ewha 에서 발표한 내용을 기록한 것입니다!

발표 직전까지 이것저것 수정하다 보니 글 내용이 슬라이드와는 다를 수 있어요. 양해부탁드려요!

Route 53

Route53은 AWS의 Global DNS 서비스입니다.

DNS

여러분 DNS가 뭔지 다들 아시거나, 들어본 적 있을 것 같아요. Domain Name System의 준말이죠. 이게 뭐였는지 복습해봅시다.

웹사이트에 접속 할 때 우리는 외우기 어려운 IP 주소 대신 도메인 이름을 사용합니다. 입력한 도메인을 실제 네트워크상에서 사용하는 IP 주소로 바꾸고 해당 IP 주소로 접속하는 과정이 필요하겠죠? 이러한 과정, 전체 시스템을 DNS(도메인 네임 시스템)라고 합니다.

DNS 용어

도메인 이름 등록 기관

Amazon Route 53, 가비아, Go Daddy 등을 도메인 이름 등록기관이라고 부릅니다. DNS와는 구분되는 개념이에요.

도메인 레지스트라 (Domain Registrar)

도메인 레지스트라는 도메인 이름을 등록하고 관리하는 기관입니다. 사용자는 이러한 레지스트라를 통해 원하는 도메인 이름을 등록할 수 있으며, 도메인 이름과 관련된 관리 작업(예: 도메인 연장, 전송, 네임서버 변경 등)도 이곳에서 수행합니다. 예를 들어, GoDaddy, Namecheap, Google Domains 등이 도메인 레지스트라의 예입니다.

DNS (Domain Name System)

DNS는 인터넷에서 도메인 이름을 IP 주소로 변환하는 시스템입니다. 사용자가 웹 브라우저에 도메인 이름(예: www.example.com)을 입력하면, DNS 서버는 해당 도메인 이름에 대응하는 IP 주소를 찾아내어 사용자를 해당 서버로 연결합니다. DNS는 인터넷 주소록과 같은 역할을 하며, 도메인 이름과 IP 주소 간의 매핑을 관리합니다.

도메인 레지스트라와 DNS는 밀접하게 연관되어 있습니다. 도메인을 등록할 때, 레지스트라는 해당 도메인에 대한 네임서버 정보를 설정하게 합니다. 이 네임서버는 DNS 쿼리를 처리하며, 도메인 이름을 IP 주소로 변환하는 역할을 합니다. 레지스트라에서 도메인을 등록한 후, 사용자는 DNS 설정을 통해 웹사이트나 이메일 서비스 등을 구성할 수 있습니다.

즉, 도메인 레지스트라는 도메인 이름의 '등록'과 '관리'를 담당하고, DNS는 인터넷에서 도메인 이름을 IP 주소로 '변환'하는 역할을 합니다.

Route53은 어떤 역할을 할까?

AWS Route 53은 두 역할을 모두 수행합니다. 즉, Route 53은 도메인 레지스트라이기도 하고, DNS 서비스 제공자이기도 합니다.

AWS에서는 다음과 같이 Route53을 설명합니다.

고가용성, 확장성
완전 관리형 DNS
도메인 등록기관
리소스 헬스체크 가능
100% SLA 제공

그렇담 Route53에서는 우리가 관리할 리소스는 없는 것일까요?

Route53의 리소스

240822-023905

Route53에서 생성하고 관리할 수 있는 리소스가 있습니다. 크게 세가지로 나눌 수 있는데요,

DNS 레코드 (Record Sets)
호스팅 영역 (Hosted Zones)
헬스 체크 (Health Checks)

입니다.

Record

먼저 레코드는, 특정 도메인에 대해 설정된 DNS 레코드를 말합니다. 도메인에 대한 값을 어떻게 반환할지말이죠!!

240822-023958

가령 제게 kyy00n.com 도메인이 있을 때, 레코드를 만들어 www.kyy00n.com 의 도메인에 대한 dns 쿼리시 제 웹사이트가 돌아가고 있는 서버 ip를 반환하게 할 수 있죵.

기본적으로 이런 도메인 레코드에는 여러 타입이 있으니, 알아두시면 좋을 것 같습니다.

A: hostname 을 IPv4에 매핑
AAAA: hostname을 IPv6에 매핑
CNAME: hostname을 다른 hostname에 매핑
NS: 호스팅영역의 Name server를 지정하는 레코드

Alias 레코드

그런데 Route53 레코드에는 특별한 기능이 있는데요, 바로 Alias 레코드입니다.

Alias 레코드를 이용하면, 도메인 이름을 AWS 리소스 (e.g. s3 버킷, Cloudfront 배포, elb 등)에 연결할 수 있어요.

240822-024450 240822-024503

Hosted zones

hosted zone 은 위에서 알아본 record 의 상위 개념이에요. 레코드를 포함하는 컨테이너라고 생각하면 됩니다.

hosted zone은 크게 public과 private 으로 나뉘어요.

Public Hosted Zones

public hosted zones 는 인터넷 상에서 루트를 제공할 레코드를 모아놓는 곳이에요.

240822-024710

Private Hosted Zones

반면 private hosted zone은 VPC 내부의 트래픽을 라우팅하는 레코드를 모아놓는 곳이죠

240822-024717

Health check

마지막 route53 리소스를 소개합니다. 바로 헬스체크인데요, 헬스체크는 Route53이 연결된 리소스에 대해 자동재해복구를 할 수 있도록하는 기능입니다.

단, 헬스체크는 public resource에만 등록할 수 있어요.

240822-024923

그림에서는 ALB에 헬스체크를 등록해서 route53에서 alb에 대한 자동재해복구를 수행할수 있게 됩니다.

배경지식 (VPC 설명 전)

Public IP & Private IP

여러분 공인IP, 사설 IP 전공 수업때 많이 들어보셨을거라 생각합니다.

CIDR

여러분 AWS에서는 네트워크 주소 표현방식으로 CIDR를 사용한대요. 그리고 AWS의 근간은 클라우드 네트워크이구요. 그래서 잘 쓰려면 반드시 무조건 이해해야하는 표기법입니다.

네트워크의 주소와 크기를 표현하는 방식 중 하나
허용된 블록 크기는 /16 넷 마스크 (사용 가능한 IP 주소 65,536개)~ /28 넷 마스크(사용 가능한 IP 주소 16개)
각 서브넷 CIDR 블록에서 첫 4개의 IP 주소와 마지막 IP 주소는 사용자가 사용할 수 없으므로 인스턴스에 할당할 수 없다.

제가 한번 계산해보겠습니다.

서브넷 마스크가 192.168.0.0/24 인 퍼블릭 서브넷 32-24 = 8bit 를 나눠 쓸 수 있음 => 2^8 = 256 개 의 IP -> 192.168.0.0 ~ 192.168.0.255

우리는 초보니까 빠르고 확실하게 이해하기 위해서는 처음부터 어설프게 공식문서/원서보는 것보다 쉽게 풀어서 설명되어있는 개념을 빠르게 흡수하고 경험하며 감을 잡는 것이 중요하다고 생각합니다.

말이 길었습니다. CIDR를 모르신다면 한번 읽어보세요. CIDR의 등장 이유와 활용 범위를 알게되실겁니당. 잘쓰여진 블로그 글 - Inpa blog

인터넷에 계산기도 있고, 계산 할때만 하면되니 이제 별거 아니라는 생각이 드셨으면 합니다.

AWS 구조

리전 (Region)

리전은 AWS에서 가장 큰 지역의 단위입니다. 우리 보통 보는 서울리전.. 도쿄리전.. 등등 이야기 리전은 AWS의 서비스들이 제공되는 서버의 물리적인 국가/도시 단위의 위치을 의미합니다.

가용영역 (Availability Zone, AZ)

리전을 이루는 데이터 센터의 모음이에요.
AZ 여러 개가 모여 리전을 구성합니다.
AZ들은 하나 이상의 데이터센터로 이루어져 있습니다.

아까 리전이 전세계 AWS 지역을 나누는 단위라고 했었죠? 보통 한 리전 단위로 서비스가 시작되기 마련이죠. 하지만 리전의 데이터 센터에 문제가 생기면 어떻게 될까요? 아예 리전단위 서비스는 운영이 불가능합니다. 그래서 리전도 한 번 더 나눕니다. 지리적으로 떨어지도록 위치시켜 하나의 az가 작동이 불가 해도 리전단위 서비스는 문제가 없도록 만들어낼 수 있죠.

<콘솔 사진 - AWS AZ 리스트>

특이한 점은, 이런 AZ들의 위치와 분류는 보안상 공개되어있지 않다는 점입니다.

AZ들의 구체적인 위치, 데이터센터의 규모, 정확한 인프라 구성 등은 공개되지 않으며, 이는 클라우드 서비스 제공자들 사이에서 흔히 볼 수 있는 보안 관행입니다.

VPC

VPC 란

aws 사용자 전용 "가상" 네트워크입니다. 한마디로 AWS용 나만의 개인 네트워크 망 데이터센터라고 생각하면 됩니다.

사실 VPC가 처음 부터 있었던 것은 아닙니다. VPC는 2011년에 출시되었는데, 이전에는 여러 사용자들의 인스턴스들이 하나의 네트워크에 얽혀있어 복잡도가 높았다고 합니다. AWS는 VPC 출시 이후 리소스에 VPC를 적용하지 않으면 생성할 수 없게 만들고 있습니다. (VPC 이전 EC2-Classic Platform 제공 중단)

그러고보면, 우리는 거의 항상 모든 컴퓨팅 리소스 토폴로지를 볼 때 VPC 박스 안에 있는 것을 확인 할 수 있어요.

(와 진짜 복잡하다.. 어쨌든 VPC 박스 안에 다들어있군 👀)

Region

VPC는 리전 단위서비스입니다. 이해가 잘 안가시나요? 눈으로 보면 바로 이해되실 겁니당! s3는

Subnet 이란

VPC의 IP 주소를 나누어 리소스가 배치되는 물리적인 주소 범위를 뜻합니다. 이해를 위해서, VPC를 채플중인 대강당에 비유를 들어보겠습니다.

일단, 채플을 들으려면 좌석을 배정받아야하죠. 우리는... 채플 수강신청을 하지요. 그 이유는 의자는 한정적이기 때문입니다.

대강당 구역 나눠져있잖아요 딱딱, 구역마다 놓여있는 의자 양도 다릅니다. 하지만 여기 앉으면 모두 채플을 들을 수 있습니다.

이게 대강당이 VPC입니다. 벗들이 리소스이구요. 리소스들은 네트워크를 사용하기(채플을 듣기) 위해서 IP(대강당 좌석)를 할당받아야해요.

그리고, 대강당에는 구역이 나눠져있죠? 의자의 개수와 위치는 다르지만 모여있습니다. 범위가 정해져있지요. 우리는 VPC의 서브넷을 대강당의 구역에 비유할 수 있어요.

차이는 하나, 대강당은 실제 세계의 공간의 분리이지만 VPC는 말그대로 가상, 논리적으로 분리하는 것이라는 점이지요.

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

솔직히 억지 비유라고 하면 할 수 있지만, 처음 이해할 때 도움이 되는 비유일 것같아 가져왔어요.ㅎㅎ 일단은 비유는 여기까지하고 서브넷을 좀 더 알아보려고해요. 다만 좀 이따 다시 대강당 이야기를 다시 들고 올테니 잊지 말아주세요.

Subnet과 AZ

그리고 이런 서브넷들은 AZ 라는 단위에 속해있습니다. 그럼 AZ는 뭘까요? 당연히, 사전 자료들 전부 읽고 오셨겠지만 복습차원에서 가볍게 설명드릴게요.

AWS 에서는 진짜로 존재하는 데이터센터들을 논리적은 단위로 분류해놨는데, 가장 큰단위가 서울, 도쿄, 버지니아 북부.. 와 같은 리전(Region) 이었습니다. 그리고 그 안에서 한 번 더 지역 단위로 나눠놓았던 단위가 AZ였어요. 그리고 AZ는 Availability Zone, 가용영역 이었지요.

무튼.. 서브넷은 이런 식으로 Availability Zone을 지정해서 만들어야하는 아이랍니다.

작은 핸즈온: 서브넷 만들기

서브넷이 상주할 영역을 선택합니다. 선택하지 않으면 Amazon이 자동으로 선택합니다.

Internet Gateway

자 이제 인터넷 게이트웨이라는 녀석입니다. 이 아이는 VPC를 인터넷과 연결하는 통로이자 관문입니다. 그래서 보통 이런식으로 표현하곤해요.

VPC 안의 리소스가 인터넷을 통하려면 이렇게 IGW를 통해야만 하지요.

다시 VPC를 대강당으로 본다면 대강당의 문이 Internet Gateway라고 생각하시면 됩니다. 240822-021632

그런데 여러분, 다시 대강당의 구조를 한번 볼까요? 대강당 안을 VPC 안 네트워크 그리고 문 밖의 세상을 인터넷이라고 생각해봅시다.

그리고 저 좌석 하나를 서브넷으로 볼수도 있지만, 좀 더 쉬운 설명을 위해 대강당이라는 VPC를 1층 서브넷, 2층 서브넷으로 나눴다고 생각해보자구요.

1층의 벗들은 이어진 문으로 바로 나갈 수 있지만, 2층의 벗은 1층을 거치지 않고서는 밖으로 나갈 방법이 없습니다. 1층 서브넷은 인터넷에 바로 연결될 수 있지만, 2층 서브넷은 그렇지 않다는 뜻이죠.

2층 서브넷의 리소스(벗)이 인터넷에 연결되려면 1층 서브넷을 거쳐야합니다.

우리는 1층과 2층을 각각 public subnet과 private subnet이라고 생각할 수 있어요.

지금까지 비유 진짜 어거지로 열심히 했는데요, 사실 이말 하려고 그랬습니다. 인터넷 게이트웨이에 바로 연결돼있는 서브넷은 public subnet이라 부르고 그렇지 않은 서브넷은 private subnet이라고 불러요. 만약 private subnet에서 인터넷이 필요하면 public subnet을 통해 인터넷에 연결할 수 있어요. 필요에 따라 이런식으로 조정할 수 있는거죠.

Route Table

사실 이전까지 보여드렸던 것은 조금 단순화된 그림이에요. 그림을 보면 이해가 안되실 수도 있습니다. 왜냐하면 저 인스턴스에서 바로 화살표를 인터넷게이트웨이로 보내기만하면 public subnet이 되는건가? 라는 생각이 들죠.

사실, public subnet이 될 수 있었던 이 초록색 서브넷은 이것이 달랐어요. 바로 연결돼있는 라우트테이블의 설정입니다.

원래 서브넷은 라우트 테이블이라는 것에 연결될 수 있어요. 하드웨어 라우터랑 같은 역할이라고 생각하면 될것 같아요. 원래 라우터는 방향을 정해주는 이정표 역할을 하잖아요!

길에 있는 이정표와 같은 역할을 하는 겁니다. 그래서 라우팅테이블까지 토폴로지에 포함시켜 그려보면 다음과 같아요.

서브넷에서 나가는 트래픽이 향하는 destination에 따라, 어디로 향하게 할지를 정해주는 겁니다.

사진에서, local이라 되어있는건 vpc 내부를 향하게하라는 것입니다. 잘 보시면 VPC CIDR 블록과 일치하는 경우 local로 향하도록 하는것을 볼 수 있지요. 내부에서 vpc 범위에 해당하는 ip를 호출하면 내부로 향할 수 있도록 해주는 것이 자동으로 되는 게 아니라, routetable 덕분이라는 것을 알 수 있습니다.

public vs private subnet 정리

결론적으로 서브넷에 트래픽이 IGW에 연결되도록 정의한 Routetable이 연결돼있으면, public subnet

서브넷에 IGW에 연결돼있지 않은 RouteTable이 연결돼있으면 private subnet이라고 부르는거여요.

서브넷 자체에서 설정을 하는 것이 아니라, 연결돼있는 라우팅 테이블의 라우팅 설정에 따라 분류되기 때문에 설정을 거꾸로 하면 안되겠죠?

오늘은 AWS의 기본적인 네트워킹 솔루션들에 대해 알아보았습니다! :D

제 생각에 VPC를 공부하는 것은 aws 의 다른 서비스를 이용하는 데도 굉장히 중요하다고 생각해요, 열심히 따라와 주신 여러분 수고하셨습니다👏🏻