[최종 프로젝트] AWS 아키텍처 구축 - 1

최종프로젝트의 전체 아키텍처를 설계해보았다. 이를 토대로 AWS 인프라를 구축해보려고 한다.

 

다음 순서로 진행할 예정이다.

1. VPC 생성
2. 서브넷 생성 (public 2대, private 2대)
3. EC2 인스턴스 생성 
4. 라우팅 테이블 생성 (IGW, NAT, 서브넷 연결)
5. 보안그룹 생성
6. ELB 생성
7. RDS 생성
8. 애플리케이션 배포

 

AWS Cloud 내에는 Region이 존재하며, 각 Region 안에는 2개 이상의 AZ(Availability Zone)이 있다

Region 이 국가/도시 단위의 지리적 위치라면, 가용영역(AZ)는 각 리전 안의 데이터 센터라고 보면 된다

하나의 가용영역이 각종 재해, 정전 등 다양한 이유로 작동불능이 되더라도 다른 가용영역에서 서비스를 재개하여 유지할 수 있고 보안적인 측면에서도 이점을 가진다

 

1. VPC (Virtual Private Cloud) 생성

VPC

AWS 클라우드에서 논리적으로 격리된 공간을 프로비저닝하여 사용자가 정의하는 가상의 네트워크

* 프로비저닝 : 어떤 종류의 서비스든 사용자의 요구에 맞게 시스템 자체를 제공하는 것

 

쉽게 말하면, AWS 용 나만의 개인 네트워크 망 데이터 센터라고 생각하면 된다. 전에 EC2 인스턴스 하나를 생성할 때는 따로 VPC를 생성하지 않았는데 사실, AWS 계정을 생성하면 각 리전에 기본 VPC가 자동으로 생성된다. 그만큼 중요하기 때문에 AWS는 모든 서비스에 VPC를 적용하도록 강제하고 있다.

 

region을 서울로 변경하고 VPC 생성 버튼을 누른다

 

설정값을 선택하고 생성하면 devloop라는 vpc가 생성되었다

(참고로 위의 - 는 계정을 생성할 때 함께 만들어지는 기본 vpc이다)

 

2. 서브넷 (Subnet) 생성

서브넷

VPC의 IP주소를 나누어 리소스가 배치되는 물리적인 주소 범위

 

VPC가 논리적인 범위라면, 서브넷은 VPC 안에 실제로 EC2, RDS 같은 리소스를 생성할 수 있는 네트워크 영역이다

하나의 VPC에 여러개의 서브넷을 가질 수 있고, 하나의 AZ에만 생성이 가능하다

• Public Subnet - 인터넷에 접근 가능한 서브넷 
• Private Subnet - 인터넷과 접근 불가능한 서브넷

private subnet은 외부에 노출되어 있지 않기 때문에 민감한 데이터 정보를 저장하여 외부 공격으로부터 보호를 강화할 수 있다. 만일 데이터를 업데이트하는데 인터넷 연결이 필수라면 NAT 게이트웨이를 통해 인터넷을 가능하게 만들 수 있다

 

생성한 VPC 내에 private 서브넷 2개, public 서브넷 2개를 생성하려고 한다

위에서 만든 VCP를 선택한다

 

이렇게 총 4개의 서브넷을 생성했다

 

`작업` > `서블릿 설정 편집` 

앞서 만든 2개의 public 서브넷에 들어간 모든 IP를 자동으로 퍼블릭 주소로 활성화 해주는 자동 할당 활성화를 체크 해준다. 이걸 설정해주지 않으면 인터넷과 통신을 못한다

 

3. 서브넷에 EC2 ( Elastic Compute Cloud ) 인스턴스 넣기

EC2

AWS에서 제공하는 가상 서버

 

클라우드 인프라에서 작동하며, 사용자가 원하는 CPU, 메모리, 운영체제 등을 선택하여 애플리케이션을 실행할 수 있는 컴퓨팅 리소스를 제공한다.

 

Private 서브넷에 springboot를 실행시킬 서버 생성

원래는 프리티어 사용 가능인 `t2.micro`를 선택했는데, 추후에 SpringBoot를 실행시켰을 때 EC2가 죽는 문제가 발생해서 `t2.medium`으로 변경했다. (시간당 요금이 발생하기 때문에 과금 주의)

`t2.micro`는 1GB 메모리이기 때문에 SpringBot와 Docker 데몬을 실행할 메모리가 부족했을 것이다.

 

생성한 VPC와 private 서브넷을 선택한다. 또한 만들어 두었던 보안그룹을 선택한다.

 

프리티어는 총 30GB까지 제공하는데 여러 개의 EC2 인스턴스를 만들 것이기 때문에 일단 8GB로 선택했다

 

Public 서브넷에 Bastion Host 생성

\

이렇게 Private 서브넷에 위치한 EC2 인스턴스들은 외부에서 접근할 수 없다. 따라서 Proxy 역할을 해주는 Bastion Host를 생성하여 SSH 접속을 하면 Private 환경에 접근할 수 있게 된다.

 

Bastion Host를 통해서만 인스턴스에 접근할 수 있기 때문에, 보안성을 높일 수 있다

 

public 서브넷과 만들어 두었던 보안그룹을 선택한다

탄력적  IP를 할당해주면 EC2 인스턴스를 중지하고 다시 실행해도 IP가 바뀌지 않는다

 

Basiton Host의 인바운드 규칙으로 관리자의 고유 IP만 접근할 수 있도록 해서 보안성을 강화했다. 

이렇게 총 4개의 인스턴스를 생성하였다

 

4. 라우팅 테이블 (Routing Table)

 

각각의 서브넷은 서로 다른 네트워크 영역을 가지고 있다. 따라서 한 서브넷에서 다른 서브넷으로 가기 위해서는 Routing이 필요하다. VPC 내부 모든 서브넷은 Routing이 자동으로 생성되어 있어서 동일 VPC 내 서브넷에서 자유롭게 통신할 수 있다.

다만, VPC는 기본적으로 격리된 네트워크 환경이라, 인터넷을 사용할 수 없다. VPC 내에 Public 서브넷의 EC2가 인터넷에 연결되려면, 인터넷 게이트웨이로 가는 경로가 라우팅 테이블에 정의되어야 한다.

 

인터넷 게이트웨이 생성

인터넷 게이트웨이를 생성해서 VPC에 연결한다. (인터넷 게이트웨이는 VPC 하나만 연결 가능)

 

Public 용 라우팅 테이블 생성

라우팅 테이블을 보면 로컬 서브넷끼리 통신하기 위해 기본적으로 만들어져 있다. 외부 인터넷과 통신하기 위한 Public 라우팅 테이블을 만들어야 한다

`서브넷 연결 편집` 으로 가서 생성된 라우팅 테이블을 Public 서브넷과 연결한다 

 

pulbic 서브넷에 인터넷 게이트웨이 라우팅 설정

`라우팅 편집`으로 가서 인터넷 게이트 웨이를 연결한다

이렇게 Public 서브넷 2개를 명시적으로 인터넷 게이트웨이를 연결한 라우팅 테이블에 등록하였다

따라서 인터넷 게이트 웨이로 향하는 라우팅이 있는 경우, Public 서브넷으로 가게 된다.

• Public 서브넷 → 내부와 인터넷 통신 가능 (Local Routing, 인터넷 게이트웨이 Routing)
• Private 서브넷 → 내부 통신만 가능 (Local Routing)

 

그렇다면, Private 서브넷이 외부 통신을 해야 한다면 어떻게 해야할까?

이러한 경우에는 위에서 생성했던 Bastion Host와 NAT 게이트웨이 기술이 있다. Bastion 서버는 관리자가 Private 서브넷으로 접근하기 위한 수단이고, NAT 게이트웨이는  Private 서브넷 내 리소스가 인터넷에 접근하기 위한 수단이다. 즉, Private 서브넷의 인바운드 트래픽은 Bastion Host이고, 아웃바운드 트래픽은 NAT 게이트웨이가 되는 것이다.

 

NAT 게이트웨이 생성

NAT 게이트웨이는 외부에 접근할 수 있어야 하기 때문에 public 서브넷으로 할당해야 하고, 탄력적 IP를 만들어서 할당해야 한다.

 

인터넷 게이트웨이를  public 서브넷 라우팅 테이블에 추가했던 것처럼, NAT 게이트웨이를 private 서브넷 라우팅 테이블에 추가한다