[모듈 프로젝트] 웹 서비스를 위한 AWS 인프라 구축

요구사항 1. 웹서비스를 위한 AWS 인프라 구축

 

프로젝트의 시작인 AWS 아키텍처 설계부터 인프라 구축까지 진행하였다.

초기에 인프라 설계 및 구축이 잘 되어야 향후 취약점 분석까지 문제가 없기 때문에 이번 작업이 특히 더 중요했다.

 

 

요구사항 분석

요구사항 명세서를 분석한 결과, 우리 팀에서 구체화한 인프라 구축 계획은 아래와 같다.

요구사항 1. 웹서비스를 위한 AWS 인프라 구축
1.1. 가용성, 확장성, 보안성을 보장하는 AWS 인프라를 구축한다.
1.2. 인프라 주요 서비스에 대한 모니터링/경보 시스템을 구축한다.
1.3. 로그를 수집/저장 하는 시스템을 구축한다.
1.4. 산출물은 수행 계획서, 결과 보고서, 아키텍처 다이어그램, 인프라 운영 매뉴얼(선택) 이다.

 

유형	서비스	목적
계정	IAM	최소 권한 부여 정책을 반영한 계정 관리
네트워크	VPC	서비스 고유의 가상 네트워크 환경 구축
	Internet Gateway	VPC와 Internet간의 통신 환경 구축
	NAT Gateway	Private Subnet의 서비스를 외부와 연결
분산처리	ALB	트래픽을 분산하여 고가용성을 확보
서버	EC2	Web 서버, Bastion 서버 구축
	Auto Scaling Group	인스턴스 자동 조정으로 가용성/확장성 확보
데이터베이스	RDS	다중 AZ에 DBMS 구축
모니터링	CloudWatch	Dashboard, SNS 경보를 통한 자원 관리
로그 수집	CloudTrail	계정 및 API 활동에 대한 로그 수집
보안 강화	AWS WAF	방화벽 설정을 통한 취약점 보완

 

 

 

인프라 설계 & 아키텍처 다이어그램 제작

설계한 인프라 구조를 가시적인 다이어그램으로 표현하여 다시 한번 정리하였다.

이렇게 시각화하여 정리하자, 팀원들 모두 우리의 아키텍처를 확실히 이해하는 시간을 가질 수 있었다.

 

 

(0) IAM

- 최소 권한 부여 정책을 반영하여 인프라 구축에 필요한 권한만을 가진 IAM 사용자를 생성

 

(1) VPC

- VPC를 생성하고 CIDR 범위를 설정

CIDR

NACL

- Security Group은 최소한의 허용 범위만 설정

 

(2) 가용 영역

- 가용 영역을 최소 2개 확보하여 가용성을 갖춘 네트워크 구조로 설계 (본 프로젝트에서는 AZ-a, AZ-c 이용)
- 각 가용 영역에 동일한 서비스를 배치하여 한 가용 영역에 장애가 발생해도 서비스가 문제없이 제공되게 설계

 

(3) Subnet

- Public Subnet과 Private Subnet을 구분하여 보안, 접근 제어, 네트워크 성능 등을 최적화
- 웹 서버나 로드 밸런서와 같은 외부에서 접근해야 하는 리소스를 Public Subnet에 배치
- Private Subnet 에는 DB와 서버를 배치하여 외부에 노출되지 않아야 하는 중요한 리소스를 보호

 

(4) Gateway

- 모든 요청은 Internet Gateway를 통하는 구조로 설계

- Routing Table을 이용하여 Internet Gateway로 들어온 요청을 각 서브넷으로 전달

- 2개의 NAT Gateway를 각각 다른 가용 영역에 분산 배치

 

(5) ALB

- Auto Scaling Group을 생성

• 최소 2대의 서버를 유지
• 장애 발생 시 자동으로 Scale-out 되는 유연한 배포 환경 구축

- ALB를 대상으로 AWS WAF webACL을 설정하여 보안 취약점을 대비

 

(6) EC2

- EC2 인스턴스를 각각 Private Subnet에 배치하여 외부로부터 불필요한 접근 차단

- public subnet에 Bastion 서버를 구축하여 SSH 접속 관련 보안성 확보

 

(7) RDS

- Multi-AZ 설정을 허용하여 데이터베이스 고가용성 확보

- Bastion 서버와 키 파일을 이용하여 인가된 사용자 및 인스턴스만 해당 데이터베이스에 접근할 수 있도록 제한

 

(8) CloudWatch

- CloudWatch 대시보드를 통해 리소스 모니터링 지표들을 한눈에 볼 수 있는 환경을 구축

• 로그 그룹에서 수집된 로그를 상위 10개 로드하여 표 형태로 노출
• Target Group에 대한 Request 개수, Response Time을 가시적으로 나타내어 장애 발생 여부를 모니터링
• Bastion Host에 대한 Cpu Utilization, SNS Alarm 현황을 표시
• RDS의 Cpu Utilization, FreeableMemory를 표시
• Healthy Host, UnHealthy Host를 모니터링
• WebACL에 대한 Request 현황을 그래프로 표현

 

 

(9) Amazon SNS

- CloudWatch & AWS SNS를 활용하여 리소스 지표가 임계값을 초과할 경우, 알림 메일 발송

- Amazon EventBridge를 이용하여 EC2 인스턴스를 Terminate한 경우, 알림 메일 발송

CPU 사용량 초과 메일 발송 결과

EC2 Terminate 이벤트 메일 발송 결과

 

 

(10) AWS CloudTrail

- CloudWatch 로그 그룹을 생성하여 로그 내역을 저장하도록 설정

- CloudTrail을 활성화하여 AWS API 로그 수집 프로세스를 구축