Azure 첫 실습 — AWS만 하던 사람이 느낀 충격적인 차이점

오늘 처음으로 Azure 실습을 했다. 솔직히 "AWS랑 비슷하겠지, 이름만 다르겠지"라고 생각했다. 근데 콘솔 켜자마자 첫 번째 당황이 왔다. 뭘 먼저 만들어야 하는지 메뉴가 너무 흩어져 있었다.

AWS는 VPC 들어가면 서브넷, IGW, 라우팅 테이블이 왼쪽 사이드바에 순서대로 있다. Azure는 검색창에 직접 쳐야 한다. Virtual Network인지 VNet인지도 처음엔 헷갈렸다. 메뉴 구조 익히는 데만 20분 걸렸다.

근데 실습 끝나고 나서는 생각이 달라졌다. 불편한 게 아니라 설계 철학 자체가 달랐다.

 

---

오늘 만든 구조

강사님이 제시한 실습 구조는 이랬다.

Resource Group: rg-practice-01
└── VNet: vnet-main (10.20.0.0/16)
    ├── Public Subnet (10.20.1.0/24)
    │   └── Windows VM (공인 IP 있음, RDP 접속용)
    └── Private Subnet (10.20.2.0/24)
        └── Ubuntu VM (공인 IP 없음)

Windows VM을 점프 서버처럼 써서, 거기서 다시 Ubuntu VM으로 들어가는 구조다. AWS로 치면 배스천 호스트 패턴이랑 같다.

CIDR은 10.20.0.0/16으로 잡았다. AWS 실습 때 10.10.0.0/16을 썼으니까 대역이 안 겹친다. 나중에 두 클라우드를 연결하는 상황을 미리 고려한 거다. 강사님이 AWS 실습 때 "습관 들여라"고 하셨던 게 여기서 써먹혔다.

---

가장 당황한 순간; 라우팅 테이블을 안 만들었는데 통신이 됐다

AWS 실습 때는 라우팅 테이블 설정 안 하면 바로 이 오류가 났다.

ssh: connect to host [EC2 PUBLIC IP] port 22: Connection timed out

인터넷 게이트웨이 붙이고, 라우팅 테이블에 0.0.0.0/0 → igw-xxxxxxxx 잡아줘야 외부 통신이 됐다. 이게 머릿속에 박혀있어서 Azure에서도 당연히 라우팅 테이블 만들러 갔다.

근데 강사님이 멈추셨다.

"Azure는 라우팅 테이블 안 만들어도 된다. 일단 VM 만들고 Public IP 붙여봐라."

반신반의하면서 그냥 VM에 공인 IP만 붙였다. RDP 연결 시도했더니 됐다.

이유가 있었다. Azure는 System Route가 기본으로 깔려있다. VNet 만드는 순간 아래 경로가 자동으로 잡힌다.

목적지: 0.0.0.0/0 → 인터넷 (자동)
목적지: 10.20.0.0/16 → VNet 내부 (자동)
목적지: 10.20.1.0/24 → 서브넷 로컬 (자동)

AWS는 이게 비어있어서 전부 직접 채워야 한다. Azure는 기본값이 이미 세팅돼있다.

강사님이 이 차이를 이렇게 정리해주셨다.

"AWS는 설계자한테 모든 권한을 준다. 대신 모든 걸 직접 결정해야 한다. Azure는 기본값이 있어서 빠르게 올릴 수 있다. 대신 내가 지금 어떤 경로로 트래픽이 흐르는지 의식하지 않으면 모르고 지나친다. 어느 쪽이 좋고 나쁜 게 아니라, 각각 다른 상황에 맞다."

---

Resource Group — 이건 AWS에 없는 개념이다

Azure 실습에서 제일 신선했던 게 Resource Group이다.

AWS는 VPC 삭제하려면 순서가 있다. EC2 먼저 종료 → ENI 해제 → 서브넷 삭제 → IGW 분리 후 삭제 → VPC 삭제. 순서 틀리면 이런 오류가 난다.

DependencyViolation: The vpc 'vpc-xxxxxxxx' has dependencies 
and cannot be deleted.

AWS 처음 배울 때 이거 몰라서 리소스 정리하는 데 한참 걸렸다.

Azure는 Resource Group 하나 삭제하면 그 안에 있는 VM, 디스크, NIC, 공인 IP, NSG가 전부 같이 지워진다. 오늘 실습 마치고 정리할 때 Resource Group 삭제 버튼 하나로 끝났다.

강사님 말씀:

"Resource Group은 단순한 폴더가 아니다. 배포 단위이자 라이프사이클 단위다. 프로젝트 하나가 끝나면 Resource Group 하나 지우면 된다. AWS는 태그로 비슷하게 관리할 수 있는데, 실제로 태그 일관성 유지하는 게 쉽지 않아서 현업에서 고아 리소스가 많이 생긴다. Azure가 이 부분은 구조적으로 깔끔하다."

---

NSG — Security Group이랑 비슷하지만 적용 레벨이 다르다

Azure의 NSG(Network Security Group)는 AWS Security Group이랑 역할은 같다. 허용/차단 규칙 만들고, 인바운드/아웃바운드 제어한다.

근데 붙이는 위치가 다르다.

AWS Security Group은 인스턴스(ENI) 단위로 붙는다. Azure NSG는 서브넷 단위로도 붙고, NIC 단위로도 붙는다.

오늘 실습에서 VM 만들 때 NSG가 자동으로 생성됐다. 기본 인바운드 규칙을 보니까:

우선순위 | 이름                    | 포트  | 프로토콜 | 소스          | 동작
1000    | RDP                     | 3389  | TCP      | Any           | Allow
65000   | AllowVnetInBound        | Any   | Any      | VirtualNetwork| Allow
65001   | AllowAzureLoadBalancer  | Any   | Any      | AzureLoadBal  | Allow
65500   | DenyAllInBound          | Any   | Any      | Any           | Deny

AWS Security Group이랑 다른 점이 눈에 띄었다. AWS는 기본이 전체 Deny고, Allow만 추가하는 방식이다. Azure NSG도 비슷한데, 우선순위 숫자가 낮을수록 먼저 적용된다는 점이 다르다. 숫자를 외워야 한다.

강사님이 현업 사례를 하나 얘기해주셨다.

"Azure NSG를 처음 쓰는 팀들이 자주 하는 실수가 있다. 서브넷 NSG랑 NIC NSG를 동시에 붙였는데, 둘 다 Allow인데 통신이 안 되는 경우가 생긴다. 이건 서브넷 NSG에서 먼저 Deny가 걸리거나, 우선순위 충돌이 난 거다. 두 레벨로 적용된다는 걸 항상 의식해야 한다. AWS는 인스턴스 레벨만 신경 쓰면 되는데, Azure는 서브넷-NIC 두 단계를 체크해야 한다."

---

오늘 실습 구조의 한계 — 강사님이 먼저 짚어주셨다

실습 마치고 강사님이 오늘 구조의 문제를 직접 짚어주셨다.

"오늘 만든 구조, 가용 영역이 몇 개냐?"

확인해보니 전부 Korea Central 리전의 단일 존이었다. AWS 실습 때 Well-Architected Tool이 High Risk로 잡아줬던 바로 그 문제다.

강사님이 이어서 말씀하셨다.

"학습용이니까 오늘은 이 구조로 했다. 근데 실무에서는 이 구조 그대로 올리면 안 된다. Azure도 Availability Zone이 있다. Zone 1, 2, 3에 분산 배포하고, Azure Load Balancer로 트래픽 나눠야 한다. 거기다 외부에서 직접 VM에 RDP 여는 것도 실무에서는 없다. Azure Bastion 서비스를 써서 공인 IP 없이 포털을 통해 안전하게 접속하는 구조로 가야 한다."

오늘 만든 구조의 실무 개선 방향을 정리하면:

현재 (학습용)                    →  실무 구조
단일 Zone                        →  Zone 1, 2 분산
VM에 직접 공인 IP                →  Azure Bastion 서비스 사용
NAT Gateway 없음                 →  NAT Gateway 추가
단일 VM                          →  Load Balancer + VM Scale Set

---

AWS랑 Azure — 같은 문제를 다르게 푼다

오늘 실습 끝나고 AWS랑 비교해서 정리해봤다.

항목 AWS Azure

네트워크 격리	VPC	VNet
서브넷	Subnet (수동 라우팅 필수)	Subnet (System Route 자동)
방화벽	Security Group (인스턴스)	NSG (서브넷 + NIC 양쪽)
인터넷 연결	IGW + Route Table 직접 구성	Public IP 붙이면 자동
리소스 관리	태그 기반	Resource Group 단위
점프 서버	직접 EC2 배스천 구성	Azure Bastion 서비스 제공
기본 라우팅	없음 (전부 직접)	System Route 자동 제공

강사님이 두 클라우드의 차이를 한 문장으로 정리해주셨다.

"AWS는 네트워크 엔지니어 친화형이고, Azure는 운영 엔지니어 친화형이다. AWS는 내가 설계한 대로 정확히 동작한다. Azure는 기본값이 많아서 빨리 올릴 수 있는데, 기본값이 어떻게 동작하는지 이해 못 하면 나중에 문제가 생긴 게 어디서 생긴 건지 모른다."

이 말이 오늘 실습 내내 계속 생각났다. Azure가 편하게 느껴질수록, 내가 통제하고 있다는 느낌이 덜했다. AWS에서는 라우팅 테이블 직접 잡을 때 "이 트래픽이 여기로 흐른다"는 게 명확했는데, Azure는 그냥 됐다.

강사님 말대로 기본값이 어떻게 동작하는지를 이해하고 써야 한다는 게 앞으로 Azure 배우면서 가장 주의할 부분인 것 같다.

---

다음 실습에서 해볼 것

오늘 실습에서 시간이 없어서 못 한 것들이 있다. 다음 시간에 해볼 것들을 정리해뒀다.

첫째, Azure Bastion 서비스를 직접 써보면서 오늘처럼 VM에 직접 공인 IP 붙이는 방식이랑 어떻게 다른지 비교해보기. 둘째, NAT Gateway 추가해서 프라이빗 서브넷 VM이 인터넷으로 나가는 경로 확인하기. 셋째, 두 개 가용 영역에 VM 분산 배포해서 고가용성 구조 만들어보기.

AWS Well-Architected Tool로 내 설계를 검증했던 것처럼, Azure에도 비슷한 도구가 있는지도 찾아볼 생각이다. Azure Advisor가 그 역할을 한다고 강사님이 언급하셨는데, 직접 써보고 결과를 기록할 예정이다.