BackEnd 프로그램 개발

AWS Auto Scaling 환경에서 CodeDeploy + Lambda로 Rolling Update 배포 자동화하기

backend 따라쟁이 — Fri, 18 Apr 2025 23:11:15 +0900

✨ 개요

Auto Scaling Group(ASG)은 EC2 인스턴스를 자동으로 확장/축소하고, 장애 복구를 수행할 수 있는 강력한 서비스입니다. 그러나 배포 전략이 명확하지 않으면 새로 생성되는 인스턴스가 구버전 애플리케이션을 포함한 AMI로 생성되는 문제가 발생할 수 있습니다.

이 글에서는 CodeDeploy로 EC2 인스턴스에 애플리케이션을 배포하고, 그 인스턴스를 기반으로 새로운 AMI를 자동 생성, 이를 Launch Template에 반영한 후 Rolling Update로 전체 인스턴스를 교체하는 방식을 실습 가능한 코드와 함께 소개합니다.

Auto Scaling 환경에서 배포 전략이 중요한 이유

1️⃣ 일반적인 배포 시나리오

[1] EC2 인스턴스에 CodeDeploy로 애플리케이션 배포
[2] 배포는 완료되었지만 ASG의 Launch Template은 여전히 구버전 AMI
[3] ASG가 새 인스턴스를 생성하면? → 애플리케이션이 없는 상태

2️⃣ 해결 전략: AMI 기반 배포 + Rolling Update

[1] 배포 완료된 인스턴스에서 AMI 생성
[2] 해당 AMI로 Launch Template 업데이트
[3] ASG에서 Rolling Update 수행 (기존 인스턴스를 새 AMI 기반으로 교체)

Rolling Update란?

기존 Auto Scaling Group을 유지하면서, 새 AMI를 기반으로 기존 인스턴스를 하나씩 교체하는 방식입니다. 무중단 배포에 가까우며, 비용도 효율적으로 관리할 수 있습니다.

실습: CodeDeploy + Lambda로 자동 Rolling Update 구성하기

Auto Scaling Group(ASG) 환경에서 EC2 인스턴스에 CodeDeploy로 Application을 배포한 후, 배포된 인스턴스를 기반으로 AMI를 생성하고, 이 AMI를 ASG의 Launch Template에 반영하여 전체 인스턴스를 Rolling Update로 교체하는 과정을 Lambda 함수 하나로 자동화하는 것을 목표로 합니다.

전체 배포 흐름 요약

[1] CodeDeploy 배포 완료 (Success)
    ↓ (EventBridge)
[2] Lambda 함수 실행
    ├─ 1) 대표 인스턴스에서 AMI 생성
    ├─ 2) Launch Template에 새 버전 생성
    └─ 3) ASG 인스턴스를 Rolling Update로 교체

✅ 사전 준비 사항

항목설명

EC2 인스턴스	ASG에 연결된 상태이며 CodeDeploy Agent 설치됨
CodeDeploy	배포 애플리케이션 및 배포 그룹 구성
S3	appspec.yml 및 배포 스크립트 저장소
ASG	기존 Launch Template 기반으로 EC2 인스턴스 1대 이상 운영 중
IAM	Lambda가 EC2, AutoScaling, CodeDeploy 작업 가능하도록 정책 부여
EventBridge	CodeDeploy 배포 성공 이벤트를 Lambda로 연결

Lambda 함수 전체 코드 (Python, Boto3)

아래 코드는 CodeDeploy 배포 성공 이벤트를 받아 자동으로 AMI 생성 → Launch Template 업데이트 → ASG 롤링 갱신까지 수행합니다.

import boto3
import time

codedeploy = boto3.client('codedeploy')
ec2 = boto3.client('ec2')
autoscaling = boto3.client('autoscaling')

LAUNCH_TEMPLATE_ID = "lt-0example123456"  # 본인의 Template ID로 교체
ASG_NAME = "my-auto-scaling-group"       # 본인의 ASG 이름으로 교체

def create_ami(instance_id):
    timestamp = time.strftime('%Y%m%d-%H%M%S')
    ami_name = f"auto-ami-{timestamp}"
    response = ec2.create_image(
        InstanceId=instance_id,
        Name=ami_name,
        Description="AMI created by Lambda after CodeDeploy success",
        NoReboot=True
    )
    return response['ImageId']

def create_launch_template_version(ami_id):
    response = ec2.create_launch_template_version(
        LaunchTemplateId=LAUNCH_TEMPLATE_ID,
        SourceVersion='$Latest',
        LaunchTemplateData={
            'ImageId': ami_id
        }
    )
    return response['LaunchTemplateVersion']['VersionNumber']

def start_instance_refresh():
    autoscaling.start_instance_refresh(
        AutoScalingGroupName=ASG_NAME,
        Strategy='Rolling',
        Preferences={
            'MinHealthyPercentage': 50,
            'InstanceWarmup': 180
        }
    )

def lambda_handler(event, context):
    print("Event received:", event)
    deployment_id = event["detail"]["deploymentId"]

    # 배포된 인스턴스 목록 조회
    instances = codedeploy.list_deployment_instances(
        deploymentId=deployment_id
    )["instancesList"]

    if not instances:
        raise Exception("No instances found for deployment")

    target_instance_id = instances[0]  # 첫 번째 인스턴스를 대표로 사용
    print(f"Using instance {target_instance_id} for AMI creation")

    ami_id = create_ami(target_instance_id)
    version = create_launch_template_version(ami_id)
    start_instance_refresh()

    return {
        'statusCode': 200,
        'body': f"Created AMI {ami_id}, updated launch template version {version}, and started ASG instance refresh"
    }

EventBridge 구성

이벤트 소스: CodeDeploy
이벤트 패턴:

{
  "source": ["aws.codedeploy"],
  "detail-type": ["CodeDeploy Deployment State-change Notification"],
  "detail": {
    "state": ["SUCCESS"]
  }
}

대상: 위 Lambda 함수 연결

Lambda IAM 권한 예시

{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Action": ["codedeploy:ListDeploymentInstances"], "Resource": "*" },
    { "Effect": "Allow", "Action": ["ec2:CreateImage", "ec2:CreateLaunchTemplateVersion"], "Resource": "*" },
    { "Effect": "Allow", "Action": ["autoscaling:StartInstanceRefresh"], "Resource": "*" }
  ]
}

[참고] CodeDeploy 성공 시 Lambda로 AMI 생성 및 ASG 롤링 업데이트 자동화

https://backend-java.tistory.com/58

CodeDeploy 성공 시 Lambda로 AMI 생성 및 ASG 롤링 업데이트 자동화 – 조건부 트리거 설정까지!

배포가 끝이 아니라 시작입니다. 운영 환경까지 자동으로 정비되는 DevOps 파이프라인을 구축해보세요. 시나리오CI/CD 환경에서 CodeDeploy를 통해 EC2 인스턴스에 애플리케이션을 성공적으로 배포

backend-java.tistory.com

✅ 실습 후 점검사항

항목확인할 내용

AMI 생성 여부	EC2 → AMI 메뉴에서 확인 가능
Launch Template 버전 증가	EC2 → Launch Template에서 새 버전 확인
ASG Instance 교체	EC2 인스턴스가 순차적으로 재기동되는지 확인

결론

이 구성을 통해, 개발자가 직접 서버를 관리하지 않아도 배포 → AMI 생성 → 롤링 업데이트까지 전 과정을 자동화할 수 있습니다. 운영 비용과 실수는 줄이고, 배포 일관성과 안정성은 높일 수 있는 베스트 프랙티스입니다.

추가로 CloudFormation 템플릿이나 Terraform 모듈과 연동해 인프라 전체를 코드로 관리할 수도 있습니다.

[Troubleshooting ] EventBridge 규칙을 통해 Lambda 함수 호출, 함수 실행 권한 및 환경 설정 문제 해결하기

backend 따라쟁이 — Wed, 16 Apr 2025 23:33:48 +0900

♨ EventBridge 규칙에서 Lambda함수 호출에 실패할때 조치 방법

EventBridge 규칙(Rule) 설정 확인:
- 이벤트 패턴(Event Pattern): CodeDeploy 배포 성공 이벤트(CodeDeploy Deployment State Change, detail.state가 SUCCESS인 경우)를 정확히 필터링하도록 이벤트 패턴이 올바르게 정의되었는지 확인합니다. 실제 CodeDeploy 성공 시 발생하는 이벤트 구조와 비교해보세요. AWS 콘솔의 CloudWatch Logs Insights나 EventBridge의 이벤트 버스 모니터링 기능을 통해 실제 전달된 이벤트 내용을 확인하면 패턴 작성에 도움이 됩니다.
- 대상(Target) 설정: 규칙의 대상으로 설정된 Lambda 함수가 올바른지, 그리고 대상 설정이 **활성화(Enabled)**되어 있는지 확인합니다. 실수로 비활성화되어 있을 수 있습니다.
- 규칙 상태(Rule Status): EventBridge 규칙 자체가 활성화(Enabled) 상태인지 확인합니다.
IAM 권한 확인 (가장 흔한 원인 중 하나): ☜ 나는 이게 문제였더라고!
- EventBridge가 Lambda 함수를 호출하려면 적절한 권한이 필요합니다. 일반적으로 EventBridge가 Lambda 함수를 대상으로 지정할 때 AWS 콘솔에서 자동으로 **리소스 기반 정책(Resource-based Policy)**을 Lambda 함수에 추가해줍니다.
- Lambda 함수 권한 확인:
  - AWS Lambda 콘솔에서 해당 함수로 이동합니다.
  - '구성(Configuration)' 탭 아래의 '권한(Permissions)' 섹션으로 이동합니다.
  - '리소스 기반 정책' 섹션을 확인합니다.
  - eventbridge.amazonaws.com 서비스 주체(principal) 또는 해당 EventBridge 규칙의 ARN이 lambda:InvokeFunction 작업을 수행할 수 있도록 허용하는 정책문(statement)이 있는지 확인합니다. 예를 들어 다음과 유사한 정책이 있어야 합니다:
  - JSON
    { "Sid": "AllowEventBridgeInvoke", "Effect": "Allow", "Principal": { "Service": "events.amazonaws.com" }, "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:REGION:ACCOUNT_ID:function:YOUR_FUNCTION_NAME", "Condition": { "ArnLike": { "AWS:SourceArn": "arn:aws:events:REGION:ACCOUNT_ID:rule/YOUR_RULE_NAME" } } }
  - 만약 이 정책이 없거나 잘못 설정되었다면, EventBridge는 Lambda 함수를 호출할 권한이 없어 실패하게 됩니다. EventBridge 규칙의 대상을 제거했다가 다시 추가하면 콘솔이 이 정책 생성을 시도할 수 있습니다. 또는 AWS CLI나 SDK를 사용하여 직접 추가할 수도 있습니다 (aws lambda add-permission 명령어 사용).
Lambda 함수 실행 로그 및 오류 확인:
- EventBridge가 Lambda를 호출했더라도, Lambda 함수 자체에서 초기화 오류나 실행 중 오류가 발생하여 즉시 실패했을 수 있습니다. 이 경우 호출되지 않은 것처럼 보일 수 있습니다.
- CloudWatch Logs 확인:
  - 해당 Lambda 함수와 연결된 CloudWatch Log Group으로 이동합니다.
  - CodeDeploy 성공 이벤트가 발생한 시점 근처에 새로운 로그 스트림이나 로그 항목이 있는지 확인합니다.
  - START, END, REPORT 로그 외에 에러 메시지나 스택 트레이스가 있는지 확인합니다. 특히 함수 핸들러 설정 오류, 코드 내 오류, 타임아웃 등을 확인하세요.
EventBridge 규칙 모니터링 확인:
- CloudWatch Metrics에서 EventBridge 관련 지표를 확인합니다.
- 해당 EventBridge 규칙(Rule)의 이름으로 필터링하여 다음 지표를 확인합니다:
  - TriggeredRules: 규칙의 이벤트 패턴과 일치하는 이벤트가 발생하여 규칙이 트리거되었는지 횟수를 보여줍니다. 이 값이 증가한다면 이벤트 패턴 매칭은 성공한 것입니다.
  - InvocationAttempts: EventBridge가 Lambda 함수 호출을 시도한 횟수입니다.
  - FailedInvocations: Lambda 함수 호출 시도가 실패한 횟수입니다. 이 값이 증가한다면 권한 문제나 Lambda 함수 자체의 문제(예: 함수가 존재하지 않음, 리소스 기반 정책 누락 등)일 가능성이 높습니다.
Lambda 함수 구성 확인:
- Lambda 함수의 핸들러 설정이 올바른지, 런타임은 적절한지 등 기본적인 구성 사항을 다시 한번 확인합니다.
- Lambda 함수의 제한 시간(Timeout) 설정이 너무 짧게 되어 있어 이벤트 처리 중 타임아웃되는 것은 아닌지 확인합니다.

요약 및 추천 접근법:

EventBridge 규칙 설정 (패턴, 대상, 활성화 상태) 재확인.
Lambda 함수 권한 탭에서 리소스 기반 정책 확인 (가장 중요!). eventbridge.amazonaws.com 또는 규칙 ARN에 대한 lambda:InvokeFunction 권한이 있는지 확인합니다.
CloudWatch에서 EventBridge 규칙의 FailedInvocations 지표 확인.
CloudWatch에서 Lambda 함수의 로그 확인. (오류가 있는지, 아예 로그 자체가 없는지)

이 단계들을 차례대로 점검해보시면 문제의 원인을 파악하고 해결하는 데 도움이 될 것입니다. 만약 위의 방법으로도 해결되지 않는다면, 사용하신 이벤트 패턴이나 Lambda 리소스 기반 정책의 구체적인 내용을 공유해주시면 좀 더 자세히 살펴볼 수 있습니다.

♨ Lambda 함수가 호출되었는데, Lambda 함수 실행 중 타임아웃이 발생할 경우 조치 방법

Lambda 함수 실행 중 타임아웃은 codedeploy.list_deployment_instances API 호출 부분에서도 충분히 발생할 수 있습니다. 특히 "Target instance IDs:", instance_ids 로그가 출력되기 전에 타임아웃이 발생했다면, 해당 API 호출 또는 관련 로직(페이지네이션 루프 포함) 수행 중에 설정된 제한 시간을 초과했을 가능성이 매우 높습니다.

타임아웃이 발생하는 주요 원인들은 다음과 같습니다.

네트워크 연결 문제 (가장 흔한 원인 중 하나): ☜ 나는 이게 문제였더라고!
- Lambda 함수가 VPC 내부에 있는 경우:
  - Private Subnet: Lambda 함수가 인터넷 아웃바운드 액세스가 없는 Private Subnet에 있고, NAT Gateway나 CodeDeploy용 VPC 엔드포인트(Interface Endpoint)가 설정되어 있지 않으면 AWS API(CodeDeploy 엔드포인트)에 연결할 수 없습니다. 이 경우 boto3 클라이언트는 응답을 기다리다가 결국 Lambda 함수의 타임아웃 시간에 도달하게 됩니다.
  - Security Group / NACL: Lambda 함수에 연결된 보안 그룹의 아웃바운드 규칙이나 서브넷의 네트워크 ACL이 HTTPS (포트 443) 트래픽을 차단하고 있을 수 있습니다. CodeDeploy API 엔드포인트로의 통신이 막히면 타임아웃이 발생합니다.
  - VPC 엔드포인트 설정 오류: CodeDeploy용 VPC 엔드포인트를 사용 중이라면, 라우팅, 보안 그룹, 엔드포인트 정책 등이 올바르게 설정되었는지 확인해야 합니다.
- 해결 방안:
  - Lambda 함수가 VPC 내에 있다면, 네트워크 구성을 점검하세요 (NAT Gateway, Internet Gateway, 라우팅 테이블, 보안 그룹, NACL).
  - CodeDeploy용 VPC 엔드포인트 설정을 확인하거나, 없다면 생성을 고려해 보세요. (VPC 엔드포인트 사용 시 NAT Gateway 불필요)
  - 보안 그룹 아웃바운드 규칙에서 포트 443이 열려 있는지 확인하세요.
매우 많은 수의 인스턴스 및 페이지네이션:
- CodeDeploy 배포 대상 인스턴스가 수백, 수천 대로 매우 많을 경우, list_deployment_instances API는 여러 페이지의 결과를 반환합니다. 코드의 while 루프는 모든 페이지를 다 가져올 때까지 반복해서 API를 호출합니다.
- 각 API 호출마다 약간의 시간이 소요되는데, 페이지 수가 너무 많으면 이 시간들이 누적되어 Lambda 함수의 전체 타임아웃 시간을 초과할 수 있습니다. 특히 Lambda 함수의 타임아웃 설정이 짧을 경우(예: 기본값 3초 또는 수십 초) 발생 가능성이 높습니다.
- 해결 방안:
  - Lambda 함수의 타임아웃 설정을 늘려보세요. (예: 1분, 5분 등). 임시로 늘려서 코드가 완료되는지 확인하면, 단순히 시간이 부족했던 것인지 다른 문제인지 판단하는 데 도움이 됩니다.
  - 정말로 많은 인스턴스를 처리해야 하고 시간이 오래 걸린다면, Step Functions 등을 사용하여 작업을 분할하거나 다른 아키텍처를 고려해야 할 수도 있습니다.
CodeDeploy API 응답 지연 또는 일시적 문제:
- 드물지만 AWS CodeDeploy 서비스 자체의 일시적인 성능 저하나 문제로 인해 API 응답이 느려져 타임아웃이 발생할 수도 있습니다.

문제 해결 방법 상세(Lambda 함수가 VPC 내부에 있는 경우):

Lambda 함수가 VPC 내부에 있을 때 타임아웃이 발생한다면 네트워크 연결 문제일 가능성이 높습니다. 다음 단계를 순서대로 점검해 보세요.

1단계: Lambda 함수 VPC 구성 확인

어떤 VPC, 서브넷, 보안 그룹에 연결되어 있는지 확인합니다.
작업: AWS Lambda 콘솔 > 해당 함수 선택 > '구성(Configuration)' 탭 > 'VPC' 메뉴로 이동합니다.
여기에 명시된 **VPC ID, 서브넷 ID(들), 보안 그룹 ID(들)**을 메모해 둡니다.

2단계: 서브넷 유형 확인 (Public vs Private)

Lambda 함수가 연결된 서브넷들이 인터넷에 직접 연결될 수 있는 Public Subnet인지, 아니면 인터넷 연결을 위해 다른 경로(NAT 게이트웨이 등)가 필요한 Private Subnet인지 확인합니다.
작업:
- AWS VPC 콘솔 > '서브넷(Subnets)' 메뉴로 이동합니다.
- 1단계에서 확인한 서브넷 ID 각각을 선택합니다.
- '라우팅 테이블(Route table)' 탭을 확인하여 연결된 라우팅 테이블 ID를 확인합니다.

3단계: 라우팅 테이블 확인

Lambda 함수 서브넷에 연결된 라우팅 테이블이 인터넷 또는 CodeDeploy 서비스 엔드포인트로 트래픽을 보낼 경로를 가지고 있는지 확인합니다.
작업:
- AWS VPC 콘솔 > '라우팅 테이블(Route tables)' 메뉴로 이동합니다.
- 2단계에서 확인한 라우팅 테이블 ID를 선택합니다.
- '라우팅(Routes)' 탭 내용을 확인합니다.
- 시나리오 A: NAT 게이트웨이 사용 예상 시 (가장 일반적) ☜ 난 이방법을 사용함.
  - 대상(Destination) 0.0.0.0/0 (모든 IPv4 트래픽)에 대한 경로가 있습니까?
  - 해당 경로의 대상(Target)이 **NAT 게이트웨이 ID (nat-xxxxxxxx)**로 지정되어 있습니까?
  - 만약 그렇다면: 4단계 (NAT 게이트웨이 확인)로 진행합니다.
  - 만약 경로가 없거나 대상이 잘못되었다면: 이것이 문제의 원인일 가능성이 높습니다. Private Subnet에서 외부 API를 호출하려면 0.0.0.0/0 트래픽을 NAT 게이트웨이로 보내는 경로가 필요합니다.
- 시나리오 B: VPC 엔드포인트 사용 예상 시
  - CodeDeploy 서비스용 VPC 인터페이스 엔드포인트(com.amazonaws.<region>.codedeploy)를 사용하도록 의도했습니까?
  - 이 경우 0.0.0.0/0 경로는 필요 없거나 다른 용도로 사용될 수 있습니다. CodeDeploy로 가는 트래픽은 엔드포인트를 통해 라우팅됩니다.
  - 만약 그렇다면: 5단계 (VPC 엔드포인트 확인)로 진행합니다.
- 시나리오 C: 퍼블릭 서브넷 사용 시 (Lambda에는 일반적이지 않음)
  - 대상 0.0.0.0/0의 대상(Target)이 **인터넷 게이트웨이 ID (igw-xxxxxxxx)**로 지정되어 있습니까?
  - 만약 그렇다면: 해당 서브넷은 퍼블릭 서브넷입니다. 이 경우 Lambda 함수 자체에 퍼블릭 IP가 할당되어야 외부 통신이 가능합니다 (기본 설정 아님). 일반적으로 Lambda는 Private Subnet + NAT/엔드포인트 조합을 사용합니다. 이 구성이 의도된 것이 아니라면 Private Subnet으로 변경하는 것을 고려하세요. 의도된 것이라면 6단계 (보안 그룹 확인)로 진행합니다.

4단계: NAT 게이트웨이 상태 및 구성 확인 (3단계 A 시나리오 해당 시) ☜ 상세한 해결방법 (주의 : NAT게이트웨이는 퍼블릿 서브넷, lambda 함수는 프라이빗 서브넷에 있어야함. 프라이빗 서브넷에서의 라우트에는 NAT 게이트웨이가 설정되어 있어야 하며, 퍼블릿 서브넷의 라우트에선 인터넷 게이트웨이가 설정되어 있어야 함.)

라우팅 테이블에서 확인한 NAT 게이트웨이가 정상적으로 작동하는지 확인합니다.
작업:
- AWS VPC 콘솔 > 'NAT 게이트웨이(NAT Gateways)' 메뉴로 이동합니다.
- 라우팅 테이블에 있던 nat-xxxxxxxx ID를 찾습니다.
- **상태(Status)**가 'available'인지 확인합니다.
- NAT 게이트웨이에 탄력적 IP(Elastic IP) 주소가 할당되어 있는지 확인합니다.
- NAT 게이트웨이가 위치한 서브넷을 확인합니다. 이 서브넷은 퍼블릭 서브넷이어야 합니다 (즉, 이 서브넷의 라우팅 테이블에는 0.0.0.0/0 -> igw-xxxxxxxx 경로가 있어야 함). 해당 서브넷의 라우팅 테이블도 확인합니다.

5단계: VPC 엔드포인트 상태 및 구성 확인 (3단계 B 시나리오 해당 시)

CodeDeploy용 VPC 인터페이스 엔드포인트가 올바르게 설정되었는지 확인합니다.
작업:
- AWS VPC 콘솔 > '엔드포인트(Endpoints)' 메뉴로 이동합니다.
- 서비스 이름이 com.amazonaws.<region>.codedeploy 인 인터페이스(Interface) 유형의 엔드포인트를 찾습니다.
- **상태(Status)**가 'available'인지 확인합니다.
- 엔드포인트가 1단계에서 확인한 올바른 VPC에 연결되어 있는지 확인합니다.
- '서브넷(Subnets)' 탭에서 Lambda 함수가 사용하는 서브넷 (또는 해당 가용 영역의 다른 서브넷)이 연결되어 있는지 확인합니다.
- '보안 그룹(Security groups)' 탭에서 연결된 보안 그룹이 Lambda 함수의 보안 그룹으로부터 HTTPS (포트 443) 인바운드 트래픽을 허용하는지 확인합니다.
- 엔드포인트 정책(Policy)이 설정되어 있다면, Lambda 함수의 실행 역할(IAM Role)이 codedeploy:ListDeploymentInstances 작업을 수행하도록 허용하는지 확인합니다. (기본값은 전체 허용)
- VPC 설정에서 'DNS 호스트 이름 활성화' 및 'DNS 확인 활성화'가 모두 활성화되어 있는지 확인합니다.

6단계: Lambda 함수 보안 그룹의 아웃바운드 규칙 확인

Lambda 함수 자체에 연결된 보안 그룹이 외부로 나가는 트래픽을 허용하는지 확인합니다.
작업:
- AWS EC2 콘솔 > '보안 그룹(Security Groups)' 메뉴로 이동합니다.
- 1단계에서 확인한 Lambda 함수에 연결된 보안 그룹 ID를 찾습니다.
- '아웃바운드 규칙(Outbound rules)' 탭을 확인합니다.
- HTTPS (포트 443) 트래픽을 대상 0.0.0.0/0 (NAT/IGW 사용 시) 또는 VPC 엔드포인트가 사용하는 IP 대역/보안 그룹 (VPC 엔드포인트 사용 시)으로 허용하는 규칙이 있는지 확인합니다. 가장 흔한 실수는 이 아웃바운드 규칙이 없거나 너무 제한적인 경우입니다.

7단계: 네트워크 ACL(NACL) 규칙 확인

서브넷 수준의 방화벽인 NACL이 트래픽을 차단하고 있지 않은지 확인합니다. NACL은 상태 비저장(Stateless)이므로 인바운드와 아웃바운드 규칙을 모두 확인해야 합니다.
작업:
- AWS VPC 콘솔 > '네트워크 ACLs(Network ACLs)' 메뉴로 이동합니다.
- Lambda 함수가 있는 서브넷과 (NAT 게이트웨이를 사용한다면) NAT 게이트웨이가 있는 서브넷에 연결된 NACL을 확인합니다.
- Lambda 서브넷 NACL:
  - 아웃바운드 규칙: 대상 0.0.0.0/0 (또는 CodeDeploy 엔드포인트 IP 대역), 포트 443 (HTTPS)으로 나가는 TCP 트래픽을 허용하는 규칙이 있는지 확인합니다.
  - 인바운드 규칙: 소스 0.0.0.0/0 (또는 CodeDeploy 엔드포인트 IP 대역), 포트 범위 1024-65535 (Ephemeral ports)로 들어오는 TCP 트래픽을 허용하는 규칙이 있는지 확인합니다. (API 응답 트래픽)
- NAT 게이트웨이 서브넷 NACL (NAT 사용 시): 유사하게 인바운드/아웃바운드 규칙을 확인합니다. (인터넷에서 오는 응답과 인터넷으로 나가는 요청)
- 참고: 기본 NACL은 모든 트래픽을 허용합니다. 사용자 정의 NACL이 적용되어 있다면 규칙 번호 순서대로 평가되므로 주의 깊게 확인해야 합니다.

8단계: (선택) EC2 인스턴스로 연결 테스트

문제 진단을 돕기 위해, Lambda 함수와 동일한 VPC 서브넷 및 동일한 보안 그룹을 사용하는 EC2 인스턴스를 임시로 생성합니다.
해당 인스턴스에 SSH로 접속하여 CodeDeploy 엔드포인트로 직접 연결 테스트를 수행합니다.

Bash

# 예시: 서울 리전
curl -v https://codedeploy.ap-northeast-2.amazonaws.com

여기서 연결이 성공하면 Lambda 환경 자체의 문제일 수 있고, 여기서도 실패하면 VPC 네트워크 경로 문제일 가능성이 높습니다.

이 단계들을 순서대로 차근차근 점검해 보시면 VPC 내부 Lambda 함수의 네트워크 연결 문제를 진단하고 해결하는 데 도움이 될 것입니다. 가장 먼저 Lambda 타임아웃 설정 증가와 보안 그룹 아웃바운드 규칙을 확인하는 것이 효과적인 경우가 많습니다.

♨ Lambda 함수가 호출되었는데, AccessDeniedException 오류가 발생할 경우 조치 방법

AccessDeniedException 오류는 Lambda 함수가 codedeploy:ListDeploymentInstances 권한이 없어서 발생한 것입니다. 이 오류를 해결하기 위해 아래 순서대로 조치하면 됩니다.

✅ 1단계: 오류 원인 파악

오류 메시지에 따르면, Lambda 함수가 사용하는 역할(myFunc-asg-update-role-n3ys1udk)에 codedeploy:ListDeploymentInstances 권한이 없습니다.

User: arn:aws:sts::...:assumed-role/myFunc-asg-update-role-n3ys1udk/myLambda-codedeploy is not authorized to perform: codedeploy:ListDeploymentInstances

✅ 2단계: Lambda 함수의 실행 역할(Role) 확인

AWS Lambda 콘솔 접속
문제 발생한 Lambda 함수 선택 (myLambda-codedeploy)
[구성] 탭 > 권한 > 실행 역할 클릭
- 여기서 확인되는 IAM Role이 myFunc-asg-update-role-n3ys1udk인지 다시 한번 확인

✅ 3단계: 해당 IAM Role에 권한 추가

이제 해당 Role에 필요한 CodeDeploy 권한을 추가해야 합니다.

IAM 콘솔 접속
역할(Roles)에서 myFunc-asg-update-role-n3ys1udk 검색하여 클릭
[권한] 탭에서 정책 추가 버튼 클릭
인라인 정책 추가 또는 기존 정책 편집

정책(JSON) 예시:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "codedeploy:ListDeploymentInstances",
                "codedeploy:GetDeploymentInstance",
                "codedeploy:GetDeployment",
                "codedeploy:GetDeploymentGroup"
            ],
            "Resource": [
                "arn:aws:codedeploy:ap-northeast-2:148761669753:deploymentgroup:SpringBootApp-1/app-deploy-1",
                "arn:aws:codedeploy:ap-northeast-2:148761669753:deployment:SpringBootApp-1/*"
            ]
        }
    ]
}

✅ 필요 시 "Resource": "*"로 설정해 우선 테스트해보고, 이후 최소 권한 원칙에 따라 리소스를 좁히는 것이 좋습니다.

✅ 4단계: 정책 저장 및 적용 확인

정책 저장 후, Lambda 함수에서 다시 테스트 이벤트 실행
동일한 AccessDeniedException이 발생하지 않으면 권한 적용 완료

✅ 5단계 (선택): CloudTrail로 추가 분석

혹시 다른 권한도 누락됐을 수 있으므로, CloudTrail에서 Lambda 호출 이력을 확인해 어떤 API 호출에 실패했는지 추가로 점검할 수 있습니다.

필요하시면 IAM 정책 생성 화면에서 어떤 버튼을 눌러야 하는지도 스크린샷 기반으로 도와드릴 수 있어요. JSON 정책 붙여넣기 창이 잘 안 보이는 경우 알려주세요!

CodeDeploy 성공 시 Lambda로 AMI 생성 및 ASG 롤링 업데이트 자동화 – 조건부 트리거 설정까지!

backend 따라쟁이 — Thu, 27 Mar 2025 23:18:49 +0900

배포가 끝이 아니라 시작입니다. 운영 환경까지 자동으로 정비되는 DevOps 파이프라인을 구축해보세요.

시나리오

CI/CD 환경에서 CodeDeploy를 통해 EC2 인스턴스에 애플리케이션을 성공적으로 배포한 후, 다음을 자동으로 처리하고 싶습니다.

배포된 인스턴스를 기준으로 최신 AMI 생성
Launch Template의 새로운 버전 생성 및 적용
ASG에서 새 AMI를 기반으로 인스턴스 순차 교체(Rolling Update)

하지만 조건이 있습니다.

여러 CodeDeploy 프로젝트 중에서도 특정 애플리케이션과 배포 그룹에서만 이 Lambda가 실행되길 원합니다.

✅ 전체 아키텍처

[CodeDeploy]
    │
    ▼ (성공 시 이벤트)
[EventBridge (조건 필터링)]
    │
    ▼
[Lambda]
 ├─ AMI 생성
 ├─ Launch Template 새 버전 생성
 └─ Auto Scaling Group Rolling Update

Lambda 함수 생성 및 설정 (콘솔 기준)

Lambda 서비스 → 함수 생성
- 이름: CreateAmiAndUpdateAsg
- 런타임: Python 3.9
- 역할: 기존 역할 사용 또는 새 역할 생성
환경 변수 설정
- LAUNCH_TEMPLATE_NAME: 예) my-launch-template
- ASG_NAME: 예) my-asg-group
코드 등록 및 배포
- Lambda 콘솔 내 편집기에서 전체 코드 복사하여 붙여넣고 배포
IAM 정책 추가
- Lambda 실행 역할에 아래 권한을 포함해야 합니다:

[ 권한1 : CodeDeploy 정보 획득 관련 권한 ]

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "codedeploy:ListDeploymentInstances",
                "codedeploy:GetDeploymentInstance",
                "codedeploy:GetDeployment",
                "codedeploy:GetDeploymentGroup"
            ],
            "Resource": [
                "arn:aws:codedeploy:{리전}:{게정ID}:deploymentgroup:{애플리케이션}/{배포그룹}",
                "arn:aws:codedeploy:{리전}:{게정ID}:deployment:{애플리케이션}/*"
            ]
        }
    ]
}

[ 권한2 : AMI 생성과 ASG launch Template 업데이트 권한 ]

{
  "Action": [
    "ec2:CreateImage",
    "ec2:Describe*",
    "ec2:CreateLaunchTemplateVersion",
    "autoscaling:UpdateAutoScalingGroup",
    "autoscaling:StartInstanceRefresh"
  ],
  "Effect": "Allow",
  "Resource": "*"
}

(그림1) Lambda 함수의 권한에서 역할 이름 클릭

(그림2) 역할에 할당된 권한 정책 클릭

(그림3) 정책 편집기를 통해 IAM관련 정책 추가

Lambda 전체 코드

import boto3
import datetime

codedeploy = boto3.client('codedeploy')
ec2 = boto3.client('ec2')
autoscaling = boto3.client('autoscaling')

def lambda_handler(event, context):
    print("Received event:", event)

    deployment_id = event['detail']['deploymentId']
    application_name = event['detail']['application']
    deployment_group = event['detail']['deploymentGroup']
    deployment_state = event['detail']['state']

    if deployment_state != "SUCCESS":
        print("Deployment not successful. Exiting.")
        return

    # 1️⃣ 배포에 포함된 인스턴스 ID 목록 조회
    instance_ids = []
    next_token = ''
    while True:
        if next_token:
            response = codedeploy.list_deployment_instances(
                deploymentId=deployment_id,
                nextToken=next_token
            )
        else:
            response = codedeploy.list_deployment_instances(
                deploymentId=deployment_id
            )
        instance_ids.extend(response['instancesList'])
        next_token = response.get('nextToken')
        if not next_token:
            break

    print("Target instance IDs:", instance_ids)

    if not instance_ids:
        print("No instances found in this deployment.")
        return

    # 2️⃣ 첫 번째 인스턴스 기준으로 AMI 생성 (원하면 loop로 전부 생성 가능)
    target_instance_id = instance_ids[0]
    timestamp = datetime.datetime.utcnow().strftime('%Y%m%d%H%M%S')
    ami_name = f"AppImage-{timestamp}"

    ami_response = ec2.create_image(
        InstanceId=target_instance_id,
        Name=ami_name,
        NoReboot=True
    )
    new_ami_id = ami_response['ImageId']
    print(f"New AMI created: {new_ami_id}")

    # 3️⃣ 기존 Launch Template 가져오기
    lt_response = ec2.describe_launch_templates(
        Filters=[
            {'Name': 'tag:Application', 'Values': [application_name]}
        ]
    )

    if not lt_response['LaunchTemplates']:
        print("No Launch Template found for application.")
        return

    launch_template = lt_response['LaunchTemplates'][0]
    launch_template_id = launch_template['LaunchTemplateId']

    # 4️⃣ Launch Template 버전 생성
    version_response = ec2.create_launch_template_version(
        LaunchTemplateId=launch_template_id,
        SourceVersion='$Latest',
        LaunchTemplateData={
            'ImageId': new_ami_id
        }
    )
    new_version = version_response['LaunchTemplateVersion']['VersionNumber']
    print(f"New Launch Template version created: {new_version}")

    # 5️⃣ ASG 업데이트
    asg_response = autoscaling.describe_auto_scaling_groups()
    for asg in asg_response['AutoScalingGroups']:
        if asg.get('LaunchTemplate', {}).get('LaunchTemplateId') == launch_template_id:
            asg_name = asg['AutoScalingGroupName']
            autoscaling.update_auto_scaling_group(
                AutoScalingGroupName=asg_name,
                LaunchTemplate={
                    'LaunchTemplateId': launch_template_id,
                    'Version': str(new_version)
                }
            )
            print(f"ASG '{asg_name}' updated with new LT version.")

    print("Lambda execution completed.")

EventBridge 규칙 생성 – 특정 CodeDeploy만 트리거

Lambda 콘솔에서는 이벤트 패턴을 직접 입력할 수 없기 때문에, EventBridge 콘솔에서 직접 규칙을 생성합니다.

EventBridge → 규칙 생성
이름: codedeploy-success-filtered
이벤트 패턴 입력 (JSON):

{
  "source": ["aws.codedeploy"],
  "detail-type": ["CodeDeploy Deployment State-change Notification"],
  "detail": {
    "state": ["SUCCESS"],
    "application": ["my-codedeploy-app"],
    "deploymentGroupName": ["backend-production"]
  }
}

(그림) EventBridge에서 규칙 만들기 예시

(그림2) Lambada함수에 구성탭에서 앞에서 만든 규칙을 "트리거 추가"를 통해 추가한 예시

대상: Lambda 함수 → CreateAmiAndUpdateAsg 선택

✅ 이렇게 하면 특정 배포 성공 시에만 Lambda가 실행됩니다!

비용은 언제 발생할까?

이벤트 대기 중 상태는 과금되지 않습니다.
실제로 Lambda 함수가 호출되어 실행될 때만 요금이 발생합니다.
EventBridge는 월 10만 건 무료, Lambda는 월 100만 건 무료 호출까지 제공되어 테스트 단계에서는 거의 무료로 이용 가능!

✅ 마무리

이 구조를 통해 우리는 다음을 달성했습니다:

배포 성공 이후 운영환경을 최신 상태로 자동 유지
AMI/Launch Template/ASG 연동을 통한 무중단 롤링 업데이트
여러 배포 중 특정 배포만 선별하여 트리거
과금 걱정 없는 서버리스 자동화 구성

[참고] 환경설정 중 오류에 대한 해결 방안

[Troubleshooting ] EventBridge 규칙을 통해 Lambda 함수 호출, 함수 실행 권한 및 환경 설정 문제 해결하기https://backend-java.tistory.com/59

[Troubleshooting ] EventBridge 규칙을 통해 Lambda 함수 호출, 함수 실행 권한 및 환경 설정 문제 해결하기

♨ EventBridge 규칙에서 Lambda함수 호출에 실패할때 조치 방법EventBridge 규칙(Rule) 설정 확인:이벤트 패턴(Event Pattern): CodeDeploy 배포 성공 이벤트(CodeDeploy Deployment State Change, detail.state가 SUCCESS인 경우)

backend-java.tistory.com

(AWS CodeDeploy) NAT를 사용하여 퍼블릭 IP 없는 프라이빗 서브넷의 EC2 인스턴스에서 CodeDeploy 환경 구성하기

backend 따라쟁이 — Mon, 17 Mar 2025 23:28:56 +0900

AWS 환경에서 보안 강화를 위해 EC2 인스턴스를 프라이빗 서브넷에 배치하는 경우가 많습니다. 하지만 이 경우, 해당 인스턴스는 인터넷과 직접 통신할 수 없으므로 CodeDeploy와 같은 AWS 서비스와 연동하려면 별도의 설정이 필요합니다. 본 블로그에서는 NAT 게이트웨이를 사용하여 퍼블릭 IP 없는 프라이빗 서브넷의 EC2 인스턴스에서 AWS CodeDeploy 환경을 구성하는 방법을 단계별로 설명합니다.

1. 아키텍처 개요

본 가이드에서는 다음과 같은 구성으로 환경을 설정합니다:

퍼블릭 서브넷: 인터넷 게이트웨이(IGW)와 연결된 NAT 게이트웨이가 위치함.
프라이빗 서브넷: 퍼블릭 IP 없이 배포된 EC2 인스턴스가 위치함.
NAT 게이트웨이: 프라이빗 서브넷의 EC2가 인터넷과 통신할 수 있도록 지원함.
IAM 역할: EC2 인스턴스가 S3 및 CodeDeploy와 통신할 수 있도록 필요한 권한을 부여함.
AWS CodeDeploy: 애플리케이션을 자동 배포하는 서비스.

(참고) AWS CodeDeploy 사용법은 링크된 블로그를 참고하세요(https://backend-java.tistory.com/49)

8.9.가. AWS CodeDeploy를 이용한 EC2 인스턴스 배포 구성 및 실행 방법

1. 개요AWS CodeDeploy는 EC2 인스턴스, 온프레미스 서버, Lambda 및 ECS 등의 환경에서 애플리케이션을 자동으로 배포할 수 있는 서비스입니다. 이 글에서는 CodeDeploy를 활용하여 EC2 인스턴스에 애플리케

backend-java.tistory.com

2. VPC 및 서브넷 구성

1) VPC 생성

먼저, VPC를 생성합니다.

AWS 콘솔에서 VPC 서비스로 이동합니다.
새 VPC를 생성하고 CIDR 블록을 10.0.0.0/16으로 설정합니다.

2) 퍼블릭 서브넷 생성

퍼블릭 서브넷을 생성합니다. (예: 10.0.1.0/24)
**인터넷 게이트웨이(IGW)**를 생성하고 VPC에 연결합니다.
퍼블릭 서브넷의 라우팅 테이블을 수정하여 0.0.0.0/0 트래픽을 IGW로 향하게 설정합니다.

3) 프라이빗 서브넷 생성

프라이빗 서브넷을 생성합니다. (예: 10.0.2.0/24)
라우팅 테이블을 기본값으로 유지합니다.

3. NAT 게이트웨이 설정

1) 퍼블릭 서브넷에 NAT 게이트웨이 생성

AWS 콘솔 → VPC → NAT 게이트웨이로 이동합니다.
퍼블릭 서브넷을 선택하고 **Elastic IP(EIP)**를 할당하여 NAT 게이트웨이를 생성합니다.

(그림) NAT 게이트웨이 생성

2) 프라이빗 서브넷의 라우팅 테이블 수정

라우팅 테이블에서 프라이빗 서브넷에 대한 테이블을 선택합니다.
새 라우트 추가:
- 대상: 0.0.0.0/0
- 대상 게이트웨이: NAT 게이트웨이

(그림) 새 라우트에 NAT게이트웨이 추가

(그림) 프라이빗 라우팅 테이블에 NAT게이트웨이가 추가된 모습

4. IAM 역할 추가 및 EC2 설정

1) IAM 역할 생성

EC2 인스턴스가 CodeDeploy 및 S3와 통신하려면 IAM 역할이 필요합니다.

AWS 콘솔 → IAM → 역할(Role) 생성
EC2 서비스 선택
다음 정책 추가
- AWSCodeDeployFullAccess
- AmazonS3ReadOnlyAccess
- CloudWatchLogsFullAccess (로그 저장용)
역할을 생성한 후, EC2 인스턴스에 할당합니다.

(그림) EC2 인스텐스에 IAM 역할 할당된 모습

2) EC2 인스턴스 생성 및 CodeDeploy 에이전트 설치

EC2 인스턴스를 프라이빗 서브넷에 배치
SSH 또는 SSM 세션을 통해 접속 후 CodeDeploy 에이전트 설치:

sudo apt update -y
sudo apt install ruby wget -y
cd /home/ubuntu
wget https://aws-codedeploy-[region].s3.amazonaws.com/latest/install
chmod +x ./install
sudo ./install auto
sudo systemctl enable codedeploy-agent
sudo systemctl start codedeploy-agent

설치 완료 후 상태 확인:

sudo systemctl status codedeploy-agent

(그림) sudo systemctl status codedeploy-agent 실행, Agent 기동 상태 확인

5. CodeDeploy 배포 구성

1) CodeDeploy 애플리케이션 생성

AWS 콘솔 → CodeDeploy → 애플리케이션 생성
배포 유형: EC2/온프레미스
배포 그룹 생성:
- EC2 태그 기반으로 프라이빗 서브넷의 인스턴스 선택
- IAM 역할 연결

2) S3에 애플리케이션 업로드 및 배포 실행

로컬에서 애플리케이션 패키징:

zip -r app.zip .

S3 버킷에 업로드:

aws s3 cp app.zip s3://your-bucket-name/

CodeDeploy 배포 실행:

aws deploy create-deployment \
    --application-name MyApp \
    --deployment-group-name MyDeploymentGroup \
    --s3-location bucket=your-bucket-name,key=app.zip,bundleType=zip

(그림) CodeDeploy를 통한 배포 실행 결과

(그림) CodeDeploy 배포 실행 결과 상세 화면

6. 트러블슈팅 및 최종 확인

1) CodeDeploy 로그 확인

vi /var/log/aws/codedeploy-agent/codedeploy-agent.log

2) NAT 게이트웨이 연결 확인

aws ec2 describe-nat-gateways

3) S3 접근 문제 해결

aws s3 ls s3://your-bucket-name/

(그림) AWS CLI 명령으로 NAT게이트웨어, S3 접근 확인

7. 결론

이제 NAT 게이트웨이를 활용하여 퍼블릭 IP 없이 프라이빗 서브넷의 EC2 인스턴스에서 CodeDeploy를 통해 애플리케이션을 배포할 수 있습니다. 이를 통해 보안성을 유지하면서도 CodeDeploy 및 S3와 원활하게 통신할 수 있는 환경을 구성할 수 있습니다.

보안과 비용 절감을 고려하여 NAT 또는 VPC 엔드포인트를 적절히 선택하여 활용해보세요!

(AWS엔드포인트) EC2 Instance Connect Endpoint를 이용한 프라이빗 EC2 접속 방법

backend 따라쟁이 — Sun, 16 Mar 2025 23:44:10 +0900

프라이빗 서브넷에 있는 EC2 인스턴스에 무료로 접속하는 방법은 AWS의 EC2 Instance Connect Endpoint를 활용하면 가능합니다. 이는 AWS PrivateLink 기반으로 작동하여 퍼블릭 IP 없이도 SSH 및 RDP 접속을 가능하게 해 줍니다. 비용을 절감하면서도 보안성을 유지할 수 있는 장점이 있습니다.

EC2 Instance Connect Endpoint를 이용한 프라이빗 EC2 접속 방법

■ VPC Endpoint 설정하기

AWS 콘솔 접속 → VPC 서비스 이동
Endpoints 메뉴에서 Create Endpoint 선택
서비스 카테고리에서 "EC2 인스턴스 연결 엔트포인드"를 선택
VPC 선택 (프라이빗 서브넷이 있는 VPC)
서브넷 선택 (프라이빗 서브넷)
보안 그룹 설정:
- Inbound 규칙에 TCP 22번 포트 허용 추가 (SSH)
- 필요하면 TCP 3389번 포트 허용 추가 (RDP)
엔드포인트 생성 클릭

(그림) 서비스 카테고리에서 "EC2 인스턴스 연결 엔트포인드"를 선택

■ EC2 인스턴스 보안 그룹 설정 확인

EC2 인스턴스의 보안 그룹에서 Inbound 규칙 확인
TCP 22 (SSH) 또는 TCP 3389 (RDP) 규칙이 EC2 Instance Connect Endpoint에서 올 수 있도록 허용

■ 로컬PC에서 SSH를 통한 EC2 접속 (AWS CLI 사용)

AWS CLI를 설치하고 인증이 완료된 상태에서 아래 명령 실행:
- i-xxxxxxxxxxxxxxxxx → 프라이빗 EC2 인스턴스 ID
- 10022 → 로컬 머신에서 사용할 포트 (변경 가능)

bash

aws ec2-instance-connect open-tunnel \
--instance-id i-xxxxxxxxxxxxxxxxx \
--local-port 10022

2. 로컬 터미널에서 SSH 접속(1.번과 다른 터미널에서 실행):

my-key.pem → EC2 인스턴스에서 사용한 키 페어(내의 키 페어 파일명으로 변경)

bash

ssh -i ~/.ssh/my-key.pem -p 10022 ec2-user@localhost

(Hint) 앞에 설명과 같이 로컬PC에서 프라이빗 EC2 인스턴스에서 접속하지 위해서는 먼저 AWS CLI 명령으로 EC2 인스턴스 연결을 위한 local port로 터널을 오픈 합니다. 그리고 ssh 명령을 통해 EC2 인스턴스에 접속 합니다. 아래 예는 Shell 스크립트를 사용해 접속을 좀더 쉽게 처리예제 입니다. 관련 Shell 스크립트 파일도 함께 올려 드립니다.

추가로 local port 설정시 주의할 점은 10000번 이상 포트를 사용해야 한다는 점과 EC2의 IP주소가 아닌 @locahost로 접속하는 점을 주의하세요.

(그림) 로컬PC에서 ssh를 사용하여 EC2 인스턴스에 접속

(다운로드) Shell 스크립트 파일

■ EC2 Instance Connect 기능 활용 (콘솔)

AWS EC2 콘솔에서 프라이빗 EC2 인스턴스 선택 후 EC2 Instance Connect (Connect 버튼 클릭)

- 연결유형으로 "EC2 인스턴스 연결 엔드포인트를 사용하여 연결"를 선택

- "EC 인스턴스 연결 엔트포인트"로 앞에서 생성한 엔드포인트를 선택

- 사용자 이름과 최대 터널 시간(초)를 입력하고 연결 버튼 클릭

(그림) EC2 인스턴스 연결 설정화면에서 연결 유형, 엔드포인트 선택

(그림2) 연결 버튼을 클릭하면 EC2 인스턴스 단말이 오픈됨

✅ 비용 절감 효과

퍼블릭 IP 불필요 → Elastic IP 및 NAT Gateway 비용 절감
VPN, Bastion Host 없이 SSH 가능 → 유지보수 비용 절감

이 방법을 적용하면 NAT Gateway 비용 없이 프라이빗 서브넷 EC2에 안전하게 접속할 수 있습니다!

(AWS 보안그룹) 왜 엔드포인트 보안 그룹과 EC2 보안 그룹이 다르게 설정되어야 할까?

backend 따라쟁이 — Tue, 11 Mar 2025 23:50:38 +0900

EC2 인스턴스는 VPC 엔드포인트를 통해 AWS 서비스(S3, CodeDeploy, EC2 API 등)에 접근해야 함
VPC 엔드포인트는 EC2의 요청을 받아서 AWS 서비스로 전달하는 역할을 함
EC2 보안 그룹이 VPC 엔드포인트의 트래픽을 허용해야 하고, 반대로 엔드포인트 보안 그룹도 EC2의 요청을 허용해야 함

1. 올바른 보안 그룹 설정 방법

(1) VPC 엔드포인트 보안 그룹 설정

대상(Destination) → EC2 보안 그룹 지정
443 포트(TCP) 허용 (HTTPS 트래픽)

설정 방법

규칙 유형프로토콜포트 범위소스

HTTPS

TCP

443

sg-EC2-SecurityGroup-ID (EC2 보안 그룹 ID)

✅ 설명:

VPC 엔드포인트는 EC2 보안 그룹에서 오는 트래픽(HTTPS 443)을 허용하도록 설정 한다.

(2) EC2 보안 그룹 설정

대상(Destination) → VPC 엔드포인트 보안 그룹 지정
443 포트(TCP) 허용 (HTTPS 트래픽)

설정 방법

규칙 유형프로토콜포트 범위대상

HTTPS

TCP

443

sg-VPC-Endpoint-SecurityGroup-ID (VPC 엔드포인트 보안 그룹 ID)

✅ 설명:

EC2 인스턴스는 VPC 엔드포인트 보안 그룹으로 보내는 트래픽(HTTP 443)을 허용하도록 설정 한다.

2. 잘못된 설정 예시

보안 그룹인바운드 규칙아웃바운드 규칙문제점

EC2 보안 그룹	443 포트, 소스: 자기 자신(sg-xxxxx)	443 포트, 대상: 자기 자신(sg-xxxxx)	EC2 인스턴스가 엔드포인트와 통신할 수 없음
VPC 엔드포인트 보안 그룹	443 포트, 소스: 자기 자신(sg-yyyyy)	443 포트, 대상: 자기 자신(sg-yyyyy)	EC2가 요청을 보내도 엔드포인트가 응답을 처리할 수 없음

보안 그룹을 동일하게 설정하면 트래픽이 차단될 가능성이 큼.
따라서 EC2 보안 그룹과 VPC 엔드포인트 보안 그룹을 별도로 설정하고, 서로를 허용하는 방향으로 설정해야 함.

3. 최종 설정 정리

✅ EC2 보안 그룹

아웃바운드 규칙: VPC 엔드포인트 보안 그룹으로 HTTPS 443 허용

✅ VPC 엔드포인트 보안 그룹

인바운드 규칙: EC2 보안 그룹으로부터 오는 HTTPS 443 허용

이렇게 설정하면 프라이빗 서브넷에 있는 EC2가 VPC 엔드포인트를 통해 AWS CodeDeploy, S3, EC2 API 등의 AWS 서비스와 안전하게 통신할 수 있습니다.

(VPC Endpoints)NAT를 사용하지 않고 프라이빗 서브넷의 EC2 인스턴스에 CodeDeploy 배포 하기

backend 따라쟁이 — Tue, 11 Mar 2025 23:45:57 +0900

프라이빗 서브넷의 EC2 인스턴스에 CodeDeploy를 통한 Application 배포 환경을 만들려면 어떻게하면 되는지 알아 보겠습니다.

퍼블릭 IP를 사용하는 EC2 인스턴스에서는 필요 없는 과정이나, 프라이빗 서브넷의 EC2의 보안이나 비용적인 측면 장점을 활용하고 싶다면 꼭 알고 있어야 하는 방법 입니다.

CodeDeploy 배포를 위해서는 EC2 인스턴스가 VPC 엔드포인드를 통해 AWS CodeDeploy, S3, EC2 서비스에 접근할 수 있도록 환경을 구성해야 합니다. 이때 보안 그룹(Security Group) 및 엔드포인트 정책을 이해하고 바르게 설정할 줄 알아야 합니다.

1. 보안 그룹(Security Group) 설정

(1) VPC 엔드포인트를 위한 보안 그룹 생성/설정

AWS 콘솔에서 VPC 서비스 → Endpoints로 이동
생성한 CodeDeploy, S3, EC2 엔드포인트 각각을 선택
하단의 보안 그룹에서 편집 버튼 클릭
EC2 인스턴스가 접근할 수 있도록 인바운드 규칙 추가
- 유형(Type): HTTPS (TCP 443)
- 프로토콜(Protocol): TCP
- 포트 범위(Port Range): 443
- 소스(Source): EC2 인스턴스의 보안 그룹 (또는 특정 IP 대역)
  - sg-xxxxxxxxxxxx (EC2가 속한 보안 그룹)
  - 또는 10.0.0.0/16 (VPC 내부에서만 허용)

(그림) VPC엔드포인드 보안그룹 설정 예시

(2) 프라이빗 서브넷의 EC2 인스턴스를 위한 보안 그룹 생성/설정

AWS 콘솔에서 EC2 서비스 → 인스턴스 → 해당 EC2 선택
보안 그룹 클릭 후 편집
아웃바운드 규칙에 추가
- 유형(Type): HTTPS (TCP 443)
- 프로토콜(Protocol): TCP
- 포트 범위(Port Range): 443
- 대상(Destination): VPC 엔드포인트의 보안 그룹 (sg-xxxxxxxxxxxx)

(그림) EC2 인스턴스의 보안그룹 아웃바운드 규칙 설정 예시

설명:

EC2 → VPC 엔드포인트: 아웃바운드에서 HTTPS 443을 허용
VPC 엔드포인트 → EC2: 인바운드에서 HTTPS 443을 허용

2. VPC 엔드포인트 정책 설정

각 VPC 엔드포인트에는 접근 정책(Endpoint Policy) 을 적용하여 EC2 인스턴스에서 특정 AWS 서비스에 접근할 수 있도록 설정해야 합니다. 아래 그림과 같이 3가지 엔드포인트를 생성 합니다.

(그림) 3가지 VPC 엔드포인트 생성 예(CodeDeploy, S3, EC2 서비스 접근)

(1) CodeDeploy 엔드포인트 정책

VPC 서비스 → Endpoints → CodeDeploy 엔드포인트 선택
Policy 탭 클릭 → 편집 버튼 클릭
아래 JSON 정책을 입력 후 저장:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "codedeploy:*",
            "Resource": "*"
        }
    ]
}

(2) S3 엔드포인트 정책

S3는 애플리케이션 패키지를 다운로드하는 데 사용되므로, S3 버킷에 대한 접근을 허용해야 합니다.

VPC 서비스 → Endpoints → S3 엔드포인트 선택
Policy 탭 클릭 → 편집 버튼 클릭
아래 JSON 정책 입력 후 저장:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::YOUR_BUCKET_NAME",
                "arn:aws:s3:::YOUR_BUCKET_NAME/*"
            ]
        }
    ]
}

YOUR_BUCKET_NAME을 실제 S3 버킷 이름으로 변경

(3) EC2 엔드포인트 정책

VPC 서비스 → Endpoints → EC2 엔드포인트 선택
Policy 탭 클릭 → 편집 버튼 클릭
아래 JSON 정책 입력 후 저장:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "ec2:DescribeInstances",
            "Resource": "*"
        }
    ]
}

이 정책은 CodeDeploy가 EC2 인스턴스 상태를 조회할 수 있도록 허용

3. 연결 확인

설정이 완료되면 EC2에서 VPC 엔드포인트를 통해 AWS 서비스에 정상적으로 접근할 수 있는지 확인해야 합니다.

(1) CodeDeploy 연결 확인

aws codedeploy list-applications --region <region>

CodeDeploy에 등록된 애플리케이션 목록이 출력되면 정상 연결됨.

또는 CLI가 설치되지 않은 경우에는 URL 호출을 통해 확인하면됨.

curl -v https://codedeploy.<region>.amazonaws.com

✔ 정상적인 경우
* Connected to codedeploy.<region>.amazonaws.com (XX.XX.XX.XX) port 443
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
비정상적인 경우
curl: (6) Could not resolve host: codedeploy.<region>.amazonaws.com
VPC 엔드포인트가 올바르게 설정되지 않았거나 보안 그룹이 차단된 상태일 가능성 있음.

(2) S3 연결 확인

aws s3 ls s3://YOUR_BUCKET_NAME --region <region>

S3 버킷의 객체 목록이 표시되면 정상 연결됨.

또는 CLI가 설치되지 않은 경우에는 URL 호출을 통해 확인하면됨.

curl -I http://s3.<region>.amazonaws.com/YOUR_BUCKET_NAME

✔ 정상적인 경우
HTTP/1.1 403 Forbidden
✔ 또는, 만약 공개된 버킷이면:
HTTP/1.1 200 OK
비정상적인 경우
curl: (6) Could not resolve host
S3 VPC 엔드포인트 문제 가능성 높음

(3) EC2 연결 확인

aws ec2 describe-instances --region <region>

EC2 인스턴스 목록이 표시되면 정상 연결됨.

또는 CLI가 설치되지 않은 경우에는 URL 호출을 통해 확인하면됨

curl -v https://ec2.<region>.amazonaws.com

✔ 정상적인 경우
* Connected to ec2.<region>.amazonaws.com (XX.XX.XX.XX) port 443
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
비정상적인 경우

curl: (6) Could not resolve host: ec2.<region>.amazonaws.com
VPC 엔드포인트가 없거나, 네트워크/보안 그룹 설정이 잘못됨.

4. 추가 고려사항

✅ 인터넷 게이트웨이 없이도 AWS 서비스 연결 가능
✅ NAT 게이트웨이 없이도 엔드포인트를 통해 AWS 서비스와 통신 가능
✅ S3 엔드포인트는 반드시 Gateway 엔드포인트로 생성해야 함
✅ CodeDeploy 및 EC2 엔드포인트는 Interface 엔드포인트로 생성해야 함

이제 프라이빗 서브넷에서도 AWS CodeDeploy를 정상적으로 사용할 수 있습니다!

8.9.나. AWS 배포 그룹 생성시 In-place 배포와 Blue/Green 배포의 차이점

backend 따라쟁이 — Sun, 2 Mar 2025 21:03:32 +0900

AWS CodeDeploy에서 EC2 인스턴스 (또는 Auto Scaling Group) 에 애플리케이션을 배포할 때, 대표적으로 In-place 배포와 Blue/Green 배포 두 가지 방식이 있어. 각 방식의 차이를 비교해보겠습니다.

1️⃣ In-place 배포 (Rolling 배포)

개념

기존 EC2 인스턴스에서 실행 중인 애플리케이션을 중단하고 업데이트하는 방식이야.
CodeDeploy가 하나씩 인스턴스를 업데이트하며 애플리케이션을 배포해.
기존 인스턴스를 그대로 유지하면서 업데이트하기 때문에 새로운 인프라를 만들지 않아 비용이 절감됨.

배포 과정

Auto Scaling Group 내의 기존 EC2 인스턴스에서 애플리케이션을 중지.
새로운 애플리케이션 버전 배포.
배포 완료 후 서비스 재시작.
모든 인스턴스에서 배포가 완료되면 서비스가 정상 운영됨.

✅ 장점

별도의 새로운 인스턴스를 생성하지 않으므로 비용이 절감됨.
Auto Scaling Group을 사용할 때, 현재 실행 중인 모든 인스턴스에 적용되므로 구성 변경이 필요 없음.
간단한 애플리케이션 업데이트에 적합.

❌ 단점

배포 중 애플리케이션이 중지되므로 서비스 중단 가능성이 있음.
배포 실패 시 롤백이 어려움 (이전 버전으로 되돌리려면 다시 배포해야 함).
새 버전이 정상적으로 작동하지 않을 경우, 일부 사용자에게만 영향을 주는 것이 아니라 전체 인스턴스에서 장애가 발생할 가능성이 있음.

언제 사용하면 좋을까?

서비스 중단이 발생해도 크게 문제가 되지 않는 경우.
배포 속도를 빠르게 해야 하는 경우.
인프라 변경 없이 간단하게 배포하고 싶은 경우.

2️⃣ Blue/Green 배포

개념

기존 (Blue) 환경과 새로운 (Green) 환경을 별도로 운영하며, 새로운 환경에서 배포 후 트래픽을 전환하는 방식.
새로운 버전의 애플리케이션을 새로운 Auto Scaling Group이나 새로운 EC2 인스턴스 (Green)에서 실행한 후, 정상 동작이 확인되면 로드 밸런서를 통해 트래픽을 새 환경으로 전환.
기존 (Blue) 환경을 그대로 유지하므로, 배포 실패 시 빠르게 롤백할 수 있음.

배포 과정

기존 인스턴스(Blue)에서 애플리케이션을 운영 중.
새로운 EC2 인스턴스(Green)를 생성하여 새 버전의 애플리케이션을 배포.
Green 환경에서 정상적으로 실행되는지 테스트.
로드 밸런서 (ALB 또는 ELB) 를 사용하여 트래픽을 Blue에서 Green으로 전환.
기존(Blue) 인스턴스를 유지할지 삭제할지 결정.

✅ 장점

무중단 배포 가능 → 기존 인스턴스(Blue)는 그대로 둔 채 새로운 인스턴스(Green)에서 테스트 가능.
빠른 롤백 가능 → 문제가 발생하면 다시 Blue로 트래픽을 전환하면 됨.
배포 안정성 증가 → 새 버전이 안정적으로 동작하는지 확인한 후 트래픽을 전환할 수 있음.

❌ 단점

기존 인스턴스(Blue)와 새로운 인스턴스(Green)를 동시에 운영하므로 추가 비용이 발생.
인프라 구성이 더 복잡해지고 로드 밸런서 설정이 필요함.
새로운 인스턴스를 실행해야 하므로 배포 속도가 다소 느릴 수 있음.

언제 사용하면 좋을까?

무중단 배포가 중요한 경우 (예: 금융, 전자상거래, AI 서비스 등).
배포 실패 시 빠르게 롤백이 필요한 경우.
테스트 환경에서 안정성을 먼저 확인한 후 배포하고 싶은 경우.

In-place 배포 vs. Blue/Green 배포 비교 정리

배포 방식In-place 배포Blue/Green 배포

배포 방식	기존 인스턴스에서 애플리케이션을 중지하고 업데이트	새로운 인스턴스에서 배포 후 트래픽 전환
서비스 중단	발생 가능 (배포 중 일부 인스턴스에서 서비스 중단)	무중단 배포 가능
롤백	어려움 (이전 버전 재배포 필요)	빠름 (트래픽을 기존 버전으로 전환)
배포 속도	빠름	상대적으로 느림
비용	낮음 (기존 인프라 유지)	높음 (새로운 인프라 추가 필요)
운영 복잡도	쉬움	높음 (로드 밸런서 및 새 인프라 관리 필요)
추천 사용 사례	소규모 업데이트, 빠른 배포가 필요한 경우	무중단 배포가 필요하거나 안정성이 중요한 경우

결론

In-place 배포는 간단하고 비용이 적게 들지만, 서비스 중단과 롤백 어려움이 단점.
Blue/Green 배포는 무중단 배포와 빠른 롤백이 가능하지만, 비용이 높고 인프라 구성이 복잡함.

만약 Auto Scaling 환경에서 무중단 배포가 필요하다면 Blue/Green 배포가 더 적합하고, 단순한 업데이트라면 In-place 배포가 적합한 방식입니다.

8.9.가. AWS CodeDeploy를 이용한 EC2 인스턴스 배포 구성 및 실행 방법

backend 따라쟁이 — Sun, 2 Mar 2025 00:17:45 +0900

1. 개요

AWS CodeDeploy는 EC2 인스턴스, 온프레미스 서버, Lambda 및 ECS 등의 환경에서 애플리케이션을 자동으로 배포할 수 있는 서비스입니다. 이 글에서는 CodeDeploy를 활용하여 EC2 인스턴스에 애플리케이션을 배포하는 방법을 단계별로 설명합니다.

2. 환경 설정

1) AWS 서비스 준비

배포를 실행하기 위해 다음과 같은 AWS 서비스를 사용합니다.

Amazon EC2: 애플리케이션을 배포할 대상 서버
Amazon S3: 배포 패키지를 저장할 저장소
AWS CodeDeploy: 배포 자동화 서비스
IAM 역할 및 정책: CodeDeploy 및 EC2가 상호 작용할 수 있도록 설정

2) IAM 역할 생성

(1) EC2용 IAM 역할 설정

AWS 콘솔 → IAM → 역할(Role) 생성
EC2를 선택한 후 "다음" 클릭
다음 정책을 추가
- AmazonEC2RoleforAWSCodeDeploy
- AmazonS3ReadOnlyAccess
역할 이름: EC2CodeDeployRole 설정 후 생성
EC2 인스턴스에 IAM 역할 할당

(그림1) IAM에서 역할(Role)생성

(그림2) EC2 인스턴스에서 IAM역할 할당 (EC2CodeDeployRole 역할)

(2) CodeDeploy용 IAM 역할 설정

AWS 콘솔 → IAM → 역할(Role) 생성
CodeDeploy를 선택한 후 "다음" 클릭
다음 정책을 추가
- AWSCodeDeployRole
역할 이름: CodeDeployServiceRole 설정 후 생성

3. EC2 인스턴스 설정

1) EC2 인스턴스 생성 및 환경 설정

AWS 콘솔 → EC2 → 인스턴스 실행
ubuntu LINUX 선택
IAM 역할: EC2CodeDeployRole 할당
보안 그룹: SSH(22) 및 HTTP(80) 허용
인스턴스 실행 후 SSH로 접속

ssh -i my-key.pem ubuntu@<EC2_PUBLIC_IP>

2) CodeDeploy 에이전트 설치

sudo apt update -y
sudo apt install ruby -y
sudo apt install wget -y
cd /home/ubuntu
wget https://aws-codedeploy-us-east-1.s3.us-east-1.amazonaws.com/latest/install
chmod +x ./install
sudo ./install auto
sudo service codedeploy-agent start
sudo systemctl enable codedeploy-agent

설치 확인:

sudo service codedeploy-agent status

4. 배포 패키지 준비

AWS에 CodeDeploy 만 사용하고 개발 및 형상관리를 직접하는 환경으로 배포 패키지 준비는 모두 Local PC환경에서 진행합니다.

아래 과정은 jar 파일과 함께 zip파일 묶어서 배포할 appspec.yml 파일과 배포 스크립트를 작성하는 과정 입니다. 해당 파일들은 CodeDeploy 에이전트가 jar 파일을 EC2 인스턴스에 배포하기위해 필요한 정보와 쉘 스크립트라고 보시면 됩니다.

(그림) 배포 패키지 준비 디렉토리 구조

1) 프로젝트 구조 생성

mkdir package
cd package
mkdir scripts

2) appspec.yml 파일 작성

version: 0.0
os: linux
files:
  - source: my-app-latest.jar
    destination: /home/ubuntu/app
  - source: scripts/
    destination: /home/ubuntu/scripts/
hooks:
  ApplicationStop:
    - location: scripts/stop_server.sh
      timeout: 60
      runas: root
  BeforeInstall:
    - location: scripts/before_install.sh
      timeout: 300
      runas: root
  AfterInstall:
    - location: scripts/after_install.sh
      timeout: 300
      runas: root
  ApplicationStart:
    - location: scripts/start_server.sh
      timeout: 300
      runas: root
  ValidateService:
    - location: scripts/validate_service.sh
      timeout: 120
      runas: root

3) 배포 스크립트 작성

■ scripts/stop_server.sh

#!/usr/bin/bash
echo "Stopping application..."
sudo pkill -f 'java -jar'

■ scripts/before_install.sh

#!/usr/bin/bash
echo "Installing dependencies..."

java --version
if [ $? -eq 127 ]; then
    echo "Java를 설치 합니다...."
    sudo apt update
    sudo apt install openjdk-21-jdk
else
    echo "Java가 설치되어 있습니다."
fi

■ scripts/after_install.sh

#!/usr/bin/bash
echo "Deploying new application..."
sudo cp /home/ubuntu/app/my-app-v1.2.jar /home/ubuntu/app/my-app-latest.jar

(참고) 배포된 v1.2.jar파일을 latest.jar로 복사하여 최신 배포 버전을 명확하게 유지 합니다.

배포가 완료되면 최신 버전의 .jar 파일을 항상 my-app-latest.jar로 유지하면, 실행 스크립트에서 특정 버전명이 아니라 고정된 파일명(latest.jar)을 사용할 수 있습니다.
즉, 애플리케이션 실행 스크립트에서 특정 버전의 .jar를 찾을 필요 없이 항상 최신 버전(my-app-latest.jar)만 실행하도록 설정할 수 있습니다.

■ scripts/start_server.sh

#!/usr/bin/bash
echo "Starting application..."
sudo nohup java -jar /home/ubuntu/app/my-app-latest.jar \
    --spring.config.location=/home/ubuntu/app/app.properties \
     > /home/ubuntu/app/springboot.log 2>&1 &

(참고) "2>&1"은 stderr 파일 디스크립트로 출력되는 내용을 stdout 파일 디스크립트로 출력 함께 출력하게 합니다. 즉, 오류 발생시 출력되는 log 내용도 stdout으로 출력되게 함으로써 springboot.log 파일에 모든 로그가 출력되도록해줍니다.

■ scripts/validate_service.sh

#!/usr/bin/bash
echo "Checking application status..."
sleep 10 # Application이 정상 기동된 후 Health check하기 위해 대기 
curl -f http://localhost/api/data/0 || exit 1

■ 쉘 스크립트를 모두 작성했으면 실행 권한을 부여 합니다.

chmod +x scripts/*.sh

4) 배포 패키지 압축 및 S3 업로드

지금까지 작성한 appspec.yml과 쉘 스크립트 파일, jar 파일을 하나의 배포 패키지 zip 파일로 묶어 S3에 업로드 합니다.

zip -r my-app.zip appspec.yml scripts/ my-app-v1.2.jar
aws s3 cp my-app.zip s3://my-deploy-bucket/

(참고) AWS CLI를 사용하여 특정 리전에 S3 버킷을 만드는 방법

aws s3api create-bucket --bucket <버킷이름> --region <리전> --create-bucket-configuration LocationConstraint=<리전>

예제: 서울 리전(ap-northeast-2)에 버킷 생성 (버킷이름: my-deploy-bucket, 리전: ap-northeast-2)

aws s3api create-bucket --bucket my-deploy-bucket --region ap-northeast-2 --create-bucket-configuration LocationConstraint=ap-northeast-2

5. AWS CodeDeploy 설정 및 배포 실행

1) CodeDeploy 애플리케이션 및 배포 그룹 생성

aws deploy create-application --application-name MySpringBootApp

aws deploy create-deployment-group \
  --application-name MySpringBootApp \
  --deployment-group-name MyDeploymentGroup \
  --deployment-config-name CodeDeployDefault.AllAtOnce \
  --ec2-tag-filters Key=Name,Value=MyEC2Instance,Type=KEY_AND_VALUE \
  --service-role-arn arn:aws:iam::123456789012:role/CodeDeployServiceRole

2) CodeDeploy 배포 실행

aws deploy create-deployment \
  --application-name MySpringBootApp \
  --deployment-group-name MyDeploymentGroup \
  --s3-location bucket=my-deploy-bucket,key=my-app.zip,bundleType=zip

3) 배포 상태 확인

aws deploy get-deployment --deployment-id d-ABCDEFGHIJ1234567

(Hint) 쉘 명령 1개로 CodeDeploy 배포를 실행하고 배포상태를 확인하는 쉘 스크립트 만들기. 아래 쉘 스크립트 내용을 복사해 나에게 필요한 부분을 변경하여 쉘 명령 파일이를 만들어 사용해보세요.

#!/usr/bin/bash
echo ">>> (my-app.zip) CodeDeploy start...."

DEP_ID=$(aws deploy create-deployment \
  --application-name MySpringBootApp \
  --deployment-group-name MyDeploymentGroup \
  --s3-location bucket=copycat-deploy-bucket,key=my-app.zip,bundleType=zip \
  --file-exists-behavior OVERWRITE --output text)

watch -n1 aws deploy get-deployment --deployment-id $DEP_ID --output table

6. 배포 완료 후 확인

EC2 인스턴스에 SSH로 접속
애플리케이션 실행 여부 확인:

ps aux | grep java

애플리케이션 로그 확인:

tail -f /home/ubuntu/app/springboot.log

7. 마무리

이제 AWS CodeDeploy를 활용하여 EC2 인스턴스에 애플리케이션을 자동 배포하는 환경을 성공적으로 구성했습니다. 이 과정에서는 IAM 역할 설정, EC2 인스턴스 구성, CodeDeploy 에이전트 설치, 배포 패키지 생성 및 업로드, CodeDeploy 배포 실행을 다루었습니다.

이제 CI/CD 파이프라인을 확장하여 CodePipeline과 연동하거나, Auto Scaling 그룹을 활용한 배포 자동화도 고려해볼 수 있습니다.

8.9. AWS에서 EC2 기반 애플리케이션 CI/CD 구축 방법

backend 따라쟁이 — Tue, 25 Feb 2025 22:43:53 +0900

CI/CD 파이프라인은 개발부터 배포까지의 전체 프로세스를 자동화하여, 코드 변경 사항이 신속하고 안정적으로 운영 환경에 반영하는 것을 도와 주며, DevOps 환경을 구축할 때 가장 핵심적인 요소 입니다. Spring Boot 애플리케이션, GitHub, 그리고 AWS EC2/Auto Scaling 환경에서 가장 기본적인 CI/CD 파이프라인을 구축하는 방법에 대해 알아보겠습니다.

1. 전체 파이프라인 개요

Source 단계:
GitHub에 코드가 커밋/푸시될 때 자동으로 파이프라인이 시작됩니다.
Build & Test 단계:
AWS CodeBuild(또는 GitHub Actions)를 사용하여 애플리케이션을 컴파일하고, JUnit 테스트를 실행합니다.
- Maven 또는 Gradle 스크립트를 통해 jar 파일이 생성됩니다.
Deployment 단계:
AWS CodeDeploy를 이용해 빌드된 jar 파일을 EC2 인스턴스에 배포합니다.
- 배포 스크립트를 통해 기존 애플리케이션을 중단하고 새로운 jar 파일로 교체합니다.
AMI 생성 및 Auto Scaling 업데이트:
배포 성공 후, 배포된 EC2 인스턴스를 기반으로 새로운 AMI를 생성하고, 해당 AMI를 사용하도록 Auto Scaling 그룹의 Launch Configuration(또는 Launch Template)을 업데이트합니다.
- 이 과정은 CodeDeploy의 후처리 스크립트나 AWS Lambda를 활용해 자동화할 수 있습니다.

2. 구성 단계별 상세 가이드

(1) GitHub와 AWS CodePipeline 연동

연동 설정:
AWS CodePipeline을 생성하고, 소스 제공자로 GitHub를 선택합니다.
- 커밋 시마다 웹훅을 통해 CodePipeline이 자동으로 시작되도록 설정합니다.

(2) AWS CodeBuild 프로젝트 구성

빌드 환경 구성:
CodeBuild 프로젝트를 생성하여, 빌드 명령어(예: mvn clean package 또는 ./gradlew build)를 설정합니다.
- 빌드 스크립트 내에 JUnit 테스트가 자동 실행되도록 구성되어 있어야 합니다.
결과:
테스트가 모두 성공하면 jar 파일이 생성되고, 이후 단계로 아티팩트가 전달됩니다.

(3) AWS CodeDeploy를 통한 배포

배포 설정:
CodeDeploy 애플리케이션과 배포 그룹을 생성하고, 대상 EC2 인스턴스를 지정합니다.
- 애플리케이션 배포 시, 기존 애플리케이션을 중지하고 새 jar 파일을 배포하는 스크립트를 작성합니다.
Hook 활용:
배포 후 Hook를 이용해 자동으로 AMI를 생성하는 스크립트(또는 AWS Lambda)를 호출하여 새 AMI를 만들고, Auto Scaling 그룹 업데이트 작업을 진행합니다.

(4) Auto Scaling 그룹 업데이트

AMI 반영:
생성된 새 AMI ID를 기반으로 Launch Configuration(또는 Launch Template)을 업데이트합니다.
- 업데이트된 구성으로 Auto Scaling 그룹이 자동으로 새 인스턴스를 기동하게 하여 무중단 배포 또는 롤백이 가능하도록 합니다.

3. 추가 고려 사항

롤백 전략:
배포 실패 시 이전 버전으로 롤백할 수 있는 전략을 마련합니다. CodeDeploy에서는 롤백 옵션을 지원하므로 이를 활용할 수 있습니다.
모니터링 및 알림:
CloudWatch와 SNS를 연동하여 빌드 및 배포 상태를 모니터링하고, 이상 발생 시 자동 알림을 받을 수 있도록 설정합니다.
확장성:
처음엔 기본적인 파이프라인으로 시작하되, 이후 필요에 따라 Blue/Green 배포, Canary 배포 등의 고급 배포 전략을 도입할 수 있습니다.

이와 같은 기본 CI/CD 구성은 GitHub에 커밋된 코드가 자동으로 빌드, 테스트되고, 성공 시 AWS CodeDeploy를 통해 EC2 인스턴스에 배포되며, 새 AMI를 생성해 Auto Scaling 환경에 반영되는 형태로 진행됩니다. 이를 통해 개발에서 운영까지의 전체 흐름이 자동화되어 신뢰성과 효율성을 높일 수 있습니다.

지금 소개해드린 방법은 AWS에서 EC2 기반 애플리케이션을 대상으로 가장 일반적으로 사용되는 CI/CD 구성 중 하나입니다. 그러나 상황과 요구사항에 따라 다양한 대안도 고려할 수 있습니다. 몇 가지 다른 방법은 아래와 같습니다.

AWS 네이티브 서비스 활용
- AWS CodePipeline + CodeBuild + CodeDeploy:
  위에서 설명한 방식처럼 GitHub 등에서 커밋이 발생하면 CodePipeline이 트리거되고, CodeBuild로 빌드와 테스트를 진행한 후, CodeDeploy로 배포하는 구성입니다.
- AWS CodeStar:
  CodeCommit, CodeBuild, CodeDeploy, CodePipeline 등을 하나의 통합 인터페이스에서 관리할 수 있도록 도와주는 서비스로, 초기 설정과 관리를 보다 쉽게 할 수 있습니다.
서드파티 CI/CD 도구와의 연계
- Jenkins, GitHub Actions, GitLab CI/CD 등:
  AWS에 배포하기 위한 플러그인이나 AWS CLI를 이용하여, 외부 CI/CD 도구를 통해 빌드, 테스트, 배포 프로세스를 구축할 수 있습니다. 이 경우, AWS 서비스와 직접 통합하기보다 기존에 익숙한 도구를 활용하는 장점이 있습니다.
- CircleCI, Travis CI 등:
  클라우드 기반 CI/CD 플랫폼을 사용하여, 빌드와 테스트 후 AWS로 배포하는 스크립트를 실행할 수 있습니다.
배포 대상과 아키텍처에 따른 대안
- 컨테이너 기반 배포:
  만약 애플리케이션을 컨테이너화하여 AWS Elastic Container Service(ECS)나 EKS에 배포한다면, CodePipeline과 CodeBuild를 통해 컨테이너 이미지를 빌드하고, Amazon ECR에 저장 후 ECS/EKS로 배포하는 방식이 효과적입니다.
- AWS Elastic Beanstalk:
  PaaS 환경에서 애플리케이션을 운영하고자 한다면, Elastic Beanstalk의 배포 파이프라인을 활용해 CI/CD를 구성할 수 있습니다.
- 서버리스 배포:
  Lambda 기반의 서버리스 애플리케이션이라면, AWS SAM이나 Serverless Framework을 활용한 CI/CD 파이프라인도 고려해볼 수 있습니다./

결국 가장 적합한 CI/CD 구성은 애플리케이션의 특성, 팀의 선호도, 운영 환경(예: EC2, 컨테이너, 서버리스) 등에 따라 달라지게 됩니다. 각 방식의 장단점을 고려해 환경에 맞는 최적의 솔루션을 선택하는 것이 중요합니다.