Azure 네트워크 트래픽 전달 과정 및 인프라 구축

오늘은 Azure에서 구축된 인프라의 일반적인 네트워크 트래픽 전달 과정에 대해 알아보고자 합니다. 😎

기존에는 AWS의 인프라, 네트워크 트래픽에 대해 많이 다뤘었는데 요즘은 멀티 클라우드 CSP환경 구축에도 관심이 많아져, Azure에 대해서도 상세히 공부해보고자 합니다.

 

AWS에서의 클라이언트로부터 EKS(Elastic Kubernetes Service)에 존재하는 Pod에 트래픽이 전달되기까지의 과정은 크게 Route53 -> NLB(L4) -> ALB(L7) -> Ingress(EKS) -> Service(EKS) -> Pod(EKS)로 표현할 수 있을 것 같습니다.

이에 대응되는 Azure의 컴포넌트로는 Azure DNS -> Azure Load Balancer(L4) -> Azure Application Gateway(L7) -> Ingress(AKS) -> Service(AKS) -> Pod(AKS)로 표현될 것 같습니다. MS에서 제공하는 네트워크 트래픽에 대한 아키텍처는 다음과 같으며, 위에서 설명한 트래픽의 과정을 간단하게 참고해볼 수 있을 것 같아 인용하였습니다.

 

이러한 네트워크 트래픽 전달 과정에 대해 살펴볼 때 IaaS로써 클라우드를 사용할 때 Terraform 등을 통한 인프라 구축 시에도 차이점이 있습니다. AWS는 각 컴포넌트들에 대한 트래픽 제어를 담당하는 Security Group이 직접 연결됩니다.

하지만 Azure의 경우에는 Network Interface라는 컴포넌트에 의해 간접적으로 Security Group과 연결됩니다. 물론 예외도 있습니다. Azure의 서브넷은 NSG(Network Security Group)과 직접 연결될 수 있으며, 서브넷에 속한 모든 리소스는 해당 NSG에 영향을 받습니다. 즉, Azure의 NSG는 리소스에 직접 연결되지 않고 NIC또는 서브넷에 연결될 수 있습니다.

 

위와 같은 표로 특징을 알아볼 수 있습니다. 하지만 Azure의 NSG같은 경우에는 NIC와 일대일 대응을 하지만, NSG가 하나의 NIC에만 대응을 할 수 있는 것은 아닙니다. 즉 NIC마다 하나의 NSG를 등록할 수 있지만, NSG는 재활용 가능하여 다른 NIC에도 연결될 수 있음을 의미합니다. 

 

• AWS: Security Group은 리소스에 직접 연결되어 세부적으로 제어가 가능하며, 리소스 단위로 유연한 설정이 가능합니다.
• Azure: NSG는 NIC 또는 서브넷에 연결되어 네트워크 인터페이스 또는 서브넷 단위로 보안 규칙을 정의하며, 이를 통해 네트워크 전반에서 규칙을 일괄 적용할 수 있는 유연성을 제공합니다.

Azure의 NSG는 서브넷 레벨에서 네트워크를 통합적으로 관리하기에 적합하며, AWS의 SG는 리소스별로 세밀한 보안 설정이 필요한 경우 유리합니다. 두 접근 방식은 환경에 따라 장단점이 달라지므로 요구 사항에 맞게 선택해야 합니다.

이로써 Azure의 네트워크 트래픽 전달 과정 및 IaaS로의 인프라 구축 시 주의해야 할 점에 대해 간략히 알아봤습니다.

긴 글 읽어주셔서 감사합니다 😊