1. 리전과 가용영역

리전은 AWS 가 서비스를 제공하고 있는 거점 ( 국가와 지역 )을 일컫는다.

리전끼리는 각각 지리적으로 떨어진 위지에 배치되어 있다.

리전 내에는 복수의 가용 영역 ( Availability Zone → AZ )가 포함되며, 하나의 AZ는 복수의 데이터 센터로 구성되어 있다.

즉 복수의 데이터 센터가 AZ를 구성하며, 복수의 AZ가 모여 하나의 리전이 된다. 이 리전과 가용 영역이 AWS의 아키텍처 설계 중 가장 기본이 되는 역할을 하고 있다.

AZ의 지리적, 전원적 독립에 따른 신뢰성 향상

각각의 AZ는 지리적, 전원적으로 독립된 장소에 배치되어 있다. 지리적인 독립이 의미하는 것은 낙뢰나, 홍수, 태풍 같은 자연재해에 따른 AZ에 소속되어 있는 장애에 대하여 별도의 AZ가 영향을 받지 않도록 배치되어 있다는 것이다. 

이것을 실현하기 위하여 AZ 간 수십 키로 정도의 거리를 두며 배치하고 있다는 의미이다.

어느 정도 거리가 떨어져 있기는 하지만, 각 AZ간은 고속의 네트워크 회선으로 연결되어 있기 때문에 네트워크 지연의 문제가 발생하는 일은 없을 것이다. AZ 간의 네트워크 지연 (레이턴시)는 2미리 세컨드 이하로 안정되어 있다고 한다.

 

다음 전원적 독립이다. 이것은 진원의 연결 부분을 말한다. 한쪽의 전류에 의해 AZ 내의 모든 데이터 센터가 일제히 다운되지 않도록 설계되어 있다. 공식적으로 공표되어 있진 않지만, AZ 안에는 AWS가 독자적으로 만든 발전소를 채용하고 있는 듯하다.

 

AZ는 지리적, 전원적 독립에 의해 리전 전체로 볼 때에 AWS는 장애에 대한 가용성이 높고, 신뢰성이 높다고 말하고 있다. 이 높은 신뢰성이 AWS의 다양한 서비스의 기반이 되고 있다.

다중 AZ에 의한 가용성 향상

AZ의 지리적, 전원적 독립에 의한 리전 전체의 신뢰성은 높게 유지할 수 있지만, 유저가 단일 AZ로 시스템을 구성할 경우, 하나의 데이터 센터에 온프레미스 시스템을 구축하고 있는 경우와 비교하여 대 장애성에 별반 차이가 없다. 대 장애성이 높은 시스템으로 가용성을 높이기 위해선 멀티 AZ를 이용하여 인프라 환경을 구축할 필요가 있다 AWS 에선 이것을 다중 AZ(Multi AZ)라고 부른다.

web server + DB 시스템의 다중 AZ 기본 구성

이 그림에는 Web + DB 시스템을 다중 AZ구성을 하는 경우 기본적인 형식을 보여주고 있다. 로드 밸런서가 2대의 가상 서버를 이용해 부하를 분산하며, AZ 간 나눠져 레플리케이션 구성된 마스터 DB에 접속한다.

EC2라고 하는 가상 서버나 데이터 베이스 서비스인 RDS 등 인스턴스를 베이스로 한 서비스는 가용성을 높이기 위한 멀티 AZ를 이용하여 구성하는 것이 기본이라 할 수 있다. 

---

VPC

AWS의 네트워크 서비스의 중심은 Amazon Virtual Private Cloud이다. VPC는 이용자 간의 프라이빗한 네트워크를 AWS안에 작성해준다. VPC는 인터넷 게이트웨이 (IGW)라고 불리는 인터넷으로의 출구를 추가하는 것으로 직접 인터넷에 접속하는 것도 가능해진다.

또한 온프레미스의 각 거점을 연결하기 위한 가상 프라이빗 게이트웨이 (VGW)를 출구로 두어 전용선의 서비스인 Direct Connect나 VPN 경유를 통해 직접적으로 인터넷에 접속하는 것이 아닌, 각 거점을 통해 접속하는 것도 가능하다.

AWS 네트워크의 구성요소

또한 S3나 CloudWatch, DynamoDB 등 AWS 에는 VPC에 속하지 않는 서비스들도 다수 존재하고 있다. 이런 서비스들과 VPC내의 리소스 등을 연결하는 것은 설계상 아주 중요한 포인트가 된다. 다만 SAA 시험에서 그 부분에 대해 직접적으로 묻지는 않으며, VPC내에 배치하는 서비스들을 어떤 식으로 배치하는 것인가 정도만 알면 충분할 것이다.

 

IP 주소

VPC는 작성자가 자유로운 IP주소 (CIDR블록)를 등록하는 것이 가능하다. 네트워크 기반의 관리 폴리시에 맞춘 주소를 등록하는 것으로 자사 네트워크의 일부로 사용하는 것도 가능하다.

CIDR 블록은 /16 으로부터 /28의 범위로 작성할 수 있다. 시험에 연관되는 부분은 아니지만, 네트워크 공간은 가능한 큰 사이즈 /16으로 작성하는 것이 좋다. 확보한 공간이 작다면 IP주소가 부족한 경우가 발생할 수 있으며, 이 경우 상황이 발생한 다음 추가적으로 확장하는 방법은 생각보다 복잡하다.

IP주소에는 클래스 A ( 0.0.0.0 ~ 10.255.255.255), 클래스 B ( 172.16.0.0 ~ 172.31.255.255 ), 클래스 C ( 192.168.0.0 ~ 192.168.255.255 )가 사용된다. 다만 클래스 A의 경우엔 /8로 CIDR블록은 획득할 수 없으며, /16이 아니면 안 되므로 주의해야 한다.

사실 프라이빗 IP 주소의 범위 외에도 CIDR로 지정 가능하다. 하지만 여러 문제의 원인이 될 수 있기 때문에 기본적으로는 프라이빗 IP의 범위를 지정하는 것이 좋다.

서울 리전에 VPC의 작성 예

서브넷

서브넷은 EC2 인스턴스 등을 기동시 켜기 위한 VPC 내부에 만든 어드레스 범위라 할 수 있다. VPC에서 설정한 CIDR 블록의 범위에 들어가는 작은 CIDR 블록을 할당할 수 있다. 각각의 서브넷에는 하나의 갓아 라우터가 존재하여 이 라우터가 후술 하는 라우트 테이블과 네트워크 ACL의 설정을 가지고 있어 서브넷 내의 EC2 인스턴스의 기본 게이트웨이로 설정되어 있다고 생각하면 쉽게 이해할 수 있을 것이다.

• 서브넷에 설정된 CIDR 블록의 사이즈는 VPC와 같은 16 비트 (65536개)에서 4비트 (16개)까지 이다.
• 서브넷 작성 시에 가용 영역을 지정한다. 작성한 뒤 수정은 불가능하다.
• 서브넷 별로 라우팅 테이블을 하나만 설정할 수 있다 ( 작성 시에 메인 라우팅 테이블이 자동적으로 할당되며, 언제든 다른 라우팅 테이블로 수정이 가능하다 )
• 서브넷 별로 네트워크 ACL을 하나만 설정할 수 있다 ( 작성 시에는 기본 네트워크 ACL이 자동적으로 할당되지만, 언제든 다른 네트워크 ACL로 변경할 수 있다. )
• 하나의 VPC에 작성할 수 있는 서브넷은 최대 200개이며 별도의 신청을 통해 확장이 가능하다.

서브넷 작성 시 주의점

• 서브넷의 처음 4개, 마지막 1개는 예약되어 있기 때문에 사용이 불가능하다 ( 25비트 마스크의 서브넷일 경우 0,1,2,3,255이다)
• 필요 이상으로 서브넷을 분할할 경우 어드레스의 낭비로 이어진다. ( 28비트 마스크의 서브넷에는 16개의 IP가 부여되지만, 유저가 사용할 수 있는 건 11개뿐이다. )
• 서비스 안에서 IP 주소의 확보가 필요한 서비스가 있다 ( ELB의 경우 IP 어드레스는 8개 필요하다 )

서브넷과 AZ

CIDR내 서브넷을 작성한 예

서브넷 작성 시의 포인트는 동일한 역할을 가진 서브넷을 복수의 AZ에 작성하는 것이다. EC2나 RDS의 작성 시에 복수의 AZ에 나눠 구축하는 것으로 AZ 장애 시에 대한 가용성이 높은 설계를 구현할 수 있다. 이 구성은 다중 AZ라고 불리며 AWS의 설계에서 가장 기본이 되는 설계이다.

 또한 퍼블릭 서브넷 (public subnet), 프라이빗 서브넷 (private subnet)이라고 하는 개념이 VPC 관련 도큐먼트 여기저기 등장하지만, 서브넷의 설정, 기능으로 해당 서브넷은 존재하지 않는다. 앞으로 소개할 인터넷 게이트웨이, 라우팅 테이블, 네트워크 ACL 등을 이용하여 이런 역할들을 만들어 낸다고 할 수 있다.

라우팅 테이블

어드레스 설계의 다음은 라우팅 설계이다. AWS의 라우팅 요소에는 라우팅 테이블과 각종 게이트웨이가 있다. 이것들을 가지고 VPC내부의 통신이나, 인터넷, 온프레미스 네트워크 기반 등 외부 통신을 실현할 수 있는 것이다.

• 각각 서브넷에는 하나씩 설정한다.
• 하나의 라우팅 테이블은 복수의 서브넷에 공유되어 사용할 수 있지만, 하나의 서브넷은 복수의 라우팅 테이블을 적용할 수 없다.
• 수신 어드레스와 타깃이 되는 게이트웨이를 지정한다.
• VPC에는 메인 라우팅 테이블이 있고, 서브넷 작성 시 설정하지 않는 경우 기본 라우팅 테이블로 사용된다.

세큐리티 그룹과 네트워크 ACL

VPC의 통신 제한은 세큐리티 그룹과 네트워크 ACL을 이용하여 구현한다.

세큐리티 그룹은 EC2나 ELB, RDS 등 인스턴스 단위의 통신 제한에 이용된다. 인스턴스는 에 적어도 하나의 세큐리티 그룹을 설정할 필요가 있다. 통신의 제한으로는 인바운드 ( 외부에서 VPC로 접근 )와 아웃바운드 ( 내부에서 밖으로 )의 양방향 제한이 가능하다. 제한 항목으로서는 프로토콜 (TCP, UDP)와 포트 범위, 송수신처의 CIDR이나 세큐리티 그룹 등을 지정할 수 있다.

특징으로는 CIDR 등의 IP주소뿐만 아니라 세큐리티 그룹을 지정할 수 있다는 것이다. 또한 세큐리티 그룹은 기본적으로 접근을 거부하는 역할을 하고 있으며, 설정된 항목만 접근을 허용한다.

 

네트워크 ACL은 서브넷 별 통신 제한에 이용한다. 제한 가능한 항목은 세큐리티 그룹과 동일하며, 인바운드, 아웃바운드의 제한이 가능하다. 또한 송수신처의 CIDR과 포트의 제한은 가능하지만, 세큐리티 그룹을 대상으로 지정할 순 없다. 네트워크 ACL은 기본 설정으로는 모든 통신을 허용하는 입장이다. 세큐리티 그룹과 네트워크 ACL의 차이는 상태를 저장하는가이다. 세큐리티 그룹은 스테이트 풀로 응답 트래픽은 룰에 관계없이 통신을 허가한다. 반면 네트워크 ACL의 경우 스테이트레스로 응답 트래픽에 대한 어느 정도 명시적인 허가 설정을 하지 않는다면 기본적으로 통신을 단절시킨다.

이 때문에 Ephemeral port( 1025 ~ 65535)를 허가 설정하지 않을 시 돌아오는 통신은 거절된다.

게이트웨이

게이트웨이는 VPC의 내부와 외부와의 통신을 가능하게 해주는 입구라 할 수 있다. 인터넷과 연결하기 위한 인터넷 게이트웨이 (IGW)와 VPN이나 Direct Connect를 경유한 온프레미스 네트워크 기반과 접속하는 가상 프라이빗 게이트웨이 (VGW)가 있다.

인터넷 게이트웨이

인터넷 게이트웨이 (IGW)는 VPC와 인터넷과의 접속을 위한 게이트웨이이다. 각 VPC에 하나만 설정할 수 있다.

인터넷 게이트웨이 자체는 설정 항목이 아무것도 없다. 또한 논리적으로 하나밖에 보이지 않기에 가용성의 시점으로 단일 장애점( Single Point Of Failure, SPOF )이 되어 문제가 될 수도 있으나, IGW는 AWS에 의해 직접 관리되기 때문에 다중화나 장애 시의 복구는 모두 자동으로 이루어진다.

VPC와 게이트웨이

라우팅 테이블에 인터넷 게이트웨이를 타깃으로 지정함으로써 해당 수신처의 주소와 통신은 인터넷 게이트웨이를 통하여 인터넷으로 향하게 된다. 많은 경우 기본 라우팅인 ( 0.0.0.0 )을 지정하고 있다. 앞서 설명한 퍼블릭 서브넷의 조건중 하나는 라우팅 테이블에 인터넷 게이트웨이를 설정하는 것도 있다. 역으로 프라이빗 서브넷의 경우 라우팅 테이블에 IGW의 송수신 설정이 없는 네트워크가 된다.

 

EC2 인스턴스가 인터넷으로 통신하기 위해선 public IP를 가지고 있어야 한다. 또는 NAT 게이트웨이를 경유하여 인터넷을 사용하는 방법도 있다. NAT게이트웨이는 네트워크 변환 기능을 가지고 있어 private IP는 NAT 게이트웨이를 거쳐 글로벌 IP로 변환되어 외부와 통신이 가능해진다.

시스템의 신뢰성을 요구되는 경우 NAT 게이트웨이의 다중성이 과제가 된다. NAT 게이트웨이는 AZ에 의존하는 서비스이기에 다중 AZ 구성을 할 경우 AZ별로 별도 작성할 필요가 있다.

가상 프라이빗 게이트웨이

VGW는 VPC가 VPN이나 Direct Connect에 접속하기 위한 게이트웨이이다. VGW도 각 VPC에 하나만 설정할 수 있다.

하나만 존재해야 하지만 복수의 VPN이나 Direct Connect와 접속하는 것은 가능하다.

라우팅 테이블에 VGW를 타깃으로 설정하면 해당 송수신 어드레스로 통신은 VGW로부터 VPN이나 Direct Connect를 통하여 온프레미스 네트워크 기반에 향하게 된다. 온프레미스 네트워크의 송수신에 대해선 라우팅 테이블에 정적으로 표기하는 방법과, 라우터 전파 ( propagation ) 기능의 동적으로 반영하는 방법, 총 2가지가 있다.

VPC 엔드포인트

VPC 내에서 인터넷의 AWS 서비스에 접속하는 방법으로는 인터넷 게이트웨이 방법 외에  VPC 엔드 포인트라 불리는 특수한 게이트웨이를 사용하는 방법도 있다.

VPC 엔드포인트에는 S3나 DynamoDB와 연결할 시 이용하는 게이트웨이 포인트와 그 이외에 대다수의 서비스에서 사용하는 인터페이스 포인트 ( AWS Private Link )가 있다.

Gatewat Endpoint는 라우팅을 이용한 서비스이다. 엔드포인트를 작성하여 서브넷과 연결하는 것으로 해당 서브넷으로부터 S3나 DynamoDB로의 통신은 인터넷 게이트웨이가 아니라 엔드 포인트를 이용하여 이루어진다.

세큐리티의 관점에서는 VPC 엔드포인트는 상당히 중요하다. 경로의 안전성을 따져 인터넷을 경유하지 않는 것을 요구하는 상황이 많기 때문이다. 이럴 경우에는 VPC 엔드 포인트는 중요한 요소가 되기 때문에 설계 패턴을 익혀두는 것이 좋다.

VPC 엔드포인트

피어링 접속

VPC 피어링은 두 VPC 간 프라이빗한 접속을 하기 위한 기능이다. VPC 피어링에선 동일 AWS 어카운트의 VPC 간뿐만 아니라 AWS 어카운트를 어우르는 접속이 가능하다.

VPC 피어링의 통싱 상대는 상대 VPC 내의 EC2 인스턴스가 되며, IGW나 VGW등에 접속하는 것은 불가능하다. 또한 상대의 VPC가 피어링 하고 있는 또 다른 VPC에 접속하는 것도 불가능하다.

VPC Flow Log

VPC 내의 통신 분석에는 VPC Flow Log를 이용한다. 이 로그는 AWS에서 가상 네트워크 인터페이스 카드인 ENI ( Elastic Network Interface ) 단위로 기록한다. 기록된 내용은 통신처, 통신처의 주소와 포트, 프로토콜 번호, 데이터량과 허가/거부로 구별된다.

Direct Connect와 Direct Connect Gateway

AWS와 오피스나 데이터 센터 등 물리 거점을 전용선으로 연결하고 싶을 경우에는 AWS Direct Connect를 이용한다. Direct Connect를 이용한다면 VPN과 비교하여 연기나, 패킷 손실률이 낮으며 슬로 풋이 상승하는 등, 안정된 네트워크 품질로 이용할 수 있다. 또한 아웃 바운드 트래픽 요금은 Direct Connect 경유 쪽이 저렴하게 설졍할 수 있다. 네트워크 품질을 중요시 여길 경우 대량의 데이터를 주고받을 상황이 많은 경우 Dicrect Connect의 도입을 생각해보자.

 

또한 최근에는 여러 AWS 어카운트와 VPC를 이용하는 경우가 많아졌다. Direct Connect Gateway를 사용한다면 하나의 Direct Connect 접속으로 거점과 여러 AWS 어카운트나 VPC에 접속하는 것이 가능하기에 Direct Connect의 도입과 함께 세트로 검토할 필요가 있다.

또한 복수의 VPC와 온프레미스 네트워크를 중앙 허브로 이용하여 접속할 수 있는 AWS Transit Gateway라는 서비스도 있다.