aws2026년 6월 30일

AWS Graviton5 프로세서 기반 Amazon EC2 C9g 및 C9gd 인스턴스 출시 | Amazon Web Services (새 탭에서 열림)

AWS가 AWS Graviton5 기반의 컴퓨팅 최적화 EC2 C9g 및 로컬 NVMe 스토리지를 갖춘 C9gd 인스턴스를 정식 출시했다. C9g는 이전 C8g보다 vCPU당 최대 25% 높은 성능과 더 빠른 메모리·대형 캐시·향상된 네트워크 성능을 제공하며, C9gd는 여기에 고속 로컬 SSD를 추가한다. 두 인스턴스는 배치 처리, HPC, 동영상 인코딩, 실시간 분석, CPU 기반 ML 추론, 에이전틱 AI 등에 적합하다. ## Graviton5 기반 성능 향상 - C9g는 이전 세대 C8g 대비 vCPU당 최대 25% 높은 성능을 제공한다. - DDR5 8800MT/s 메모리를 사용해 클라우드 프로세서 인스턴스 중 가장 빠른 메모리 성능을 제공한다. - L3 캐시가 5배 늘어나 데이터 대기 시간을 줄이고, 인메모리 분석과 실시간 애플리케이션의 처리량을 높인다. - Graviton4 기반 인스턴스 대비 패킷 처리 성능이 최대 3배 향상됐다. - 평균적으로 이전 세대보다 네트워크 대역폭은 최대 15%, EBS 대역폭은 최대 20% 높다. - 48xlarge는 네트워크 최대 100Gbps, EBS 최대 72Gbps를 지원하며, 이는 이전 세대 대비 최대 2배 수준이다. ## C9g와 C9gd의 용도 차이 - **C9g** - Amazon EBS를 스토리지로 사용하는 배치 작업, 동영상 인코딩, 분산 분석에 적합하다. - 높은 코어 수와 대형 캐시가 필요한 에이전틱 AI의 병렬 실행 환경과 CPU 중심 추론에 유리하다. - 실시간 분석, 게임, 과학 모델링, 광고 서버 등 CPU 집약적 워크로드에 활용할 수 있다. - **C9gd** - C9g의 컴퓨팅 성능에 로컬 NVMe SSD를 결합한 유형이다. - HPC 시뮬레이션의 임시 작업 공간, ML 추론 캐시, 광고 서버의 로컬 버퍼 등에 적합하다. - 로컬 스토리지 성능은 이전 세대 대비 최대 30% 향상됐다. ## 세부 네트워크·스토리지 기능 - 중간형부터 48xlarge까지 11개 크기와 베어메탈 옵션을 제공한다. - **Instance Bandwidth Configuration(IBC)**으로 EBS와 VPC 네트워크 간 대역폭 배분을 최대 25% 조정할 수 있다. - 데이터베이스나 캐시처럼 특정 대역폭 구성이 중요한 워크로드를 세밀하게 최적화할 수 있다. - ENA Express를 지원해 향상된 네트워킹을 제공한다. - 가상 인스턴스에는 최대 128개의 EBS 볼륨을 연결할 수 있다. - NVMe 인스턴스 스토어 사용 시 I/O 크기별 지연 시간 히스토그램과 1초 단위의 고해상도 성능 지표를 CloudWatch 또는 `nvme-cli`에서 추가 비용 없이 확인할 수 있다. ## Nitro Isolation Engine 적용 - C9g와 C9gd는 Nitro Isolation Engine을 탑재한 최초의 컴퓨팅 최적화 EC2 인스턴스다. - 이 기능은 AWS Nitro System의 구성 요소로, Rust로 구현된 Nitro Hypervisor 기반 격리 기능이다. - 가상 머신 간 메모리, CPU 레지스터 상태, I/O 장치 접근을 최소한의 API를 통해 중재해 격리를 강화한다. - 공식 검증 결과와 적용 범위는 AWS 기술 백서에서 확인할 수 있다. ## 제공 방식과 리전 - On-Demand, Spot, Dedicated Instance, Dedicated Host 및 Savings Plans를 지원한다. - 현재 미국 동부 오하이오·버지니아 북부, 미국 서부 오리건, 유럽 프랑크푸르트 리전에서 사용할 수 있다. - AWS Management Console, AWS CLI, AWS SDK로 생성할 수 있으며 추가 리전은 추후 제공될 예정이다. 워크로드가 CPU 처리량과 메모리 접근 속도를 중시한다면 C9g를, 고성능 로컬 임시 스토리지까지 필요하다면 C9gd를 우선 검토하는 것이 좋다. 실제 도입 전에는 애플리케이션을 Graviton5에서 벤치마크하고, IBC를 활용해 네트워크와 EBS 대역폭 구성을 조정하는 것이 권장된다.

aws-cloudwatchrustamazon-ec2aws-graviton5+4

aws2026년 6월 22일

전체 수명 주기 제어로 격리된 샌드박스 실행하기: AWS Lambda, MicroVM 도입 | Amazon Web Services (새 탭에서 열림)

AWS Lambda MicroVMs는 사용자나 AI가 생성한 신뢰할 수 없는 코드를 사용자별로 격리된 실행 환경에서 실행하도록 설계된 서버리스 컴퓨팅 기능이다. Firecracker 기반의 VM 수준 격리, 스냅샷을 활용한 빠른 시작·재개, 메모리와 디스크 상태를 유지하는 실행 세션을 제공하면서도 인프라를 직접 운영할 필요가 없다. 특히 AI 코딩 도구, 온라인 개발 환경, 데이터 분석, 취약점 스캐너처럼 사용자별 장기 실행 환경이 필요한 서비스의 기존 격리·성능 trade-off를 줄이는 것이 핵심이다. ## 사용자별 격리 실행 환경이 필요한 이유 - AI 코딩 어시스턴트, 대화형 코드 실행 환경, 데이터 분석 플랫폼, 취약점 스캐너, 사용자 스크립트를 실행하는 게임 서버 등이 주요 대상이다. - 기존 방식에는 각각 한계가 있다. - **가상 머신**: 강력한 격리를 제공하지만 시작에 수분이 걸릴 수 있다. - **컨테이너**: 빠르게 시작되지만 공유 커널 때문에 신뢰할 수 없는 코드를 안전하게 격리하려면 추가적인 보안 강화가 필요하다. - **서버리스 함수**: 이벤트 기반 요청-응답 처리에 적합하지만, 사용자 상호작용 사이에 상태를 유지하는 장기 세션에는 적합하지 않다. - 직접 가상화 인프라를 구축하면 낮은 지연 시간과 강한 격리를 모두 확보할 수 있지만, 상당한 운영·보안 전문성이 필요하다. ## Firecracker 기반 VM 수준 격리 - 각 사용자 또는 세션은 독립된 MicroVM을 할당받는다. - MicroVM 간 커널과 리소스를 공유하지 않으므로 한 사용자가 실행한 신뢰할 수 없는 코드가 다른 사용자 환경이나 호스트 시스템에 접근하는 것을 막는다. - AWS Lambda에서 대규모로 사용되어 온 Firecracker 기술을 기반으로 하므로, 자체 가상화 시스템을 구축하는 대신 AWS의 운영 성숙도를 활용할 수 있다. ## MicroVM Image 생성 과정 - 애플리케이션 코드와 Dockerfile을 ZIP 파일로 패키징해 Amazon S3에 업로드한다. - `public.ecr.aws/lambda/microvms:al2023-minimal` 기반 이미지에서 Python, pip 등을 설치하고 애플리케이션을 구성할 수 있다. - 예시 애플리케이션은 Gunicorn으로 실행되는 Flask API이며, `0.0.0.0:5000` 포트에서 요청을 처리한다. - 다음과 같은 CLI 명령으로 이미지를 생성한다. ```bash aws lambda-microvms create-microvm-image \ --code-artifact uri=<path/to/s3/artifact.zip> \ --name <VM_image_name> \ --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \ --build-role-arn <IAM role ARN> ``` - Lambda는 ZIP 파일을 가져와 Dockerfile을 빌드하고 애플리케이션을 초기화한다. - 초기화가 끝난 실행 중인 디스크와 메모리 상태를 Firecracker 스냅샷으로 저장한다. - 빌드 로그는 다음 CloudWatch Logs 경로에서 확인할 수 있다. ```text /aws/lambda/microvms/<image-name> ``` ## 스냅샷 기반 빠른 시작과 재개 - MicroVM은 일반적인 콜드 부팅 대신 사전에 초기화된 스냅샷에서 시작한다. - 애플리케이션 프로세스, 설치된 패키지, 메모리 상태 등이 준비된 상태이므로 실행 직후부터 요청을 처리할 수 있다. - 이후 생성되는 MicroVM도 동일한 이미지 스냅샷에서 복원되므로 초기화 시간을 줄일 수 있다. - 대규모 대화형 세션도 사용자 입장에서 즉시 반응하는 수준의 시작·재개 성능을 목표로 한다. ## 상태를 유지하는 세션과 유휴 정책 - 실행 중인 MicroVM은 다음 상태를 세션 동안 유지한다. - 메모리 상태 - 디스크 상태 - 실행 중인 프로세스 - 일정 시간 요청이 없으면 MicroVM을 일시 중지할 수 있다. - 중지 시 메모리와 디스크 상태를 보존하고, 요청이 다시 들어오면 해당 상태에서 자동으로 재개한다. - 예시 설정은 15분 유휴 후 중지하고, 5분 동안 중지 상태를 유지한 뒤 요청이 오면 자동 재개하도록 구성한다. ```bash aws lambda-microvms run-microvm \ --image-identifier arn:aws:lambda:<region>:<acct>:microvm-image:my-image \ --execution-role-arn arn:aws:iam::<acct>:role/MicroVMExecutionRole \ --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}' ``` ## 엔드포인트와 요청 인증 - MicroVM을 실행하면 Lambda가 고유 ID와 전용 엔드포인트 URL을 제공한다. - 별도의 네트워킹 구성을 하지 않아도 애플리케이션에 접근할 수 있다. - CLI로 단기 인증 토큰을 생성한 뒤 HTTPS 요청의 `X-aws-proxy-auth` 헤더에 포함해 요청을 보낸다. - MicroVM이 중지된 뒤 다시 요청해도 애플리케이션 상태가 유지된 채 복원되므로 클라이언트는 중지·재개 과정을 직접 처리할 필요가 없다. ## 실용적인 활용과 추천 Lambda MicroVMs는 단순한 단발성 함수보다 사용자별로 지속되는 안전한 실행 환경이 필요한 서비스에 적합하다. 사용자 코드 실행, AI 에이전트의 도구 호출, 온라인 IDE, 샌드박스형 분석 환경을 구축한다면 컨테이너 직접 격리나 VM 운영을 대체할 수 있는 후보로 검토할 만하다. 다만 실제 도입 전에는 IAM 실행 역할, 인증 토큰 관리, 유휴·재개 정책, 상태 보존 범위와 비용을 서비스의 세션 패턴에 맞게 검증하는 것이 좋다.

aws-cloudwatchpythondockeramazon-s3+3

aws2026년 6월 18일

Amazon ECS, 더 빠른 서비스 자동 조정을 위한 새로운 고해상도 지표 도입 | Amazon Web Services (새 탭에서 열림)

Amazon ECS가 20초 단위 고해상도 CloudWatch 지표를 지원해 서비스 자동 조 scaling 반응 속도를 크게 높였다. AWS 벤치마크에서 스케일 아웃 시작까지의 시간이 363초에서 86초로 76% 단축됐고, 새 태스크 프로비저닝 완료까지도 386초에서 109초로 줄었다. 이를 통해 트래픽 급증에 더 빠르게 대응하면서도 사전 확보 태스크 수와 비용을 줄일 수 있다. ## ECS 서비스 자동 조정 방식 - ECS 서비스 자동 조정은 수요에 맞춰 실행 중인 태스크 수를 자동으로 조절한다. - 지원되는 주요 방식은 다음과 같다. - **예측 조정**: 머신러닝으로 반복적인 트래픽 패턴을 예측해 선제적으로 확장 - **예약 조정**: 계획된 이벤트에 맞춰 사용자가 지정한 일정으로 조정 - **Target Tracking**: CPU, 메모리, 요청 수, 큐 깊이 등 실시간 지표가 목표값을 유지하도록 조정 - 고해상도 지표는 특히 Target Tracking 방식에서 빠른 반응을 제공한다. ## 20초 고해상도 지표의 효과 - 기존 표준 지표는 60초 단위였지만, 새 지표는 20초 간격으로 스케일링 결정을 평가한다. - AWS 테스트 결과: - 스케일 아웃 시작: **363초 → 86초**, 76% 단축 - 태스크 확장 및 프로비저닝 완료: **386초 → 109초**, 72% 단축 - 기대 효과: - 트래픽 급증 시 지연 시간과 장애 가능성 감소 - 급증에 대비한 과도한 기본 태스크 수를 줄여 비용 절감 - 복잡한 Step Scaling 정책 없이 Target Tracking만으로 공격적인 확장 가능 ## 설정 방법 - ECS 서비스 생성 또는 업데이트 시 Monitoring 설정에서 **20초 해상도 지표**를 활성화한다. - Service auto scaling에서 다음을 설정한다. - 자동 조정 활성화 - 정책 유형으로 **Target Tracking** 선택 - 다음 고해상도 지표 중 하나 선택 - `ECSServiceAverageCPUUtilizationHighResolution` - `ECSServiceAverageMemoryUtilizationHighResolution` - 기존 서비스는 먼저 `Update Service`로 고해상도 지표를 활성화하고 배포가 완료된 뒤, 서비스의 자동 조정 정책을 고해상도 지표 기반으로 변경해야 한다. - 콘솔뿐 아니라 AWS SDK, AWS CloudFormation, Application Auto Scaling을 통한 AWS CLI로도 설정할 수 있다. ## 지원 범위와 비용 - AWS Fargate, ECS Managed Instances, Amazon EC2 기반 ECS 서비스에서 사용할 수 있다. - ECS의 고속 자동 조정 기능 자체에는 별도 비용이 없지만, 20초 단위 고해상도 CloudWatch 지표에는 추가 요금이 발생한다. - 표준 60초 지표는 무료이며, 실제 비용은 CloudWatch 요금 정책을 확인해야 한다. 트래픽 변동이 크고 급격한 부하 증가에 민감한 ECS 서비스라면 고해상도 CPU 또는 메모리 지표와 Target Tracking을 함께 사용하는 것이 권장된다. 다만 지표 비용과 실제 확장 효과를 함께 검토해, 모든 서비스에 일괄 적용하기보다는 스케일 아웃 지연이 문제가 되는 워크로드부터 적용하는 것이 적절하다.

aws-cloudwatchamazon-ec2aws-cliamazon-ecs+4