Azure Virtual Network 피어링

• Azure Virtual Network 피어링을 사용하면 같은 지역이나 다른 지역에 있는 가상 네트워크를 연결할 수 있음 -> 리소스 간에 안전한 통신을 제공, 인터넷에 서비스 노출 방지

지역 가상 네트워크 피어링

• 동일한 지역에 있는 Azure 가상 네트워크를 연결
  
  
  

전역 가상 네트워크 피어링

• 서로 다른 지역에 있는 Azure 가상 네트워크를 연결
• 다른 Azure Government 클라우드 지역에 있는 가상 네트워크의 글로벌 피어링은 허용되지 않음
  
  
  

VNet 피어링 이점

1. 프라이빗 네트워크 연결 : 피어링된 가상 네트워크 간의 네트워크 트래픽은 프라이빗 (Azure 백본 네트워크) -> 공용 인터넷, 게이트웨이 또는 암호화가 필요하지 않음
2. 강력한 성능 : 리소스 간에 대기 시간이 짧고 대역폭이 높은 연결
3. 기본 통신 : 한 가상 네트워크의 리소스가 다른 가상 네트워크의 리소스와 통신 가능
4. 원활한 데이터 전송 : Azure 구독, 배포 모델 및 Azure 지역 간에 데이터를 전송 가능
5. 리소스 중단 없음 : 리소스에 대한 가동 중지 시간이 필요하지 않음
   
   
   

Azure VPN Gateway

• 가상 네트워크 A 및 가상 네트워크 B는 각각 허브 가상 네트워크와 피어링됨

• 가상 네트워크 B는 원격 VPN 게이트웨이를 사용하여 게이트웨이 서브넷을 포함한 허브의 리소스에 액세스
  
  
  

• VPN Gateway 특징

1. 각 가상 네트워크에는 하나의 VPN Gateway
2. 지역 및 글로벌 가상 네트워크 피어링 모두에 대해 지원
3. 피어링된 가상 네트워크가 게이트웨이를 공유하고 리소스에 액세스
4. 가상 네트워크의 네트워크 보안 그룹을 적용 가능
   
   
   

피어링 확장

• 피어링 확장 : 네트워크 A와 B 간, 네트워크 B와 C 간에 가상 네트워크 피어링을 설정 -> 네트워크 A와 C 간의 피어링 통신 기능이 가능하도록 확장
• 피어링 확장 방법

1. 허브 및 스포크 네트워크 : 허브 가상 네트워크가 NVA(네트워크 가상 어플라이언스) 또는 Azure VPN Gateway와 같은 인프라 구성 요소를 호스트 -> 래픽은 허브 가상 네트워크의 NVA 또는 VPN 게이트웨이를 통해 이동 가능
2. 사용자 정의 경로(UDR) : 사용자 정의 경로의 다음 홉이 피어링된 가상 네트워크 또는 VPN 게이트웨이에 있는 가상 머신의 IP 주소가 될 수 있음
3. 서비스 체이닝 : 한 가상 네트워크에서 가상 어플라이언스 또는 게이트웨이로 트래픽을 전송하는 데 사용 (UDR은 피어된 네트워크를 정의)

Azure DNS

• Azure DNS : DNS 도메인을 위한 Azure 호스팅 서비스
  
  
  

• DNS : 사람이 읽을 수 있는 도메인 이름(예: www.wideworldimports.com)을 알려진 IP 주소로 변환하는 데 필수적인 역할
  
  
  

• DNS 특징

1. DNS는 전 세계 서버에서 호스트되는 글로벌 디렉터리를 사용
2. DNS서버는 최근에 액세스한 또는 사용된 도메인 이름과 해당 IP 주소에 대한 로컬 캐시를 유지
3. DNS서버는 IP 주소와 DNS 서버가 권한이 있는 모든 호스트 또는 하위 도메인의 키-값 쌍 데이터베이스를 유지
4. 온-프레미스의 경우 DNS 설정은 네트워크내 서버에서 제공
5. 외부 위치에서 웹에 액세스하는 경우 DNS 설정은 ISP(인터넷 서비스 공급자)에서 제공
   
   
   

• 도메인 이름 조회 프로세스

1. 도메인 이름이 단기 캐시에 저장된 경우 DNS 서버는 도메인 요청을 확인
2. 도메인이 캐시에 없으면 웹에서 하나 이상의 DNS 서버에 연결하여 일치하는 항목이 있는지 확인
3. 일치하는 항목이 검색되면 DNS 서버가 로컬 캐시를 업데이트하고 요청을 확인
4. 적절한 수의 DNS 검사를 했음에도 도메인을 찾을 수 없는 경우, DNS 서버는 도메인 찾을 수 없음 에러로 응답
   
   
   

DNS 레코드

• DNS 서버 구성 정보는 DNS 서버의 영역에 파일로 저장. 각 파일을 레코드라고 함
• 레코드 형식

1. A : 호스트 레코드이며 가장 일반적인 유형의 DNS 레코드. 도메인 또는 호스트 이름을 IP 주소에 매핑
2. CNAME : 한 도메인 이름에서 다른 도메인 이름으로 별칭을 만드는 데 사용되는 정식 이름 레코드 (서로 다른 도메인 이름이 모두 동일한 웹 사이트에 액세스하는 경우 사용)
3. MX : 메일 교환 레코드 (메일 서버에 메일 요청을 매핑)
4. TXT : 텍스트 레코드 (텍스트 문자열을 도메인 이름과 연결)
   
   
   

• 레코드 집합 : 레코드 집합을 사용하여 단일 레코드에 여러 리소스를 정의

www.wideworldimports.com.     3600    IN    A    127.0.0.1
www.wideworldimports.com.     3600    IN    A    127.0.0.2

Azure DNS란?

• 전 세계적으로 분산된 이름 서버 인프라를 사용하여 도메인을 호스트하고 관리
• 기존 Azure 자격 증명을 사용하여 모든 도메인을 관리
• 도메인 등록은 타사 도메인 등록 기관을 통해 등록
• Azure DNS 사용이유 (Azure Resource Manager 서비스를 기반)

1. 보안 강화
   • 역할 기반 액세스 제어
   • 활동 로그를 통한 리소스 변경 내용을 추적
   • 리소스 잠금 기능
2. 사용 편의성
   • Azure 서비스와 동일한 Azure 자격 증명, 지원 계약 및 대금 청구를 사용
   • Azure portal 등을 통한 편리한 도메인 및 레코드를 관리
3. 프라이빗 DNS 도메인
   • 외부 도메인 이름을 IP 주소로 변환하는 과정을 처리
   • 가상 네트워크 안에서, 그리고 가상 네트워크들 간에 VM(가상 머신) 이름 확인을 제공하여 사용자 지정 DNS 솔루션을 만들 필요가 없음
   • 프라이빗 영역을 사용하면 Azure에서 제공하는 이름 대신 사용자 지정 도메인 이름을 사용 (별도 솔루션이 필요 없음)
4. 별칭 레코드 집합 : 별칭 레코드 집합은 Azure 리소스를 가리킬 수 있음
   
   
   

Azure DNS 구성 방식

방식1. 공용 DNS영역 구성

• DNS 영역을 사용하여 wideworldimports.com 같은 도메인에 대한 DNS 레코드를 호스트
  
  
  

1단계, Azure에서 DNS영역 만들기

• DNS영역을 만들 때 필요한 정보

1. 구독
2. 리소스 그룹
3. 이름
4. 리소스 그룹 위치
   
   
   

2단계, Azure DNS 이름 서버 가져오기

• NS(이름 서버) 레코드에서 이름 서버 세부 정보를 가져와야 합니다. 이러한 세부 정보를 사용하여 도메인 등록 기관의 정보를 업데이트하고 Azure DNS 영역을 가리킴
  
  
  

3단계, 도메인 등록 기관 설정 업데이트

• 도메인 소유자는 도메인 등록 기관에서 제공하는 도메인 관리 애플리케이션에 로그인 -> 관리 애플리케이션에서 NS 레코드를 편집하고 NS 세부 정보를 Azure DNS 이름 서버 세부 정보와 일치하도록 변경 -> 도메인 위임
  
  
  

4단계, 도메인 이름 서비스 위임 확인

• 위임된 도메인이 도메인에 대해 만든 Azure DNS 영역을 가리키는지 확인
  
  
  

• 확인 커맨드
  : Azure DNS 영역이 설정되면 SOA 레코드가 자동 생성 -> SOA 레코드는 도메인을 나타내며 다른 DNS 서버가 인터넷에서 도메인을 검색할 때 참조 지점이 됨

nslookup -type=SOA wideworldimports.com

5단계, 사용자 지정 DNS 설정 구성

• 리소스에는 DNS 영역에 A 레코드 또는 CNAME으로 고유한 사용자 지정 설정 필요
  
  
  

방식2. 프라이빗 DNS 영역 구성

• 프라이빗 DNS 영역은 인터넷에서 볼 수 없으므로 도메인 등록 기관을 사용할 필요가 없음
  
  
  

1단계, 프라이빗 DNS 영역 만들기

• Azure Portal에서 프라이빗 DNS 영역을 검색 -> 영역 이름 및 리소스 그룹을 입력
  
  
  

2단계, 가상 네트워크 식별

• 이름 확인이 지원되어야 하는 VM에 연결된 가상 네트워크를 식별
  
  
  

3단계, 가상 네트워크를 프라이빗 DNS 영역에 연결

• 가상 네트워크에 프라이빗 DNS 영역을 연결하려면 가상 네트워크 링크를 생성
  
  
  

별칭 레코드를 사용하여 동적으로 리소스 이름 확인

• A 레코드 및 CNAME 레코드가 부하 분산 장치와 같은 Azure 리소스에 대한 직접 연결 지원 불가 -> 별칭레코드 활용

• 부하분산 관련 리소스인 Azure Traffic Manager 프로필 또는 Azure Content Delivery Network 엔드포인트는 Apex 수준에서 지원 불가 -> 별칭 레코드 활용
  
  
  

• apex 도메인 : 도메인의 최고 수준 (NS 및 SOA. NS 및 SOA 레코드, DNS영역 만들 때 자동 생성)
  
  
  

• 별칭레코드 : 영역 Apex 도메인이 DNS 영역에서 다른 Azure 리소스를 참조 가능
  
  
  

• 별칭레코드가 가리킬 수 있는 Azure 리소스

1. Traffic Manager 프로필
2. Azure Content Delivery Network 엔드포인트
3. 공용 IP 리소스
4. Front Door 프로필
   
   
   

• 특징

1. 대상 리소스의 수명을 주기적으로 추적해 대상 리소스 변경 내용이 DNS 영역에 자동으로 적용
2. 영역 Apex에서 부하 분산 애플리케이션을 지원
3. 다음 DNS 영역 레코드 형식 지원
   • A: IPv4 도메인 이름 매핑 레코드.
   • AAAA: IPv6 도메인 이름 매핑 레코드.
   • CNAME: 도메인의 별칭, A 레코드에 대한 링크.
     
     
     

• 용도

1. 매달린 DNS 레코드(dangling DNS records) 방지 : DNS 영역 레코드가 IP 주소 변경 내용으로 업데이트되지 않는 경우에 발생 -> 별칭 레코드는 DNS 레코드의 수명 주기를 Azure 리소스와 긴밀하게 연결하여 dangling 참조를 방지.
2. IP 주소 변경 시 DNS 레코드 집합 자동 업데이트 : 리소스, 서비스 또는 애플리케이션의 기본 IP 주소가 변경되면 별칭 레코드는 연결된 모든 DNS 레코드를 자동으로 새로 고치도록 함.
3. 영역 Apex에서 부하 분산 애플리케이션 호스트 : 별칭 레코드는 Traffic Manager에 대한 영역 Apex 리소스 라우팅을 허용.
4. 영역 Apex가 Azure Content Delivery Network 엔드포인트를 가리키도록 지정 : 이제 별칭 레코드를 사용하여 Azure Content Delivery Network 인스턴스를 직접 참조 가능.

Azure 가상 네트워크

• Azure 가상 네트워크 : Azure 클라우드 리소스를 논리적으로 격리 -> 서로 다른 Azure 리소스 간 상호 통신, 인터넷 통신 및 온-프레미스 네트워크 통신을 안전하게 수행 가능
  
  
  

• 특징

1. Azure에서 VPN(가상 사설망)을 프로비저닝하고 관리 가능
2. 고유한 CIDR(Classless Interdomain Routing) 블록을 가짐
3. 다른 가상 네트워크 및 온-프레미스 네트워크에 연결 가능
4. 가상 네트워크에 대한 DNS 서버 설정을 제어 가능
5. 가상 네트워크를 서브넷으로 구분 가능

• 활용 시나리오

1. 프라이빗 클라우드만 사용하는 전용 가상 네트워크 :
2. 가상 네트워크를 사용하여 안전하게 데이터 센터 확장 : 기존의 사이트 간 VPN을 빌드하여 데이터 센터 용량을 안전하게 확장
3. 하이브리드 클라우드 시나리오 사용 : 모든 형식의 온-프레미스 시스템에 클라우드 기반 애플리케이션을 안전하게 연결
   
   
   

서브넷

• Azure 서브넷 : 가상 네트워크 내에서 논리적 구분을 구현하는 방법
  
  
  

• 특징

1. 각 서브넷은 가상 네트워크 주소 공간에 속하는 IP 주소 범위를 포함
2. 서브넷의 주소 범위는 가상 네트워크의 주소 공간 내에서 고유해야 함
3. 하나의 서브넷에 대한 범위는 동일한 가상 네트워크의 다른 서브넷 IP 주소 범위와 겹치지 않아야 함
4. CIDR 표기법을 사용하여 서브넷의 IP 주소 공간을 지정
   
   
   

• 예약된 주소 (아래는 192.168.1.0/24의 IP 주소 범위에서의 예시)

• 서브넷 사용 시 고려사항

1. 서비스 요구 사항을 고려 : 서브넷 내부 및 외부로 허용되어야 하는 트래픽 유형 및 라우팅에 대한 특정 요구 사항이 있음
2. 네트워크 가상 어플라이언스를 고려 : Azure의 기본 라우팅을 재정의하여 서브넷 간 Azure 라우팅을 방지
3. 네트워크 보안 그룹을 고려 : 각 네트워크 보안 그룹에는 원본과 대상 간의 트래픽을 허용하거나 거부하는 규칙이 있음
4. 프라이빗 링크를 고려 : Azure Private Link는 가상 네트워크에서 Azure PaaS(Platform as a Service), 고객 소유 또는 Microsoft 파트너 서비스에 대한 프라이빗 연결을 제공
   
   
   

가상 네트워크 만들기

• 주의사항

1. 조직에서 아직 사용하지 않는 IP 주소 공간을 사용하도록 계획
2. IP 주소 공간을 만든 후에는 변경 불가
3. 하나 이상의 서브넷을 정의 필요
4. 네트워크에 대한 Azure 구독, 리소스 그룹, 가상 네트워크 이름 및 서비스 지역을 제공해야 함
   
   
   

ip주소 지정

• 다른 Azure 리소스, 온-프레미스 네트워크 및 인터넷과 통신하기 위해 Azure 리소스에 IP 주소를 할당
• private ip : Azure 가상 네트워크 및 온-프레미스 네트워크 내에서 통신
• public ip : 리소스가 인터넷과 통신

• 고정ip주소 적합 상황

1. DNS 이름 확인(IP 주소를 변경하려면 A 레코드를 업데이트해야 하는 경우)
2. 앱 또는 서비스에 고정 IP 주소를 사용해야 하는 IP 주소 기반 보안 모델
3. TLS/SSL 인증서가 IP 주소에 연결
4. IP 주소 범위를 사용하여 트래픽을 허용하거나 거부하는 방화벽 규칙
5. 도메인 컨트롤러 및 DNS 서버와 같은 역할 기반 가상 머신.
   
   
   

• public ip 할당 시 고려사항

1. 동적 주소 : 공용 IP 주소가 Azure 리소스에 연결되고 처음으로 시작된 후에 할당 -> 가상 머신과 같은 리소스가 중지(할당 취소)된 다음, Azure를 통해 다시 시작되면 동적 주소가 변경
2. 고정 주소 : 공용 IP 주소를 만들 때 할당 -> 공용 IP 주소 리소스를 삭제할 때까지 해제되지 않음
   
   
   

• public ip 주소 리소스 연결

1. 가상 머신 네트워크 인터페이스, 인터넷 연결 부하 분산 장치, VPN 게이트웨이 및 애플리케이션 게이트웨이와 연결 가능
   
   
   

• private ip 주소 리소스 연결

1. 가상 머신 네트워크 인터페이스, 내부 부하 분산 장치 및 애플리케이션 게이트웨이와 연결 가능
   
   
   

네트워크 보안 그룹

• 네트워크 보안 그룹 : 가상 네트워크의 리소스에 대한 네트워크 트래픽을 제한하는 방법
  
  
  

• 특징

1. 인바운드 또는 아웃바운드 네트워크 트래픽을 허용하거나 거부하는 보안 규칙 목록이 포함
2. 서브넷 또는 네트워크 인터페이스(NIC(네트워크 인터페이스 카드))에 연결
3. 여러 번 연결 가능
   
   
   

• DMZ : 가상 네트워크와 인터넷 내의 리소스 간에 버퍼 역할 서브넷 (네트워크 보안 그룹 설정을 통해 만들 수 있음)
  
  
  

• 보안규칙

1. 각 보안 규칙에는 우선 순위 값이 할당 -> 네트워크 보안 그룹에 대한 모든 보안 규칙은 우선 순위에 따라 처리
2. 기본 보안 규칙은 제거 불가

• 예제1) 인바운드 트래픽 규칙 : 가상 네트워크 및 Azure 부하 분산 장치의 트래픽을 제외한 모든 인바운드 트래픽을 거부

• 예제2) 아웃바운드 트래픽 규칙 : 인터넷 및 가상 네트워크로의 아웃바운드 트래픽만 허용

• 보안그룹 규칙 순서

1. 인바운드 트래픽
   1. 서브넷에 대한 네트워크 보안 그룹 보안 규칙을 처리
   2. 네트워크 인터페이스에 대한 보안 규칙을 처리
2. 아웃바운드 트래픽 (인바운드 트래픽 역순)
   1. 네트워크 인터페이스에 대한 네트워크 보안 그룹 보안 규칙을 평가
   2. 서브넷에 대한 보안 규칙을 평가

• 보안그룹 설정 시 고려사항

1. 모든 트래픽 허용 : 기본 Azure 보안 규칙에 따라 서브넷 또는 NIC를 통한 모든 네트워크 트래픽을 허용 -> 가상 머신을 서브넷 내에 배치하거나 네트워크 인터페이스를 활용하는 경우 서브넷 또는 NIC를 네트워크 보안 그룹과 연결할 필요가 없음
2. 허용 규칙의 중요성을 고려 : 네트워크 보안 그룹에 서브넷 또는 NIC가 있는 경우 각 수준에서 허용 규칙을 정의해야 함. 그렇지 않으면 허용 규칙 정의를 제공하지 않는 모든 수준에 대해 트래픽이 거부
3. 서브넷 내 트래픽을 고려 : 서브넷에 연결된 네트워크 보안 그룹에 대한 보안 규칙은 서브넷의 모든 가상 머신 간의 트래픽에 영향을 줄 수 있음
4. 규칙 우선 순위를 고려 : 네트워크 보안 그룹에 대한 보안 규칙은 우선 순위에 따라 처리
   
   
   

• 애플리케이션 보안 그룹 : 워크로드별로 가상 머신을 논리적으로 그룹화 -> 그룹화된 애플리케이션 보안 그룹에 따라 네트워크 보안 그룹 규칙을 정의할 수 있음 (워크로드별 보안 그룹)

Azure Container Instances (ACI)

• 동일한 물리적 하드웨어에서 여러 개의 격리된 운영 체제 인스턴스를 동시에 실행할 수 있음
• Container에 대한 내용은 kubernetes 개요 글 참고

구현 방법

• 컨테이너 그룹 : Azure Container Instances의 최상위 리소스 (동일한 호스트 머신(=host os?)에서 예약되는 컨테이너의 컬렉션)
  
  
  

• 특징

1. 컨테이너 그룹은 kubernetes의 POD와 유사 (수명 주기, 리소스, 로컬 네트워크, 스토리지 볼륨 공유)
2. Azure Container Instances는 그룹 내 모든 컨테이너의 리소스 요청을 함께 추가하여 리소스를 다중 컨테이너 그룹에 할당
3. 다중 컨테이너 그룹을 배포하는 두 가지 일반적인 방법은 ARM(Azure Resource Manager) 템플릿 및 YAML 파일
   
   
   

• 예시

1. 단일 호스트 컴퓨터에서 예약되며 DNS 이름 레이블이 할당
2. 하나의 노출된 포트를 사용하여 단일 공용 IP 주소를 노출
3. 그룹의 한 컨테이너가 포트 80에서 수신 대기합니다. 다른 컨테이너는 포트 1433에서 수신 대기
4. 이 그룹에는 Azure Files 파일 공유 두 개가 볼륨 탑재로 포함. 그룹의 각 컨테이너는 파일 공유 중 하나를 로컬로 탑재

Azure Container Apps

• Azure Container Apps : 컨테이너화된 애플리케이션을 실행하면서 인프라를 덜 유지하고 비용을 절감할 수 있는 서버리스 플랫폼 (서버 구성, 컨테이너 오케스트레이션 및 배포 세부 정보를 염려x)
  
  
  

• 특징

1. 컨테이너에 배포된 많은 마이크로 서비스에 걸쳐 있는 애플리케이션에 최적화
2. Kubernetes 및 Dapr, KEDA 및 envoy와 같은 오픈 소스 기술을 통해 제공
3. 서비스 검색 및 트래픽 분할과 같은 기능을 통해 Kubernetes 스타일 앱 및 마이크로 서비스를 지원
4. 트래픽에 따라 비율 크기 조정
5. 이벤트 기반 애플리케이션 아키텍처를 사용하도록 설정
6. 요청 시, 예약된 및 이벤트 기반 작업 실행을 지원
7. 기본 Kubernetes API에 대한 직접 액세스를 제공하지 않음
   
   
   

• ACA vs AKS 비교
  : 요약하면 ACA는 kubernetes 인프라에 대한 제어가 필요 없을 때, AKS는 kubernetes 인프라에 대한 제어가 필요할 때 활용