다음을 통해 공유


Azure Container Apps 환경에서 네트워킹

Azure Container Apps는 고유한 VNet(가상 네트워크)이 있는 환경의 컨텍스트에서 실행됩니다.

기본적으로 컨테이너 앱 환경은 자동적으로 생성되는 VNet을 이용하여 생성됩니다. 네트워크를 세밀하게 제어하기 위하여 환경을 생성할 때 기존의 VNet을 제공할 수 있습니다. 생성된 VNet 또는 기존의 VNet을 사용하여 환경을 생성한 뒤에는 네트워크 유형을 변경할 수 없습니다.

생성된 VNet은 다음과 같은 특성을 사용합니다.

화면은 다음과 같습니다.

  • Microsoft 테넌트에서 생성되므로 액세스할 수 없습니다.
  • 인터넷을 통해 공개적으로 액세스할 수 있습니다.
  • 엔드포인트에 액세스할 수 있는 인터넷만 연결할 수 있습니다.

또한 수신 IP 제한 및 컨테이너 앱 수준 수신 컨트롤과 같은 네트워킹 기능의 제한된 하위 집합만 지원합니다.

다음과 같은 더 많은 Azure 네트워킹 기능이 필요한 경우에는 기존 VNet을 사용합니다.

  • Application Gateway와 통합
  • 네트워크 보안 그룹
  • 가상 네트워크의 프라이빗 엔드포인트 뒤에 있는 리소스와 통신

사용 가능한 VNet 기능은 환경 선택에 따라 달라집니다.

환경 선택

Container Apps에는 두 가지 환경 형식이 있으며 이러한 환경 형식은 같지만 몇 가지 주요 차이점이 있는 네트워킹 특징을 상당 수 공유합니다.

환경 유형 설명 지원 계획 형식
워크로드 프로필 UDR(사용자 정의 경로) 및 NAT Gateway를 통한 송신을 지원합니다. 필요한 최소 서브넷 크기는 /27입니다. 사용량, 전용
사용량 과금만 UDR(사용자 정의 경로), NAT Gateway를 통한 송신, 원격 게이트웨이를 통한 피어링 또는 기타 사용자 지정 송신을 지원하지 않습니다. 필요한 최소 서브넷 크기는 /23입니다. 소비

액세스 가능성 수준

컨테이너 앱이 환경 수준에서 공개 수신 또는 VNet 내에서만 수신을 허용할지 여부를 구성할 수 있습니다.

접근성 수준 설명
외부 컨테이너 앱이 공개 요청을 수락하도록 허용합니다. 외부 환경은 외부 공용 IP 주소에 가상 IP를 사용하여 배포됩니다.
Internal 내부 환경에는 공개 엔드포인트가 없으며 이 환경은 내부 IP 주소에 매핑된 VIP(가상 IP)를 통해 배포됩니다. 내부 엔드포인트는 Azure ILB(내부 부하 분산 장치)이며 IP 주소는 사용자 지정 VNet의 개인 IP 주소 목록에서 발급됩니다.

사용자 지정 VNet 구성

사용자 지정 VNet을 만들 때는 다음 상황에 유의하세요.

  • 컨테이너 앱이 모든 외부 액세스를 제한하도록 하려면 내부 Container Apps 환경을 만듭니다.

  • 고유한 VNet을 사용하는 경우 배포하는 컨테이너 앱 환경의 전용 서브넷을 제공해야 합니다. 이 서브넷은 다른 서비스에서 사용할 수 없습니다.

  • 네트워크 주소는 환경을 만들 때 정의된 서브넷 범위에서 할당됩니다.

    • Container Apps 환경에서 사용하는 서브넷 범위를 정의할 수 있습니다.

    • 환경을 내부로 배포하여 환경에 대한 인바운드 요청을 VNet으로만 제한할 수 있습니다.

참고 항목

고유한 가상 네트워크를 제공하면 관리되는 리소스가 추가 생성됩니다. 이러한 리소스에는 관련 속도로 비용이 발생합니다.

컨테이너 앱을 중심으로 네트워크를 설계하면 가상 네트워크 계획을 참조하세요.

Azure Container Apps 환경에서 기존 VNET을 사용하거나 직접 제공할 수 있는 방법을 보여 주는 다이어그램.

참고 항목

Container Apps 환경에서 VNet을 사용 중인 경우 다른 리소스 그룹이나 구독 간에 VNet을 이동할 수 없습니다.

HTTP 에지 프록시 동작

Azure Container Apps는 Envoy 프록시를 에지 HTTP 프록시로 사용합니다. TLS(전송 계층 보안)는 에지에서 종료되고 요청은 트래픽 분할 규칙에 따라 라우팅되며 트래픽을 올바른 애플리케이션으로 라우팅합니다.

HTTP 애플리케이션은 HTTP 요청 및 연결 수에 따라 크기가 조정됩니다. Envoy는 클러스터 내에서 내부 트래픽을 라우팅합니다.

다운스트림 연결은 HTTP1.1 및 HTTP2를 지원하며 Envoy는 클라이언트 연결에서 업그레이드를 요구하는 경우 연결을 자동으로 검색하고 업그레이드합니다.

업스트림 연결은 수신 개체에서 transport 속성을 설정하는 방식으로 정의됩니다.

수신 구성

수신 섹션에서 다음 설정을 구성할 수 있습니다.

  • 접근성 수준: 환경에서 외부적으로 또는 내부적으로 액세스할 수 있는 것으로 컨테이너 앱을 설정할 수 있습니다. 환경 변수 CONTAINER_APP_ENV_DNS_SUFFIX는 환경의 FQDN(정규화된 도메인 이름) 접미사를 자동으로 확인하는 데 사용됩니다. 같은 환경 내에서 컨테이너 앱 간에 통신하는 경우 앱 이름을 사용할 수도 있습니다. 앱에 액세스하는 방법에 대한 자세한 내용은 Azure Container Apps의 수신을 참조하세요.

  • 트래픽 분할 규칙: 애플리케이션의 여러 수정 버전 간에 트래픽 분할 규칙을 정의할 수 있습니다. 자세한 내용은 트래픽 분할을 참조하세요.

다양한 네트워킹 시나리오에 대한 자세한 내용은 Azure Container Apps의 수신을 참조하세요.

포털 종속성

Azure Container Apps의 모든 앱에는 URL이 두 개 있습니다.

Container Apps 런타임은 처음에 앱에 액세스하는 데 사용되는 FQDN(정규화된 도메인 이름)을 생성합니다. 컨테이너 앱의 FQDN은 Azure Portal에서 컨테이너 앱의 개요 창에 있는 애플리케이션 URL을 참조하세요.

두 번째 URL도 자동으로 생성됩니다. 이 위치는 로그 스트리밍 서비스와 콘솔에 대한 액세스 권한을 부여합니다. 필요한 경우 방화벽 또는 프록시의 허용 목록에 https://azurecontainerapps.dev/를 추가해야 할 수 있습니다.

포트 및 IP 주소

다음 포트는 인바운드 연결을 위해 노출됩니다.

프로토콜 포트
HTTP/HTTPS 80, 443

IP 주소는 다음 유형으로 세분화됩니다.

Type 설명
공용 인바운드 IP 주소 외부 배포의 애플리케이션 트래픽과 내부 및 외부 배포 모두의 관리 트래픽에 사용됩니다.
아웃바운드 공용 IP 가상 네트워크에서 나가는 아웃바운드 연결의 "원본" IP로 사용됩니다. 이러한 연결은 VPN을 통해 라우팅되지 않습니다. 아웃바운드 IP는 시간이 경과함에 따라 변할 수 있습니다. 워크로드 프로필 환경에서는 Container Apps 환경의 아웃바운드 트래픽에 NAT Gateway이나 기타 프록시만 사용할 수 있습니다.
내부 부하 분산 장치 IP 주소 이 주소는 내부 배포에만 존재합니다.

서브넷

가상 네트워크 통합은 전용 서브넷에 따라 다릅니다. 서브넷에 IP 주소를 할당하는 방법과 지원되는 서브넷 크기는 Azure Container Apps에서 사용하는 플랜에 따라 달라집니다.

서브넷 크기를 신중하게 선택합니다. Container Apps 환경을 만든 후에는 서브넷 크기를 수정할 수 없습니다.

환경 형식에 따라 서브넷 요구 사항이 다릅니다.

  • /27은 가상 네트워크 통합에 필요한 최소 서브넷 크기입니다.

  • 서브넷은 Microsoft.App/environments에 위임되어야 합니다.

  • 외부 수신과 함께 외부 환경을 사용하는 경우 인바운드 트래픽은 서브넷이 아닌 인프라의 공용 IP를 통해 라우팅됩니다.

  • Container Apps는 서브넷과 통합을 위해 IP 주소 12개를 자동으로 예약합니다. 인프라 통합에 필요한 IP 주소 수는 환경의 규모 요구에 따라 달라지지 않습니다. 추가 IP 주소는 사용하는 워크로드 프로필 형식에 따라 다음 규칙에 의해 할당되고 더 많은 IP 주소는 환경의 워크로드 프로필에 따라 할당됩니다.

    • 전용 워크로드 프로필: 컨테이너 앱을 스케일 아웃하면 노드마다 IP 주소 하나가 있습니다.

    • 사용량 워크로드 프로필: 각 IP 주소는 여러 복제본 간에 공유될 수 있습니다. 앱에 필요한 IP 주소 수를 계획할 때 복제본 10개당 IP 주소 1개를 계획합니다.

  • 단일 수정 모드에서 수정 버전을 변경하면 가동 중지 시간이 없는 배포를 지원하기 위해 필요한 주소 공간은 짧은 시간 동안 두 배가 됩니다. 이로 인해 지정된 서브넷 크기에 실제로 사용할 수 있는 지원 복제본이나 노드가 영향을 받습니다. 다음 표에서는 CIDR 블록당 사용 가능한 최대 주소 수와 수평 스케일링에 대한 영향을 보여줍니다.

    서브넷 크기 사용할 수 있는 IP 주소1 최대 노드 수(전용 워크로드 프로필)2 최대 복제본 수(사용량 워크로드 프로필)2
    23/ 500 250 2,500
    /24 244 122 1,220
    /25 116 58 580
    /26 52 26 260
    /27 20 10 100

    1 사용할 수 있는 IP 주소는 서브넷 크기에서 Azure Container Apps 인프라에 필요한 IP 주소 12개를 크기입니다.
    2 단일 수정 모드의 앱을 고려합니다.

서브넷 주소 범위 제한 사항

서브넷 주소 범위는 다음과 같은 Azure Kubernetes Service에서 예약한 범위와 겹칠 수 없습니다.

  • 169.254.0.0/16
  • 172.30.0.0/16
  • 172.31.0.0/16
  • 192.0.2.0/24

또한 워크로드 프로필 환경에서는 다음 주소를 예약합니다.

  • 100.100.0.0/17
  • 100.100.128.0/19
  • 100.100.160.0/19
  • 100.100.192.0/19

CLI를 사용하여 서브넷 구성

Container Apps 환경이 생성되면 단일 서브넷의 리소스 ID를 제공합니다.

CLI를 사용하는 경우 서브넷 리소스 ID를 정의하는 매개 변수는 infrastructure-subnet-resource-id입니다. 서브넷은 인프라 구성 요소 및 사용자 앱 컨테이너를 호스트합니다.

소비 전용 환경에서 Azure CLI를 사용 중이며 platformReservedCidr 범위가 정의된 경우 두 서브넷 모두 platformReservedCidr에 정의된 IP 범위와 겹치지 않아야 합니다.

경로

UDR(사용자 정의 경로)

사용자 정의 경로(UDR) 및 NAT Gateway를 통한 제어된 송신은 워크로드 프로필 환경에서 지원됩니다. 소비 전용 환경에서는 이러한 기능이 지원되지 않습니다.

참고 항목

Azure Container Apps의 Azure Firewall에서 UDR을 사용하는 경우 특정 FQDN 및 서비스 태그를 방화벽의 허용 목록에 추가해야 합니다. 자세한 내용은 Azure Firewall을 사용하여 UDR 구성을 참조하세요.

  • 워크로드 프로필 환경에서 UDR을 사용하여 Azure Firewall 또는 기타 네트워크 어플라이언스 통해 컨테이너 앱에서 아웃바운드 트래픽을 제한할 수 있습니다.

  • UDR 구성은 Container Apps 환경 범위 외부에서 수행됩니다.

Container Apps에 대해 UDR을 구현하는 방법의 다이어그램.

Azure는 만들 때 가상 네트워크에 대한 기본 경로 테이블을 만듭니다. 사용자 정의 경로 테이블을 구현하여 가상 네트워크 내에서 트래픽이 라우팅되는 방식을 제어할 수 있습니다. 예를 들어 모든 트래픽을 방화벽으로 라우팅하는 UDR을 만들 수 있습니다.

Azure Firewall 사용하여 UDR 구성

사용자 정의 경로는 워크로드 프로필 환경에서만 지원됩니다. 사용 중인 리소스에 따라 다음 애플리케이션 및 네트워크 규칙을 방화벽의 허용 목록에 추가해야 합니다.

참고 항목

Azure Firewall 사용하여 아웃바운드 트래픽을 제한하도록 Container Apps에서 UDR을 설정하는 방법에 대한 가이드는 Container Apps 및 Azure Firewall 사용법을 참조하세요.

애플리케이션 규칙

애플리케이션 규칙은 애플리케이션 레이어를 기준으로 트래픽을 허용하거나 거부합니다. 시나리오에 따라 다음 아웃바운드 방화벽 애플리케이션 규칙이 필요합니다.

시나리오 FQDN 설명
모든 시나리오 mcr.microsoft.com, *.data.mcr.microsoft.com 이러한 MCR(Microsoft Container Registry) FQDN은 Azure Container Apps에서 사용되며 Azure Firewall에서 Azure Container Apps를 사용하는 경우 MCR의 이러한 애플리케이션 규칙이나 네트워크 규칙을 허용 목록에 추가해야 합니다.
ACR(Azure Container Registry) Your-ACR-address, *.blob.core.windows.net, login.microsoft.com 이러한 FQDN은 ACR 및 Azure Firewall에서 Azure Container Apps를 사용할 때 필요합니다.
Azure Key Vault Your-Azure-Key-Vault-address, login.microsoft.com 이러한 FQDN은 Azure Key Vault의 네트워크 규칙에 필요한 서비스 태그 외에 필요합니다.
관리 ID *.identity.azure.net, login.microsoftonline.com, *.login.microsoftonline.com, *.login.microsoft.com 이러한 FQDN은 Azure Container Apps의 Azure Firewall에서 관리 ID를 사용할 때 필요합니다.
Docker Hub 레지스트리 hub.docker.com, registry-1.docker.io, production.cloudflare.docker.com Docker Hub 레지스트리를 사용하고 방화벽을 통해 액세스하려는 경우 이러한 FQDN을 방화벽에 추가해야 합니다.
네트워크 규칙

네트워크 규칙은 네트워크 및 전송 레이어를 기준으로 트래픽을 허용하거나 거부합니다. 시나리오에 따라 다음 아웃바운드 방화벽 네트워크 규칙이 필요합니다.

시나리오 서비스 태그 설명
모든 시나리오 MicrosoftContainerRegistry, AzureFrontDoorFirstParty 이러한 MCR(Microsoft Container Registry) 서비스 태그는 Azure Container Apps에서 사용되며 Azure Firewall에서 Azure Container Apps를 사용하는 경우 MCR의 이러한 네트워크 규칙이나 애플리케이션 규칙을 허용 목록에 추가해야 합니다.
ACR(Azure Container Registry) AzureContainerRegistry, AzureActiveDirectory Azure Container Apps에서 ACR을 사용하는 경우 Azure Container Registry에서 사용하는 이러한 애플리케이션 규칙을 구성해야 합니다.
Azure Key Vault AzureKeyVault, AzureActiveDirectory 이러한 서비스 태그는 Azure Key Vault에 대한 애플리케이션 규칙의 FQDN 외에 필요합니다.
관리 ID AzureActiveDirectory Azure Container Apps에서 관리 ID를 사용하는 경우 관리 ID에서 사용하는 이러한 애플리케이션 규칙을 구성해야 합니다.

참고 항목

Azure Firewall에서 사용 중인 Azure 리소스가 이 문서에 나와 있지 않으면 서비스 태그 문서를 참조하세요.

NAT 게이트웨이 통합

NAT Gateway를 사용하여 워크로드 프로필 환경의 가상 네트워크에서 아웃바운드 인터넷 트래픽에 대한 아웃바운드 연결을 간소화할 수 있습니다.

서브넷에서 NAT Gateway를 구성할 때 NAT Gateway는 사용자 환경의 고정 공용 IP 주소를 제공합니다. 컨테이너 앱의 모든 아웃바운드 트래픽은 NAT Gateway의 고정 공용 IP 주소를 통해 라우팅됩니다.

환경 보안

Container Apps에 대한 네트워크를 완전히 잠그는 방법의 다이어그램.

다음 작업을 수행하여 수신 및 송신 네트워킹 트래픽 워크로드 프로필 환경을 완전히 보호할 수 있습니다.

Azure Container Apps 환경의 피어 투 피어 암호화

Azure Container Apps는 환경 내에서 피어 투 피어 TLS 암호화를 지원합니다. 이 기능을 사용하도록 설정하면 Azure Container Apps 환경 범위 내에서 유효한 프라이빗 인증서를 사용하여 환경 내의 모든 네트워크 트래픽이 암호화됩니다. 이러한 인증서는 Azure Container Apps에서 자동으로 관리됩니다.

참고 항목

기본적으로 P2P 암호화는 사용하지 않도록 설정되어 있습니다. 애플리케이션에 대해 P2P 암호화를 사용하도록 설정하면 부하가 높은 시나리오에서 응답 대기 시간이 늘어나고 최대 처리량이 줄어들 수 있습니다.

다음 예에서는 P2P 암호화가 사용하도록 설정된 환경을 보여 줍니다. P2P 암호화를 사용하도록 설정하여 트래픽을 암호화/복호화하는 방법을 보여 주는 다이어그램.

1 인바운드 TLS 트래픽은 환경 가장자리에 있는 수신 프록시에서 종료됩니다.

2 환경 내의 수신 프록시로 들어오고 나가는 트래픽은 프라이빗 인증서로 TLS 암호화되고 수신자에 의해 해독됩니다.

3 앱 A에서 앱 B의 FQDN으로 이루어진 호출은 먼저 에지 수신 프록시로 전송되고 TLS로 암호화됩니다.

4 앱 B의 앱 이름을 사용하여 앱 A에서 앱 B로 이루어진 호출은 앱 B로 직접 전송되며 TLS로 암호화됩니다.

Container Apps 환경 내 애플리케이션은 자동으로 인증됩니다. 그러나 Container Apps 런타임은 기본 제공된 P2P 암호화를 사용하는 애플리케이션 간의 액세스 제어에 대한 권한 부여를 지원하지 않습니다.

앱이 환경 외부의 클라이언트와 통신하는 경우 mTLS를 사용한 양방향 인증이 지원됩니다. 자세한 내용은 클라이언트 인증서 구성을 참조하세요.

다음 명령을 사용하여 P2P 암호화를 사용하도록 설정할 수 있습니다.

만들 때 다음 명령을 실행합니다.

az containerapp env create \
    --name <environment-name> \
    --resource-group <resource-group> \
    --location <location> \
    --enable-peer-to-peer-encryption

기존 컨테이너 앱의 경우 다음 명령을 실행합니다.

az containerapp env update \
    --name <environment-name> \
    --resource-group <resource-group> \
    --enable-peer-to-peer-encryption

DNS

  • 사용자 지정 DNS: VNet이 기본 Azure 제공 DNS 서버 대신 사용자 지정 DNS 서버를 사용하는 경우 확인되지 않은 DNS 쿼리를 168.63.129.16에 전달하도록 DNS 서버를 구성합니다. Azure 재귀 확인자는 이 IP 주소를 사용하여 요청을 확인합니다. NSG 또는 방화벽을 구성할 때 168.63.129.16 주소를 차단하지 마세요. 차단하면 Container Apps 환경이 올바르게 작동하지 않습니다.

  • VNet 범위 수신: 내부 환경에서 VNet 범위 수신을 사용하려는 경우 다음 방법 중 하나로 도메인을 구성합니다.

    1. 사용자 지정이 아닌 도메인: 사용자 지정 도메인을 사용하지 않으려면 Container Apps 환경의 기본 도메인을 Container Apps 환경의 고정 IP 주소로 확인하는 프라이빗 DNS 영역을 만듭니다. Azure 프라이빗 DNS 또는 자체 DNS 서버를 사용할 수 있습니다. Azure 프라이빗 DNS를 사용하는 경우 A 레코드를 사용하여 Container Apps 환경의 기본 도메인(<UNIQUE_IDENTIFIER>.<REGION_NAME>.azurecontainerapps.io)으로 명명된 프라이빗 DNS 영역을 만듭니다. A 레코드에는 이름 *<DNS Suffix>와 Container Apps 환경의 고정 IP 주소가 포함됩니다.

    2. 사용자 지정 도메인: 사용자 지정 도메인을 사용하려고 하고 기존 Container Apps 환경을 사용하고 있는 경우 공개적으로 확인 가능한 도메인을 사용하여 컨테이너 앱에 사용자 지정 도메인과 인증서를 추가합니다. 내부 컨테이너 앱 환경을 사용하는 경우에는 가상 네트워크 내에서만 클러스터에 액세스할 수 있으므로 DNS 바인딩에 관한 유효성 검사가 없습니다. 또한, Apex 도메인을 컨테이너 앱 환경의 고정 IP 주소로 확인하는 프라이빗 DNS 영역을 만듭니다. Azure 프라이빗 DNS 또는 자체 DNS 서버를 사용할 수 있습니다. Azure 프라이빗 DNS를 사용하는 경우 Container Apps 환경의 고정 IP 주소를 가리키는 A 레코드를 사용하여 Apex 도메인으로 명명된 프라이빗 DNS 영역을 만듭니다.

Azure Portal에 있는 컨테이너 앱 페이지의 사용자 지정 DNS 접미사에서 또는 Azure CLI az containerapp env list 명령을 사용하여 Container Apps 환경의 고정 IP 주소를 사용할 수 있습니다.

관리형 리소스

내부 또는 외부 환경을 자체 네트워크에 배포하면 환경이 호스트되는 Azure 구독에 새 리소스 그룹이 생성됩니다. 이 리소스 그룹에는 Azure Container Apps 플랫폼에서 관리되는 인프라 구성 요소가 포함되어 있습니다. 이 그룹이나 리소스 그룹 자체의 서비스를 수정하지 마세요.

워크로드 프로필 환경

환경이 호스트되는 Azure 구독에서 만든 리소스 그룹 이름에는 기본적으로 ME_ 접두사가 추가되며 컨테이너 앱 환경을 만들 때 리소스 그룹 이름을 사용자 지정할 수 있습니다.

외부 환경의 경우 이 리소스 그룹에는 외부 환경과 부하 분산 장치에 대한 인바운드 연결에 특별히 사용되는 공용 IP 주소가 포함되어 있습니다. 내부 환경의 경우 리소스 그룹에는 Load Balancer만 포함됩니다.

표준 Azure Container Apps 청구 외에 다음 요금도 청구됩니다.

소비 전용 환경

환경이 호스트되는 Azure 구독에서 만든 리소스 그룹 이름에는 기본적으로 MC_ 접두사가 추가되며 컨테이너 앱을 만들 때 리소스 그룹 이름을 사용자 지정할 수 없습니다. 이 리소스 그룹에는 환경과 부하 분산 장치에서 아웃바운드 연결에 특별히 사용되는 공용 IP 주소가 포함되어 있습니다.

표준 Azure Container Apps 청구 외에 다음 요금도 청구됩니다.

  • 송신용 표준 고정 공용 IP 1개 SNAT(Source Network Address Translation) 이슈로 인해 송신용 IP가 더 많이 필요할 경우 지원 티켓을 열어 재정의를 요청합니다.

  • 표준 부하 분산 장치 2개(내부 환경을 사용하는 경우) 또는 표준 부하 분산 장치 1개(외부 환경을 사용하는 경우). 각 부하 분산 장치에는 6개 미만의 규칙이 있습니다. 처리된 데이터 비용(GB 단위)에는 관리 작업에 사용되는 수신과 송신 모두 포함됩니다.

다음 단계