- 나의 해석 : API GATEWAY를 통해 들어온 API에 대해 ACM이 자격증명을 거친다. 그 이후 EC2 인스턴스에서 API GATE WAY를 통해 인증되었다면 S3나 Lambda 함수에 접근할 수 있다.
0. 한 줄 요약
ACM이 발급한 HTTPS 인증서를 쓰는 API Gateway를 앞단에 두고,
요청은 VPC 안의 EC2, Lambda, S3 버킷으로 각각 라우팅하는 애플리케이션 계정 아키텍처
즉,
- 바깥에서 들어오는 요청 → API Gateway가 전부 받아서
- 일부는 EC2로 프록시,
- 일부는 Lambda 실행,
- 일부는 S3에 바로 저장
하게 설계한 구조.
1. 컴포넌트부터 정리
(1) OU – Workloads / Application account / Permissions / Roles
-
이 계정은 실제 서비스가 돌아가는 애플리케이션 계정.
-
IAM Permissions / Roles는:
- EC2에 붙는 Role (예: S3 읽기 권한, CloudWatch 로그 권한)
- Lambda에 붙는 Role (S3 data bucket 읽기/쓰기 권한 등)
- API Gateway가 S3·Lambda·VPC에 접근할 때 쓰는 Role
들을 의미
(2) Amazon API Gateway
-
이 구조의 “정문(프런트 도어)” 역할.
-
클라이언트(브라우저, 모바일 앱, 다른 시스템)는 전부 API Gateway의 URL/도메인으로 접속.
-
API Gateway는 메서드별로:
- EC2 백엔드로 프록시
- Lambda 실행
- S3에 직접 쏘기(서비스 통합)
(3) AWS Certificate Manager (ACM) + Certificate authority
- ACM: SSL/TLS 인증서를 관리하는 서비스.
- Certificate authority: 인증서를 실제로 발급해 주는 CA (Amazon Trust Services 같은 루트/중간 CA).
- API Gateway 앞에 붙일 HTTPS 인증서(도메인용) 를
“ACM이 CA로부터 받아서 관리”
(4) Amazon S3 – store bucket / data bucket
-
Amazon S3 store bucket
- API Gateway가 직접 연결되는 버킷.
- 로그/요청 본문/업로드 파일 등을 “그대로 저장”하는 용도일 가능성이 큼.
-
Amazon S3 data bucket
- Lambda가 사용하는 데이터 저장소.
- 가공된 결과, 레포트, 분석 데이터, 설정 파일 등 비즈니스 데이터.
(5) AWS Lambda
- 서버 없이 코드를 실행하는 함수.
- API Gateway가 특정 엔드포인트를 호출하면 해당 Lambda를 트리거.
- Lambda는 안에서 S3 data bucket을 읽고/쓰고, 필요하면 다른 서비스도 호출.
2. 번호로 보는 흐름
그림의 검은 동그라미 번호랑 맞춰볼게.
① API Gateway ↔ ACM : HTTPS 인증서 연결
“API Gateway가 쓸 인증서를 ACM에서 가져와서 붙인다.”
-
먼저 ACM에 도메인 인증서를 만들어놓고(예:
api.myservice.com), -
API Gateway에서 Custom Domain Name 설정 시 ACM 인증서를 연결.
-
그 결과:
- 클라이언트는
https://api.myservice.com으로 접속하고, - TLS 핸드셰이크 시 ACM이 관리하는 인증서가 사용됨.
- 클라이언트는
② ACM ↔ Certificate authority : 인증서 발급/갱신
“ACM이 CA에 가서, 이 도메인 진짜 우리 거니까 인증서 주세요~ 라고 요청.”
-
ACM은 내부적으로 CA와 통신해서:
- 도메인 검증(DNS 검증, 이메일 검증 등)을 수행하고,
- 검증이 끝나면 정식 TLS 인증서를 발급받음.
-
만료되기 전에 자동 갱신도 ACM이 알아서 처리해 줘서,
- 운영자는 인증서 갱신 걱정을 크게 줄일 수 있음.
③ API Gateway → EC2 instance (VPC Private 통신)
“일부 API는 VPC 안 EC2로 프록시한다.”
-
API Gateway에서 VPC Link / Private integration을 설정해두면,
- 특정 경로 예:
GET /legacy/*요청은 - VPC 안의 EC2 인스턴스(혹은 NLB, ALB)로 라우팅.
- 특정 경로 예:
-
이때 트래픽은:
- 인터넷으로 나가지 않고,
- AWS 백본 네트워크 + VPC 내부 통신으로만 이동.
예시
/report API는 예전에 EC2에 올려둔 Spring Boot 애플리케이션이 담당하고 있다면,
API Gateway GET /report → EC2 http://10.0.1.15:8080/report 로 프록시하는 식.
④ API Gateway → Amazon S3 store bucket
“어떤 요청/응답은 S3에 바로 저장한다.”
-
API Gateway는 서비스 통합(Service integration) 으로
S3를 직접 호출할 수 있음. -
예를 들면:
PUT /upload요청을 받으면,
본문을 그대로 S3store-bucket/user-123/file.txt에 저장.- 또는 API 로그, 요청 Raw 데이터 등을 증거 보존용 버킷에 저장.
비유
“리셉션(API GW)이 어떤 서류를 받자마자, 사무실(Lambda/EC2)에 보내지 않고
그냥 바로 창고(S3 store bucket) 에 꽂아두는” 느낌.
⑤ API Gateway → AWS Lambda
“나머지 비즈니스 로직은 Lambda 함수로 실행한다.”
-
POST /cases,GET /analysis같은 엔드포인트를 Lambda에 매핑. -
요청이 오면 API Gateway가 이벤트를 JSON으로 만들어 Lambda에 전달.
-
Lambda는 코드를 실행해서 비즈니스 로직 처리 후,
- 응답 JSON을 돌려주면,
- API Gateway가 이걸 HTTP 응답으로 변환해서 클라이언트에게 반환.
⑥ AWS Lambda ↔ Amazon S3 data bucket
“Lambda가 비즈니스 데이터 S3 버킷을 읽고/쓴다.”
-
Lambda 함수 Role에 S3 data bucket 읽기/쓰기 권한을 부여해 두고,
-
함수 안에서:
- 데이터를 S3에서 로딩,
- 가공,
- 결과를 다시 같은 버킷 혹은 다른 prefix에 저장.
예시
-
/analyzeAPI 호출 → Lambda가:- S3 data bucket에서
raw-logs/아래 로그 파일 읽고, - 분석 후
reports/아래에 요약 JSON 저장, - 클라이언트에게 “분석 완료, 리포트 위치는 /reports/xxx.json” 반환.
- S3 data bucket에서
