AWS 08 빌드·배포 자동화 — ECR·CodeBuild·CodePipeline·CodeDeploy·CloudFormation·CDK
고친 사람 github-actions[bot]
이 편을 펼친 사람 대부분은 이미 GitHub Actions 로 배포하고 있을 겁니다. 푸시하면 워크플로가 돌고, 테스트를 거쳐 Docker 이미지를 굽고, 서버에 올립니다. 그런데 AWS 에도 소스 저장소(CodeCommit)부터 빌드(CodeBuild), 단계 묶기(CodePipeline), 배포(CodeDeploy)까지 한 벌이 다 있습니다. 이미 잘 도는 것을 두고 이걸 쓸 이유가 있을까요?
결론부터 말하면 한 벌을 통째로 갈아탈 이유는 드뭅니다. 워크플로는 GitHub 에 두더라도 이미지를 둘 곳(ECR), 워크플로에 AWS 권한을 주는 방법(OIDC), 인프라를 적어 둘 방법(CloudFormation·CDK) 은 AWS 쪽에서 고르게 됩니다. 빌드를 AWS 안에서 돌려야 하는 사정이 생기면 CodeBuild 가 GitHub Actions 의 러너(워크플로의 잡을 실제로 실행하는 컴퓨터)가 되어 들어옵니다. 이 편은 도구마다 GitHub 에 둘 것과 AWS 로 가져올 것을 가르고, 끝에서 빌드 한 달 값을 직접 셉니다. 요금은 전부 2026-09-27 서울(ap-northeast-2) 기준입니다.
지도
flowchart TD
PUSH["git push"] --> SRC["소스<br/>GitHub · CodeCommit"]
SRC --> BUILD["빌드<br/>GitHub Actions · CodeBuild"]
BUILD --> IMG["이미지 보관<br/>ECR"]
IMG --> DEP["배포<br/>ECS 자체 · CodeDeploy"]
DEP --> RUN["EC2 · ECS · Lambda"]
PIPE["CodePipeline<br/>단계를 잇는다"] -.-> BUILD
PIPE -.-> DEP
IAC["CloudFormation · CDK<br/>인프라를 코드로"] -.-> RUN
실선은 코드 한 번이 지나가는 길입니다. 소스에서 빌드가 돌고, 빌드가 만든 컨테이너 이미지가 ECR 에 쌓이고, 배포 도구가 그 이미지를 실행 환경에 올립니다. 배포 칸의 「ECS 자체」는 ECS 가 CodeDeploy 없이 스스로 하는 블루/그린 배포입니다(5절). 점선으로 붙은 두 도구는 이 길 옆에서 거듭니다. CodePipeline 은 단계들을 차례로 부르는 지휘자이고, CloudFormation·CDK 는 이미지가 올라갈 서버·로드 밸런서·네트워크 자체를 코드로 만들어 둡니다.
1. ECR — 이미지를 AWS 안에 둔다
ECR(Elastic Container Registry)은 컨테이너 이미지를 저장하는 레지스트리(이미지를 이름과 태그로 올리고 내려받는 저장소)입니다. Docker Hub 와 같은 일을 하되, 접근 권한을 IAM(AWS 의 권한 체계)으로 걸고 ECS·EKS(Elastic Kubernetes Service)·Lambda 가 같은 리전에서 바로 끌어 씁니다. 빌드를 GitHub Actions 에서 하더라도 ECS 로 배포한다면 이미지는 대개 여기 둡니다. ECS 쪽 이야기는 컨테이너 편(01-2)에서 봤습니다.
요금은 저장한 양과 밖으로 나간 양으로 받습니다(Amazon ECR pricing).
ECR 사설 저장소 · 서울 · 2026-09-27
저장 GB-월당 $0.10
같은 리전 전송 무료 (EC2·ECS·Lambda 가 끌어갈 때)
인터넷으로 전송 EC2 와 같은 데이터 전송 요금
무료 한도 사설 저장소 500 MB/월, 가입 뒤 1년
(2025-07 이전 가입 계정의 12개월 혜택)
- 무료 한도의 「가입 뒤 1년」은 옛 계정 기준입니다. 2025년 7월 이후 새 계정은 12개월 무료 대신 크레딧을 받습니다(AWS Free Tier)
- ECR 전송료는 없지만, 사설 서브넷에서 NAT Gateway 를 거쳐 받으면 서울 기준 GB당 $0.059 처리 요금이 붙습니다. NAT 를 거치지 않게 하는 VPC 엔드포인트도 시간 요금이 있습니다(Amazon VPC pricing)
- 공개 저장소는 50 GB 까지 늘 무료입니다. 사내 이미지를 둘 곳은 아니고, 오픈소스 이미지를 배포할 때 씁니다
돈이 새는 곳은 저장입니다. 9절처럼 하루 20번 빌드하면서 빌드마다 300 MB 짜리 이미지를 하나씩 올리면 한 달에 180 GB, 월 $18 이 쌓이고, 지우지 않으면 석 달 뒤엔 540 GB 로 월 $54 가 됩니다. 되돌릴 일이 없는 옛 이미지를 지우는 장치가 수명 주기 정책(lifecycle policy)입니다. 「태그 없는 이미지는 14일 뒤 삭제」「최근 30개만 남기기」처럼 규칙을 적어 두면, 조건을 만족한 이미지를 24시간 안에 지우거나 보관 저장 등급(archival storage class)으로 옮깁니다. 보관 등급은 거의 안 쓰지만 규정상 남겨야 하는 이미지를 두는 곳이고, 다시 쓰려면 복원해야 하는데 20분 안쪽이 걸립니다(Automate the cleanup of images by using lifecycle policies in Amazon ECR · Archiving an image in Amazon ECR).
올린 이미지에 알려진 취약점(CVE, 공개적으로 번호가 붙은 보안 결함)이 있는지 보는 이미지 스캔은 두 가지입니다. 기본 스캔은 OS 패키지만 보고, 푸시할 때나 손으로 돌릴 때 검사하며 추가 요금이 없습니다(New version of Amazon ECR basic scanning). 향상된 스캔은 Amazon Inspector 가 맡아 OS 패키지에 더해 자바·파이썬 같은 언어 패키지까지 보고, 새 취약점이 발표되면 이미 올라간 이미지를 알아서 다시 검사합니다(Scan images for software vulnerabilities in Amazon ECR). 서울에서 처음 검사는 이미지당 $0.11, 다시 검사는 $0.01 이고 Inspector 를 처음 켜면 15일 무료입니다(Amazon Inspector pricing). Inspector 자체는 09편(보안 감시)에서 봅니다.
마지막으로 풀스루 캐시(pull through cache)가 있습니다. Docker Hub·GitHub Container Registry 같은 바깥 레지스트리의 이미지를 ECR 주소로 한 번 받으면 ECR 이 내 사설 저장소에 사본을 만들어 두고, 이후 요청은 사본으로 답합니다. 바깥에 새 판이 있는지는 24시간에 한 번만 확인하므로, 빌드가 node·python 같은 기반 이미지를 수십 번 받아도 바깥 레지스트리에는 요청이 거의 안 갑니다. 바깥 레지스트리가 거는 pull 횟수 제한에 덜 걸리는 이유입니다. Docker Hub 는 로그인 정보를 Secrets Manager 에 넣어 둬야 하고, Lambda 는 풀스루 캐시로 받은 이미지를 못 씁니다(Sync an upstream registry with an Amazon ECR private registry).
ECR 자체는 AWS 에서 컨테이너를 돌리는 한 거의 늘 따라오므로, 실제로 판단할 것은 ECR 을 쓸지와 풀스루 캐시·향상된 스캔을 언제 켤지입니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| ECS·EKS·Lambda 로 이미지를 돌린다 | 이미지를 AWS 밖(다른 클라우드·사내 서버)에서 주로 받는다 | 인터넷으로 나가는 전송에 데이터 전송 요금이 붙는다 |
| 빌드가 기반 이미지를 자주 받아 바깥 한도에 걸린다(풀스루 캐시) | 기반 이미지를 드물게 받아 바깥 한도에 걸릴 일이 없다 | 사본도 저장 요금을 먹고, 첫 pull 에는 인터넷 경로가 있어야 한다 |
| 언어 패키지 취약점까지 계속 감시해야 한다(향상된 스캔) | 스캔은 빌드 단계의 도구로 이미 하고 있다 | Inspector 요금이 이미지 수와 재검사 횟수만큼 붙는다 |
2. 소스와 패키지 — CodeCommit·CodeArtifact
CodeCommit 은 AWS 가 운영하는 사설 Git 저장소입니다. 2024년 7월 신규 가입을 막아 사실상 접는 듯했다가, 2025-11-24 에 사과와 함께 다시 신규 고객을 받는 정식 서비스로 되돌렸습니다. AWS 는 규제 업종이나 개발 인프라를 모두 AWS 안에 두려는 팀을 되돌린 이유로 들었습니다(AWS CodeCommit returns to general availability). 이미 GitHub 에 코드와 리뷰·이슈가 다 있다면 옮길 까닭은 없습니다. 접었다가 되살아난 경위는 15편(AWS 가 접은 서비스들)에서 봅니다.
CodeArtifact 는 Maven·Gradle·npm·pip·NuGet 같은 패키지 관리자가 붙는 사설 패키지 저장소입니다. 사내 라이브러리를 올려 팀끼리 나눠 쓰고, Maven Central·npmjs·PyPI 같은 공개 저장소를 뒤에 연결해 두면 처음 요청된 패키지를 받아 사본으로 쌓습니다(What is AWS CodeArtifact?). 공개 저장소가 멈추거나 패키지가 지워져도 빌드가 안 깨지는 것이 이 사본의 값입니다. 한 가지 걸리는 점은 서울 리전에 없다는 것입니다. 가까운 곳은 도쿄(ap-northeast-1)입니다(AWS CodeArtifact endpoints and quotas).
CodeArtifact · 도쿄 · 2026-09-27
저장 GB-월당 $0.055
요청 1만 건당 $0.065
월 무료 한도 저장 2 GB + 요청 10만 건
+ 리전 밖으로 나가는 데이터 전송 요금
사내 패키지를 나눌 곳이 따로 없다면 맞지만, 서울에서 빌드하면 패키지를 받을 때마다 도쿄를 다녀오고, GitHub 호스팅 러너에서 받을 때도 인터넷을 거쳐 도쿄 엔드포인트에 닿아 위 요금표의 전송 요금이 붙습니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 사내 라이브러리를 여러 팀이 나눠 쓴다 | 이미 GitHub Packages 같은 저장소를 쓰고 있다 | 패키지 관리자마다 인증 토큰을 받아 설정해야 한다 |
| 공개 저장소 장애나 패키지 삭제에도 빌드가 돌아야 한다 | 빌드가 전부 서울에서 돌고 지연에 민감하다 | 리전 간 전송 요금과 왕복 지연을 문다 |
3. CodeBuild — 관리형 빌드 서버
CodeBuild 는 빌드 명령을 돌릴 컴퓨터를 빌드 한 번마다 띄워 주고 끝나면 치우는 서비스입니다. 저장소 최상단에 buildspec.yml 이라는 파일로 설치·테스트·빌드 명령을 적어 두면, CodeBuild 가 그 명령을 컨테이너 안에서 차례로 돌립니다. GitHub Actions 의 GitHub 호스팅 러너와 같은 일을, AWS 계정 안에서 IAM 권한과 VPC(AWS 안에 떼어 낸 내 전용 네트워크) 안쪽 접근을 가진 채로 합니다.
컴퓨팅은 두 방식입니다. EC2 방식은 크기가 정해진 유형 가운데 고르고, 가장 작은 Linux Small·ARM Small 이 vCPU 2개·메모리 4 GiB·디스크 64 GB 입니다. Lambda 방식은 메모리 1~10 GiB 에 디스크 10 GB 로 작지만 시작이 빨라, 가볍고 짧은 빌드에 맞습니다(Build environment compute modes and types).
CodeBuild EC2 온디맨드 · 서울 · 2026-09-27
Linux Small (x86) 분당 $0.005
ARM Small 분당 $0.00385
Linux Medium (x86) 분당 $0.01
월 무료 한도 Linux Small·ARM Small 합쳐 100분
- 빌드 시간은 분 단위로 올림합니다. 4분 10초 빌드는 5분으로 셉니다
- 무료 한도는 가입 12개월이 지나도 없어지지 않고, 기존 고객에게도 적용됩니다
- 빌드 로그를 쌓는 CloudWatch Logs, 산출물을 두는 S3, 암호화 키를 쓰는 KMS(Key Management Service) 요금은 따로 붙습니다(AWS CodeBuild pricing)
GitHub Actions 를 쓰는 사람에게 CodeBuild 가 들어오는 길이 하나 더 있습니다. CodeBuild 호스팅 GitHub Actions 러너입니다. CodeBuild 프로젝트에 GitHub 웹훅을 연결하고 워크플로의 runs-on 을 아래처럼 바꾸면 그 잡이 CodeBuild 에서 돕니다.
jobs:
build:
runs-on:
- codebuild-app-${{ github.run_id }}-${{ github.run_attempt }}
runs-on에 적는 값은 잡을 받을 러너를 고르는 이름표(레이블)입니다.codebuild-뒤에 잡을 받을 CodeBuild 프로젝트 이름(여기서는app)을 붙입니다. 뒤의 두 값은 실행마다 레이블이 겹치지 않게 붙입니다
잡 하나마다 CodeBuild 가 빌드 하나를 띄우고, 잡이 끝나면 러너와 빌드를 곧바로 없앱니다. 워크플로 파일은 GitHub 에 그대로 두고, 실행은 AWS 계정 안에서 합니다. IAM 권한을 그대로 쓰고, VPC 안쪽 DB 에 닿고, Arm·GPU 컴퓨팅도 고를 수 있습니다. 요금은 CodeBuild 빌드 시간으로 나갑니다(AWS CodeBuild now supports managed GitHub Action runners · About the CodeBuild-hosted GitHub Actions runner).
빌드를 AWS 로 옮길 이유는 빌드가 AWS 안쪽의 무엇에 닿아야 하는지, 그리고 어떤 사양이 필요한지 두 가지입니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 테스트가 VPC 안의 DB·사설 API 에 닿아야 한다 | 빌드가 인터넷의 공개 자원만 쓴다(→ GitHub 호스팅 러너로 충분) | VPC 설정과 IAM 역할을 직접 챙긴다 |
| GitHub Actions 워크플로는 두고 실행만 AWS 로 옮기고 싶다(호스팅 러너) | 지금 러너의 사양·네트워크에 불만이 없다 | CodeBuild 프로젝트와 웹훅을 하나 더 관리한다 |
| Arm·GPU·큰 메모리 빌드가 필요하다 | 빌드가 1분 안쪽으로 짧고 잦다 | 분 단위 올림이라 짧은 빌드일수록 올림으로 더 내는 몫이 커진다 |
4. CodePipeline — 단계를 잇는다
CodePipeline 은 「소스 → 빌드 → 승인 → 배포」 같은 흐름을 스테이지(단계)로 나눠 적고, 스테이지마다 액션(CodeBuild 빌드 실행, ECS 배포, 사람의 수동 승인 같은 일 하나)을 넣어 차례로 돌리는 서비스입니다. GitHub Actions 의 워크플로와 겹치는 일을 합니다. 다른 점은 AWS 서비스들을 액션으로 바로 부르고, 여러 계정·리전으로 배포하는 흐름을 한곳에서 본다는 것입니다.
요금 모델이 둘입니다. 처음 나온 V1 은 파이프라인 개수로, 뒤에 나온 V2 는 액션이 돈 시간으로 받습니다(AWS CodePipeline pricing).
CodePipeline · 서울 · 2026-09-27
V1 활성 파이프라인 하나당 월 $1.00
월 1개 무료
V2 액션 실행 분당 $0.002
월 100분 무료 (계정 안 V2 파이프라인 전체 합)
- V1 의 「활성」은 만든 지 30일이 넘었고 그달에 변경이 한 번이라도 지나간 파이프라인입니다
- V2 는 수동 승인과 사용자 정의 액션을 뺀 모든 액션의 실행 시간을 분 단위로 올려 셉니다. CodeBuild 액션이 5분 돌면 CodeBuild 요금과 별도로 파이프라인 5분이 또 나갑니다
- 콘솔은 V2 만 만듭니다. CLI·API·CloudFormation 에서 유형을 비워 두면 V1 이 됩니다(Tutorial: Deploy to Amazon EC2 instances with CodePipeline)
V1 과 V2 중 어느 쪽이 싼지는 파이프라인 수와 도는 횟수에 따라 바뀌고, 9절에서 셉니다. 요금보다 먼저 볼 것은 흐름을 AWS 안에 두어야 하느냐입니다. CodePipeline 이 필요한 것은 배포 흐름이 여러 AWS 계정에 걸치거나 AWS 이벤트로 시작해야 할 때입니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 여러 AWS 계정·리전으로 차례로 배포하고 한 화면에서 본다 | GitHub Actions 워크플로가 이미 빌드부터 배포까지 끝낸다 | 흐름 정의가 GitHub 과 AWS 두 곳으로 갈린다 |
| 소스가 CodeCommit·S3·ECR 이라 AWS 이벤트로 시작해야 한다 | 소스가 GitHub 이고 흐름이 빌드 한 번에 배포 한 번으로 단순하다 | 파이프라인 요금이 빌드 요금 위에 더해진다 |
| 운영 배포 전에 사람 승인을 끼워야 한다 | 배포할 환경이 하나뿐이라 승인 단계가 필요 없다 | V2 는 승인 대기는 안 세지만, 빌드 액션은 CodeBuild 요금과 별도로 또 센다 |
5. CodeDeploy — 끊지 않고 갈아 끼운다
새 판을 올리는 방법은 크게 둘입니다. 돌고 있는 서버에서 옛 판을 멈추고 새 판을 까는 현재 위치 배포(in-place)가 하나이고, 새 판을 옛 판 옆에 따로 띄워 두고 트래픽만 넘기는 블루-그린 배포(blue/green)가 다른 하나입니다. 블루/그린에서 트래픽을 한꺼번에 넘기지 않고 일부(예: 10%)만 먼저 보내 보는 방식이 카나리 배포(canary), 일정 비율씩 나눠 늘리는 방식이 선형 배포(linear)입니다.
CodeDeploy 는 이 두 방식과 블루/그린의 변형 둘을 EC2·온프레미스 서버·Lambda·ECS 에 대신 해 주는 서비스입니다. 무엇을 어떻게 올릴지는 AppSpec 파일(CodeDeploy 전용 배포 명세)에 적습니다(What is CodeDeploy?). 다만 대상마다 쓸 수 있는 방식이 다르고, 카나리·선형은 Lambda·ECS 에서만 됩니다.
| 대상 | 가능한 배포 | 방식 |
|---|---|---|
| EC2 | 현재 위치 배포(서버를 몇 대씩 차례로 바꾸는 롤링 업데이트) · 블루/그린 | 서버마다 CodeDeploy 에이전트가 떠서 새 판을 받아 깐다. 블루/그린은 새 인스턴스를 띄워 로드 밸런서에 붙인다 |
| 온프레미스 서버 | 현재 위치 배포만 | 에이전트 설치. 블루/그린은 EC2 만 된다 |
| Lambda | 블루/그린(카나리·선형·한꺼번에) | 함수의 옛 버전에서 새 버전으로 호출 비율을 옮긴다 |
| ECS | 블루/그린(카나리·선형·한꺼번에) | 새 태스크(ECS 가 띄운 컨테이너 묶음)를 띄우고, 로드 밸런서가 요청을 받는 리스너를 새 쪽으로 옮긴다 |
EC2·Lambda·ECS 로 가는 배포에는 추가 요금이 없고, 요금이 붙는 것은 온프레미스 인스턴스 업데이트 한 번당 $0.02 뿐입니다(AWS CodeDeploy pricing).
ECS 쪽 경계는 2025년에 바뀌었습니다. 2025년 7월 ECS 가 서비스 자체에 블루/그린 배포를 넣었고, 10월에는 ALB 나 Service Connect 를 쓰는 서비스에 카나리·선형까지 더했습니다(Amazon ECS enables built-in blue/green deployments · Amazon ECS built-in linear and canary deployments). 이제 ECS 서비스 설정에 deploymentController 를 ECS, 전략을 BLUE_GREEN 으로 두면 CodeDeploy 없이 UpdateService 호출 하나로 블루/그린이 돕니다(Migrate CodeDeploy blue/green deployments to Amazon ECS blue/green deployments). AWS 도 새 프로젝트 대부분에는 ECS 자체 블루/그린을 권하고, CodeDeploy 는 이미 CodePipeline 흐름에 묶여 있거나 여러 서비스·계정을 한 번에 배포하는 경우에 남긴다고 봅니다(Choosing between Amazon ECS Blue/Green Native or AWS CodeDeploy in AWS CDK).
그래서 CodeDeploy 가 제값을 하는 곳은 EC2·Lambda·사내 서버처럼 컨테이너 밖이고, ECS 에서는 이미 CodePipeline 흐름에 묶였거나 여러 서비스·계정을 한 번에 배포할 때만 남습니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| EC2 에 새 판을 깔고, 여러 대면 몇 대씩 끊김 없이 바꾼다 | 새 판을 ECS 서비스로 돌린다(→ ECS 자체 블루/그린) | 서버마다 에이전트를 깔고 AppSpec 을 따로 관리한다 |
| Lambda 새 버전에 호출을 10%씩 옮기며 지켜본다 | 함수를 한꺼번에 바꿔도 탈이 없다 | 호출이 가리키는 버전 이름표(별칭)를 배포 단위로 관리한다 |
| 사내 서버와 EC2 를 같은 방식으로 배포한다 | 사내 서버에 블루/그린을 하고 싶다 | 온프레미스는 업데이트마다 $0.02, 현재 위치 배포만 된다 |
6. CloudFormation — 인프라를 선언으로 적는다
지금까지는 이미 있는 서버에 코드를 올리는 이야기였습니다. 그 서버와 로드 밸런서·VPC·IAM 역할은 누가 만들까요? 콘솔에서 손으로 만들면 무엇을 어떻게 설정했는지가 사람 기억에만 남습니다. 인프라를 코드 파일로 적어 두고 그 파일로 만들고 고치는 방식을 코드형 인프라(IaC, Infrastructure as Code)라고 하고, CloudFormation 은 AWS 가 직접 운영하는 IaC 서비스입니다.
CloudFormation 에서는 만들 리소스와 설정을 YAML 이나 JSON 으로 적은 템플릿을 올리고, 템플릿 하나로 만들어진 리소스 묶음을 스택(stack)이라는 한 단위로 만들고 고치고 지웁니다. 만들다 실패하면 이미 만든 것을 지우며 되돌립니다. 템플릿을 고쳤을 때 바로 반영하지 않고 변경 세트(change set)를 먼저 뽑으면, 무엇이 바뀌고 무엇이 교체되는지 미리 볼 수 있습니다. RDS 인스턴스 이름을 바꾸면 CloudFormation 은 새 DB 를 만들고 옛 DB 를 지우는데, 변경 세트가 그걸 적용 전에 보여 줍니다. 다만 권한 부족이나 한도 초과까지 잡아 주지는 않아서, 그런 실패는 적용해 봐야 드러납니다(How CloudFormation works).
누군가 콘솔에서 스택의 리소스를 손으로 고치면 템플릿과 실제가 어긋납니다. 이 어긋남을 드리프트(drift)라고 하고, 드리프트 감지를 돌리면 CloudFormation 이 템플릿의 기대값과 실제 설정을 비교해 리소스마다 IN_SYNC·MODIFIED·DELETED 를 매깁니다. 늘 지켜보는 기능이 아니라 부를 때 한 번 도는 검사이고, 템플릿에 명시한 속성만 비교합니다(Detect unmanaged configuration changes to stacks and resources with drift detection).
AWS 리소스(AWS::*)를 다루는 데는 요금이 없고, 만든 리소스 값만 냅니다. 요금은 서드파티가 만든 리소스 유형과 훅(스택 작업 전에 규칙을 검사하는 확장)에만 붙습니다(AWS CloudFormation pricing).
CloudFormation 확장 · 서울 · 2026-09-27
AWS::* 리소스 무료
서드파티 리소스·훅 처리 작업 1건당 $0.0009
월 1,000건 무료
한 건이 30초를 넘으면 초당 $0.00008
CloudFormation 은 AWS 리소스만 다룹니다. DNS·모니터링 같은 AWS 밖 서비스까지 한 도구로 적으려는 팀은 Terraform 을 씁니다. HashiCorp 가 만든 IaC 도구로 AWS 서비스가 아니며, 7절에서 CDK 와 견줍니다.
손으로 만든 인프라가 몇 개 안 되면 과해 보이지만, 같은 환경을 두 번 만들 일이 생기면 값을 합니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 개발·운영처럼 같은 구성을 여러 벌 만든다 | 한 번 만들고 거의 안 바꾸는 리소스 몇 개 | 템플릿 문법과 리소스 속성 이름을 익혀야 한다 |
| 관리할 인프라가 전부 AWS 안이다 | AWS 밖의 DNS·모니터링까지 한 도구로 관리한다(→ Terraform) | AWS 밖 리소스가 생기면 그 몫은 다른 도구로 따로 관리한다 |
| 반복이 적어 YAML 이 짧게 끝난다 | YAML 이 수천 줄로 불어나 반복이 많다(→ CDK) | 반복과 조건을 YAML 로 적으면 금세 읽기 어려워진다 |
7. CDK — 프로그래밍 언어로 쓰고 CloudFormation 으로 내보낸다
CloudFormation 템플릿은 선언이라 반복문도 함수도 없습니다. 서비스 열 개에 거의 같은 설정을 붙이면 YAML 이 열 벌 생깁니다. CDK(Cloud Development Kit)는 이 템플릿을 TypeScript·JavaScript·파이썬·자바·C#/.NET·Go 코드로 쓰게 해 주는 오픈소스 프레임워크입니다. 코드에서 컨스트럭트(construct, 리소스 하나 또는 여러 개를 묶은 재사용 부품)를 조합해 스택을 짜고, cdk synth 로 CloudFormation 템플릿을 합성(synthesize, 코드를 실행해 템플릿을 뽑아내는 일)한 뒤 CloudFormation 으로 배포합니다(What is the AWS CDK?).
높은 수준의 컨스트럭트 하나가 많은 리소스를 대신 적어 줍니다. CDK 안내서의 예제를 보면, 로드 밸런서 뒤의 Fargate 서비스 하나를 선언하는 스무 줄 남짓의 코드가 500줄 넘는 템플릿과 50개 넘는 리소스(VPC·서브넷·NAT Gateway·보안 그룹·IAM 역할·로그 그룹 등)가 됩니다(What is the AWS CDK?). 편한 대신, 무엇이 만들어졌는지 모르는 채 배포하기도 쉽습니다. cdk diff 나 합성된 템플릿을 읽는 습관이 필요한 이유입니다.
CDK 자체에는 요금이 없고 배포는 CloudFormation 이 하므로 요금 구조도 같습니다. 다만 처음 쓰는 계정·리전마다 부트스트랩(cdk bootstrap)을 한 번 해야 합니다. 합성한 템플릿과 Lambda 코드를 둘 S3 버킷, Docker 이미지를 둘 ECR 저장소, 배포용 IAM 역할을 CDKToolkit 스택으로 만들어 두는 일이고, 그 버킷·저장소에 쌓이는 양만큼 저장 요금이 나갑니다(AWS CDK bootstrapping).
CDK 를 고를 때 늘 따라오는 비교 상대가 6절에서 소개한 Terraform 입니다. 둘은 두 군데서 다릅니다. 하나는 범위입니다. CDK 는 AWS 리소스를 CloudFormation 으로 만드는 도구이고, Terraform 은 프로바이더(provider, 클라우드·SaaS 마다의 연결 플러그인)를 갈아 끼워 AWS·다른 클라우드·DNS·모니터링 서비스까지 한 문법으로 다룹니다. 다른 하나는 「지금 무엇이 만들어져 있나」를 기억하는 주체입니다. CDK 는 그 상태를 CloudFormation 스택이 AWS 안에서 들고 있고, Terraform 은 상태 파일을 사용자가 직접 두고 지켜야 합니다. 여럿이 함께 쓰면 그 파일을 S3 같은 곳에 두고 동시에 고치지 못하게 잠그는 장치까지 챙겨야 합니다. 그래서 다룰 인프라가 AWS 뿐이면 CDK 가, AWS 밖까지 한 도구로 다뤄야 하면 Terraform 이 맞습니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 비슷한 구성이 여러 벌이라 반복문·함수로 줄이고 싶다 | AWS 밖의 클라우드·서비스까지 한 도구로 관리한다(→ Terraform) | 배포는 CloudFormation 이 하므로 그 한도와 동작을 그대로 물려받는다 |
| 애플리케이션과 같은 언어로 인프라까지 적고 테스트한다 | 팀이 선언형 템플릿을 읽고 리뷰하는 데 익숙하다(→ CloudFormation) | 높은 수준 컨스트럭트가 무엇을 만드는지 합성 결과로 확인해야 한다 |
| 로드 밸런서·Fargate 같은 흔한 구성을 짧게 시작한다 | 계정·리전마다 부트스트랩을 허용할 수 없다 | 부트스트랩 스택(S3·ECR·IAM 역할)을 계정·리전마다 둔다 |
8. GitHub Actions 에서 AWS 로 — 액세스 키 대신 OIDC
GitHub Actions 로 빌드하고 ECR 에 올리고 ECS 를 갱신하려면 워크플로가 AWS 권한을 가져야 합니다. 예전에는 IAM 사용자의 액세스 키를 GitHub 시크릿에 넣어 두었는데, 이 키는 지울 때까지 유효해서 새면 그대로 계정이 열립니다. 지금은 OpenID Connect(OIDC)로 키 없이 권한을 받습니다. 워크플로가 돌 때마다 GitHub 가 「이 저장소의 이 브랜치에서 도는 잡」이라는 서명된 토큰(JWT)을 발급하고, AWS 가 그 토큰을 확인해 IAM 역할을 맡기고 기한이 정해진 임시 자격 증명을 줍니다. 저장해 둘 키가 없어집니다.
설정은 IAM 에 GitHub 를 OIDC 제공자(token.actions.githubusercontent.com)로 등록하고, 역할의 신뢰 정책에 어느 조직·저장소·브랜치의 토큰만 받을지 token.actions.githubusercontent.com:sub 조건으로 좁히는 것입니다. 이 조건을 비우거나 와일드카드만 두면 남의 저장소 워크플로도 내 역할을 맡을 수 있어서, IAM 은 그런 신뢰 정책을 아예 거부합니다(Create a role for OpenID Connect federation (console)). IAM 역할과 신뢰 정책은 IAM 편(05-1)에서 봤고, GitHub OIDC 에서 ECR·ECS 까지 끝에서 끝까지 따라가는 구성은 조합 편 25(배포 파이프라인)에서 봅니다.
9. 하루 20번 빌드하면 한 달에 얼마인가
한 번에 5분 걸리는 빌드를 하루 20번, 30일 돌린다고 해 봅니다. 파이프라인은 이것 하나뿐이라고 둡니다. 무료 100분은 CodeBuild 두 유형이 함께 쓰는 한도라, 아래는 한 유형만 쓸 때로 셉니다.
하루 20번 × 5분 × 30일 · 서울 · 2026-09-27
빌드 시간 20 × 5 × 30 = 3,000분
과금 대상 3,000 − 100(무료) = 2,900분
CodeBuild
Linux Small 2,900 × $0.005 = $14.50
ARM Small 2,900 × $0.00385 = $11.17
빌드를 4분으로 (2,400 − 100) × $0.005 = $11.50 (Linux Small)
CodePipeline 으로 묶을 때 (소스 액션 1분 + 빌드 액션 5분)
V1 파이프라인 하나, 월 1개 무료 = $0.00
V2 6 × 600 = 3,600분
3,600 − 100(무료) = 3,500분 × $0.002 = $7.00
+ CloudWatch Logs·S3 산출물 요금
- 빌드가 4분 10초여도 5분으로 올려 세므로 결과는 같습니다
- 소스 액션 1분은 가정입니다. 분 단위로 올리므로 짧아도 1분으로 셉니다
x86 에서 Arm 으로 옮기면 월 $3.33, 빌드를 5분에서 4분으로 줄이면 $3.00 이 빠져서 두 절감은 비슷한 크기입니다. 청구서를 더 크게 가르는 것은 CodePipeline 요금 유형입니다. 이 시나리오에서 V1 은 $0, V2 는 $7.00 입니다. V1 은 파이프라인 하나에 월 $1 이고 V2 는 분당 $0.002 이므로, 한 달 액션 시간이 500분($1 ÷ $0.002)을 넘는 파이프라인은 V1 이 쌉니다. 500분에 못 미치는 파이프라인이 여럿이면 V2 가 쌉니다. V1 은 콘솔에서 못 만들므로 CLI·API·CloudFormation 으로 만듭니다. GitHub 호스팅 러너로 같은 빌드를 돌릴 때의 값은 GitHub 쪽 요금표와 견주어 보세요.
이럴 땐 무엇
배포 대상이 EC2 냐 ECS 냐에 따라 가져다 쓸 AWS 도구가 달라지고, 인프라 정의는 AWS 밖까지 다루느냐로 CDK 와 Terraform 중 하나를 고릅니다.
| 상황 | 서비스 | 이유 |
|---|---|---|
| GitHub Actions 로 빌드해 ECS 에 배포한다 | ECR + ECS 자체 블루/그린 + OIDC | 이미지는 같은 리전에서 전송료 없이 끌어가고, 배포 도구를 더 두지 않는다 |
| GitHub Actions 로 빌드해 EC2 에 배포한다 | OIDC 역할 + CodeDeploy | EC2 배포는 추가 요금이 없고, 여러 대면 몇 대씩 나눠 깐다 |
| 테스트가 VPC 안의 DB 에 닿아야 한다 | CodeBuild 호스팅 GitHub Actions 러너 | 워크플로는 그대로 두고 실행만 VPC 안쪽으로 |
| 빌드 기반 이미지를 자주 받아 pull 한도에 걸린다 | ECR 풀스루 캐시 | 바깥 확인은 24시간에 한 번 |
| 빌드를 AWS 안에서 돌리고 싶고 x86 을 고집할 이유가 없다 | CodeBuild ARM Small | 분당 요금이 x86 보다 23% 싸다 |
| 여러 계정·리전에 승인을 끼워 차례로 배포한다 | CodePipeline | 자주 도는 파이프라인 하나면 V1(월 1개 무료), 드물게 도는 것이 여럿이면 V2 |
| EC2 에 몇 대씩, Lambda 에 조금씩 새 판을 늘린다 | CodeDeploy | EC2 는 몇 대씩 현재 위치 배포, Lambda 는 카나리·선형. 둘 다 추가 요금 없음 |
| 같은 AWS 구성을 개발·운영 두 벌로 만든다 | CloudFormation 또는 CDK | 변경 세트로 교체될 리소스를 미리 본다 |
| 반복이 많고 애플리케이션과 같은 언어로 쓰고 싶다 | CDK | 합성 결과는 CloudFormation 템플릿 |
| AWS 밖 DNS·모니터링까지 인프라를 한 도구로 적는다 | Terraform | 프로바이더로 한 문법. 상태 파일은 직접 지킨다 |
| 사내 자바·파이썬 라이브러리를 팀끼리 나눈다 | CodeArtifact(도쿄 등) | 서울에 없다 |
자주 붙는 서비스는 IAM·CloudWatch·S3·Secrets Manager·EventBridge·Inspector 입니다. 엮이는 방식은 조합 편(이 시리즈 20번대)에서 봅니다.
한 장 요약
GitHub Actions 로 배포하더라도 이미지(ECR)·권한(OIDC 역할)·인프라 정의(CloudFormation·CDK)는 AWS 쪽에서 고릅니다. 빌드와 흐름은 GitHub 에 두는 것이 기본이고, CodeBuild·CodePipeline 은 빌드가 VPC 안쪽에 닿거나 배포가 여러 계정에 걸칠 때 들어옵니다. 요금을 가장 크게 가르는 것은 CodePipeline V1·V2 선택입니다.
관련 항목
코드가 지나가는 길의 AWS 도구
Amazon ECR · AWS CodeCommit · AWS CodeBuild · AWS CodePipeline · AWS CodeDeploy · AWS CodeArtifact
인프라를 코드로 적는 도구
AWS CloudFormation · AWS CDK · 코드형 인프라 · Terraform · 변경 세트 · 드리프트 감지 · CDK 부트스트랩
AWS 도구와 겹치거나 맞물리는 바깥 도구
GitHub Actions · GitHub Actions 러너 · Docker Hub · GitHub Packages · Git · Maven · Gradle
새 판을 올리는 배포 방식
블루-그린 배포 · 카나리 배포 · 선형 배포 · 롤링 업데이트 · 현재 위치 배포 · AppSpec
ECR 이 이미지를 다루는 장치
컨테이너 이미지 · 수명 주기 정책 · 풀스루 캐시 · 이미지 스캔 · Amazon Inspector · CVE
워크플로에 AWS 권한을 주는 방식
OpenID Connect · JWT · IAM 역할 · 신뢰 정책 · AWS STS · 액세스 키
배포가 닿는 실행 환경
Amazon ECS · AWS Fargate · AWS Lambda · Amazon EC2 · Amazon EKS · 로드 밸런서