멀티클라우드 아키텍처가 머릿속에 안 그려질 때 — AWS 실습으로 직접 부딪혀봤다

 

수업에서 "멀티클라우드 아키텍처"라는 말을 처음 들었을 때 솔직히 감이 없었다. VPC가 뭔지, 서브넷이 뭔지 하나씩은 이해가 되는데, 그게 전체적으로 어떤 그림을 이루는지는 잘 안 보였다. 강사님이 "구조를 봐야 한다"고 하셨는데 그 말 자체가 뭔 말인지 몰랐다.

그 감각이 생긴 건 실습에서 직접 망가뜨려보고 나서였다.

---

"나눈다"는 게 뭔지 — 실습에서 처음 느꼈다

VPC 설계 실습 과제에서 강사님이 이런 조건을 주셨다.

"웹서버, DB, 관리용 배스천 호스트를 배치해라. 어떻게 나눌지는 각자 결정해라."

처음엔 그냥 EC2 세 개 다 같은 서브넷에 넣으려 했다. 어차피 같은 VPC 안이면 통신 되는 거 아닌가 싶어서. 그렇게 했더니 강사님이 지나가시면서 한마디 하셨다.

"DB가 퍼블릭 서브넷에 있으면 인터넷에서 3306 포트 직접 스캔 들어온다. 지금은 Security Group으로 막혀있어도, 설정 실수 한 번이면 DB가 열린다. 계층을 나누는 이유가 거기 있다."

그 말 듣고 구조를 다시 잡았다.

퍼블릭 서브넷 (10.10.1.0/24)
└── 배스천 호스트 (EC2) — 외부 SSH 접근용

프라이빗 서브넷 A (10.10.2.0/24)
└── 웹서버 (EC2) — ALB 통해서만 접근

프라이빗 서브넷 B (10.10.3.0/24)
└── RDS MySQL — 웹서버에서만 접근

VPC CIDR은 10.10.0.0/16으로 잡았다. 강사님이 "나중에 Azure VNet이나 GCP VPC랑 연결할 때 10.0.0.0/16이면 충돌 난다. 지금부터 대역 나누는 습관 들여라"고 하셔서 처음부터 10.10으로 시작했다.

이게 "분리"의 실체였다. 서비스 계층, 데이터 계층, 관리 계층을 나눈다는 말이 이론에선 뜬구름 같았는데, 직접 서브넷 세 개를 성격에 따라 나눠보니까 왜 그렇게 해야 하는지가 보였다.

---

"연결한다"는 게 뭔지 — 안 되는 걸 보고 이해했다

나눠놓고 나서 문제가 생겼다. 프라이빗 서브넷에 있는 웹서버가 yum으로 패키지를 설치하려는데 안 됐다.

Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=7 error was
14: curl#6 - "Could not resolve host: mirrorlist.centos.org; 
Unknown error"

프라이빗 서브넷은 인터넷 게이트웨이로 직접 나가는 경로가 없어서 그랬다. NAT Gateway를 퍼블릭 서브넷에 만들고, 프라이빗 서브넷 라우팅 테이블에 이 경로를 추가해야 했다.

대상: 0.0.0.0/0
타겟: nat-xxxxxxxxxxxxxxxxx

이 한 줄 추가하고 나서야 패키지 설치가 됐다. 근데 여기서 내가 착각한 게 있었다. NAT Gateway 만들면 자동으로 라우팅이 잡히는 줄 알았다. 실제로는 라우팅 테이블에 직접 경로를 명시해야 한다. 안 넣으면 NAT Gateway가 있어도 트래픽이 거기로 안 간다.

강사님이 나중에 이 부분을 짚으셨다.

"멀티클라우드에서 연결이 안 된다는 장애의 70%는 라우팅 문제다. 리소스가 존재한다고 연결이 되는 게 아니다. 트래픽이 어디서 나와서 어디로 흘러가는지 경로가 명시적으로 잡혀 있어야 한다. AWS든 Azure든 GCP든 이 원칙은 똑같다."

Azure에서는 이게 어떻게 다를지 이번 주 배우면서 비교해볼 생각이다. 조사해보니 Azure VNet은 기본적으로 서브넷 간 통신이 허용되는 시스템 라우트가 자동으로 잡힌다고 한다. AWS는 같은 VPC 내 서브넷 간에도 라우팅이 자동이지만, 인터넷 경로는 명시적으로 잡아야 한다. 세부 동작이 조금씩 다른 것 같아서 직접 실습해봐야 확인이 될 것 같다.

---

"보호한다"는 게 뭔지 — Security Group 규칙 꼬이면서 배웠다

보안 설정에서 제일 헷갈렸던 게 Security Group 규칙이 여러 개 붙으면서 의도대로 안 되는 상황이었다.

웹서버 EC2에 Security Group을 두 개 붙였다. 하나는 ALB에서 오는 80포트 허용용, 하나는 배스천에서 SSH 허용용. 설정 다 했는데 배스천에서 SSH가 안 됐다.

ssh -i key.pem ec2-user@10.10.2.10
ssh: connect to host 10.10.2.10 port 22: Connection timed out

원인 찾는 데 꽤 걸렸다. Security Group은 다 맞게 설정한 것 같은데 왜 안 되나 봤더니, 배스천 호스트의 아웃바운드 규칙에 프라이빗 서브넷 대역(10.10.2.0/24)으로 나가는 SSH가 막혀있었다. 인바운드만 신경 쓰고 아웃바운드를 기본값(0.0.0.0/0 허용)에서 바꿔놨던 거다.

이걸 겪고 나서 Security Group 설계할 때 내가 정한 기준이 생겼다.

• 웹서버 인바운드: ALB Security Group ID에서 80, 443만
• 웹서버 인바운드: 배스천 Security Group ID에서 22만
• RDS 인바운드: 웹서버 Security Group ID에서 3306만
• 배스천 아웃바운드: 10.10.0.0/16 전체에 22 허용

소스를 IP 대역이 아니라 Security Group ID로 지정하는 게 핵심이다. IP는 바뀔 수 있는데, Security Group ID는 고정이다. 강사님이 "현업에서 IP 대역으로 Security Group 짜면 나중에 IP 바뀔 때마다 규칙 수정하느라 고생한다"고 하셨다.

Azure에서는 이게 NSG(Network Security Group)로 대응된다. 조사해보니 Azure NSG는 서브넷 단위와 NIC 단위 둘 다 붙일 수 있어서 AWS보다 적용 레벨이 하나 더 있다. 같은 개념인데 구현이 달라서, Security Group을 제대로 이해해두면 NSG 배울 때 비교가 될 것 같다.

---

강사님이 현업에서 겪은 이야기 — 구조가 없으면 장애 원인도 못 찾는다

수업 중에 강사님이 실제 사례를 하나 얘기해주셨다.

"AWS랑 Azure를 같이 쓰는 환경을 맡은 적이 있다. 어느 날 특정 API가 간헐적으로 타임아웃이 났는데, 원인을 못 찾겠는 거다. AWS CloudWatch 보고, Azure Monitor 보고, 네트워크 팀에 물어보고 두 시간을 날렸다. 나중에 원인이 뭔지 알았냐면, Azure에서 AWS 쪽으로 가는 트래픽 경로에 NSG 규칙이 하나 빠져있던 거다. 구조가 머릿속에 그려져 있었으면 처음부터 거기를 봤을 텐데, 그때는 각 클라우드를 따로따로 보다 보니 연결 지점을 놓쳤다."

그 이야기 듣고 "아키텍처 관점"이 뭔지 처음으로 느낌이 왔다. 개별 서비스는 다 정상인데 연결 구간에서 문제가 생기는 것, 그걸 찾으려면 전체 흐름이 머릿속에 있어야 한다는 거다.

강사님이 덧붙이셨다.

"AWS Security Group, Azure NSG, GCP Firewall Rule — 이름이 다 다른데 결국 '어디서 오는 트래픽을 어디로 보낼 것인가'를 제어하는 거다. 하나를 구조로 이해하면 나머지는 번역만 하면 된다. 근데 하나를 기능으로만 외우면 다른 거 배울 때 처음부터 다시 시작이다."

---

지금 내가 이해한 멀티클라우드 아키텍처

아직 AWS 기본 설계까지만 실습했고, 이번 주부터 Azure를 배운다. GCP는 개념 수준이다. 그럼에도 실습하면서 아키텍처의 세 가지 질문이 실제로 무슨 의미인지는 어렴풋이 잡혔다.

나눈다 — 서브넷을 성격에 따라 나눴을 때, 계층 간 접근 통제가 가능해졌다. 나누지 않으면 보호 기준 자체가 없다.

연결한다 — NAT Gateway 만들고 라우팅 경로 명시했을 때 비로소 트래픽이 흘렀다. 연결은 자동으로 되는 게 아니라 경로를 그려야 한다.

보호한다 — Security Group 소스를 IP가 아닌 SG ID로 지정했을 때 의도한 접근만 허용됐다. 보호는 막는 게 아니라 구획을 나누는 것이다.

이 세 가지가 하나의 그림으로 보이기 시작하면, 나중에 Azure VNet이 나오고 GCP VPC가 나와도 "이건 어느 역할이지?"로 자리를 찾을 수 있을 것 같다.

일단 이번 주 Azure 실습 해보고 AWS랑 실제로 어떻게 다른지 또 기록할 예정이다.