Overwegingen voor netwerktopologie en connectiviteit voor de integratieservices-landingszoneversneller
Dit artikel bevat ontwerpoverwegingen en aanbevelingen voor netwerktopologie en -connectiviteit die u kunt toepassen wanneer u de azure Integration Services-landingszoneversneller (AIS) gebruikt. Netwerken zijn centraal in bijna alles in een landingszone.
De overwegingen voor netwerktopologie en connectiviteit voor deze architectuur zijn afhankelijk van de vereisten van de workloads die worden gehost en van de beveiligings- en nalevingsvereisten van uw organisatie.
Ontwerpoverwegingen
Gebruik een netwerktopologie op basis van Virtual WAN als uw organisatie:
Plannen voor het implementeren van resources in verschillende Azure-regio's en vereist wereldwijde connectiviteit tussen VNets in deze Azure-regio's en meerdere on-premises locaties.
Moet een grootschalige vertakkingsnetwerk rechtstreeks integreren in Azure, via een SD-WAN-implementatie (softwaregedefinieerde WAN) of vereist meer dan 30 vertakkingssites voor systeemeigen IPsec-beëindiging.
U hebt transitieve routering tussen VPN en ExpressRoute nodig, zoals externe vertakkingen die zijn verbonden via site-naar-site-VPN of externe gebruikers die zijn verbonden via punt-naar-site-VPN, vereisen connectiviteit met een met ExpressRoute verbonden DC via Azure.
Organisaties gebruiken Virtual WAN om te voldoen aan grootschalige interconnectiviteitsvereisten. Microsoft beheert deze service, waardoor de algehele netwerkcomplexiteit wordt verminderd en het netwerk van uw organisatie wordt gemoderniseerd.
Gebruik een traditionele Azure-netwerktopologie op basis van een hub-and-spoke-architectuur als uw organisatie:
Plannen voor het implementeren van resources in alleen bepaalde Azure-regio's.
Er is geen wereldwijd, onderling verbonden netwerk nodig.
Heeft weinig externe of vertakkingslocaties per regio en heeft minder dan 30 IP-beveiligingstunnels (IPsec).
Vereist volledig beheer van de configuratie of handmatige aangepaste configuratie van uw Azure-netwerk.
Referentienetwerktopologie
In het volgende architectuurdiagram ziet u de referentiearchitectuur voor een AIS-bedrijfsimplementatie:
IP-adressering plannen
Bedrijfsimplementaties van AIS moeten het gebruik van privé-eindpunten en virtuele netwerken omvatten. Bij het plannen van uw IP-adressering moeten rekening worden gehouden met de volgende ontwerpoverwegingen:
Voor sommige AIS-services zijn toegewezen subnetten vereist
U kunt een bepaald subnet t0 een bepaalde service aanwijzen om exemplaren van die service in het subnet te maken. U kunt bijvoorbeeld een subnet aanwijzen voor App Service-abonnementen, zodat u in de loop van de tijd extra apps kunt toevoegen.
Azure VPN Gateway kan overlappende on-premises sites verbinden met overlappende IP-adresruimten via de NAT-mogelijkheid (Network Address Translation).
Aangepaste DNS
Met de meeste AIS-services kunnen klanten hun eigen DNS-namen gebruiken voor openbare eindpunten, hetzij via hun eigen DNS-servers of via de Azure DNS-aanbieding. De configuratie van deze resources wordt per resource uitgevoerd, maar de ondersteunde resources worden hieronder vermeld:
API Management ondersteunt aangepaste domeinen.
Functie-apps en Logic Apps ondersteunen aangepaste domeinen wanneer deze worden gehost door een App Service-plan of App Service-omgeving.
Opslagaccounts ondersteunen aangepaste domeinen voor blob-opslageindpunten.
Data Factory, Service Bus en Event Grid bieden geen ondersteuning voor aangepaste domeinen.
Privé-DNS
Azure Privé-DNS biedt een betrouwbare en veilige DNS-service voor uw virtuele netwerk. Azure Privé-DNS beheert en lost domeinnamen op in het virtuele netwerk zonder dat u een aangepaste DNS-oplossing hoeft te configureren.
Als u de records van een privé-DNS-zone vanuit uw virtuele netwerk wilt omzetten, moet u het virtuele netwerk koppelen aan de zone. Gekoppelde virtuele netwerken hebben volledige toegang tot en kunnen alle DNS-records omzetten die zijn gepubliceerd in de privézone.
Ontwerpoverwegingen
Het is belangrijk dat u uw DNS-instellingen correct configureert om het IP-adres van het privé-eindpunt om te omzetten in de FQDN (Fully Qualified Domain Name) van uw resources.
Bestaande Microsoft Azure-services hebben mogelijk al een DNS-configuratie voor een openbaar eindpunt. Deze configuratie moet worden overschreven om verbinding te maken met uw privé-eindpunt.
Versleuteling en certificaatverificatie
Als voor uw netwerkontwerp versleuteling van in-transitverkeer en/of verificatie op basis van certificaten is vereist, moet u mogelijk rekening houden met waar en hoe deze versleuteling/verificatie wordt uitgevoerd. U moet bijvoorbeeld bepalen welke service TLS-beëindiging uitvoert.
Ontwerpoverwegingen
Vereist uw ontwerp dat verkeer tussen Azure-services wordt versleuteld? Kan uw versleuteling worden beëindigd bij een Azure Front Door en vervolgens niet-versleuteld zijn tijdens het doorlopen van de Azure-backbone of binnen uw VNet?
Moet u de versleuteling op meerdere locaties beëindigen?
Moet u verificatie op meerdere locaties afhandelen of kan deze eenmaal worden uitgevoerd voor een externe aanvraag?
Ontwerpaanaanvelingen
Als u een enterprise hub-and-spoke-ontwerp gebruikt, kunt u Azure Front Door gebruiken als toegangspunt voor aanvragen op internet.
Overweeg het gebruik van Azure-toepassing Gateway als het beëindigingspunt voor externe TLS-aanvragen of API Management voor certificaatverificatie en/of SSL-beëindiging.
Verbinding maken iviteit van on-premises resources
Voor veel bedrijfsintegratiescenario's moet u uw on-premises systemen verbinden met Azure. Het is belangrijk om rekening te houden met de aanbevolen modellen om deze connectiviteit te bieden.
Ontwerpoverwegingen
Azure ExpressRoute biedt toegewezen privéconnectiviteit met Azure IaaS-resources (Infrastructure as a Service) en PaaS-resources (Platform as a Service) vanaf on-premises locaties.
Azure VPN Gateway biedt site-naar-site (S2S) gedeelde connectiviteit via het openbare internet naar virtuele IaaS-netwerkbronnen van Azure Infrastructure as a Service (IaaS) vanaf on-premises locaties.
Azure ExpressRoute en Azure VPN Gateway hebben verschillende mogelijkheden, kosten en prestaties.
De on-premises gegevensgateway (OPDG) of Azure Hybrid Verbinding maken ions kunnen worden gebruikt waarbij ExpressRoute of VPN Gateway niet praktisch is: OPDG-/hybride Verbinding maken ionen zijn beide voorbeelden van relayservices, waarbij Service Bus wordt gebruikt om verbindingen te maken die uitgaand zijn van uw on-premises netwerk om aanvragen van Azure te ontvangen, zonder dat u poorten hoeft te openen in uw externe firewall/netwerk.
OPDG is beperkt in het aantal aanvragen per minuut dat wordt ondersteund (de beperkingslimiet), heeft specifieke limieten voor de gegevensgrootte en werkt alleen met beperkte Azure-resources (Logic Apps, Power BI, Power Apps, Power Automate, Analysis Services).
Hybride verbindingen werken met App Services (functie-apps of web-apps) en hebben een eigen beperkings- en groottelimiet.
Azure Relay Hybrid Verbinding maken ions is een belangrijk onderdeel van Service Bus waarmee relays buiten App Services of OPDG kunnen worden uitgevoerd.
Ontwerpaanaanvelingen
Gebruik Azure ExpressRoute als het primaire connectiviteitskanaal voor het verbinden van een on-premises netwerk met Azure.
Zorg ervoor dat u de juiste SKU gebruikt voor de ExpressRoute en/of VPN Gateway op basis van bandbreedte- en prestatievereisten.
Gebruik Azure VPN Gateway om vertakkingen of externe locaties te verbinden met Azure.
Gebruik OPDG- en/of hybride Verbinding maken ions waarbij ExpressRoute of VPN Gateway niet kan worden gebruikt, waarbij de doorvoerlimieten geen probleem zijn en waar u een ondersteuningsresource van Azure (bijvoorbeeld Logic Apps, Functie-apps) gebruikt.
Verbinding maken iviteit van AIS PaaS-services
Azure AIS PaaS-services worden doorgaans geopend via openbare eindpunten. Het Azure-platform biedt mogelijkheden voor het beveiligen van deze eindpunten of zelfs om ze volledig privé te maken.
Het beveiligen van deze eindpunten kan worden bereikt met behulp van privé-eindpunten.
Als u al het internetverkeer naar een doelresource wilt blokkeren, gebruikt u een privé-eindpunt.
Als u een specifieke subresource naar uw VNet-resources wilt beveiligen, gebruikt u een privé-eindpunt.
Als u een specifiek opslagaccount wilt beveiligen voor uw VNet-resources, kunt u een privé-eindpunt gebruiken.
Met Azure Private Link hebt u toegang tot Azure AIS-services (bijvoorbeeld Service Bus en API Management) en door Azure gehoste services van klanten/partners via een privé-eindpunt in uw virtuele netwerk.
Wanneer u Private Link gebruikt, gaat verkeer tussen uw virtuele netwerk en de service via het Backbone-netwerk van Microsoft, zodat uw service niet meer nodig is voor het openbare internet. U kunt een eigen Private Link-service maken in uw virtuele netwerk en deze aanbieden bij klanten. Het instellen en gebruiken van Azure Private Link is consistent voor Azure PaaS-services, services die eigendom zijn van klanten en gedeelde partnerservices.
Ontwerpoverwegingen
Virtuele netwerkinjectie biedt toegewezen persoonlijke implementaties voor ondersteunde services. Het beheervlakverkeer loopt nog steeds via openbare IP-adressen.
Azure Private Link biedt toegewezen toegang met behulp van privé-IP-adressen voor Azure PaaS-exemplaren of aangepaste services achter de Standard-laag van Azure Load Balancer.
Zakelijke klanten hebben vaak zorgen over openbare eindpunten voor PaaS-services die op de juiste wijze moeten worden beperkt.
Ontwerpaanaanvelingen
Gebruik virtuele netwerkinjectie voor ondersteunde Azure-services om ze beschikbaar te maken vanuit uw virtuele netwerk.
Azure PaaS-services die zijn geïnjecteerd in een virtueel netwerk voeren nog steeds beheervlakbewerkingen uit met behulp van servicespecifieke openbare IP-adressen. Verbinding maken iviteit moet gegarandeerd zijn om de service correct te laten functioneren.
Toegang tot Azure PaaS-services vanaf on-premises via ExpressRoute met persoonlijke peering. Gebruik virtuele netwerkinjectie voor toegewezen Azure-services of Azure Private Link voor beschikbare gedeelde Azure-services.
Gebruik ExpressRoute met Microsoft-peering om toegang te krijgen tot Azure PaaS-services vanaf on-premises wanneer er geen virtuele netwerkinjectie of Private Link beschikbaar is. Zo voorkomt u dat u het openbare internet doorkruist.
Toegang tot Azure PaaS-services vanuit on-premises via ExpressRoute met Microsoft-peering voorkomt geen toegang tot de openbare eindpunten van de PaaS-service. U moet dit afzonderlijk configureren en beperken zoals vereist.
Schakel service-eindpunten voor virtuele netwerken niet standaard in op alle subnetten.
Openbare toegang tot AIS PaaS-services uitschakelen.
Netwerkontwerp voor API Management
Ontwerpoverwegingen
Bepaal of API's extern, intern of hybride van beide toegankelijk zijn.
Bepaal of u de interne API Management-gateway wilt gebruiken als uw hoofdeindpunt of als u een WAF-service (Web Application Firewall) wilt gebruiken, zoals Azure-toepassing Gateway of Azure Front Door.
Bepaal of er meerdere gateways moeten worden geïmplementeerd en hoe deze taakverdeling moeten worden verdeeld, bijvoorbeeld door Application Gateway vóór de API Management-gateway te gebruiken.
Bepaal of connectiviteit met on-premises of multicloudomgevingen is vereist.
Ontwerpaanaanvelingen
Implementeer uw API Management-exemplaar in een VNet om toegang tot back-endservices in het netwerk toe te staan.
Gebruik Application Gateway voor externe toegang tot API Management wanneer het API Management-exemplaar wordt geïmplementeerd in een VNet in de interne modus.
Gebruik een privé-eindpunt voor uw API Management-exemplaar om clients in uw privénetwerk toegang te geven tot het exemplaar via Azure Private Link.
Netwerkontwerp voor opslagaccounts
Azure Storage wordt gebruikt als opslagoplossing voor Azure Logic Apps en Azure Functions.
Ontwerpaanaanvelingen
Voor de beste prestaties moet uw logische app/functie-app een opslagaccount in dezelfde regio gebruiken, waardoor de latentie wordt verminderd.
Gebruik privé-eindpunten voor Azure Storage-accounts om clients in een virtueel netwerk (VNet) veilig toegang te geven tot gegevens via een Private Link.
Er moeten verschillende privé-eindpunten worden gemaakt voor elke tabel-, wachtrij- en blobopslagservice.
Netwerkontwerp voor App Service-omgevingen
Een App Service Environment (ASE) is een toegewezen, geïsoleerde omgeving voor het uitvoeren van web-apps, functie-apps en Logic Apps (Standard). Het wordt geïmplementeerd in uw VNet en bevat een aantal App Service-plannen, die elk worden gebruikt om uw app-services te hosten.
Ontwerpoverwegingen
Een ASE wordt geïmplementeerd in één subnet binnen uw VNet. Een ASE kan worden geïmplementeerd met behulp van een virtueel IP-adres (VIP) zodat externe verbindingen een openbaar zichtbaar IP-adres kunnen gebruiken, dat kan worden toegevoegd aan een openbare DNS-record.
Toepassingen binnen een ASE hebben toegang tot alle andere resources binnen het virtuele netwerk, afhankelijk van regels voor netwerktoegang. Toegang tot resources in andere VNets kan worden bereikt met behulp van peering van virtuele netwerken.
Toepassingen binnen een ASE hoeven niet te worden geconfigureerd om deel te uitmaken van een VNet. Ze bevinden zich automatisch in het VNet omdat ze worden geïmplementeerd in de ASE. Dit betekent dat u de netwerktoegang niet per resource hoeft te configureren, maar dat u deze eenmaal op ASE-niveau kunt configureren.
Ontwerpaanaanvelingen
- Gebruik indien mogelijk ASE v3, omdat dit de grootste mate van netwerkflexiviteit biedt, terwijl de configuratie die nodig is voor afzonderlijke resources binnen de ASE wordt verminderd. ASE v3 ondersteunt ook zoneredundantie.
Netwerkontwerp voor App Service-plannen
App Services in een omgeving met meerdere tenants kan worden geïmplementeerd met een privé- of een openbaar eindpunt. Wanneer deze wordt geïmplementeerd met een privé-eindpunt, wordt openbare blootstelling van de App Service verwijderd. Als er een vereiste is dat het privé-eindpunt van de App Service ook bereikbaar is via internet, kunt u het gebruik van App Gateway overwegen om de app-service beschikbaar te maken.
Plan uw subnetten zorgvuldig voor uitgaande VNet-integratie, rekening houdend met het aantal VEREISTE IP-adressen. VNet-integratie vereist een toegewezen subnet. Wanneer u de grootte van uw subnet plant, moet u er rekening mee houden dat Azure 5 IP-adressen in elk subnet reserveert. Daarnaast wordt er één adres gebruikt vanuit het integratiesubnet voor elk planexemplaren. Wanneer u uw app schaalt naar vier exemplaren, worden er vier adressen gebruikt. Wanneer u de grootte omhoog of omlaag schaalt, wordt de vereiste adresruimte gedurende een korte periode verdubbeld. Dit is van invloed op de werkelijke, beschikbare ondersteunde exemplaren in uw subnet.
Wanneer er vanuit een App Service verbinding moet worden gemaakt met on-premises, privé- of IP-beperkte services, moet u rekening houden met het volgende:
Wanneer deze wordt uitgevoerd in de omgeving met meerdere tenants, kan de App Service-aanroep afkomstig zijn van een breed scala aan IP-adressen en kan VNet-integratie nodig zijn om te voldoen aan uw netwerkvereisten.
Services zoals API Management (APIM) kunnen worden gebruikt voor proxy-aanroepen tussen netwerkgrenzen en kunnen zo nodig een statisch IP-adres bieden.
Ontwerpaanaanvelingen
- Omdat subnetgrootten niet kunnen worden gewijzigd na de toewijzing, gebruikt u een subnet dat groot genoeg is om te voldoen aan de schaal die uw app kan bereiken. Als u problemen met subnetcapaciteit wilt voorkomen, moet u een /26-achtervoegsel (64 adressen) gebruiken voor VNet-integratie.
Netwerkontwerp voor Azure Data Factory
Ontwerpoverwegingen
Als u Data Factory wilt verbinden met een gegevensbron die zich in uw on-premises netwerk bevindt, of misschien op een Azure-service die is geconfigureerd om de toegang van alle Azure-services te blokkeren, tenzij ze specifiek zijn toegestaan, moet u overwegen om uw Data Factory te integreren met een virtueel netwerk dat netwerktoegang tot de doelgegevensbron biedt.
Data Factory maakt gebruik van afzonderlijke omgevingen met de naam Integration Runtimes. De standaard Data Factory-runtime, de Azure Integration Runtime, is niet gekoppeld aan een VNet en kan daarom niet worden gebruikt om verbinding te maken met gegevensbronnen die zijn beveiligd met de meest beperkende firewalls. Bedenk welke van deze runtimes het beste voldoen aan uw vereisten.
Het duurt even voordat beheerde VNets zijn opgestart, terwijl normale Azure-runtimes vrijwel onmiddellijk beschikbaar zijn. Dit is iets waarmee u rekening moet houden bij het plannen van uw pijplijnen en het opsporen van fouten.
Het starten van SSIS-runtimes met een met VNet geïntegreerde runtime duurt maximaal 30 minuten.
Zelf-hostende integratieruntimes kunnen alleen de kopieeractiviteit uitvoeren, waarmee gegevens van de ene bron naar de andere worden gekopieerd. Als u transformaties naar de gegevens wilt uitvoeren, kunt u deze niet uitvoeren met behulp van de gegevensstromen van Data Factory.
Beheerde privé-eindpunten zijn privé-eindpunten die zijn gemaakt in het beheerde virtuele netwerk van Azure Data Factory, waarbij een privékoppeling naar Azure-resources (over het algemeen gegevensbronnen voor ADF) tot stand wordt gebracht. Deze privé-eindpunten worden namens u beheerd in Azure Data Factory.
Privé-eindpunten zijn alleen beschikbaar voor zelf-hostende integratieruntimes om verbinding te maken met Data Factory.
Netwerkontwerp voor Logic Apps (Standard) - geïntegreerde VNet-apps
Ontwerpoverwegingen
Binnenkomend verkeer naar uw logische apps komt via privé-eindpunten. Raadpleeg de overwegingen voor binnenkomend verkeer via documentatie over privé-eindpunten bij het plannen van uw Logic Apps-netwerkontwerp.
Uitgaand verkeer van uw logische apps loopt via het VNet. Raadpleeg de overwegingen voor uitgaand verkeer via de documentatie voor integratie van virtuele netwerken bij het plannen van uw Logic Apps-netwerkontwerp.
Netwerkontwerp voor Service Bus
Ontwerpoverwegingen
Gebruikt u Privé-DNS zones of uw eigen DNS-server (met DNS-doorsturen) om om te zetten in een private link-resource?
IP-filtering en VNets worden alleen ondersteund in de Premium SKU-laag voor Service Bus. Als de Premium-laag niet praktisch is, bekijkt u het gebruik van SAS-tokens als uw primaire manier om de toegang tot uw naamruimte te vergrendelen.
Ontwerpaanaanvelingen
Openbare netwerktoegang moet worden uitgeschakeld met BEHULP van IP-filtering, die van toepassing is op alle ondersteunde protocollen (bijvoorbeeld AMQP en HTTPS).
Verkeer naar deze naamruimte mag alleen worden beperkt via privé-eindpunten door openbare netwerktoegang te beperken (via IP-filtering).
Plaats uw privé-eindpunt in een eigen toegewezen subnet dat is gereserveerd voor Service Bus.
Voeg een DNS-record toe met behulp van de privé-DNS-zone voor het privé-eindpunt. Schakel vertrouwde services in Azure in om rechtstreeks toegang te krijgen tot uw naamruimte (waardoor de firewall wordt overgeslagen) om problemen met uw integratieontwerp te voorkomen.
Netwerkontwerp voor functie-apps
Ontwerpoverwegingen
- Gebruikt u Privé-DNS zones of uw eigen DNS-server (met DNS-doorsturen) om om te zetten in een private link-resource?
Ontwerpaanaanvelingen
Openbare netwerktoegang moet worden uitgeschakeld.
Verkeer naar deze naamruimte mag alleen worden beperkt via privé-eindpunten.
Plaats uw privé-eindpunt in een eigen toegewezen subnet dat is gereserveerd voor Functions.
Voeg een DNS-record toe met behulp van een privé-DNS-zone voor het privé-eindpunt.
Netwerkontwerp voor Azure Key Vault
Ontwerpaanaanvelingen
Openbare netwerktoegang moet worden uitgeschakeld.
Maak een privé-eindpunt voor het beperken van de toegang via het enige VNet.
Plaats uw privé-eindpunt in een eigen toegewezen subnet dat is gereserveerd voor Key Vault.
Voeg een DNS-record toe met behulp van een privé-DNS-zone voor het privé-eindpunt.
Netwerkontwerp voor Event Grid
Ontwerpoverwegingen
- Gebruikt u Privé-DNS zones of uw eigen DNS-server (met DNS-doorsturen) om om te zetten in een private link-resource?
Ontwerpaanaanvelingen
Openbare netwerktoegang moet worden uitgeschakeld met IP-filtering.
Verkeer naar uw onderwerpen en domein moet alleen worden beperkt via privé-eindpunten.
Plaats uw privé-eindpunt in een eigen toegewezen subnet dat is gereserveerd voor Event Grid.
Voeg een DNS-record toe met behulp van een privé-DNS-zone voor het privé-eindpunt.
Netwerkontwerp voor Event Hubs
Ontwerpoverwegingen
- Netwerktoegang beperken werkt niet met de Basic SKU-laag in Event Hubs
Ontwerpaanaanvelingen
Openbare netwerktoegang moet worden uitgeschakeld met IP-filtering.
Openbare netwerktoegang moet worden uitgeschakeld met behulp van service-eindpunten: maak een service-eindpunt voor een virtueel netwerk in uw VNet en bind deze aan uw Event Hubs-naamruimte met behulp van een regel voor een virtueel netwerk
Schakel de optie Vertrouwde services in om bepaalde Azure-resources toegang te geven tot uw naamruimte.
Volgende stap
Bekijk de kritieke ontwerpgebieden om volledige overwegingen en aanbevelingen voor uw architectuur te maken.