25년 9월에 출시된 ECS Managed Instance에 대해

25년 9월에 출시된 ECS Managed Instance에 대해

25년 9월 30일에 출시된 ECS Managed Instance 기능에 대해 간단하게 알아보는 글입니다.
2025.10.06

안녕하세요 클래스메소드의 이수재입니다.

25년 9월 30일에 ECS Managed Instance 라는 기능이 출시되었습니다.

https://aws.amazon.com/ko/blogs/aws/announcing-amazon-ecs-managed-instances-for-containerized-applications/

https://aws.amazon.com/ko/blogs/korea/announcing-amazon-ecs-managed-instances-for-containerized-applications/

EC2의 기능을 사용하면서 인프라 관리 책임을 AWS에 맡길 수 있는 기능이라고 합니다.
어떤 기능이고 어떻게 사용하는지 알아보겠습니다.

기존의 ECS 환경

ECS를 사용해서 컨테이너 환경을 배포하기 위해서는 컨테이너를 배포하기 위한 노드 그룹이 필요합니다.
노드 그룹은 EC2와 Fargate 유형이 선택가능합니다.
EC2를 사용하면 보다 유연하게 설정할 수 있는 장점이 있고 Fargate를 사용하면 인스턴스의 관리를 AWS에 맡길 수 있기 때문에 사용자는 서비스에만 집중할 수 있다는 장점이 있습니다.

두 기능을 비교하자면 다음과 같습니다.

비교 항목 EC2 시작 유형 Fargate 시작 유형
개요 사용자가 관리하는 EC2 인스턴스 클러스터에서 컨테이너를 실행하는 모델. 컴퓨팅 인프라(서버)를 신경 쓸 필요 없이 컨테이너를 실행할 수 있는 서버리스 모델.
인프라 관리 필요
・EC2 인스턴스 선택, 시작, 모니터링
・OS 패치 적용, 보안 업데이트
・컨테이너 에이전트 업데이트
불필요
・AWS가 인프라 프로비저닝과 관리를 모두 수행.
・사용자는 컨테이너 정의와 실행에만 집중할 수 있음.
과금 모델 실행 중인 EC2 인스턴스에 대해 과금.
(컨테이너가 실행되지 않아도 요금 발생)
실행 중인 **태스크(컨테이너)**가 사용하는 vCPU와 메모리, 실행 시간에 대해 과금.
(태스크가 중지되면 과금도 중지)
비용 최적화 ・예약 인스턴스(Reserved Instances)
・Savings Plans
・스팟 인스턴스(Spot Instances)
・Compute Savings Plans
・Fargate Spot (최대 70% 할인)
스케일링 태스크 스케일링(Service Auto Scaling)
인스턴스 스케일링(Cluster Auto Scaling)
양쪽 모두 고려해야 함.
태스크 스케일링(Service Auto Scaling)만 고려.
・인스턴스를 신경 쓸 필요 없이 빠른 스케일링 가능.
제어 및 유연성 높음
・인스턴스 유형(GPU, 고용량 메모리 등)을 자유롭게 선택 가능.
・OS나 커널 파라미터 커스터마이징 가능.
・EBS 볼륨 직접 마운트 등 고급 설정 가능.
낮음
・CPU와 메모리 조합은 AWS가 정의한 것 중에서 선택.
・OS나 커널 커스터마이징 불가.
・GPU 지원은 제한적.
네트워크 awsvpc, bridge, host 등 여러 네트워크 모드 지원. awsvpc 모드만 지원.
(각 태스크에 전용 ENI가 할당되어 보안상 격리됨)
보안 공동 책임 모델
・사용자가 OS, 미들웨어, 네트워크 설정의 보안을 관리할 책임이 있음.
AWS가 인프라 관리
・사용자는 컨테이너 이미지와 애플리케이션 보안에만 집중할 수 있음.
・태스크별로 격리된 환경에서 기본적으로 높은 보안 수준을 제공.
비용 ・고부하・고밀도로 컨테이너를 실행한다면 Fargate보다 코스트 효율이 좋은 경우가 있음
이용률이 낮으면 불필요한 비용 발생이 생김
・ 트래픽 변동이 크거나 지속적인 워크 로드(배치 처리 등)에서 코스트 효율이 좋음
항상 고부하 작업이 발생하는 경우에는 EC2보다 많은 비용이 발생할 가능성 있음.

Managed Instances?

이 새로운 솔루션은 인프라 오프로드를 통한 운영 단순성, Amazon EC2의 유연성과 제어 역량을 결합했습니다. 즉, 고객은 총 소유 비용(TCO)을 줄이고 AWS 모범 사례를 유지하면서 혁신을 주도할 애플리케이션을 구축하는 데 집중할 수 있습니다.

완전히 새로운 시작 유형이 아니라 'EC2 시작 유형'의 한 종류입니다.
하지만 사용자가 OS 선정부터 패치 적용까지 모든 것을 직접 수행하는 '자체 관리형 EC2(Self-managed EC2)'와는 다르게 AWS가 제공하는 ECS 최적화 AMI, Auto Scaling Group, Systems Manager 등의 기능을 조합하여 운영 부담을 줄여주는 모델입니다.

Fargate의 '완전한 서버리스'와 사용자가 모든 것을 관리하는 '자체 관리형 EC2'의 중간에 위치하는, 균형 잡힌 선택지로 이해하면 쉽습니다.

주요 특징

공식 문서에서 제공하는 내용으로 특징과 모범 사례를 알아보자면 다음과 같습니다.

1. 인스턴스 선택

Amazon ECS 관리형 인스턴스는 인스턴스 유형을 선택하는 두 가지 방법을 제공합니다.[1]

  • 특정 인스턴스 유형 선택 : 작업에 사용할 EC2 인스턴스 유형을 명시적으로 지정합니다.
    • 단일 인스턴스 유형에 의존하지 않고 여러 패밀리, 크기, 세대를 혼합하여 사용함으로써, 특정 인스턴스가 부족할 경우의 리스크를 분산하고 스팟 인스턴스의 중단 내성을 높입니다.
  • 속성 기반 인스턴스 유형 선택 : 애플리케이션에 필요한 속성(예: vCPU, 메모리, 아키텍처)을 지정하면 Amazon ECS 관리형 인스턴스가 적절한 인스턴스 유형을 선택합니다.
    • 'c5.largem5.large'처럼 구체적인 인스턴스 유형을 지정하는 대신, 'vCPU 4개 이상, 메모리 8GB 이상'과 같이 요구사항(속성)으로 지정하는 방식입니다.
      • 이를 통해 Auto Scaling Group이 해당 요구사항을 충족하는 다양한 인스턴스(특히 가격이 저렴한 스팟 인스턴스)를 자동으로 찾아 시작해주므로, 비용 효율성과 가용성이 크게 향상됩니다.

Amazon ECS Managed Instances는 다음과 같은 여러 메커니즘을 통해 인프라 활용도와 비용을 최적화합니다.[2]

  • 멀티태스크 배치 : 기본적으로 Amazon ECS는 여러 개의 작은 작업을 더 큰 인스턴스에 배치하여 활용도를 극대화하고 비용을 절감합니다.
  • 활성 워크로드 통합 : Amazon ECS는 컨테이너 인스턴스가 실제로 유휴 상태인 시점을 식별하여 애플리케이션 가용성이나 배포 성능에 영향을 줄 수 있는 조기 종료를 방지합니다. 시스템은 서비스에 설정된 최소 및 최대 작업 수, 시작 전 중지 동작, 그리고 작업 보호 동작을 준수합니다.
  • 적정 크기 조정 : 워크로드 요구 사항이 변경되면 Amazon ECS는 현재 요구 사항에 맞게 적절한 크기의 대체 인스턴스를 시작합니다.

2. 운영 관리 간소화 (패치 적용)[3]

기본적으로 Amazon ECS 관리형 컨테이너 인스턴스는 표준화된 14~21일 수명 주기로 작동합니다.

Amazon ECS는 인스턴스 시작 후 14일째에 정상적인 워크로드 드레이닝을 시작하고, 최종 종료는 늦어도 21일째에 이루어집니다. Amazon ECS는 다음과 같은 특정 상황에서 조기 드레이닝을 지원합니다.

  • 소프트웨어의 보안 취약점 감지
  • 하드웨어 상태 저하
  • 고객이 구성한 이벤트 창을 존중하려면

이러한 접근 방식은 고객이 정의한 유지 관리 요구 사항을 준수하는 동시에 시스템 규정 준수를 유지합니다.
보안과 안정성을 유지하기 위한 인스턴스 관리가 간소화됩니다.

  • ECS 최적화 AMI 사용:
    • AWS가 제공하는, ECS 에이전트와 Docker가 사전 설치된 최신 AMI를 이용합니다.
  • 반자동 패치 적용:
    • 방법 1: 인스턴스 교체 (권장)
      • 최신 ECS 최적화 AMI를 사용하여 새 인스턴스를 시작하고, 이전 인스턴스를 안전하게 종료하는 방식(롤링 업데이트)으로 항상 최신 상태를 유지합니다. 이는 Auto Scaling Group의 기능으로 자동화할 수 있습니다.
    • 방법 2: AWS Systems Manager Patch Manager
      • 실행 중인 인스턴스에 대해 OS 보안 패치 등을 자동으로 적용합니다.

3. 보안

Amazon ECS 관리형 인스턴스는 유연성과 보호의 균형을 이루는 포괄적인 보안 모델을 구현합니다.

  • AWS 관리형 인프라 : AWS는 관리형 인스턴스의 수명 주기를 제어하고 보안 패치를 처리하여 인적 오류와 변조 가능성을 제거합니다.
  • 관리자 액세스 불가 : 보안 모델이 잠겨 있어 관리형 인스턴스에 대한 관리자 액세스가 금지됩니다.
  • 멀티태스크 배치 : 기본적으로 Amazon ECS 관리형 인스턴스는 비용과 활용도를 최적화하기 위해 단일 인스턴스에 여러 작업을 배치하므로 Fargate에 비해 워크로드 격리 제약이 완화됩니다.
  • 데이터 격리 : AWS는 인스턴스 수명 주기와 작업 배치를 제어하지만 AWS는 관리형 인스턴스에 로그인하거나 고객 데이터에 액세스할 수 없습니다.

또한 공동 책임 모델에 따라, 사용자가 담당하는 범위의 보안을 강화하기 위한 모범 사례가 제시됩니다.

  • 최소 권한 원칙: IAM 역할에 필요한 권한만 부여합니다.
  • 네트워크 분리: 보안 그룹 및 네트워크 ACL로 통신을 엄격하게 제어합니다.
  • 인스턴스 접근 제한: SSH를 통한 직접 접근은 피하고, 감사 및 관리가 용이한 AWS Systems Manager Session Manager 사용이 권장됩니다.

4. 인프라 및 비용 최적화

컴퓨팅 리소스를 낭비 없이 사용하기 위한 접근 방식을 고려해볼 수 있습니다.

  • 스팟 인스턴스 적극 활용: 중단을 허용할 수 있는 워크로드에서 스팟 인스턴스를 사용하면 온디맨드 요금에 비해 대폭적인 비용 절감이 가능합니다. '속성 기반 인스턴스 유형 선택'과 조합하면 매우 효과적입니다.
  • Savings Plans / 예약 인스턴스: 안정적인 워크로드에 대해서는 이러한 구매 옵션으로 비용을 절감합니다.
  • 클러스터 오토 스케일링: 수요에 따라 인스턴스 수를 자동으로 증감시켜 불필요한 유휴 비용을 방지합니다.

모범 사례

인스턴스 선택에 대한 모범 사례[4]

인스턴스 타입을 선전할 때 다음 내용을 기반으로 검토해보는 것을 권장합니다.

  • Amazon ECS Managed Instances 기본 용량 공급자 사용
  • 대부분의 작업 부하에 대해 속성 기반 선택을 사용하여 유연성을 제공하고 배치 성공률을 개선
  • 애플리케이션에 특정 하드웨어 요구 사항이 있는 경우에만 특정 인스턴스 유형을 사용
  • 과도한 프로비저닝과 불필요한 비용을 피하기 위해 균형 잡힌 리소스를 선택
  • 다양한 작업 부하가 있는 애플리케이션에 대해 인스턴스 유형을 혼합하여 성능과 비용의 균형을 맞추기

마이그레이션 동기

Fargate나 자체 관리형 EC2에서 'Managed Instances'로의 마이그레이션이 검토되는 경우는 주로 다음과 같습니다.

Fargate에서 마이그레이션하는 경우

  • 더 세밀한 제어가 필요할 때: OS 커널 파라미터 조정이나 특정 모니터링 에이전트 도입이 필요해진 경우.
  • 특수한 하드웨어가 필요할 때: GPU, 추론 칩(Inferentia), Graviton 프로세서 등 Fargate에서 사용할 수 없는 하드웨어를 사용하고 싶은 경우.
  • 추가적인 비용 최적화: 워크로드가 항상 높은 부하로 안정적이며, 예약 인스턴스나 스팟 인스턴스를 최대한 활용하여 컴퓨팅 요금을 극한까지 낮추고 싶은 경우.

자체 관리형 EC2에서 마이그레이션하는 경우

  • 운영 부담 감소: 커스텀 AMI 생성, OS 패치 관리, ECS 에이전트 업데이트와 같은 수작업을 없애고 AWS의 관리형 구조에 맡기고 싶은 경우.
  • 비용 및 가용성 향상: '속성 기반 인스턴스 유형 선택'이나 스팟 인스턴스 활용 등 AWS의 최신 모범 사례를 도입하고 싶은 경우.

요약

개인적인 의견으로 세 유형을 비교하면 다음과 같다고 생각합니다.

Fargate ECS Managed Instances 자체 관리형 EC2
관리 부담 낮음 (불필요) 중간 높음
유연성 낮음 높음 가장 높음
비용 변동/소규모에 유리 안정/대규모에 유리 최적화에 따라 다름
추천 대상 편의성 최우선 유연성과 운영 부담의 균형 완전한 맞춤형 환경

마무리

이 글이 Managed Instance를 사용하려는 분에게 도움이 되었으면 좋겠네요.
사용 방법은 이 글 서두에 첨부한 AWS 코리아의 글을 참고하시는 것을 권장합니다.

긴 글 읽어주셔서 감사합니다.
오탈자 및 내용 피드백은 must01940 지메일로 보내주시면 감사합니다.

문의 사항은 클래스메소드코리아로!

클래스메소드코리아에서는 다양한 세미나 및 이벤트를 진행하고 있습니다.
진행중인 이벤트에 대해 아래 페이지를 참고해주세요.

https://classmethod.kr/board/library

AWS에 대한 상담 및 클래스메소드 멤버스에 관한 문의사항은 아래 메일로 연락주시면 감사드립니다!
Info@classmethod.kr

脚注
  1. https://docs.aws.amazon.com/AmazonECS/latest/developerguide/managed-instances-instance-types.html ↩︎

  2. https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ManagedInstances.html#managed-instances-instance-selection ↩︎

  3. https://docs.aws.amazon.com/AmazonECS/latest/developerguide/managed-instances-patching.html ↩︎

  4. https://docs.aws.amazon.com/AmazonECS/latest/developerguide/managed-instances-instance-selection-best-practices.html ↩︎

この記事をシェアする

FacebookHatena blogX

関連記事

25년 9월에 출시된 ECS Managed Instance에 대해 | DevelopersIO