에디.이이

HTTP 에러코드 - 500번대와 1000번대

에디.이이 — Mon, 5 Jan 2026 20:05:28 +0900

현재 전 세계 인터넷 트래픽의 상당 부분은 Cloudflare를 경유해 전달되고 있습니다.

알려진바에 따르면, 체 웹서비스의 약 20% 이상이 Cloudflare의 보호 아래 있는 것으로 조사 결과 확인됩니다.

https://www.netcraft.com/blog/november-2025-web-server-survey

많은 웹서비스가 보안 강화와 성능 최적화를 목적으로 Cloudflare를 사용하고 있으며,

사용자가 웹사이트에 접속할 때 요청은 원본 서버로 바로 전달되지 않고

Cloudflare의 글로벌 엣지 네트워크를 먼저 통과하게 됩니다.

이 과정에서 Cloudflare는 요청을 프록시 처리하고, 보안 규칙을 적용하며,

캐시 여부를 판단한 뒤 원본 서버로 요청을 전달합니다.

이러한 구조에서는 장애가 발생했을 때 요청 처리 과정 중 어느 지점에서 문제가 발생했는지를 구분하는 것이 특히 중요합니다. Cloudflare 환경에서 사용자가 자주 접하는 에러는 크게 HTTP 500번대 에러와 Cloudflare 1000번대 에러로 나눌 수 있으며,

이 둘은 발생 위치와 원인, 그리고 대응 방식이 명확히 다릅니다.

먼저 HTTP 500번대 에러는 서버가 요청을 정상적으로 처리하지 못했음을 의미합니다.

Cloudflare를 사용하는 환경에서도 기본적인 의미는 동일하지만,

Cloudflare가 원본 서버와 통신하는 과정에서 상태를 판단해 반환하는 52x 계열 에러가 함께 나타난다는 점이 특징입니다.

에러코드	에러내용	설명
500	Internal Server Error	원본 애플리케이션 오류
502	Bad Gateway	원본 서버의 비정상 응답
503	Service Unavailable	서버 과부하, 유지보수
504	Gateway Timeout	원본 서버의 응답 타임아웃
520	Web Server Returned an Unknown Error	Cloudflare가 원본 응답을 정상적으로 해석하지 못함
521	Web Server Is Down	원본 서버가 연결을 거부함
522	Connection Timed Out	Cloudflare–원본 간 연결 시간 초과
523	Origin Is Unreachable	원본 네트워크 접근 불가
524	A Timeout Occurred	TCP 연결은 성공했으나 HTTP 응답 지연
525	SSL Handshake Failed	Cloudflare–원본 SSL 핸드셰이크 실패
526	Invalid SSL Certificate	원본 SSL 인증서 오류
530		원본 hostname에 대한 조회 불가

500번대 에러는 기본적으로 HTTP 프로토콜 차원에서 정의된 상태 코드이지만,

Cloudflare 환경에서는 위와 같이 Cloudflare가 원본과의 연결 상태나 응답 특성을 반영해 직접 반환하는 코드도 포함됩니다.

이 경우에도 문제의 근본 원인은 대부분 원본 서버 설정이나 상태에 있는 경우가 많습니다.

다음으로 Cloudflare 1000번대 에러는 성격이 다릅니다.

1000번대 에러는 HTTP 표준 상태 코드가 아니며, Cloudflare가 자체적으로 생성해 사용하는 전용 에러 식별자입니다.

이 숫자는 주로 Cloudflare 에러 페이지의 본문에 표시되며,

실제 HTTP 응답 상태 코드는 403, 429, 503 등으로 별도 전달되는 구조를 가집니다.

에러코드	에러내용	설명
1000	DNS points to prohibited IP	DNS가 Cloudflare에서 허용되지 않은 IP를 가리킴
1001	DNS resolution error	DNS 조회(해석)에 실패함
1002	DNS points to Prohibited IP	DNS가 금지된 IP 주소를 가리킴
1002	Restricted	접근이 제한된 리소스임
1003	Access Denied: Direct IP Access Not Allowed	도메인 없이 IP로 직접 접근이 차단됨
1004	Host Not Configured to Serve Web Traffic	해당 호스트가 웹 트래픽을 제공하도록 설정되지 않음
1005	Access Denied: Autonomous System Number (ASN) banned	특정 ASN(네트워크 사업자)이 차단됨
1006	Access Denied: Your IP address has been banned	IP 주소가 차단됨
1007	Access Denied: Your IP address has been banned	IP 주소가 차단됨
1008	Access Denied: Your IP address has been banned	IP 주소가 차단됨
1009	Access Denied: Country or region banned	국가 또는 지역 단위로 접근이 차단됨
1010	The owner of this website has banned your access based on your browser's signature	브라우저(User-Agent) 기준으로 차단됨
1011	Access Denied (Hotlinking Denied)	핫링크 방지 설정으로 접근 차단
1012	Access Denied	일반적인 접근 거부
1013	HTTP hostname and TLS SNI hostname mismatch	HTTP Host 헤더와 TLS SNI 호스트명이 일치하지 않음
1014	CNAME Cross-User Banned	다른 Cloudflare 계정의 CNAME 사용이 차단됨
1015	You are being rate limited	요청이 너무 많아 속도 제한에 걸림
1016	Origin DNS error	원본 서버의 DNS 설정에 오류가 있음
1018	Could not find host	호스트를 찾을 수 없음
1019	Compute server error	Cloudflare Compute 서버 내부 오류
1020	Access denied	방화벽 규칙에 의해 접근 차단됨
1023	Could not find host	호스트를 찾을 수 없음
1025	Please check back later	서버가 일시적으로 요청을 처리할 수 없음
1033	Argo Tunnel error	Argo Tunnel(Cloudflare Tunnel) 관련 오류
1034	Edge IP Restricted	특정 Cloudflare 엣지 IP 접근이 제한됨
1035	Invalid request rewrite (invalid URI path)	요청 재작성 규칙의 URI 경로가 잘못됨
1036	Invalid request rewrite (maximum length exceeded)	재작성된 요청이 길이 제한을 초과함
1037	Invalid rewrite rule (failed to evaluate expression)	재작성 규칙 표현식 평가 실패
1040	Invalid request rewrite (header modification not allowed)	허용되지 않은 헤더 수정 시도
1041	Invalid request rewrite (invalid header value)	잘못된 헤더 값으로 재작성 실패
1101	Rendering error	Cloudflare 렌더링 중 오류 발생
1102	Rendering error	Cloudflare 렌더링 중 오류 발생
1104	A variation of this email address is already taken in our system. Only one variation is allowed.	이메일 주소 변형이 이미 사용 중임
1106	Access Denied: Your IP address has been banned	IP 주소가 차단됨
1200	Cache connection limit	캐시 연결 수 제한에 도달함

1000번대 에러는 Cloudflare 프록시(엣지) 및 보안·DNS 처리 영역에서 발생하며,

주로 보안 정책이나 설정에 의해 요청이 차단되었을 때 표시됩니다.

이 때문에 화면에는 1020과 같은 숫자가 보이지만,

개발자 도구에서는 HTTP 403이나 429 상태 코드가 함께 보이는 경우도 있습니다.

이 점은 HTTP 5xx 상태 코드만 보고 문제를 추적할 때와의 중요한 차이점입니다.

또한, 각 에러페이지를 보면 Ray ID라는 값이 함께 표시되고 있습니다.

Ray ID는 Cloudflare를 통과한 모든 요청에 대해 생성되는 고유한 식별자입니다.

이 값은 해시된 영숫자 문자열과 세 글자의 데이터 센터 코드로 구성되며,

요청을 처리한 Cloudflare 엣지 데이터 센터 정보를 함께 담고 있습니다.

또한 Ray ID는 HTTP 응답 헤더의 CF-Ray 항목을 통해 원본 서버로도 전달됩니다.

원본 서버 로그에 CF-Ray 값을 함께 기록해 두면,

Cloudflare 대시보드의 보안 이벤트와 서버 로그를 하나의 요청 단위로 정확히 매칭할 수 있습니다.

이를 통해 문제가 Cloudflare 단계에서 발생했는지, 아니면 원본 서버 단계에서 발생했는지를 빠르게 구분할 수 있으며,

장애 분석 시 문제의 범위를 효율적으로 좁힐 수 있습니다.

정리하면 Cloudflare 환경에서 에러를 분석할 때는 다음과 같은 기준이 도움이 됩니다.

- 500번대 에러 : 대부분 원본 서버 문제 (Cloudflare 52x 계열 포함)

- 1000번대 에러 : 주로 Cloudflare 보안·정책·설정 문제

- Ray ID : 문제의 위치와 책임 주체를 구분하는 핵심 열쇠

이 차이를 이해하고 접근하는 것만으로도

Cloudflare를 사용하는 환경에서 장애 대응의 우선순위와 책임 범위를 훨씬 빠르고 정확하게 판단할 수 있습니다.

참고1. Cloudflare 5xx errors

참고2. Cloudflare 1xxx errors

스타링크의 DNS는 Cloudflare입니다.

에디.이이 — Sun, 4 Jan 2026 17:57:11 +0900

지난달 스타링크(Starlink)가 국내에서 공식 서비스를 시작했습니다.

이제 항공기나 선박처럼 네트워크 연결이 제약적인 환경에서도 위성을 통해 인터넷을 사용할 수 있게 되었습니다.

일반 주거용 사용자 기준으로 월 8만 7천원에 무제한 데이터를 이용할 수 있으며,

최대 다운로드 135Mbps, 업로드 40Mbps의 속도를 제공합니다.

유선이나 지상 통신이 아닌 위성 인터넷이라는 점을 고려하면 꽤 인상적인 수치입니다.

다만, 서비스 이용을 위해서는 'Starlink Standard 키트' 장비 비용이 55만원 추가로 발생합니다.

이 스탠다드 키트는 크게 두 가지로 구성되어 있습니다.

- 위성과 직접 통신하는 안테나

- 내부 네트워크에 인터넷을 제공하는 라우터(Wi-Fi 공유기)

안테나는 위성과 통신이 원활하도록 시야가 트인 외부 공간에 설치해야 하며,

라우터는 실내 중심부에 설치해 Wi-Fi의 커버리지를 최대한 확보하는 것이 좋습니다.

스타링크에서 제공하는 공유기에는 몇 가지 유용한 기능이 포함되어 있는데,

그 중 하나가 컨텐츠 필터링 기능입니다.

현재 제공되고 있는 기본 필터링 옵션은 총 3가지 입니다.

- NO FILTERING: 모든 웹사이트에 접근 가능

- MALWARE: 악성코드가 포함되어 있을 가능성이 있는 웹사이트 차단

- MALWARE AND ADULT CONTENT : 악성코드 및 성인용 컨텐츠 웹사이트를 모두 차단.

라우터에서 컨텐츠 필터링 기능을 활성화하기만 하면

별도의 프로그램 설치 없이도 기본적인 유해 사이트 차단이 가능하기 때문에,

인터넷에 익숙하지 않은 가족이나 여러 사용자가 함께 사용하는 환경에서는 꽤 유용한 기능으로 보입니다.

하지만 공유기 단독으로 빠르게 진화하는 맬웨어나 방대한 성인용 컨텐츠를

실시간으로 모두 차단하기에는 한계가 있습니다.

그래서 스타링크는 공식적으로 Cloudflare의 DNS 서비스를 기반으로 해당 기능을 제공하고 있다고 안내하고 있습니다.

Cloudflare에서 제공하는 DNS는 스타링크에서 제시한 것처럼, 주소에 따라 기능이 분리되어 있습니다.

- 기본 DNS : 1.1.1.1, 1.0.0.1

- 맬웨어 차단 DNS : 1.1.1.2, 1.0.0.2

- 맬웨어 및 성인용 컨텐츠 차단 DNS : 1.1.1.3, 1.0.0.3

스타링크 라우터에서는 이 DNS들을 활용해

사용자가 Wi-Fi로 접속할 때 DHCP를 통해 IP 주소와 함께 Cloudflare DNS 정보를 자동으로 할당하는 방식으로

컨텐츠 필터링을 구현합니다.

메인 DNS	보조 DNS	제공자	특징	평균 ping latency
1.1.1.1	1.0.0.1	Cloudflare		약 2ms
1.1.1.2	1.0.0.2	Cloudflare	맬웨어 차단	약 3ms
1.1.1.3	1.0.0.3	Cloudflare	맬웨어/성인물 차단	약 3ms
8.8.8.8	8.8.4.4	Google		약 33ms
168.126.63.1	168.126.63.2	KT		약 2ms

※ 평균 Latency는 서울에서 SKB망 기준으로 단순 ping 테스트를 통해 측정한 값이며, 측정 환경에 따라 달라질 수 있습니다.

Cloudflare의 DNS는 더 나은 인터넷을 위해 누구나 자유롭게 사용할 수 있도록 공개되어 있습니다.

구글 DNS(8.8.8.8)이나 KT의 DNS(168.126.63.1)와 마찬가지로 별도의 비용이나 가입 절차 없이 사용할 수 있습니다.

특히 Cloudflare DNS는 보안과 프라이버시 측면에서도 장점이 있습니다.

- DNS 주소만으로 맬웨어 및 성인용 컨텐츠 차단 가능

- 사용자 접속 데이터를 광고 목적으로 활용하지 않음

즉, DNS 설정만 변경해도 인터넷을 더 안전하게 사용할 수 있으며,

스타링크에서 제공하는 컨텐츠 필터링 수준의 기능을 누구나 동일하게 활용할 수 있습니다.

가정에서는 공유기의 DHCP 서버에서 DNS 주소를 1.1.1.2 또는 1.1.1.3으로 변경하면 되고,
외부 환경에서는 PC나 모바일 기기의 DNS 설정만 바꿔주면 됩니다.

2026년에는 더 쉬운 주소를 가진 DNS(1.1.1.1)와 함께 더 깨끗하고, 더 안전한 인터넷을 만들었으면 좋겠습니다.

VMware Cloud 외장 스토리지 옵션과 AVS vLSR 업데이트

에디.이이 — Thu, 20 Nov 2025 16:27:18 +0900

VMware Cloud는 대부분의 글로벌 CSP에서 제공하고 있으며,

각 CSP는 NVMe SSD 기반 베어메탈 인스턴스를 활용해 vSAN을 기본 스토리지로 제공합니다.

(단, OCVS는 모델에 따라 선택적입니다.)

하지만 vSAN은 대표적인 HCI(Hyper-Converged Infrastructure) 기반 스토리지 서비스로,

스토리지와 컴퓨팅 자원이 함께 확장되기 때문에 특정 자원만 독립적으로 늘리기 어렵다는 한계가 있습니다.

- 컴퓨팅(CPU/MEM) 자원이 부족한경우 : Host를 추가하여 Scale-out 확장

- 디스크만 부족할 경우 : 역시 Host를 추가하여 전체 물리 용량 확장

이 때문에 컴퓨팅은 충분하지만, 스토리지가 매우 많이 필요한 경우,

또는 반대로 스토리지는 적지만 컴퓨팅만 필요한 경우 효율적인 확장에 제약이 발생합니다.

이 문제를 해결하기 위해 CSP들은 외장 스토리지를 VMware Cloud와 연동할 수 있는 옵션을 제공합니다.

일반적으로 스토리지는 Block, File, Object로 구분되며,

클라우드에서는 기존 온프레미스처럼 FC 기반 SAN은 제공하지 않기 때문에

Block은 iSCSI로, File은 NFS 기반으로 서비스됩니다.

아래 표는 각 CSP가 VMware Cloud에 제공하는 관리형 Block/File 스토리지 서비스와

3rd Party 스토리지를 통한 직접 연결(iSCSI/NFS) 방식을 정리한 것입니다.

CSP	Service	기본 스토리지	Block (CSP 제공)	Flie (CSP 제공)	iSCSI (3rd party)	NFS (3rd party)
AWS (VMware)	VMC	vSAN		VMware Cloud Flex Storage	Amazon FSx for NetApp ONTAP	Amazon FSx for NetApp ONTAP
AWS	EVS	vSAN			① Amazon FSx for NetApp ONTAP ② Pure Cloud Block Store	Amazon FSx for NetApp ONTAP
Azure	AVS	vSAN	Azure Elastic SAN		Pure Cloud Block Store	Azure NetApp Files
GCP	GCVE	vSAN	OCI Block Storage	OCI File Storage service
OCI	OCVS	vSAN 또는 OCI Block Storage		FileStore		① Google Cloud NetApp Volumes NFS ② Dell PowerScale

※ OCVS는 Shape에 따라 다르게 동작하며,

Standard는 기본 스토리지가 OCI Block Storage이고, DenseIO는 vSAN을 기본으로 사용합니다.

외장 스토리지를 사용할 때 주의해야 할 사항 중 하나는

vLSR(VMware Live Site Recovery, 구 SRM)에서 외장 스토리지를 타겟 스토리지로 사용할 수 없다는 것입니다.

OCVS의 경우 Root 권한이 있어 강제로 지정하는 것이 가능하지만, Broadcom 에서 검증하거나 권장하는 방식은 아닙니다.

그런데 이번 달부터 AVS의 외장 스토리지를 vLSR의 타겟 스토리지로 사용할 수 있다는 공지가 발표되었습니다.

이를 활용하면, DR 구성 시 최소한의 host만 유지하면서 대규모 DR 영역을 Pilot light 형태로 구성하는 것이 가능해 집니다.

참고. What's new in Azure VMware Solution

이번 AVS의 업데이트로 외장 스토리지를 vLSR의 타겟 스토리지로 사용할 수 있게 된 점은

아키텍처 측면에서 상당히 중요한 변화입니다.

기존에는 DR 구성을 위해 스토리지 용량을 확보해야 할 때,

필요한 용량과 관계없이 Host를 추가로 구성해야 하는 비효율이 존재했습니다.

그러나 이제는 외장 스토리지를 활용해 필요한 스토리지 용량만 별도로 확장할 수 있기 때문에,

DR 환경에서 컴퓨팅과 스토리지의 종속성을 크게 줄일 수 있습니다.

이를 통해 최소한의 Host만 유지하면서도 대규모 보호 대상 워크로드를 Pilot Light 형태로 확보할 수 있으며,

DR 사이트 운영 비용을 크게 절감할 수 있는 구조가 가능합니다.

즉, 외장 스토리지를 vLSR 타겟으로 활용할 수 있게 되면서 DR 설계 시 선택의 폭이 넓어졌고,

VMware Cloud 기반 DR 아키텍처의 유연성이 한층 강화되었다고 볼 수 있습니다.

HCX DR 기능은 2027년 10월까지 사용이 가능합니다.

에디.이이 — Mon, 27 Oct 2025 17:16:08 +0900

HCX는 VMware Cloud 환경에서 사용할 수 있는 가장 간편하고 경제적인 DR(Disaster Recovery) 솔루션입니다.
대부분의 VMware Cloud 서비스에서 HCX가 기본으로 포함되어 제공되기 때문에,

별도의 라이선스 비용 없이 손쉽게 사용할 수 있습니다.

물론 SRM(Site Recovery Manager)처럼 고도화된 자동화나 복구 훈련 기능을 제공하지는 않습니다.
하지만 VM 복제 및 복구라는 본연의 역할에 충실하며,

HCX의 버전(Advanced/Enterprise)에 관계없이 모든 에디션에서 Disaster Protection 기능을 사용할 수 있습니다.

최근 Broadcom의 정책에 따라 VCF(VMware Cloud Foundation) 가 v9 버전으로 업그레이드되면서,

HCX도 함께 v9로 전환되었습니다.

이에 따라 기존 VCF v5 환경에서 사용되던 HCX v4 버전도 업그레이드가 필요한 상황이 되었습니다.
다만, 현재 시점에서는 VCF v9를 기반으로 운영되는 VMware Cloud 서비스가 아직 출시되지 않았기 때문에,
기존 환경에서는 여전히 HCX를 통한 DR 구성이 가능합니다.

그러나, 작년 말 공개된 HCX 4.11 Release Note에서는

향후 버전에서 Disaster Recovery 기능이 제거될 예정임이 명시되어 있었습니다.

이로 인해 HCX의 Disaster Recovery 기능의 도입이 중단되었고, 향후 불확실성은 커졌습니다.

이로 인해 향후 DR 기능 유지에 대한 우려가 있었지만,
최근 공개된 HCX 4.11.3 Release Note에서

기술지원이 2027년 10월 11일까지 연장된다고 공지되면서 이러한 불확실성이 해소되었습니다.

즉, HCX v9에서는 DR 기능이 더 이상 지원되지 않지만,
현재 사용 중인 HCX v4.11.3 버전은 2027년 10월 11일까지 공식 지원을 받을 수 있습니다.
따라서 VCF 업그레이드를 진행하지 않는 기존 환경이라면,

2027년 10월 11일까지는 HCX DR 기능을 안정적으로 사용할 수 있게 된 셈입니다.

참고로, HCX 4.11.x 릴리스 전체가 현재 유지보수 모드(Maintenance Mode) 로 전환되었습니다.
따라서 새로운 기능 추가나 구조 변경은 없으며, 버그 수정과 보안 업데이트만 제공됩니다.
그럼에도 불구하고, Disaster Recovery 기능은 기존과 동일하게 계속 지원되므로,
현재 환경에서는 비용 효율적인 DR 구성을 유지할 수 있습니다.

참고1. VMware HCX 4.11 Release Notes : Disaster Recovery 추후 종료 공지

참고2. VMware HCX 4.11.3 Release Notes : 2027년 10월 11일까지 Support 연장 공지

라이센스 포함 AVS, 2025년 10월 15일까지만 가능합니다.

에디.이이 — Wed, 1 Oct 2025 16:32:40 +0900

새로운 Broadcom의 회계년도(2025년 11월)부터

모든 하이퍼스케일러 플랫폼에서 VMware Cloud Foundation(VCF)에 대해 별도의 구독이 필요합니다.

그동안은 CSP가 하드웨어(HW)와 소프트웨어(SW)를 함께 제공하던 통합 모델이였지만,

앞으로는 CSP가 HW를, Broadom에서 SW(VCF)를 제공하는 분리 모델로 전환되는 것입니다.

Azure의 AVS에서는 그동안 라이센스 포함 모델과 BYOL(Bring Your Own License) 모델을 모두 지원해왔습니다.

이번 Broadcom의 정책 변화에 따라, 2025년 10월 15일까지는 라이센스 포함 모델을 주문할 수 있고,

10월 16일부터는 Broadcom을 통해 별도로 구매한 VCF 구독만 사용할 수 있음을 공지하였습니다.

새로운 변화는 라이센스에 정책에만 적용되는 것으로 AVS 자체의 운영방식이나 기능에는 전혀 변화가 없습니다.

즉, VMware 라이센스는 Broadcom에서 구매하지만, VCF의 패치, 관리, 업데이트 등은 여전히 Azure가 담당합니다.

- 2025년 10월 15일 : VCF 구독이 포함된 AVS 판매가 종료됩니다.

- 2025년 10월 16일 이후 : 신규 노드 구매시 Broadcom을 통해 구매한 VCF 구독을 제공해야 합니다.

- 2026년 10월 31일 : PayGo 노드의 마지막 가능일로, 해당 일정 전에 VCF 구독으로 전환해야 합니다.

다만, 2025년 10월 15일 이전에 Reserved Instance(RI)를 구매하였을 경우에는 계약 기간동안 그대로 구독을 유지할 수 있으며, ,

RI가 종료된 이후에는 Broadcom으로부터 라이센스 별도로 구매해야 합니다.

또한 라이센스가 포함된 PayGo 노드를 사용중이라면, 1년 뒤인 2026년 10월 31일까지 그대로 운영할 수 있습니다.

결론적으로 AVS 고객은 2025년 10월 15일 이전에 필요한 노드를 확보하거나 RI 계약을 체결하는 것이 유리해 보이며,

이후부터는 Broadcom에서 별도의 VCF 구독을 구매해 BYOL 방식으로 운영해야 합니다.

참고. Broadcom VMware Licensing Changes: What Azure VMware Solution Customers Need to Know

Elastic VMware Service(EVS) - III. EVS 배포

에디.이이 — Fri, 19 Sep 2025 21:55:32 +0900

2025년 9월 18일 진행된 AWS Innovate: Migrate and Modernize에서 발표된

'VMware 워크로드를 클라우드로, 가장 스마트한 마이그레이션의 시작 - Amazon EVS' 를 정리합니다.

참고로, 발표 내용 중 일부를 흐름에 맞추어 변경하였습니다.

I. EVS 소개

II. EVS 구성 요소

III. EVS 배포 (현재글)

EVS를 배포하기 위해서는 사전에 AWS 환경 및 배포 환경에 대한 정의가 필요합니다.

먼저, 전체적인 관점에서 네트워크에 대한 설계가 필요합니다.

EVS가 VPC 내에 존재하게 되는 만큼 전체적인 네트워크 구성과 함께 어울리는 설계가 필요합니다.

또한, 필요한 Host 수량과 VMware 라이센스 정보를 미리확인하여, 보유한 라이센스 수량이 적합한지 등 확인하는 것이 좋습니다.

두번째로, VPC 환경을 구성합니다.

AWS 콘솔에서 VPC 환경을 구성하며, VPC Route Server를 구성하여 NSX Edge와 연결 준비를 합니다.

NSX Edge는 2대가 이중화로 구성됨으로 VCF 클러스터별로 2개의 Endpoint를 준비해야 합니다.

이제 본격적으로 AWS 콘솔을 통해 VCF 환경의 EVS를 배포하며, 전체 배포 과정은 약 3~4시간정도가 소요됩니다.

물론 초기 기본적인 설정 값들을 정의해주면 자동으로 진행되는 과정임으로 직접 수행해야할 작업은 없습니다.

배포가 완료된 이후 VM 환경을 구성해야 합니다.

이제 vCenter에 접근이 가능함으로 관련 접근을 통해 새로운 VM을 생성하거나,

NSX manager을 통해 오버레이 네트워크를 구성하여 외부와 연결을 구성합니다.

EVS를 배포하기 위해, 먼저 AWS 관리 콘솔에서 EVS 랜딩페이지에 접근하면 EVS 소개에 대한 시작화면을 만나게 됩니다.

배포를 위해 오른쪽 상단의 Get started를 선택하여, overview 로 넘어갑니다.

그럼 EVS의 overview 화면으로 넘어갑니다.

위쪽부터 EVS 배포를 위한 전체 단계가 소개되어 있으며, 주요하게 확인해야 할 사항들은 위쪽에 위치하고 있습니다.

1. AWS account requirements check

- 배포 계정이 AWS support plan의 Business 이상으로 등록되어 있어야 합니다.

- host-count-per-environment : 해당 region에 배포 가능한 충분한 Host가 있는지 확인합니다.

혹시나 부족으로 표기되는 경우 한도 증가를 요청할 수 있습니다.

2. VCF licenses & version requirement

- EVS를 배포하기 위해서는 계획된 host만큼의 유효한 VCF와 vSAN의 구독을 보유하고 있어야 합니다.

- 현재 VCF는 버전 5.2.1로만 배포가 가능함으로, 사용하려는 다른 APP들과의 호환성을 확인해야 합니다.

3. Complete prerequisites

- AWS : EVS가 위치할 VPC나 서브넷, Route server 구성 등 필요환경을 미리 구성하고 해당 정보를 제공해야 합니다.

- VMware : VCF에서 사용할 항목별 VLAN 등 underlay 구성과 관련된 계획을 미리 작성하고 역시 해당 정보를 제공해야 합니다.

4. Key Pairs

- 배포된 host 접근시 사용될 SSH Key pair가 필요합니다.

- Network and Security 항목에서 key pairs를 미리 생성해 두어야 합니다.

준비가 완료되었으면 실제 배포를 위해 왼쪽 메뉴 중에 Environments로 넘어갑니다.

오른쪽 위에 'Create environment'를 선택하여 실제 배포를 시작합니다.

실제 배포의 첫번째 단계로 기본 요구사항에 대한 검증이 필요합니다.

앞서 Overview에서 확인하였던 AWS account requirements check 외에도 필요한 사항들이 있습니다.

대부분 Broadcom으로부터 해당 정보를 확인 받아 입력해야 합니다.

- Name : 전체 환경에 대한 이름을 명명합니다.

- VCF version : 배포할 버전을 선택하며, 아직까지는 5.2.1만 선택 가능합니다.

- Site ID : Broadcom에서 제공하는 사용자에 대한 고유 ID를 입력합니다.

- VCF Solution key : Broadcom으로부터 발급받은 유효한 key를 입력합니다.

- vSAN license key : Broadcom으로부터 발급받은 유효한 key를 입력합니다.

입력이 완료되었으면, VCF license terms에 대한 확인 후 Next를 선택해 다음단계를 진행합니다.

다음 단계는 EVS에서 사용될 기반 Host를 배포하는 단계입니다.

이 작업은 EC2 인스턴스 단위로 진행되기 때문에, 배포하고자 하는 수량만큼 반복되어야 합니다.

시작을 위해 오른쪽 위의 'Add host details'를 선택합니다.

팝업이 뜨면, 추가하려는 Host의 세부사항을 입력합니다.

- DNS hostname : host의 이름을 입력합니다.

- Instance type : 현재는 i4i.metal만 유효하기 때문에 추가적인 선택은 없습니다.

- SSH Key pair : host 접근시 사용될 SSH Key pair를 선택합니다.

Network and Security 항목에서 key pairs를 미리 생성해 두는 것이 좋습니다.

하단의 Advanced options에서는 추가적인 옵션을 입력할 수 있습니다.

- Dedicated Host ID : Shared Tenancy와 Dedicated Host를 선택할 수 있습니다.

Dedicated Host의 경우 Windows License의 BYOL를 위해 전용 host가 필요한 경우에 사용합니다.

- Placement group ID : 아키텍처나 레이턴시 복원력 관점에서 EC2에서 설정한 Placement Group의 ID를 선택합니다.

선택된 그룹의 룰에 따라 동일한 물리적 랙 내에 배치하거나, 다른 랙에 Host를 배치할 수 있습니다.

모든 설정이 완료되면 오른쪽 아래 'Add host details'를 선택하여 host 추가를 완료합니다.

이 작업이 배포를 희망하는 Host 수만큼 반복되어야 합니다.

원하는 수량의 Host를 추가하고 나면, 전체 Host에 대한 요약을 확인할 수 있습니다.

설정한 값이 맞는지 확인한 후 오른쪽 아래 'Next'를 선택하여 다음단계로 넘어갑니다.

이제 네트워크와 관련된 많은 값들을 입력해야 합니다.

초기 설계시 해당 네트워크에 대한 정의를 해두는 것이 좋습니다.

1. Network Setting

- VPC : EVS가 위치할 VPC입니다.

- Service access subnet :

EVS의 물리적 환경과 VCF 소프트웨어 간 연결에 사용됩니다.

배포가 완료된 이후에 Health Check등을 위해 SDDC manager와 개별 host간의 연결이 계속적으로 필요합니다.

- Service access security group : EVS의 관리망에 적용될 security group입니다.

2. VCF Connectivity : 실제 EVS가 사용할 네트워크의 IP 대역을 정의합니다. 최초 생성단계에서만 입력할 수 있으며, 배포가 완료된 이후에는 수정될 수 없습니다. 따라서 사전에 IP 관련 계획을 수립하여 충돌이나 변경없는 네트워크의 입력이 필요합니다.

1) Management Connectivity

- Host VMkernel management VLAN CIDR block

- vMotion VLAN CIDR block

- vSAN VLAN CIDR block

- VTEP VLAN CIDR block

- Edge VTEP VLAN CIDR block

- Management VM VLAN CIDR block

- HCX uplink VLAN CIDR block

2) Workload Connectivity

- NSX uplink VLAN CIDR block : NSX Edge의 업링크에 사용되는 VLAN

- private route server peerings

NSX의 오버레이 네트워크와 VPC 네트워크간 라우팅을 위해 미리 생성해 둔 route server의 endpoint 2를 선택합니다. NSX Edge와 Router server 사이에서는 BGP 프로토콜을 통해 서로간의 네트워크를 학습합니다..

3) Expansion VLANs : 향후 확장(NSX federation, VCF 추가 기능 등)을 고려하여 미리 예약해두는 대역

- Expansion VLAN 1 CIDR block

- Expansion VLAN 2 CIDR block

이제 관리를 위해 기본 구성되는 VCF 구성요소들에 대한 DNS 이름을 정의하는 단계입니다.

- vCenter

- NSX: NSX manager용 VIP

- SDDC Manager

- Cloud Builder

- NSX Edge 1

- NSX Edge 2

- NSX manager 1

- NSX manager 2

- NSX manager 3

이후 vCenter, SDDC manager, NSX manager에 대한 접속용 key를 정의해야 합니다.

기본적으로는 AWS에서 관리되는 키 관리 서비스를 사용할 수도 있고,

직접 관리하거나 원하는 3rd party의 키 관리 서비스를 사용할수도 있습니다.

환경에 따라 tag를 통해 관리가 되고 있는 경우, 원하는 tag를 추가할 수 있습니다.

그동안 입력된 값을 다시한번 확인하고

특히 VLAN CIDR의 경우 배포된 이후에 변경되지 않기 때문에 다시한번 꼼꼼한 확인이 필요합니다.

모든 데이터가 정상이라고 판단되면 오른쪽 아래 'Create environment'를 선택하여 진짜 배포를 시작합니다.

시작 이후 약 3~4시간 이후 배포가 완료됩니다.

배포가 완료된 이후 다수의 클러스터가 배포되어 있는 경우 특정 클러스터를 선택하면,

그 아래쪽 화면에서 세부 사항을 확인할 수 있습니다.

배포가 완료되고 나면, 화면 중간쯤에 각 컴포넌트에 직접 접속할 수 있는 링크가 제공됩니다.

- SDDC Manager

- NSX Manager

- vSphere Client

그리고 그 아래 탭으로 구성된 메뉴에서 구성 사항을 확인할 수 있습니다.

- Details :

배포된 EVS 환경에 대한 기본 사항을 보여줍니다.

참고로 Environment status는 SDDC 매니저와 인스턴스간의 통신이 정상적으로 이루어지고 있는지에 대한 확인입니다.

만약 Fail이 발생하는 경우 즉시 알람이 발생됩니다.

- Hosts : vSphere로 구성된 개별 host들에 대한 정보를 보여줍니다.

- Network and connectivity : 배포시 설정한 다양한 용도별 VLAN에 대해 구성상태를 보여줍니다.

- Management appliance : 배포된 VCF 관련 관리용 VM들의 정보를 보여줍니다.

- Tags : 설정된 Tag 정보를 보여줍니다.

Elastic VMware Service(EVS) - II. EVS 구성

에디.이이 — Fri, 19 Sep 2025 21:55:09 +0900

2025년 9월 18일 진행된 AWS Innovate: Migrate and Modernize에서 발표된

'VMware 워크로드를 클라우드로, 가장 스마트한 마이그레이션의 시작 - Amazon EVS' 를 정리합니다.

참고로, 발표 내용 중 일부를 흐름에 맞추어 변경하였습니다.

I. EVS 소개

II. EVS 구성 요소 (현재글)

1. 컴퓨팅

2. 네트워킹

3. 스토리지

III. EVS 배포

1. 컴퓨팅

EVS는 AWS의 베어메탈 EC2 인스턴스를 그대로 사용합니다.

기본적으로 EVS는 vSAN을 내장형 스토리지로 사용하고 있어, 물리적 디스크 용량이 큰 모델이 우선 적용되고 있습니다.

현재는 i4i.metal 1종류의 인스턴스가 제공되고 있으며, 점차적으로 지원 인스턴스를 늘려갈 예정으로,

VCF 인증을 진행중인 4개 이상의 인스턴스가 공식 지원을 대기 중에 있습니다.

EVS의 컴퓨팅은 ESXi가 직접 설치되는 베어메탈 Host입니다.

On-premises의 물리 서버와 동일한 의미로, 물리적으로 아래와 같은 스펙으로 구성되어 있습니다.

1. CPU

- 구분 : Intel Xeon Scalable Processor 3세대(Ice Lake)

- 모델명 : Xeon Platinum 8375C

- 사양 : 32 core * 2 Sockets(Hyper Threading Enabled)

- 성능 : 일반 2.9GHz, 터보 3.5GHz

2. Memory : 1024GiB

- 채널 : 8 channel/cpu

- 메모리 : 64GB * 16EA

3. Disk

- 개별 용량 : 3,750GB AWS Nitro SSD

- 수량 : 8개

4. NIC

- Network Card : 1개

- Shared across 2 x ENIs

- 최대 대역폭 : 75GB

2. 네트워킹

1) 내부 네트워킹

EVS는 기본적으로 VCF의 표준 네트워크 구성을 따라갑니다.

VCF의 경우 목적별로 내부 네트워킹을 위해 많은 서브넷이 필요합니다.

예를 들어, 외부 네트워크와의 통신을 위한 NSX Edge의 업링크 네트워크나,

vMotion을 위한 vMotion 네트워크도 필요합니다.

개별 필수 네트워크에 대해서는 사전에 설계가 필요하며, 설계된 범위를 배포 단계에서 입력하게 됩니다.

해당 값들은 추후에 변경할수 없으니, 입력전 네트워크 구성에 대한 설계에 유의해야 합니다.

VCF가 배포되는 과정에서 해당 서브넷들이 자동으로 생성되고, 관련된 컴포넌트들이 구성되면,

서로간의 통신을 통해 정보를 주고 받으며 최종적인 설정이 마무리되게 됩니다.

이후 제공되는 NSX Manager에 접속하여 실제 VM 워크로드가 위치할 segment를 생성하고,

VM에 생성된 Segment를 할당하면 네트워크는 모두 준비가 완료됩니다.

2) 외부 네트워킹

EVS를 하이브리드로 구성하여 On-premises 데이터센터와 클라우드를 연결하는 경우,

AWS의 전용선 서비스인 Direct Connect(DX)를 통해서 연결하거나 인터넷 망을 통해서 VPN 터널을 생성할 수 있습니다.

EVS는 일반적인 VPC 안에 구성이 되기 때문에 AWS의 네트워킹 기법을 이용해서 손쉽게 On-premises와 연결할 수 있습니다.

EVS를 통해 생성된 SDDC에서 NSX manager를 통해 생성한 논리적 segment는 VCF 내에서만 유효한 네트워크입니다.

모든 패킷은 GENEVE 프로토콜로 감싸지는 오버레이 형태로, 외부와의 통신을 위해서는 무조건 Edge를 통해야 합니다.

즉 기본적으로 VPC 내부의 네트워크에서는 해당 네트워크의 통신을 인지할 수 없습니다.

따라서 VPC와의 원한 통신을 위해 Amazon VPC route server를 구성하게 됩니다.

Amazon VPC route server를 통해서 VPC 네트워크와 VCF에 위치한 NSX 오버레이 네트워크 간의 라우팅 정보를 교환합니다.

서로간에는 BGP를 통해 서로간의 동적인 라우팅 정보를 주고 받을 수 있으며,

정보교환 및 네트워크 통신을 위해 Route server에 endpoint가 2개까지 사전에 배포되어 있어야 합니다.

3. 스토리지

1) 내부 스토리지

EVS의 기본 스토리지는 vSAN입니다.

베어메탈 기반의 EC2 인스턴스에 연결된 8개의 NVMe All Flash 스토리지를 기반으로, vSAN 스토리지를 구현합니다.

EVS는 vSAN의 ESA 아키텍처를 사용하여 별도의 Cache와 Data 디스크를 구분하지 않고,

전체 디스크를 하나의 Pool로서 활용합니다.

vSAN은 HCI를 위한 스토리지 솔루션입니다.

Host 안에 있는 내장 스토리지를 모아서 하나의 커다란 공유 스토리지를 만들고

클러스터 안에 있는 모든 Host에게 제공하는 서비스로 Host의 수량에 따라 스토리지 용량이 결정되게 됩니다.

최소 클러스터 구성기준인 4대를 기준으로 보면

(3,750GB * 8개) * 4대 = 120,000 GB의 물리 용량을 제공하며, GiB 기준으로 약 109,14GiB의 물리 디스크 용량을 제공합니다.

사용량과 데이터에 따라 실제 논리적 제공량은 달라질 수 있음으로, VMware Cloud on AWS와 동일한 Host를 사용하고 있어,

VMware Cloud on AWS 의 사이저를 통해 VM 워크로드가 사용 가능한 Disk 용량을 유추해 볼 수 있습니다.

(압축 1.25:1 기준, MGMT 제외, ESA 아키텍처 조건)

i4i.metal	RAID 1, FTT=1	RAID 5, FTT=1	RAID6, FTT=2
4대	37.22 TiB	51.21 TiB	-
5대	47.71 TiB	65.19 TiB	-
6대	58.2 TiB	95.96 TiB	79.18 TiB
7대	68.69 TiB	112.74 TiB	93.16 TiB
8대	79.18 TiB	129.52 TiB	107.15 TiB
9대	89.67 TiB	146.31 TiB	121.13 TiB
10대	100.16 TiB	163.09 TiB	135.12 TiB
11대	110.64 TiB	179.87 TiB	149.1 TiB
12대	121.13 TiB	196.66 TiB	163.09 TiB
13대	131.62 TiB	213.44 TiB	177.08 TiB
14대	142.11 TiB	230.22 TiB	191.06 TiB
15대	152.6 TiB	247 TiB	205.05 TiB
16대	163.09 TiB	263.79 TiB	219.03 TiB

2) 외부 스토리지

VM 워크로드를 만들다보면 컴퓨팅 파워와 스토리지 용량 간의 미스매치가 발생하기도 합니다.

EVS는 기본적으로 vSAN을 사용하여 디스크가 부족할 경우 HCI 특성상 CPU/MEM도 함께 추가되어야 합니다.

즉, 컴퓨팅 용량은 충분한데 스토리지 용량이 부족해서 Host를 추가해야 하는 경우도 발생합니다.

EVS는 이런 경우 활용할 수 있는 추가 외부 스토리지 기능을 제공합니다.

AWS에서 제공되는 Amazon FSx for NetApp ONTAP을 이용하여

EVS 클러스터에 NFS 또는 iSCSI로 데이터스토어를 연결하고, VM 워크로드들을 통해 활용합니다.

이를 통해 On-premises의 외장 스토지와 유사하면서도 클라우드스러운 장점들을 얻을 수 있습니다.

1. 비용 최적화 : 컴퓨팅과 스토리지를 분리하여 비용을 최대 50% 절감합니다.

2. 성능 및 신뢰성 향상 : 엔터프라이즈 데이터 보호를 통해 보호 강화 및 SLA 충족합니다.

3. 운영 우수성 향상 : On-premises ONTAP 기반 아키텍처 및 기능 일관성으로 마이그레이션을 간소화합니다.

이렇게 스토리지를 컴퓨팅에 독립적으로 확장하고

중복제거와 압축 등을 통해 외장 스토리지의 효율성을 누릴수 있으며, Snap-mirror 같은 복제 솔루션을 이용하여

빠른 마이그레이션이나 데이터 보호, 재해복구도 손쉽게 구성할 수 있습니다.

또한 성능 및 데이터 보호 측면에서 엔터프라이즈급의 스토리지 기능을 포함하고 있기 때문에,

EVS에 배포된 워크로드 유형과 상관없이, 모든 유형의 워크로드에 적합한 성능과 기능을 제공합니다.

외장 스토리지의 구성은 EVS 자체적으로 구현되는 구성은 아닙니다.

Amazon FSx for NetApp ONTAP는 기본적으로 AWS 내 배포되는 서비스이고,

EVS는 VPC 네트워크를 통해 해당 서비스를 이용하는 구성입니다.

먼저, Amazon FSx for NetApp ONTAP을 통해 디스크 볼륨을 생성하고 생성된 볼륨을 export합니다.

이제 VPC 안에 구성된 EVS에서 NFS를 통해 해당 볼륨을 데이터스토어로 마운트 하여 VM 워크로드에 활용합니다.

프로토콜은 다르지만, iSCSI를 사용하는 경우에도 동일한 형태로 구성합니다.

Elastic VMware Service(EVS) - I. EVS 소개

에디.이이 — Fri, 19 Sep 2025 21:54:48 +0900

2025년 9월 18일 진행된 AWS Innovate: Migrate and Modernize에서 발표된

'VMware 워크로드를 클라우드로, 가장 스마트한 마이그레이션의 시작 - Amazon EVS' 를 정리합니다.

참고로, 발표 내용 중 일부를 흐름에 맞추어 변경하였습니다.

I. EVS 소개 (현재글)

1. 개요

2. EVS 서비스

3. EVS 마이그레이션

4. 하이브리드 클라우드 구성

5. EVS 가격 구조

II. EVS 구성 요소

III. EVS 배포

1. 개요

AWS는 VMware 워크로드를 위해 Elastic VMware Service(EVS)를 새롭게 출시하였습니다.
EVS는 Broadcom의 VMware Cloud Foundation(VCF)를 AWS에서 서비스 형태로 제공하는 신규 클라우드 서비스이며,

곧 국내에서도 출시될 예정입니다.

기존에 VMware가 AWS 위에서 직접 운영하던 VMware Cloud on AWS와 달리,

EVS는 AWS가 직접 제공하는 서비스라는 차별점이 있습니다

이제 EVS를 이용하면 VMware 워크로드를 클라우드로 가장 빠르고 편리하게 마이그레이션 할 수 있으며,

AWS 위에서 VMware 워크로드를 이용함으로써 다양한 이점을 누릴 수 있습니다.

첫째, VMware 환경에서도 클라우드의 탄력성과 신속성을 제공합니다.

On-premises의 경우 최대 용량에 대한 사전 준비나, 장애에 대비하여 충분히 여유있는 Redundancy 확보가 필요합니다.

하지만 클라우드에서는 원하는 시점에 원하는 만큼의 자원(Host, 스토리지 등)을 빠르게 확장하고 축소할 수 있기 때문에

효율적인 하이브리드 클라우드 환경과 최적화된 자원을 구축합니다.

둘째, On-premises와 클라우드 간에 VM의 자유로운 이동이 제공됩니다.

On-premises와 클라우드에 동일한 vSphere 하이퍼바이저가 구성되어 있어,

On-premises에서 클라우드로, 또는 그 반대인 클라우드에서 On-premises의 이동이 자유롭습니다.

셋째, 클라우드에 위치한 다양한 서비스를 즉시 활용합니다.

On-premises에서는 구현하기 쉽지 않은 서비스들도 클라우드에 위치한 서비스로서 즉시 사용하기 때문에,

VMware의 워크로드들에 대해서도 Application 현대화를 쉽게 제공할 수 있습니다.

EVS는 AWS의 글로벌 인프라스트럭처 안에서 구현됩니다.

AWS의 기본 토대가 되는 VPC 안에 EVS가 위치하게 되며, 당연히 AWS의 다양한 서비스에 자유롭게 접근할 수 있습니다.

EVS 안에는 On-premises와 동일하게 VCF의 기술스택이 그대로 배포가 됩니다.

즉, On-premis의 VMware 기반의 환경들과의 완벽한 호환성을 보장합니다.

또한, VMware에서 제공하는 NSX와 HCX를 통해 On-premises의 네트워크를 클라우드로 확장하고

IP를 변경하거나 다운타임을 가져갈 필요 없이 VM 워크로드들을 자유롭게 이동시킬 수도 있습니다.

물론 필요에 의해 언제든지 On-premises로 다시 역마이그레이션도 가능합니다.

EVS는 다양한 사례에서 활용할 수 있습니다.

1. 데이터센터 확장

On-prem에서 사용하시는 VMware의 기술과 환경을 그대로 유지하시면서 데이터센터의 용량을 클라우드로 확장합니다.

필요시 자유롭게 확장하여 사용하고, 필요가 줄어들면 축소할 수 있는 탄력적인 하이브리드 형태로 구성합니다.

2. 클라우드로의 빠른 마이그레이션

On-premises의 데이터센터 Exit시 Relocate라는 마이그레이션 방법을 통해서 매우 빠르게 마이그레이션을 완료합니다.

VM 자체를 동일 플랫폼으로 이동하기 때문에 Assessment와 호환성, 재검증 등의 절차가 매우 단순해지며,

이를 통해 EVS로 빠르게 마이그레이션 하여 즉시 서비스 합니다.

3. 재해 복구

평상시에 최소한의 용량으로 DR(Disaster Recovery) 센터를 EVS에 구축해두고,

재해 시점에 클라우드의 탄력성과 신속성을 이용해서 EVS 클러스 자원을 즉시 확대합니다.

이후 서비스를 즉시 배포하여 최소한의 RTO로 복구하는 효율적인 클라우드 DR을 구성합니다.

DR 상황이 모두 해제된 이후에도 짧은 시간 내에 빠르게 On-premises로 워크로드를 복구할 수 있습니다.

4. 애플리케이션 현대화

On-premises에서 즉시 도입하기 어렵거나, 규모로 인한 비용의 문제가 있는 서비스들이 있을 수 있습니다.

AWS에서 제공하는 다양한 서비스를 즉시 연계하여, VM 워크로드에 대한 애플리케이션 현대화를 가속시켜 줍니다.

2. EVS 서비스

EVS는 AWS의 VPC 내에서 직접 VMware Cloud Foundation(VCF)를 실행하는 형태로 서비스가 제공됩니다.

그렇기 때문에 AWS로의 마이그레이션을 간소화하고 또 가속화 시킬수 있으며,

클라우드에서도 VMware 아키텍처에 대한 제어권을 그대로 유지할 수 있습니다.

또한 유지보수에 있어서도 직접 관리하거나, AWS의 파트너를 통해 지원받는 서비스를 선택할 수 있는 유연성을 제공하며,

200개가 넘는 다양한 AWS 서비스에 대해 직접 접근하고,

애플리케이션을 현대화하면서 혁신을 주도해 나가실 수 있는 특징들을 가지고 있습니다.

1. 자동 프로비저닝

AWS 관리 콘솔 또는 AWS CLI를 통해서 EVS를 자동으로 배포하고 구성합니다.

배포과정에서 필요한 여러가지 설정들을 초기 입력 후 VMware Cloud Builder를 통해서 쉽게 배포합니다.

2 EC2 베어메탈 서비스

최적의 성능을 위해서 EC2 베어메탈 인스턴스를 사용합니다.

현재는 i4i.metal이라는 단일 인스턴스 모델만 제공되고 있으나 현재 최소 4개 이상의 모델로 확장이 계획되어 있습니다.

또한, 인스턴스에 대한 Tenancy 옵션으로 Shared Tenancy 또는 Dedicated Host를 선택하여 사용할 수 있습니다.

1) Shared Tenancy

다수가 공유하는 베어메탈 풀에서 배포시마다 할당받아 사용하게 되며, 배포시마다 다른 서버를 할당 받을 수 있습니다.

2) Dedicated Host

특정 물리 서버를 지정해두고 독점으로 사용하게 되며, 주로 SW 라이센스 문제로 인해 사용하는 경우입니다.

3. 표준 VCF 소프트웨어

EVS는 AWS에 의해 검증된 표준 VCF 소프트웨어를 통해 구현됩니다.

현재는 v5.2.1을 지원하고 있으며, 최신 버전의 경우 향후 업데이트를 통해 순차적으로 제공될 예정입니다.

4. 관리 및 제어

EVS는 사용자에게 Full administrative access 권한을 제공합니다.

즉, On-premises와 같이 고유의 Root 권한을 이용하여 VCF에서 사용할 수 있는 모든 기능을 활용할 수 있습니다.

5. 유연한 소비 모델

비용의 경우 EC2 인스턴스에 대해 On-demand 그리고 1년/3년의 약정을 통한 하드웨어 약정을 제공합니다.

VCF의 경우 On-premises에서 구독중인 라이센스를 이동하여(Bring Your Own Subscription) 사용해야 하며,

이는 EVS 배포 전 준비되어야 합니다.

6. 관리 방법 선택

기본적으로 Premium Support Business 이상 서비스를 이용해야 하며, 이에 대해 AWS의 L1, L2 서비스가 제공됩니다.

만약 더 상위 지원이나 L3 이상의 지원이 필요한 경우 Broadcom과 협력하여 지원하고 있습니다.

그 외 기술적인 Hands-on이 필요한 유지보수의 경우 직접 관리 또는 AWS 파트너를 통한 관리를 제공합니다.

3. EVS 마이그레이션

EVS로 VMware 워크로드를 마이그레이션 할 때 가장 효과가 확실합니다.

마이그레이션 방법론적인 측면에서 Relocate 방식을 통해 가장 빠르고, 가장 안전하며, 최소 비용으로 마이그레이션 합니다.

일반적으로 클라우드로 마이그레이션 할때, Rehost 방식으로 진행되는 경우가 많습니다.

이 경우 새로운 호스트 위에 OS를 설치하고 사용자의 애플리케이션 바이너리와 데이터를 복제 하는 형태로

마이그레이션이 진행되며, 이는 애플리케이션 입장에서 위치가 변경되는 의미입니다.

이때 일반적으로 Rehost 전용 도구를 사용하게 되는데,

원본 VM 안에 Agent를 설치하고, 이를 통해 디스크 볼륨을 복제하는 형태로 마이그레이션을 진행하게 됩니다.

이경우 신규 하드웨어 및 OS로 변경 되었기 때문에 디바이스 드라이버에 대한 최적화 작업이 필요하고,

제공되는 OS에 따라 별도의 변환 및 최적화 작업이 필요할수도 있습니다.

이에 반해 Relocate 방식은

타겟 환경(여기서는 EVS)에 이미 완벽하게 호환이 되고 있는 동일한 제품의 vSphere 하이퍼바이저가 설치되어 있습니다.

복제되는 대상은 사용자 애플리케이션과 데이터 뿐만 아니라 OS 전체 ,

즉 VM을 통째로 복제하는 형태로 마이그레이션이 진행되기 때문에 별도의 후속작업이 필요하지 않고,

마이그레이션 된 이후에 OS를 포함해서 애플리케이션에 문제가 발생할 만한 여지가 발생하지 않습니다.

따라서 relocate라는 마이그레이션 방식은 마이그레이션 방법론 측면에서 가장 빠르고 편리한 마이그레이션 방식입니다.

4. 하이브리드 클라우드 구성

AWS에 EVS를 배포하는 경우 On-premises와 AWS 사이에 진정한 하이브리드 클라우드 아키텍처를 구현할 수 있습니다.

VCF 솔루션에 포함된 VMware HCX(Hybrid Cloud Extension)를 이용하는 경우

HCX Interconnect(IX)를 이용하여 On-premises와 클라우드 간에 IPsec 터널을 구성하며,

이 터널을 이용하여 VM 워크로드들이 자유롭게 이동할 수 있습니다.

또한, 이동하는 VM 워크로드들의 다운타임을 잡기 어려운 경우에는

HCX L2 Extension을 통해서 On-premises에서 사용중인 L2 네트워크를 확장하여 클라우드 상에서 제공합니다.

네트워크 경로와 게이트웨이 보안 정책등의 변경 없이, VM을 라이브 상태로 즉시 마이그레이션 할수 있습니다.

5. EVS 가격 구조

EVS의 경우 AWS 서비스와 Broadcom의 VCF가 결합된 형태이므로, 양쪽 환경에 대한 비용을 함께 고려해야 합니다.

기본적으로 AWS에서 고려해야할 비용은 VPC, 서브넷, 라우팅 테이블 및 EC2 베어메탈 인스턴스가 있습니다.

1. EC2 인스턴스

현재 i4i.metal이 제공되고 있으며, on-demand, 1년, 3년의 약정이 가능합니다.

2. Dynamic Routing Service

VCF 내부 네트워크와 AWS VPC 네트워크간의 연결 및 라우팅 정보 전달을 위한 Route Server가 필요합니다.

Route Server에서 VCF 내 NSX Edge 2대(이중화)와 각각 연결되는 endpoint를 제공합니다.

3. EVS Control Plane

EVS의 핵심 코어 역할을 담당하는 VCF 소프트웨어에 대한 구독이 필요합니다.

현재는 BYOS 형태로만 제공되고 있기 때문에, 별도의 Broadcom 파트너를 통한 가격 확인이 필요하며,

EVS에서 VCF 라이센스가 포함된 모델은 향후 출시 예정으로 되어 있습니다.

4. External Storage

HCI 형태로 스토리지만 부족한 경우 컴퓨팅까지 증가해야 하는 불합리함을 방지하기 위해

Amazon FSx for NetApp ONTAP을 이용하여 NFS 또는 iSCSI 형태로 데이터스토어를 확장할 수 있습니다.

필요한 용량에 따른 가격 고려가 필요합니다.

추가적으로

EVS는 Amazon Premium Support의 Business Plan 이상의 지원을 필요로 합니다.

이는 사용량과 조건에 따라 달라지는 부분으로 환경에 맞는 Premium Support 비용의 추가도 함께 고려되어야 합니다.

곧 VMware Cloud는 License Portability를 통해서만 제공됩니다.

에디.이이 — Mon, 8 Sep 2025 16:51:51 +0900

Broadcom의 VMware 인수 이후, 많은 제품들이 VVF/VCF 기반의 구독형 라이선스 체계로 전환되었습니다.

이 과정에서 가격 상승에 대한 불만도 있었지만,

기존에 잘 활용되지 않던 제품들의 사용이 늘어나는 긍정적인 효과도 있었습니다.

특히 다양한 클라우드 구성을 위해 꼭 필요한 핵심 제품들이 패키지에 포함되면서

프라이빗 클라우드 도입도 한층 더 가속화될 수 있었습니다.

새롭게 도입된 구독 라이선스 체계에서는 License Portability가 제공되기 시작했습니다.

이는 라이선스가 특정 위치에 묶이지 않고 설치 환경과 관계없이 자유롭게 활용될 수 있도록 한 중요한 변화입니다.

예를 들어 VCF 100코어를 구독 중이라면 온프레미스에서 전부 사용할 수도 있고,
온프레미스 50코어와 AWS EVS 50코어로 나누어 사용하는 것도 가능합니다.

또한 AWS EVS 환경에서 Azure AVS로 이전할 경우에도 약정과 관련된 매몰 비용이나 중복 투자를 최소화하면서
기존 라이선스를 그대로 활용할 수 있습니다.

License Portability 도입 이전에는

VMware Cloud on AWS처럼 인프라와 VCF 라이선스가 통합된 형태로만 제공되었습니다.

따라서 물리적 위치를 변경하거나 클라우드 사업자를 바꿀 경우 추가적인 라이선스 비용이 발생하는 구조였습니다.

License Portability는 이러한 제약을 해소하여 하이퍼스케일러 환경을 보다 자유롭게 선택할 수 있도록 지원합니다.

이러한 변화에 따라 현재 많은 하이퍼스케일러는 VMware Cloud에 대해 두 가지 가격 모델을 제공합니다.

첫째는 CSP를 통해 인스턴스와 라이선스가 통합된 가격 체계이고,
둘째는 BYOL 방식을 통해 보유한 VCF 라이선스를 적용하고 CSP는 인스턴스만 제공하는 분리형 가격 체계입니다.

그러나 최근 Broadcom이 발표한 블로그에 따르면 이 부분에도 큰 변화가 예정되어 있습니다.

Broadcom is transforming its hyperscaler go to market to a license portability-only operating model beginning in the new fiscal year. Customers will purchase VCF subscriptions from Broadcom, which includes license portability to any supported hyperscale cloud.

Broadcom은 새로운 회계연도인 2026년 11월부터
하이퍼스케일러용 VCF 라이선스를 License Portability 기반의 단일 운영 모델로 전환한다고 발표했습니다.

즉, 인스턴스와 라이선스가 통합된 기존 형태는 더 이상 제공되지 않으며,
Broadcom에서 구독한 VCF 라이선스를 어떤 CSP 환경에서든 동일하게 사용할 수 있게 됩니다.

이를 통해 물리적 위치나 클라우드 사업자에 관계없이 일관된 라이선스 체계를 적용받을 수 있으며,

보다 단순하고 효율적인 방식으로 클라우드를 운영할 수 있습니다.

더 이상 특정 환경에 종속되지 않고,

목표와 전략에 맞추어 인프라를 자유롭게 구성하고 확장할 수 있을 것으로 기대합니다.

다만, VMware Cloud 중 OCVS의 경우 아직 VCF 라이센스 체계를 따르지 않고 있어,

해당 서비스는 아직까지는 제외하고 고려가 필요합니다.

참고 .VMware Cloud Foundation – Cloud on Your Terms

VMware Cloud 포털이 Broadcom 포털로 마이그레이션 됩니다.

에디.이이 — Tue, 2 Sep 2025 10:22:43 +0900

VMC와 VLR 등 VMware Cloud 서비스의 콘솔을 제공하는 VMware Cloud Services Portal이

Broadcom Cloud Services Console로 완전히 전환됩니다.

이번 전환은 한국시간 기준으로 9월 20일~ 22일까지 진행되며,

전환 기간 동안 포털을 통한 조회만 가능하고, 설정 변경이나 신규 배포는 제한됩니다.

부득이하게, 필요한 일이 발생하는 경우 Broadcom Support를 통해 지원받을 수 있습니다.

1. ~~2025년 9월 20일 오후 1시(KST)~~ ~~- 9/19 8:00 PM (PST)~~
~~2025년 9월 27일 오후 1시(KST) - 9/26 8:00 PM (PST)~~

2025년 10월 4일 오후 1시(KST) - 10/3 8:00 PM (PST)

전체 시작 일정이 ~~일주일~~ 다시 한번 연기되었습니다.

VMware Cloud Services Portal이 읽기 전용(Read-Only) 모드로 전환됩니다.
사용자는 여전히 로그인하여 사용중인 서비스에 접근하여 상황을 확인할 수 있으며,

당연히 서비스 중인 VMC 및 VLR 인스턴스에는 영향이 없습니다.

다만, 추가적인 계정, 조직, 사용자 수정 기능은 제어할 수 없습니다.

2. ~~2025년 9월 22일 오후 2시~~ ~~- 9/21 9:00 PM (PST)~~

~~2025년 9월 29일 오후 2시 - 9/28 9:00 PM (PST)~~

2025년 10월 6일 오후 11시(KST) - 10/6 6:00 AM (PST)

전체 재오픈 일정이 ~~일주일~~ 다시 한번 연기되었습니다.

VMware Cloud Services Portal에 접속하면 자동으로 Broadcom Cloud Services Console로 전환됩니다.

새로운 인터페이스를 통한 서비스가 제공되며, 기존 VMware Cloud Services와 동일한 인증을 사용하므로,

로그인 자격 증명과 역할/권한이 그대로 이전되어, 첫 로그인 시 비밀번호와 MFA 인증을 통해 로그인 가능합니다.

기본적인 로그인과 제어에 대한 기능은 제공되지만,

기존 기능 중 일부는 즉시 지원되지 않거나 제외될 예정이므로, 사용 중인 기능에 주의가 필요합니다.

1. 향후 지원 예정 : IAM / Groups

2. 제외 기능

- Organization / Authentication Policy (IP Address/Range, Source Domain)

- IAM / Projects Functionality

- IAM / Custom Roles

- Billing & Subscriptions / Subscriptions (Moved to respective product console)

특히, IP 나 Subnet에 따른 콘솔 접근을 제어하는 필터링 기능이 제외될 예정입니다.

현재 보안상의 목적으로 로그인을 제한하는 용도로 사용되고 있는 IP 필터링 기능을 사용중이라면,

해당 기능이 제외됨을 인지하여야 하며, 해당 기능에 대해 대체할 수 있는 기능은 아직 제시되지 않았음으로,

내부 보안 정책과 관련된 논의가 필요합니다.

~~Flex 스토리지의 경우에도 변경된 오픈 일정에 따라 일정이 변경되었습니다.~~

~~1. 2025년 9월 27일 오전 9시 - 9/26 PM 5시(PST)~~

~~2. 2025년 9월 30일 오전 0시 - 9/29 AM 8시(PST)~~

관련된 사항은 변경될수 있으며, 변경사항에 대해서는 아래 링크에서 안내되고 있습니다.

VMware Cloud Services Portal migration to the Cloud Services Console on Broadcom