이번 프로젝트에서는 기존에 공부하던 백엔드 개발 뿐만 아니라, 인프라 환경 구축도 경험 해보고 싶어서 담당하게 되었습니다.
AWS를 혼자 공부할 때는 비용이 부담되어 많은 서비스를 사용해보지 못했었는데, 소마에서 지원금이 나오기 때문에 최대한 많은 서비스를 사용해보고, 현재 프로젝트 환경에 적합한 알맞은 서비스를 선택해 나가는 과정을 기록해 보려고 합니다.

가장 먼저, 네트워크 환경을 세팅하겠습니다.

VPC (Virtual Private Cloud)

• 논리적으로 격리된 가상 네트워크
• AWS 리소스들이 위치할 네트워크 공간
• 다수의 AZ(Availability Zone)로 구성할 수 있다.
• Private IPv4 또는 IPv6를 사용할 수 있고 CIDR 표기법을 이용한다.

Subnet

• VPC CIDR블록의 하위 집합.
• VPC 내의 단일 AZ에 위치한다.
• 서브넷 간 중첩 불가

서브넷은 두 가지 형태로 활용될 수 있다.

Public Subnet

• 외부 접근이 가능한 네트워크 영역
• 기본적으로 서브넷 생성시 외부와 통신할 수 없으므로 Private 이라고 생각하면 되며, 서브넷과 연결된 라우팅 테이블에 IGW(Internet GateWay)를 연결하여 인터넷과 양방향 통신을 허용하게 되면 Public으로 활용할 수 있다.
• Public 서브넷은 인터넷과 연결이 가능하기 때문에 Public IP를 가진다.
• Public IP는 인스턴스를 Stop 또는 Start 할 때 변경되지만, Elastic IP를 부여하면 고정 가능.

Private Subnet

• 외부에서 직접 접근이 불가능한 네트워크 영역
• NAT(Network Address Translation) GateWay를 이용하면 Private 서브넷 내부의 Private IP주소를 가진 인스턴스가 내부 → 외부로 (아웃바운드) 인터넷을 이용하게 할 수 있다.
  • Public 서브넷에 NAT 게이트웨이를 생성
  • Elastic IP를 할당
  • Private 서브넷의 라우팅 테이블에서 NAT 게이트웨이 라우팅
• 일반적으로 버전 업그레이드를 위해 적용한다.
• 동일 VPC 영역에서는 Private IP로 접근이 가능하다.

굳~이 서브넷을 분리하는 이유

• 가장 큰 이유는 당연히 보안이다.
• 리소스들을 안전하게 관리하기 위해 외부 노출을 최소화 시키는 것이다.
• DB와 WAS 등을 Private 서브넷에 위치시키고, Public 서브넷에는 LoadBalancer, 인스턴스 접속을 위한 Bastion Host 등을 둔 설계를 통해 보다 안전하게 리소스를 관리할 수 있다.

이후 과정은 다음 게시글에서 진행하겠습니다.
[참고 블로그] https://dontbesatisfied.tistory.com/13