본문 바로가기
서적 추천 & 네트워크 엔지니어의 일상/네트워크 엔지니어 환영의 일상

AWS Landing Zone 구축 프로젝트 이후(AWS vs Azure)

by 네트워크 엔지니어 환영 2024. 9. 29.
반응형
일상에서 문득 드는 생각을 적는 공간입니다.

작년, AWS Landing Zone(이하 랜딩존) 구축 프로젝트에 갑자기 투입되어 즐겁게 일했습니다. 이번엔 Azure네요. Azure 역시나 갑자기 찾아왔습니다. 프로젝트 시작 당시, 랜딩존의 방화벽 설치 및 최적화를 맡았던 분이 소속 조직이 변경되었다며, "본인은 이제 상관 없으니 알아서 하시라" 라는 말과 함께 도망을 가버려 제가 빈자리를 채우고 있습니다. 심지어 기능 검증이나 구축도 제대로 해놓지 않아 뒷수습을 해야 했고 지금도 하고 있죠(...) 그나마 작년에 AWS 랜딩존 구축을 진행해봤기에 적응하는 데 그렇게 어렵지는 않았습니다. 

Azure는 AWS와 비슷한 부분이 많았습니다. 네트워스 서비스들은 이름은 조금 다를지언정 대동소이한 부분이 많았습니다. AWS의 ELB(ALB/NLB)는 Azure Application Gateway / Load Balaner에 해당했고 기능도 꽤 비슷했습니다. AWS VPC는 Azure의 VNET, AWS Route 53(Private hosted zone)은 Azure Public DNS(Private dns zone)와 거의 동일했습니다. 그럼에도 세세한 부분은 꽤 다른 것이 많았고, 인터페이스에서는 AWS와 Azure 각자 장단점이 보이기도 했습니다. 이에 대해 몇 가지 차이를 적어보면 다음과 같습니다. 네트워크 서비스 위주로 나열해보겠습니다.

1. AWS Management Console vs Azure Portal
콘솔 접속은 Azure가 좀 더 낫다는 생각이 들었습니다. AWS는 속도가 느린감이 없지 않아 있고, 몇 분이 지나면 자동 로그아웃되는 불편함이 있지만 Azure는 ID / Password 저장에 "로그인 유지" 기능이 있고 진입 속도가 상당히 빨랐습니다. 회사에서 2가지 솔루션 모두를 접근하고 있는 제 입장에선 Azure가 훨씬 편리했습니다.

2. 리소스 조회
VPC(VNet), EC2(VM)와 같은 리소스 조회는 Azure가 다소 적응하기 어려웠습니다.Azure는 Subscription(이하 구독)이란 개념이 존재하며 그 아래 리소스 그룹을 생성하여 리소스를 제어하고 비용을 컨트롤하기 때문에 리소스의 성격이 아닌 어느 구독과 리소스 그룹에 있느냐를 알아야 조회가 편했습니다. 모든 구독의 리소스가 한꺼번에 보이고 구독을 구별할 줄 알아야 조회가 편하니 다소 불편했습니다.  AWS는 VPC는 VPC, EC2는 EC2 서비스를 클릭하면 모든 리소스를 볼 수 있고 비용 관리는 Tag(이하 태그)를 통해 컨트롤하기에 조회는 편했지만 비용 조회가 다소 불편합니다. 

리소스 검색 또한 Azure가 다소 불편했습니다. AWS는 기능을 대분류로 나누어 그 안에 세부 기능이 있는데요. 예를 들어 ELB가 하나의 리소스이고 그 안에 ALB, NLB, GWLB가 있기에 ELB만 검색하면 되지요. Azure는 ELB에 해당하는 기능을 찾으려면 Application Gateway 혹은 Load Balancer를 직접 찾아야 합니다. DNS도 Private dns zone, DNS Private resolver 등 모두 각각의 기능이어서 일일이 찾는 불편함이 있었습니다.

3. Console(Portal) 조회/이동 속도
Azure가 확실히 빠릅니다. 아주 훌륭합니다.

4. Console(Portal)의 리소스 설정 적용 속도
Azure가 확실히 느립니다. Azure Firewall의 경우, Rule Collection 하나 생성하는데 한세월입니다.

5. Console 동시 적용 가능 여부
Azure는 이게 불가능합니다. 흑흑..... 동일 리소스에 대해 누군가가 설정을 변경 적용 중이라면 다른 사람은 끝날 때까지 기다려야합니다. 역으로 생각하면 Azure가 리소스의 변경과 무결성을 중시한다는 생각이 들었습니다.

6. 리소스 관리
개인 계정으로 AWS를 사용하는 분들 중 "비용이 조금씩 나오는데 어딘지 모르겠다"라고 하시는 분들이 많습니다. Azure는 리소스 그룹이 있기 때문에 리소스 그룹을 삭제하면 모든 리소스 삭제가 가능해 편리합니다.

7. 네트워크 서비스의 사용자 설정 자유도(혹은 편리함)
네트워크 엔지니어로서 가장 유심히 지켜본 부분입니다. AWS는 네트워크 설정(특히 라우팅)에 손이 많이 가는 대신 사용자가 최대한 자유롭게 설정할 수 있어서 네트워크 설정의 자유도가 높았습니다.  Azure의 경우, 네트워크 설정이 아주 간편했습니다. 소위 UDR(User-Defined Routes)를 제외하고 라우팅 설정이 필요할만한 부분은 그리 많지 않았습니다. 게다가 Virtual Hub(이하 vhub)를 사용한다면 Routing Intent(이하 라우팅 의도)를 통해 vhub에 연결된 VNet들의 라우팅을 일괄적으로 제어할 수 있고 간편했습니다. 다만 라우팅 설정에 대한 자유도가 낮아 사용자가 의도하는 라우팅을 설정하기 어려웠습니다.

8. Public IP의 Network Address Translation(NAT) 설정
Public IP의 NAT에 대해서는 AWS가 확실히 나았습니다. AWS의 모든 NAT Table 관리는 Internet Gateway(이하 IGW)가 관리하고 자동으로 실시합니다. 그렇기에 사용자가 VPC 내부에서 Internet Load Balanacer를 몇 개를 만들든, NAT Gateway를 몇 개를 생성하든 NAT에 대해 신경쓰지 않아도 됩니다. Azure는 사용자가 직접 NAT를 제어해야하거나 NAT에 대한 구체적 제어가 어려웠습니다. Azure Firewall을 통한 NAT를 실시하게 될 경우, SNAT는 Public IP의 랜덤 선택으로 출발지 IP 확인이 어렵고, DNAT는 Firweall에서 사용자가 방화벽에 할당된 Public IP로 직접 실시해야 합니다.

 

댓글