Netwerktopologie en connectiviteit voor de Azure Spring Apps-accelerator voor landingszones

In dit artikel worden ontwerpoverwegingen en aanbevelingen beschreven voor het netwerk waar de Spring Boot-workload wordt geplaatst. Uw doelontwerp is afhankelijk van de vereisten van de workload en de beveiligings- en nalevingsvereisten van uw organisatie.

Het gecentraliseerde platformteam en het toepassingsteam delen de verantwoordelijkheid van het ontwerpgebied voor netwerken. Het platformteam selecteert de netwerktopologie. Dit kan een traditioneel hub-spoke-model zijn of Virtual WAN netwerktopologie (door Microsoft beheerd). Het toepassingsteam is verantwoordelijk voor de ontwerpkeuzen van het spoke-netwerk. Er wordt verwacht dat de workload afhankelijk is van gedeelde services die door het platform worden beheerd. Het toepassingsteam moet de gevolgen van deze afhankelijkheden begrijpen en hun vereisten communiceren, zodat de algemene doelstellingen van de workload worden bereikt.

Zie Netwerktopologie en -connectiviteit voor meer informatie over het platformontwerp.

Volg deze ontwerpoverwegingen en aanbevelingen als best practices voor besturingselementen voor subnetten, inkomend verkeer en uitgaand verkeer.

Overwegingen bij het ontwerpen

• Isolatie. Het centrale team kan een virtueel netwerk bieden voor het toepassingsteam om hun workloads uit te voeren. Als de Spring Boot-workload een scheiding van problemen heeft met andere workloads, kunt u overwegen om uw eigen virtuele netwerk in te richten voor de Spring App Service-runtime en de toepassing.

• Subnetten. Houd rekening met de schaalbaarheid van de toepassing wanneer u de grootte van het subnet en het aantal toepassingen kiest.

  Als u bestaande subnetten gebruikt of uw eigen routetabellen gebruikt, moet u beleid instellen om ervoor te zorgen dat regels die zijn toegevoegd door Azure Spring Apps, niet worden bijgewerkt of verwijderd.

  Een ander aspect is beveiliging. Houd rekening met regels die verkeer in het subnet toestaan of weigeren.

• Uitgaand (uitgaand) verkeer. Verkeer dat van het virtuele netwerk gaat, moet worden gerouteerd via Azure Firewall of virtueel netwerkapparaat (NVA).

  Houd rekening met de beperkingen van de ingebouwde load balancer van Azure Spring Apps. Op basis van uw vereisten moet u mogelijk uitgaande paden aanpassen met behulp van door de gebruiker gedefinieerde routering (UDR), bijvoorbeeld om al het verkeer via een NVA te routeren.

• Inkomend (binnenkomend) verkeer. Overweeg het gebruik van een omgekeerde proxy voor verkeer dat naar Azure Spring Apps gaat. Kies op basis van uw vereisten systeemeigen opties, zoals Azure Application Gateway en Front Door, of regionale services, zoals API Management (APIM). Als deze opties niet voldoen aan de behoeften van de workload, kunnen niet-Azure-services worden overwogen.

Ontwerpaanbeveling

Deze aanbevelingen bieden prescriptieve richtlijnen voor de voorgaande reeks overwegingen.

Virtueel netwerk en subnetten

• Voor Azure Spring Apps is een eigenaarsmachtiging voor uw virtuele netwerk vereist. Deze rol is vereist voor het verlenen van een toegewezen en dynamische service-principal voor implementatie en onderhoud. Zie Azure Spring Apps implementeren in een virtueel netwerk voor meer informatie.

• Azure Spring Apps die zijn geïmplementeerd in een particulier netwerk, biedt een FQDN (Fully Qualified Domain Name) die alleen toegankelijk is binnen het particuliere netwerk. Maak een privé-DNS-zone van Azure voor het IP-adres van uw Spring-app. Koppel de privé-DNS aan uw virtuele netwerk door een privé-FQDN toe te wijzen in Azure Spring Apps. Zie Toegang tot uw toepassing in een particulier netwerk voor stapsgewijze instructies.

• Voor Azure Spring Apps zijn twee toegewezen subnetten vereist. Het ene subnet heeft de serviceruntime en het andere subnet is voor de Spring Boot-toepassingen.

  De minimale CIDR-blokgrootte van elk van deze subnetten is /28. Het runtime-subnet en het toepassingssubnet hebben een minimale adresruimte van /28 nodig. Maar het aantal Spring-apps dat u kunt implementeren, is van invloed op de grootte van het subnet. Zie Kleinere subnetbereiken gebruiken voor informatie over het maximum aantal app-exemplaren per subnetbereik.

• Als u Azure Application Gateway als omgekeerde proxy voor Azure Spring Apps gebruikt, hebt u een ander subnet voor dat exemplaar nodig. Zie Using Application Gateway as the reverse proxy (Application Gateway gebruiken als omgekeerde proxy) voor meer informatie.

• Gebruik netwerkbeveiligingsgroepen (NSG's) op subnetten om oost-west-verkeer te filteren om verkeer naar uw serviceruntimesubnet te beperken.

• Resourcegroepen en subnetten die door de Implementatie van Azure Spring Apps worden beheerd, mogen niet worden gewijzigd.

Uitgaand verkeer

• Standaard heeft Azure Spring Apps onbeperkte uitgaande internettoegang. Gebruik een NVA zoals Azure Firewall om noord-zuidverkeer te filteren. Profiteer van Azure Firewall in het gecentraliseerde hubnetwerk om de beheeroverhead te verminderen.

  Notitie

  Uitgaand verkeer naar Azure Spring-onderdelen is vereist om de service-exemplaren te ondersteunen. Zie Netwerkvereisten voor Azure Spring Apps voor informatie over specifieke eindpunten en poorten.

• Azure Spring Apps bieden een door de gebruiker gedefinieerde route (UDR) uitgaand type om het pad voor uitgaand verkeer volledig te beheren. OutboundType moet worden gedefinieerd wanneer een nieuw Azure Spring Apps-service-exemplaar wordt gemaakt. Deze kan later niet meer worden bijgewerkt. OutboundType kan alleen worden geconfigureerd met een virtueel netwerk. Zie Voor meer informatie Het uitgaand verkeer van Azure Spring Apps aanpassen met een door de gebruiker gedefinieerde route.

• De toepassing moet communiceren met andere Azure-services in de oplossing. Gebruik Azure Private Link voor ondersteunde services als uw toepassingen privéconnectiviteit vereisen.

Inkomend verkeer

• Gebruik een omgekeerde proxy om ervoor te zorgen dat kwaadwillende gebruikers de Web Application Firewall (WAF) niet kunnen omzeilen of beperkingslimieten kunnen omzeilen. Azure Application Gateway met geïntegreerde WAF wordt aanbevolen.

  Als u de Enterprise-laag gebruikt, gebruikt u het toegewezen eindpunt van de Spring Cloud Gateway-app als de back-endpool van de Application Gateway. Dit eindpunt wordt omgezet in een privé-IP-adres in het runtime-subnet van de Azure Spring Apps-service.

  Voeg een NSG toe aan het serviceruntime-subnet dat alleen verkeer toestaat vanaf het Application Gateway subnet, Azure Spring Apps-subnet en Azure Load Balancer.

  Notitie

  U kunt een alternatief kiezen voor de omgekeerde proxy, zoals Azure Front Door of niet-Azure-services. Zie Azure Spring Apps beschikbaar maken via een omgekeerde proxy voor informatie over configuratieopties.

• Azure Spring Apps kan worden geïmplementeerd in een virtueel netwerk via VNet-injectie of buiten het netwerk. Zie Configuratieoverzicht voor meer informatie.

Volgende stappen

Beveiligingsoverwegingen voor de azure Spring Apps-landingszoneversneller