https://thedotnetblog.com/ko/tags/networking/Articles, tutorials and insights from the .NET community.Hugoko@thedotnetblog (The .NET Blog)@thedotnetblogTue, 19 May 2026 00:00:00 +0000https://thedotnetblog.com/ko/news/emiliano-montesdeoca/aspire-azure-enterprise-networking-private-endpoints/Tue, 19 May 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/ko/news/emiliano-montesdeoca/aspire-azure-enterprise-networking-private-endpoints/Aspire의 새로운 Azure 엔터프라이즈 네트워킹 지원을 통해 VNet, 프라이빗 엔드포인트, NAT 게이트웨이, NSG, 네트워크 보안 경계를 AppHost에서 직접 모델링할 수 있습니다. 인프라 드리프트가 필요 없습니다.<p>이 시나리오를 너무 많이 봤습니다. 앱이 완성됩니다. 데모가 훌륭합니다. 그런 다음 보안 체크리스트가 나타납니다: 스토리지를 공용 인터넷에서 제거하고, VNet 내에서 실행하고, 파트너 허용 목록을 위한 아웃바운드 IP를 제공하고, 올바른 서브넷만 올바른 서비스와 통신한다는 것을 증명합니다.</p> <p>이 시점에서 애플리케이션 모델과 인프라 모델이 유지 관리하기 어려운 방식으로 분리되기 시작합니다.</p> <p>Aspire의 새로운 Azure 엔터프라이즈 네트워킹 지원은 이 문제를 직접적으로 해결합니다. AppHost에서 해당 네트워크를 사용하는 리소스 옆에 네트워크 모양을 설명합니다.</p> <h2 id="구성-요소">구성 요소</h2> <p>각 Azure 네트워킹 개념이 무엇을 위한 것인지 요약:</p> <table> <thead> <tr> <th>기능</th> <th>사용 시기</th> <th>중요한 이유</th> </tr> </thead> <tbody> <tr> <td>가상 네트워크</td> <td>프라이빗 주소 공간이 필요할 때</td> <td>서브넷, 프라이빗 엔드포인트 및 라우팅을 위한 네트워크 경계</td> </tr> <tr> <td>서브넷</td> <td>VNet 내에서 워크로드를 분리해야 할 때</td> <td>시스템의 각 부분이 자체 주소 범위와 정책 표면을 가짐</td> </tr> <tr> <td>위임된 서브넷</td> <td>플랫폼 서비스(예: ACA)가 서브넷을 관리해야 할 때</td> <td>서비스가 VNet에 관리되는 인프라를 안전하게 배치할 수 있음</td> </tr> <tr> <td>NAT 게이트웨이</td> <td>예측 가능한 아웃바운드 공용 IP가 필요할 때</td> <td>허용 목록 및 감사를 위한 안정적인 주소</td> </tr> <tr> <td>프라이빗 엔드포인트</td> <td>PaaS 리소스에 프라이빗하게 접근하고 싶을 때</td> <td>VNet 내에 해당 서비스의 프라이빗 IP를 배치하고 공용 노출 제거</td> </tr> <tr> <td>NSG</td> <td>서브넷 수준의 트래픽 규칙이 필요할 때</td> <td>서브넷별 인바운드 및 아웃바운드 트래픽에 대한 명시적 허용/거부</td> </tr> </tbody> </table> <h2 id="apphost에서-설명하기">AppHost에서 설명하기</h2> <p>여기서 핵심 변화는 시간이 지남에 따라 앱 모델에서 멀어지는 별도의 Bicep 파일이 아니라 해당 네트워크를 사용하는 리소스 <em>옆</em>에 네트워크를 모델링한다는 것입니다.</p> <p>AppHost에서 다음을 수행할 수 있습니다:</p> <ul> <li><code>AddVirtualNetwork()</code> 및 <code>AddSubnet()</code>으로 VNet 및 서브넷 만들기</li> <li>안정적인 아웃바운드 IP를 위해 서브넷에 NAT 게이트웨이 연결</li> <li>스토리지, Key Vault, SQL 및 기타 PaaS 서비스에 대한 프라이빗 엔드포인트 만들기</li> <li>인바운드 및 아웃바운드 보안 규칙으로 NSG 정의</li> <li>교차 리소스 정책을 위한 네트워크 보안 경계 구성</li> </ul> <p>결과적으로 <code>azd up</code>을 실행하면 인프라가 앱 모델이 필요하다고 말하는 것과 일치합니다. 수동으로 유지 관리되는 템플릿이 말하는 것이 아닙니다.</p> <h2 id="실제-애플리케이션에-중요한-이유">실제 애플리케이션에 중요한 이유</h2> <p>Aspire에서 네트워크가 모델링되면 훨씬 쉬워지는 몇 가지:</p> <p><strong>Key Vault 및 스토리지를 위한 프라이빗 엔드포인트</strong> — 해당 리소스에 <code>WithPrivateEndpoint()</code>를 설명하면 Aspire가 DNS 영역 구성 및 엔드포인트 연결을 처리합니다. 앱은 절대 변경되지 않습니다.</p> <p><strong>일관된 아웃바운드 IP</strong> — 관련 서브넷에 NAT 게이트웨이를 추가하면 앱의 모든 아웃바운드 요청이 알려진 안정적인 IP를 통해 이동합니다. 파트너가 허용 목록에 추가할 수 있습니다. 감사자가 추적할 수 있습니다.</p> <p><strong>코드에서 NSG 규칙</strong> — 포털을 클릭하거나 Bicep 스니펫을 유지 관리하는 대신 보안 규칙이 보호하는 리소스 옆 AppHost에 존재합니다.</p> <p>이것이 데모를 흥미롭게 만들지는 않지만 프로덕션 시스템을 유지 가능하게 만드는 통합의 종류입니다.</p> <h2 id="결론">결론</h2> <p>프로젝트 라이프사이클 후반에 네트워크 보안이 나타나는 것은 처음부터 앱과 함께 모델링하면 해결된 문제입니다. Aspire의 엔터프라이즈 네트워킹 지원은 별도의 인프라 트랙 없이도 이를 가능하게 합니다.</p> <p>원본 게시물의 전체 내용: <a href="https://devblogs.microsoft.com/aspire/aspire-azure-enterprise-networking/">Securing Azure apps with Aspire enterprise networking</a></p>