AWS 클라우드 아키텍쳐 1.2 버전 구현

AWS 아키텍쳐 구현 경험

뭉크테크 2024. 10. 27. 18:10

이번 시간에는 저번에 구축해본 아키텍쳐 1.1 버전을 보강한 1.2 버전에 대한 글을 남기고자한다.
이전에 내가 부족하다고 느꼈던 부분들은 온전히 다 수정해봤고, 나아가 맨 아래 미리 보여준 아키텍쳐에서 수정한 부분들도 있었다
그 이유는 CloudFront는 굳이 넣을 필요가 당장은 없었다. 왜냐하면, 내가 처음에 넣은 이유는 CloudFront와 Aws Certificate 를 연동시켜 HTTPS 통신 구현을 목적으로 넣은 것이다.
그러나 이미 ALB가 있으면 ALB에다가 AWS Cerficate와 연동시키면 되기때문에 굳이 CloudFront를 넣지는 않았다. CloudFront의 주요 기능이 캐싱 역할인데, 그 기능도 크게 써먹고 있지는 않으니 더욱 쓸 필요가 없었던 것이다.
바로 아키텍쳐 소개를 시작하겠다

S3를 내용물을 조회하는 Node.js 어플리케이션 EC2 웹서버를 https://httpstest.sjmweb12.com/ 이라는 URL을 통해 사용자가 접속할 수 있도록 구성한 아케텍쳐입니다.
최대한 보안에 신경 쓰기 위해 통신 보안, 최소 권한의 원칙, 주요 통신 노출 금지 등을 활용하였습니다.

1.1. 정의

Route 53: 도메인 등록, DNS 관리, 트래픽 라우팅을 위한 확장 가능한 DNS 웹 서비스입니다.
ALB(Application Load Balancer): HTTP와 HTTPS 트래픽을 대상으로 한 애플리케이션 레벨의 로드 밸런서로, 웹 애플리케이션의 트래픽을 분산시켜 가용성과 확장성을 제공합니다.
ACM(AWS Certificate Manager): SSL/TLS 인증서를 손쉽게 생성하고 관리하여 웹 애플리케이션의 보안을 강화할 수 있도록 지원하는 서비스입니다.

1.2. 구성 역할

Route 53: 사용자가 https://httpstest.sjmweb12.com/ 라는 URL에 접속을 시도하면 ALB로 라우팅해준다.
ALB(Application Load Balancer): 사용자가 위 URL에 접속을 시도하면 타겟 그룹안에 있는 EC2 웹 서버쪽으로 트래픽 전달하는데, 이때 사용자와는 https 통신을, 웹 서버와는 http 통신을 제공한다. 서버가 다운되어있는지 health check 기능도 수행한다.
ACM(AWS Certificate Manager): httpstest.sjmweb12.com/ 라는 도메인에 대한 인증서를 발급하고 ALB와의 연동 설정을 통해 사용자 단에서 HTTPS 통신을 할 수 있도록 해준다.

1.3. 보안 고려 사항

EC2 서버를 외부에 노출 시키지 않도록 사용자와 EC2서버 중간에 ALB를 두었습니다.
그림 3을 보면, 해당 ALB에 ACM의 도메인 인증서를 연동시키고, 리스너를 HTTPS 프로토콜로 설정함으로써 사용자와의 송수신간 기밀성을 보장하였습니다.

그림 4 아키텍쳐 내부단 1	2.1. 정의 NAT Gateway: AWS에서 제공하는 네트워크 주소 변환 서비스로, 사설 서브넷의 EC2 인스턴스가 인터넷에 접근할 수 있도록 IP 주소 변환을 지원합니다. EC2: AWS의 가상 서버 제공 서비스로, 필요에 따라 확장 가능한 컴퓨팅 용량을 제공하여 애플리케이션 호스팅 및 실행을 지원합니다.
	2.2. 구성 역할 NAT Gateway: EC2 서버의 인터넷 통신을 제공하는 역할을 함으로써 EC2 서버에서 특정 파일을 다운로드할 때 중간 매개체로서 주로 사용된다. EC2: 사용자가에게 제공할 웹페이지를 호스팅한다

2.3. 보안 고려 사항

그림 4을 보면, EC2를 프라이빗 서브넷에 배치함으로써 외부와의 노출을 최소화시켰습니다. 나아가 그림 5를 보면, 보안 그룹은 ALB 보안 그룹으로부터 오는 HTTP 통신만 허용하도록 구성하였습니다.
EC2에서 외부와의 통신을 시도할 시 퍼블릭 서브넷에 있는 NAT를 활용하여 이 또한 EC2의 IP 및 포트를 최대한 외부에 노출시키지 않도록 하였습니다.

3.1. 정의

S3(Simple Storage Service): AWS의 객체 스토리지 서비스로, 대규모 데이터를 안정적으로 저장하고 관리하며 다양한 애플리케이션에 필요한 파일을 저장하기에 적합합니다.
Session Management: 사용자의 인증 세션을 관리하는 AWS의 기능들로, 주로 AWS Cognito와 함께 사용하여 애플리케이션 로그인 세션을 안전하게 관리합니다.
IAM(Identity and Access Management): AWS 리소스에 대한 접근 제어 및 권한 관리 서비스로, 사용자의 접근 권한을 세밀하게 설정하여 보안을 강화할 수 있습니다.

3.2. 구성 역할

S3(Simple Storage Service): EC2 서버에게 필요한 파일 목록을 조회하거나 파일을 제공할 수 있도록 한다.
Session Management 관리자: EC2 서버를 직접 접속하여 관리하고자할 떄, SSH 키를 이용하여 접속하는 것이 아닌, AWS 콘솔을 이용하여 안전하게 접속할 수 있도록 도와준다.
IAM(Identity and Access Management): EC2가 S3에 읽기 접근을 할 수 있도록 AmazonS3ReadOnlyAccess 정책을, SSM을 이용할 수 있도록 AmazonSSMManagedInstanceCore 정책이 있는 역할을 EC2에 적용하였다

3.3. 보안 고려 사항

EC2에서 S3에 접근 시, 외부 인터넷을 경유해서 접속하는 것이 아닌 Gateway Endpoint를 통해 AWS 내부에서 통신 트래픽을 처리함으로써 통신 트래픽의 외부 노출을 최소화하였다.
EC2가 S3 이용시 파일 조회만 하면되기 때문에, 최소 권한 원칙을 지키고자 AmazonS3ReadOnlyAccess 역할을 EC2 서버에게 부여하였다.
나아가 SSH 키를 생성하여 EC2에 SSH로 접속하는 것은 EC2 자체에 SSH 포트를 개방시키고, IP도 외부에 노출되며, 키도 외부 유출되면 보안상 치명적이라고 하여 AWS 자체내에서 제공하는 Session Management를 활용하여 AWS 내부에서 EC2에 접속할 있도록 하였다.

다른 분들의 아키텍쳐를 참고해가며, 내가 놓친 부분들이 무엇일까를 고민해보며 이전 아키텍쳐를 보강했더니, 나름 완성도있는 아키텍쳐를 구성해서 뿌뜻했다.
보안 측면에 있어 내가 간과한 부분들이 뭘까, 내가 이 구성 요소를 쓰는 이유는 뭐지, 굳이 이걸 넣어야하나, 괜히 욕심부려서 의미도 없는 기능들을 추가하고 있는 것이 아닌가 라는 고민도 하게되었다
사람들과 서로 피드백을 주고 받고, 오류를 찾아 해결해나가는 과정은 이전부터 중요하다고는 생각은 했다. 그러나 그것을 실제로 체감해본 것은 이번이 거의 처음인듯 싶다. 물론 이전 주차에서도 이런 과정이 있었지만, 크게 와 닿지는 않았었다. 거의 이론 위주로 정리하는 시간을 가지다보니 크게 몰입도 안되었고, 수용하고 반영한다고 한 들, 글 몇 줄 수정되거나 추가된 것 밖에 없었기 때문이다. 물론 이러한 과정을 거치고 지금을 맞이하였기에 돌이켜 생각해보면 의미없는 과정은 없었다