AWS DVA-C02 #24 서버리스 CI/CD

#개발자의도구들 #AWS시험 #AWSDVA-C02 #DVA-c02문제 #DVA-c02덤프

​

참고: ExamPotic Disscussion

문제 찾는법 : 여기 최하단

요구사항 분석

• 정적 웹사이트 다수 운영
• 소스 저장소가 혼합: CodeCommit, Bitbucket, GitHub
• 단계적 배포(Phased releases): dev → staging → UAT → prod 환경 분리
• 브랜치 머지로 배포 트리거 (환경별 대상 브랜치 다름)
• HTTPS 전 구간(클라이언트 ↔ 엣지, 엣지 ↔ 오리진)
• 상시 서버 없이(Serverless/Managed), 운영 오버헤드 최소화

​

📌 Least Operantional

보기 분석

A. AWS Amplify Hosting

• Amplify로 각 웹사이트 호스팅
• Git 브랜치를 환경(dev/staging/prod 등)과 연결
• 브랜치 머지 시 자동 빌드, 배포
• 서버리스 구조, HTTPS, CloudFront, S3 자동관리 → 운영 오버헤드 감소

​

B. Elastic Beanstalk + CodePipeline

• Beanstalk에 각 환경(dev/staging/prod)구성
• EB CLI로 브랜치 이동
• CodePipeline으로 코드 머지시 자동 배포
• EC2 기반 상시 서버 필요

​

❌ 정적 사이트에는 과도한 스팩

​

C. S3 + CodePipeline/CodeBuild

​

❌ 오버헤드 높음

​

D. EC2 + 커스텀 스크립트

​

❌ 운영 부담 가장 크다.

단계별 필요 지식 (too much)

문제 요구사항 단계별로 필요한 서비스들을 정리하였다.

​

• 정적 웹사이트
• S3: 정적 파일 저장
• Amazon CloudFront: 전 세계 캐싱, HTTPS, 커스텀 도메인
• ACM 인증서: CloudFront용 TLS(HTTPS)
• Origin Access Control(OAC): CloudFront만 S3에 접근(퍼블릭 차단)
• 캐시 무효화(Invalidation): 배퐆 후 최신 팡리 서빙

​

• Git연동 & 브랜치 기반 자동 배포
• AWS CodeStar Connections: Github/Bitbucket 연결을 위한 표준 커넥터
• AWS CodeCommit: 네이티브 Git 소스
• 트리거: 브랜치 필터(dev, staging, uat, main/master)로 파이프라인 시작

​

• 서버리스 CI/CD
• 최소 오버헤드: AWS Amplify Hosing
• Github, Bitbucket, CodeCommit 모두 지원
• 브랜치 ↔ 환경 매핑으로 자동 배포
• CloudFront - S3 - HTTPS - domain 연결을 벡엔드에서 자동관리
• PR 미리보기/리라이트 - 리디렉션, 규칙 / 비공개 환경 보호 등 제공

​

-

• AWS CodePipeline + CodeBuild
• 소스: CodeCommit 또는 CodeStar Connections
• 빌드: CodeBuild로 정적 산출물 생성
• 배포: S3로 업로드 → CloudFront Invalidation
• 환경별로 파이프라인 분리 혹은 하나의 파이프라인 내 여러 스테이지 + Manual approval(UAT → Prod 전 승인)
• 전부 서버리스

개념 정리

AWS amplify Hosing

정적 웹사이트 및 프론트엔드 앱을 완전 관리형으로 호스팅하는 서비스

• Git 기반 브런치 연동
• 브런치 코드 변동시 자동 빌드 & 배포
• CloudFront + S3 + ACM(HTTPS) 구성, 캐시/도메인/리디렉션 등을 벡엔드에서 자동 관리
• 서버리스 구조 : 상시 서버 없음

​

👏 장점

• 운영 오버헤드 감소: 인프라 프로비저닝 설정 불필요
• HTTPS 기본제공: 무료 ACM 인증서 자동 발급
• 다중 환경 지원: 브랜치별 별도 환경 생성
• 미리보기 기능: PR/브랜치 미리보기 자동 생성
• VCS 지원: GitHub, GitLab, Bitbucket, AWS CodeCommit

​

👇 사용 사례

• 마케팅, 랜딩 페이지, 블로그, 포털 등 정적 콘텐츠 위주
• SPA/SSR 지원 필요 없는 순수 프론트엔드 앱
• 브랜치 단위 환경과 자동 배포가 필요한 프론트앤드 팀

​

✅ 프론트엔드 프로젝트 CI/CD 전용

실습

• Git source와 연동

• Github 로그인 후 나의 repo를 모두 불러올 수 있다.

• branch별로 생성이 가능하다.

헷갈리는 서비스들

Elastic Beanstalk

애플리케이션 실행 환경을 자동 프로비저닝 관리해주는 PaaS

• EC2, ELB, Auto Scaling, RDS 등 인프라를 자동 구성하되, 필요시 직접 수정 가능
• Node js, java, Python, .NET, PHP, GO 등 백엔드 런타임 지원

​

📌 차이점

• 상시 서버 운영 필요 (EC2 기반)
• 정적 웹 호스팅보다는 백엔드 애플리케이션 배포에 최적화
• HTTPS 가능하지만 CloudFront, ACM 수동 구성 필요
• Git 연동 가능하나, 브랜치별 환경을 자동 세팅하는 기능이 없다.

​

👇 사용 사례

• API 서버, 백오피스, 데이터 처리 애플리케이션
• 서버 자원/환경 설정에 대한 세부 제어 필요시
• 서버 측 렌더링 (SSR) 필요 시

​

AWS CodePipeline (+ Code Build)

CI/CD 파이프라인 서비스 (코드 → 빌드 → 테스트 → 배포 자동화)

• 소스: CodeCommit, GitHub, Bitbucket, S3
• 빌드: CodeBuild로 산출물 생성
• 배포: S3, CloudFront, ECS, Lambda, Beanstalk 등 다양하게

​

📌 차이점

• Amplify보다 구성 자유도가 높다. (백엔드, 프론트앤드, 멀티 서비스 통합 가능)

• 모든 인프라를 직접 설계해야한다 → HTTPS, 캐시, 환경별 배포 모두 직접

• 서버리스/서버 기반 앱 모두 가능
• Amplify처럼 UI/미리보기, 브랜치 자동 환경 매핑 기능 없음

​

👇 사용사례

• 정적 웹뿐 아니라 API, Lambda, ECS 등 멀티 서비스 통합 배포
• CI/CD 파이프라인 세부 제어 필요
• 사내 규격화된 필드,테스트 절차 적용

​

💡 한 줄 정리

• Amplify Hosting: “정적 웹 + 브랜치 자동 배포 + 최소 오버헤드”면 무조건 이거.
• Elastic Beanstalk: “상시 서버 + 백엔드 앱”이면 이거.
• CodePipeline: “멀티 서비스 + 세밀 제어” 필요하면 이거.