9월 14일의 주는 AWS가 플랫폼 엔지니어링을 제품으로 판 주였다. Elastic Beanstalk Cluster Mode는 애플리케이션 포트폴리오를 공유된 완전 관리형 EKS에 올리고, 새 시작 경험은 신규 빌더에게 빈 계정 대신 미리 구성된 프로젝트를 건넨다. 그 아래에서 컴퓨트는 두 방향으로 싸졌고(T8i 인스턴스, ECS Express Mode의 ARM64), PrivateLink는 네트워크 세그먼트 전체를 공유하기 위한 터널 엔드포인트를 얻었고, 무시하면 모니터링을 조용히 망가뜨릴 ID 변경 두 건이 들어왔다. 마이그레이션 도구 쪽은 이번 주 조용했으므로(AWS Transform이나 DMS에서 나온 것이 없다), 플랫폼 이야기가 앞장선다.

Elastic Beanstalk Cluster Mode: PaaS 논쟁, 다시

9월 17일 AWS Elastic Beanstalk이 Cluster Mode를 선보였다. 여러 애플리케이션이 Amazon EKS로 구동되는 공유 인프라 위에서, 완전 관리형으로, 하나의 운영 기준선을 갖고 돌아간다. Java, .NET, Python, Node.js, PHP, Ruby, Go 소스(또는 Dockerfile, 또는 이미지)를 업로드하면 Beanstalk이 필요할 때 Cloud Native Buildpacks로 컨테이너화하고, 환경은 자동 롤백이 딸린 트래픽 전환 배포, 이벤트 기반 오토스케일링, Secrets Manager 통합, OpenTelemetry 관측성, AI 보조 트러블슈팅을 얻는다. Standard 환경과 Cluster Mode 환경은 같은 애플리케이션 안에 공존하므로, 환경을 하나씩 옮긴다.

애플리케이션당 비용 논리는 모든 내부 플랫폼 팀이 공유 EKS 클러스터 예산을 따내기 위해 펼쳤던 바로 그것이다. 차이는 누가 운영하느냐다. AWS가, 워크로드의 수명 동안, 그리고 당신은 노드도, kubeconfig도, 업그레이드 창도 결코 보지 않는다.

작은 서비스 스무 개가 있고 Kubernetes에 입맛이 없다면 Cluster Mode가 아마 옳은 기본값이다. 이미 EKS를 소유한 플랫폼 팀이 있다면, Cluster Mode는 같은 워크로드를 두고 그들과 경쟁하면서 통제권은 덜 준다. 커스텀 어드미션 정책도, 노드 튜닝도, CNI 선택도 없다. 실패 모드는 공유 플랫폼이 늘 갖는 그것이다. 열아홉 개 애플리케이션에는 맞고 스무 번째에는 틀린 기준선 업그레이드, 다만 이제 스무 번째는 아무것도 고정할 수 없다. 통제권을 잃어도 괜찮을 애플리케이션으로 파일럿하라.

더 싼 컴퓨트, 두 가지 길

9월 17일 EC2 T8i 인스턴스가 정식 출시됐다. 커스텀 6세대 Intel Xeon 6, 6세대 Nitro 카드, 네 가지 크기(nano, micro, small, medium), T3보다 최대 30퍼센트 나은 가격 대비 성능, 최대 70퍼센트 더 많은 컴퓨트, 1.25배의 네트워크 대역폭, 2.4배의 EBS 대역폭. Standard와 Unlimited 모드가 있는 같은 CPU 크레딧 시스템이므로, T3에서의 이동은 인스턴스 타입 변경이고 그 외에는 아무것도 아니다. t8i.micro와 t8i.small은 Free Tier에 들어 있다.

9월 18일 ECS Express Mode가 CPU 아키텍처로 ARM64를 추가했다. "이 이미지에 URL을 달아 줘" 경로가 Graviton에 떨어질 수 있고, AWS는 x86보다 최대 40퍼센트 나은 가격 대비 성능이라고 평가한다. 콘솔, CLI, SDK, IaC를 통해 새 Express Mode 서비스와 기존 서비스 모두에서 구성할 수 있다.

둘 다 누군가 변경을 해야만 돈을 아낀다. 대부분 계정의 T3 플릿은 배스천, 빌드 러너, 잊힌 내부 도구다. Terraform 변수 변경 한 번과 인스턴스 리프레시가 일의 전부다. Express Mode ARM64의 전제 조건은 멀티 아키텍처 이미지이고, 실패 모드는 amd64만 배포하는 베이스 이미지나 네이티브 의존성이다. docker buildx build --platform linux/amd64,linux/arm64로 빌드하고 매니페스트 리스트가 일하게 한 다음, 아키텍처를 바꿔라.

PrivateLink Tunnel Endpoints: 서비스가 아니라 CIDR를 공유한다

9월 18일 AWS PrivateLink가 Tunnel Endpoints를 발표했다. 새 VPC 엔드포인트 타입이다. 이전에는 외부 당사자와 리소스를 공유한다는 것은 리소스당 Resource Configuration 하나를 뜻했다. 이제 Resource Configuration이 당신 네트워크의 CIDR 범위를 나타낼 수 있다. AWS RAM으로 공유하면 상대편이 터널 엔드포인트를 만들고 GENEVE 캡슐화로 그 범위 안의 무엇에든 닿는다. 터널 엔드포인트당 시간 요금에 처리된 데이터의 GB당 요금이 붙는다.

이것은 PrivateLink(서비스 하나, 엔드포인트 하나, 라우팅 노출 없음)와 Transit Gateway 또는 피어링(완전한 라우팅, 양방향, 그리고 CIDR 협상) 사이의 틈을 메운다. 관리 서브넷의 호스트 마흔 대가 필요한 벤더는 예전에는 무거운 옵션을 강요했다. 이제 그들은 당신이 지정한 바로 그 범위로 들어가는 터널을 얻는다.

GB당 요금은 이것을 대량 데이터 경로가 아닌 컨트롤 플레인 경로로 만든다. 누군가 백업을 그쪽으로 라우팅하기 전에 비용을 모델링하라. 그리고 "CIDR 범위"는 "서비스"보다 넓은 허가다. 그 범위 안의 보안 그룹과 NACL 규율이 이제 외부 공격 표면의 일부이므로, 노출하는 범위를 DMZ로 다루고 그에 맞게 크기를 잡아라.

대시보드를 망가뜨리는 두 가지 ID 변경

9월 14일 루트 사용자 로그인이 N. Virginia뿐 아니라 US East (Ohio)와 US West (Oregon)에서도 서비스되기 시작했다. 트래픽은 세 곳에 분산된다. 복원력에는 좋지만, 루트 로그인의 CloudTrail ConsoleLogin 이벤트는 이제 그것을 처리한 어느 리전에서든 기록된다. 루트 로그인 알람이 us-east-1 트레일의 메트릭 필터라면, 이제 루트 로그인의 대략 3분의 1만 잡는다. 이번 주에 조직 트레일로 옮기거나 다른 두 리전을 추가하라.

9월 15일 STS가 세션 토큰 한도를 단일 4,096바이트 한도로 통합했다. 토큰 크기와 전달되는 세션 정책 및 태그에 대한 별도 상한을 대체한다. STS는 이제 토큰 크기와 사용률을 반환하고, CloudTrail에 기록하고, CloudWatch 메트릭을 발행한다. 새 선택 파라미터는 의도적으로 큰 토큰을 발급해서 프록시와 헤더가 그것을 견디는지 테스트할 수 있게 한다. "packed policy too large"에 부딪힌 적이 있다면 이것이 해결책이고, 테스트 파라미터는 세션 태그가 당신을 그 상한으로 밀어 넣기 전에 스택이 그것을 처리한다는 것을 증명한다.

이번 주의 다른 소식

관통하는 맥락

Cluster Mode와 새 빌더 경험은 두 규모로 나온 같은 제품이다. AWS가 기본값을 고르고 그에 따르는 운영 책임을 진다. 비용은 모두를 위해 고른 기본값이 누구에게도 완벽히 맞지 않는다는 것이고, 그것이 물어뜯는 지점(노드 튜닝, 리전이 하나라고 가정한 루트 로그인 알람, 한도가 둘이라고 가정한 세션 토큰)이 바로 이번 주의 작은 출시들이 건드린 지점이다. AWS가 플랫폼을 운영한다고 플랫폼 일이 사라지지는 않는다. 그 일은 물건을 만드는 데서, 그 기본값 중 어느 것이 당신에게 틀렸는지 아는 데로 옮겨 간다.

다음으로 읽을 글

같은 주의 AI와 에이전트 쪽 읽기는 ercan.ai를 보라. 팀에 AWS, 클라우드 아키텍처, CI/CD 파이프라인, Linux, GitHub 또는 GitLab, 그리고 그 주변의 플랫폼 작업에 대한 실무 도움이 필요하다면, 컨설팅은 ercanermis.com에 있다.

참고 자료