대상 기간: 오늘 · 수집 항목: 7건 · 출처: Azure 공식 업데이트 RSS
오늘 Azure 업데이트는 꽤 “실무형 공부거리”가 많습니다. AKS 운영 표준화와 멀티클러스터 관리가 한꺼번에 진전됐고, 네트워크 쪽에서는 IPv6 워크로드가 IPv4 인터넷과 연결되는 NAT64가 GA로 들어왔습니다. 여기에 민감 워크로드를 위한 Azure Enclave 프리뷰까지 나와서, 오늘은 “클라우드 운영 고도화”와 “보안 격리”, “네트워크 현대화”를 한 번에 훑기 좋은 날입니다.
· Gateway API — 기존 Kubernetes Ingress를 넘어, 더 표준화된 L4/L7 트래픽 라우팅 모델을 이해할 때 중요한 키워드
· Kubernetes Fleet Manager — 여러 AKS 클러스터를 일관되게 운영하는 멀티클러스터 관리 개념의 중심
· NAT64 / DNS64 — IPv6 전용 혹은 IPv6 중심 워크로드가 IPv4 대상과 통신할 때 필요한 주소 변환 패턴
· Prepared Image Specification — 노드 기동 시 이미지 pull/초기화 시간을 줄여 대규모 AKS 확장 성능을 개선하는 접근
· Isolated cloud environments — 민감한 업무를 위한 격리된 환경 배포·운영을 단순화하는 보안 아키텍처 관점의 개념
6 items
· AKS에서 Application Routing과 Kubernetes Gateway API가 GA
· Kubernetes 최신 표준을 따라 ingress 라우팅을 구성할 수 있는 방향성 제시
· 기존 배포를 유지하면서도 라우팅 계층 현대화를 검토하는 팀에 의미가 큼
· AKS 운영 시 Ingress 중심 구성에서 Gateway API 기반 설계로 넘어갈 학습 포인트 제공
무엇인가: AKS에서 Gateway API를 활용한 애플리케이션 라우팅 기능이 정식 출시된 것입니다. 기존 Ingress 중심 모델 대비, 더 구조화된 라우팅 리소스와 역할 분리를 통해 Kubernetes 네트워킹 표준화 흐름을 따라갈 수 있습니다.
왜 흥미로운가: 앞으로 AKS를 운영할 때 “단순히 Ingress 하나 둔다”가 아니라, 플랫폼 팀과 앱 팀의 책임을 나누는 네트워크 설계를 고민하게 됩니다. Kubernetes 표준 진화가 실제 Azure 관리 경험에 어떻게 반영되는지 보기 좋은 사례입니다.
해보기: AKS 문서와 함께 Gateway API 리소스(Gateway, HTTPRoute 등) 구조를 먼저 정리하고, 기존 Ingress 구성과 차이를 비교해 보세요.
원문 링크: https://azure.microsoft.com/updates?id=567944
· Azure Kubernetes Fleet Manager의 resource placement가 GA
· 여러 클러스터에 Kubernetes 리소스를 일관되게 배포·동기화하는 데 초점
· 플랫폼 팀과 애플리케이션 팀이 멀티클러스터 운영 부담을 줄일 수 있음
· 수작업 업데이트와 클러스터 간 드리프트(drift) 관리 문제를 줄이는 방향
무엇인가: Fleet Manager에서 여러 Kubernetes 클러스터에 리소스를 배치하고 유지하는 기능이 정식 출시된 것입니다. 멀티클러스터 환경에서 동일한 리소스를 반복 적용하는 운영 패턴을 Azure 차원에서 더 체계화합니다.
왜 흥미로운가: AKS를 한 클러스터만 쓰는 시대보다, 지역별·환경별·업무별로 여러 클러스터를 운영하는 경우가 많아졌습니다. 이 기능을 이해하면 GitOps, 정책 배포, 플랫폼 엔지니어링 관점에서 Azure의 멀티클러스터 전략을 더 잘 읽을 수 있습니다.
해보기: 개발/스테이징용 AKS 클러스터가 여러 개 있다고 가정하고, 어떤 리소스를 공통 배포 대상으로 둘지 네임스페이스·정책·애드온 기준으로 분류해 보세요.
원문 링크: https://azure.microsoft.com/updates?id=567931
· Fleet Manager 업데이트 실행 시 허용 가능한 실패 수(maximum allowed failures) 옵션이 프리뷰
· 기존 fail-fast 방식에서 일부 클러스터 실패가 전체 롤아웃 중단으로 이어지는 문제를 완화
· 대규모 멀티클러스터 업데이트의 점진적 배포 전략을 더 세밀하게 설계 가능
· 운영 안정성과 배포 속도 사이의 균형점을 잡는 데 유용
무엇인가: Fleet Manager의 업데이트 실행 시, 일부 멤버 클러스터에서 실패가 발생해도 전체 업데이트가 무조건 즉시 중단되지 않도록 허용치를 둘 수 있는 기능입니다. 멀티클러스터 롤아웃 제어를 더 현실적인 운영 방식에 가깝게 만듭니다.
왜 흥미로운가: 실무에서는 모든 클러스터가 완벽히 동일한 상태가 아니기 때문에, 소수 실패 때문에 전체 배포가 멈추는 상황이 자주 부담이 됩니다. 이 기능은 “안전한 대규모 배포”를 설계할 때 SRE 관점의 중요한 옵션이 됩니다.
해보기: 현재 팀의 AKS 배포 절차를 기준으로, “몇 개 클러스터 실패까지 허용할 것인가”를 환경별(운영/비운영)로 가정해 롤아웃 정책안을 써보세요.
원문 링크: https://azure.microsoft.com/updates?id=567939
· AKS 대규모·AI·GPU·Windows·성능 민감 워크로드에서 긴 노드 기동 시간을 줄이기 위한 프리뷰
· 새 노드가 반복적으로 컨테이너 이미지를 다운로드하고 초기화하는 비용 문제를 겨냥
· 이미지 사전 준비(prepared image) 방식으로 스케일 아웃 지연을 줄이는 방향
· 급격한 확장이나 워크로드 워밍업이 중요한 환경에서 특히 의미가 있음
무엇인가: AKS에서 노드 시작 시 필요한 이미지와 초기화 작업을 미리 준비해 두는 형태의 사양(Prepared Image Specification) 프리뷰입니다. 노드가 새로 뜰 때마다 동일한 작업을 반복하는 비효율을 줄이려는 기능으로 보입니다.
왜 흥미로운가: GPU 워크로드나 대형 이미지 기반 애플리케이션은 노드 추가 자체보다 “실제로 앱이 올라오기까지”가 더 오래 걸리는 경우가 많습니다. 이 기능은 AKS 성능 튜닝을 단순 오토스케일 설정이 아니라 이미지/초기화 전략까지 확장해서 보게 만듭니다.
해보기: 현재 운영 중이거나 학습용으로 만든 AKS 워크로드에서 가장 큰 이미지와 초기화가 무거운 컨테이너를 골라, 노드 스케일 아웃 시 병목이 어디인지 먼저 기록해 보세요.
원문 링크: https://azure.microsoft.com/updates?id=567949
· StandardV2 NAT Gateway에서 NAT64가 GA
· IPv6 워크로드가 IPv4-only 인터넷 목적지와 통신 가능
· 합성된(synthesized) IPv6 아웃바운드 트래픽을 IPv4로 변환
· DNS64 지원 리졸버에 의존하는 구조
· IPv6 도입 과정에서 레거시 IPv4 외부 대상과의 연결 문제를 완화
무엇인가: Azure StandardV2 NAT Gateway가 NAT64를 지원해, IPv6 기반 워크로드가 IPv4 전용 인터넷 대상과 통신할 수 있게 된 것입니다. NAT64는 보통 DNS64와 함께 동작하며, IPv6 환경에서 IPv4 대상 접속을 이어주는 브리지 역할을 합니다.
왜 흥미로운가: IPv6 전환은 “주소 공간이 넓다”에서 끝나지 않고, 실제 외부 연동성 문제가 핵심입니다. 이 기능을 알면 Azure 네트워크 설계에서 IPv6 채택 시 어떤 현실적인 연결 전략을 가져갈지 훨씬 구체적으로 생각할 수 있습니다.
해보기: NAT64와 DNS64가 어떤 흐름으로 동작하는지 패킷 흐름도를 직접 그려 보고, 현재 사용하는 Azure 네트워크 구성에서 IPv6 워크로드가 붙을 지점을 상상해 보세요.
원문 링크: https://azure.microsoft.com/updates?id=568409
· Azure, Azure Government, Azure Government Secret, Azure Government Top Secret에서 퍼블릭 프리뷰 발표
· 민감한 워크로드를 위한 격리된 클라우드 환경의 배포와 관리를 단순화하는 데 초점
· 보안과 격리 요구가 높은 업무를 위한 아키텍처 옵션으로 제시
· 상용 및 정부 클라우드 맥락 모두에서 언급됨
무엇인가: Azure Enclave는 민감한 작업을 위한 isolated cloud environments의 배포·관리를 간소화하려는 Azure 기능입니다. 제공 설명상, 높은 보안·격리 수준이 필요한 환경을 더 손쉽게 운영하도록 돕는 방향의 프리뷰입니다.
왜 흥미로운가: 보안 아키텍처를 공부할 때 “공용 클라우드냐 아니냐”를 넘어서, 같은 Azure 안에서도 얼마나 격리된 실행·운영 환경을 설계할 수 있는지가 중요해집니다. 특히 규제 산업, 공공, 민감 데이터 처리 업무를 맡는 엔지니어라면 눈여겨볼 만합니다.
해보기: 현재 다루는 워크로드 중 격리 수준 요구가 높은 사례를 하나 골라, 일반 Azure 환경과 별도로 어떤 네트워크·접근제어·운영 경계가 필요할지 설계 메모를 작성해 보세요.
원문 링크: https://azure.microsoft.com/updates?id=568377
1 item
· Azure 인도 지역에 네 번째 데이터센터 리전인 India South Central 오픈
· Hyderabad, Telangana 캠퍼스 기반으로 제공
· 로컬·보안·AI readiness를 강조
· 지역 선택, 데이터 레지던시, 지연 시간 설계 측면에서 의미 있는 업데이트
무엇인가: Azure가 인도에 새 클라우드 리전 India South Central을 추가한 발표입니다. 인프라 관점에서는 단순 리전 확대가 아니라, 지역별 배포 전략과 데이터 상주성 선택지가 늘어난 변화입니다.
왜 흥미로운가: 리전 추가는 서비스 목록보다 아키텍처 선택지에 직접 영향을 줍니다. 글로벌 서비스를 설계할 때 재해 복구, 사용자 지연 시간, 규제 대응, AI 워크로드 배치 전략까지 함께 생각해 볼 수 있습니다.
해보기: Azure 글로벌 리전 맵을 보면서, 인도 사용자 대상 서비스를 만든다고 가정하고 Primary/DR 리전을 어떻게 둘지 간단한 배치안을 그려보세요.
원문 링크: https://azure.microsoft.com/updates?id=568013
오늘 제공된 목록에는 서비스 종료(retirement) 항목이 없습니다.