💭 Minji's Archive

[2SeC] AWS 레이어 이해하기 + 2SeC 구조 이해하기

December 20, 2025

개요

우리 프로젝트는 EC2에서 발생한 웹 공격/접근 로그를 CloudWatch -> Kinesis -> ECS(Fargate) 위의 Logstash로 실시간 처리 -> OpenSearch에 적재 + S3에는 원본 장기 보관 이렇게 구성되어 있고, 모든 인프라는 Terraform으로 코드로 관리된다. 우리 프로젝트는 이해가 되는데, AWS 인프라에 대한 전체적인 흐름과 레이어가 헷갈려서 이 포스트에 정리해보고자 한다.

1. AWS 서비스의 ‘역할별 레이어’

AWS 서비스들은 보통 아래의 레이어들로 구분할 수 있다.

  1. Application / Compute Layer -> 실제로 프로그램이 도는 곳
  2. Container / Image Layer -> 실행 형태와 배포 단위
  3. Networking Layer -> 서로 어떻게 통신하는지
  4. Logging / Streaming Layer -> 로그를 어떻게 모으고 흘리는지
  5. Analytics / Storage Layer -> 저장하고 분석하는 곳
  6. IaC / Control Layer -> 이 모든 걸 누가, 어떻게 생성/관리하는지

2. Application / Compute 계층

(1) EC2 = 가상 컴퓨터

  • EC2 = AWS에 있는 리눅스 서버 한 대
  • SSH 접속 가능
  • 파일 시스템 있음
  • CPU, 메모리 직접 체감됨

2SeC에서는

  • DVWA 웹 서버
  • 공격을 당하는 대상
  • Apache / PHP / Docker 컨테이너가 여기서 실행됨
  • 로그가 /var/log/… 파일로 쌓임

헷갈렸던 부분들 정리

Q. Apache는 웹 서버인데 어떻게 Docker에서 실행된다는 거지? 무슨 말이지? A. Apache란 HTTP 요청을 받아서 HTML/PHP 결과를 응답으로 돌려주는 서버 프로그램이다. 리눅스에서는 모든 프로그램이 “프로그램 파일 -> 실행 -> 메모리에 올라감 -> 프로세스가 됨 -> 포트(80번)을 열고 대기” 방식으로 돌아간다. 즉 Apache는 sudo systemctl start apache2같은 명령으로 백그라운드에서 계속 실행 중인 프로세스이다.

Q. PHP는 뭐고, Apache랑 무슨 관계? A. PHP는 언어이자 실행기이다. 서버에서 실행되는 스크립트 언어로, 요청이 오면 실행된다. 보통 “브라우저 요청 -> Apache가 받음 -> 이게 PHP 파일이면 -> PHP 인터프리터에 넘김 -> PHP 실행 결과(HTML)을 받아서 -> 브라우저로 응답” 과정으로 돌아간다.

Q. 갑자기 Docker는 왜 나옴? A. DVWA는 “docker 컨테이너”로 실행된다. DVWA는 보통 docker run -d -p 80:80 vulnerables/web-dvwa처럼 배포된다. 즉 Apache + PHP + DVWA 코드를 Docker 이미지 하나에 묶어두고, EC2에서는 Docker만 실행하면 되는 것.

(2) ECS Fargate - 서버 관리 없는 컨테이너 실행기

  • ECS = 컨테이너 오케스트레이션
  • Fargate = EC2를 직접 안 만지는 ECS
  • 서버 보안패치, 커널, OS 신경 안 씀

2SeC에서는

  • Logstash 컨테이너 실행
  • Logstash는 “서버”가 아니라 컨테이너 단위 작업자
  • 로그를 받아서 -> 파싱 -> OpenSearch로 전송하는 로그 처리 공장

헷갈렸던 부분들 정리

Q. EC2 위에 DVWA 컨테이너 하나, Logstash 컨테이너 하나가 있고 이걸 ECS가 관리하는 건가? A. 아님. DVWA 컨테이너의 실행 위치는 EC2고, 실행 주체는 사람 or EC2 초기 스크립트. docker run / docker ps / EC2 안에서 직접 관리하는 방식으로 관리됨 -> ECS랑 전혀 관계 없음. Logstash 컨테이너는 ECS에서 실행되고, 실행 주체는 ECS 서비스. Task Definition, Service, Desired Count 방식으로 관리됨. +) ECS를 쓰는 방법은 2가지. (1) ECS + EC2 (EC2 Launch Type): EC2 생성해야 하고 패치, 용량, 장애 신경 써야 함. (2) ECS + Fargate: EC2 필요없음, 서버가 있는지 없는지 신경 안 씀, 컨테이너만 던지면 실행됨.

Q. 왜 ECS는 Logstash에만 쓰는 거지? A. Logstash는 항상 떠있어야 하고, 장애 나면 자동 재시작 필요하고, 로그량이 늘면 scale-out이 가능해야 해서 딱 전형적인 오케스트레이션 대상임. 반면 DVWA는 실습용 타겟이고 내부 구조를 직접 봐야 하며 공격자가 “서버 하나”를 때리는 그림이 필요해서 EC2가 더 교육용으로 적합함.

3. Container / Image 계층 (설계도)

Docker Image

  • 이 컨테이너는 이렇게 생겼다라는 레시피
  • 실행 파일 + 설정 + 라이브러리 포함

ECR - Docker Image 창고

  • ECR = AWS용 Docker Hub
  • ECS는 이미지 없이 실행 불가

2SeC에서는

  • Logstash 커스텀 이미지: Kinesis input plugin, OpenSearch output plugin
  • Github actions -> ECR로 push
  • ECS는 ECR에서 pull해서 실행됨

헷갈렸던 부분 정리

Q. ECR이랑 ECS랑 무슨 관계? A. ECS는 ‘컨테이너를 실행하는 서비스’이고, 컨테이너를 실행하려면 반드시 ‘이미지’가 필요함. 그래서 이미지를 ECR에서 가져와서 ECS가 실행하는 것. ECS는 오직 “이미 빌드된 Docker Image”만 실행함. 우리 프로젝트에서는 Logstash를 실행하기 위한 Docker 이미지를 미리 빌드하고 -> 그 이미지를 ECR에 저장한 뒤 -> ECS가 ECR에서 이미지를 pull해서 Logstash 컨테이너를 실행하는 흐름. 즉 GitHub Repo에서 Dockerfile를 읽어서 -> GitHub Actions에서 docker build가 실행되고 -> 도커 이미지가 생성되고 -> 이를 ECR로 Push 함.

4. Networking 계층

VPC

  • AWS 안의 “가상 사설 네트워크”
  • 우리만 쓰는 네트워크 공간

IGW/NAT

  • IGW: 외부 -> 내부
  • NAT: 내부 -> 외부
  • Logstash가 외부(Kinesis, AWS API)에 나갈 수 있는 이유는 NAT임

5. Logging & Streaming 계층

CloudWatch Agent (EC2 내부)

  • 파일을 계속 tail하면서 로그를 CloudWatch로 전송함
  • 우리 프로젝트에서는 /var/log/apache2/access.log, /var/log/docker/dvwa.log

CloudWatch Logs

  • 로그를 중앙에 모아두는 서비스
  • 분석용은 아님. 중간 집결지같은 느낌

Kinesis Data Streams

  • 실시간 로그 파이프
  • 대량 이벤트 스트리밍용

2SeC에서는

  • CloudWatch Subscription Filter -> Kinesis
  • Logstash가 여기서 pull함

6. Analytics & Storage 계층

OpenSearch

  • 검색 + 분석 DB
  • 로그 전용

OpenSearch Dashboards

  • OpenSearch 전용 시각화 UI

번외 - Terraform이란?

  • Terraform = 인프라 설계도 + 실행기
  • EC2, ECS, VPC, IAM을 코드로 정의해서 버튼을 클릭하지 않고 코드로 인프라를 생성
  • terraform apply를 하면 -> VPC / EC2 / ECS / OpenSearch 생성 + IAM Role 연결까지
  • Terraform은 실행 환경이 아니라 관리자임.