Azure Front Door gebruiken in een multitenant-oplossing
Azure Front Door is een modern netwerk voor cloudinhoudlevering (CDN) dat snelle, betrouwbare toegang biedt tussen de statische en dynamische webinhoud van gebruikers en toepassingen over de hele wereld. In dit artikel worden enkele van de functies van Azure Front Door beschreven die handig zijn wanneer u in multitenant-systemen werkt. Het bevat ook koppelingen naar aanvullende richtlijnen en voorbeelden.
Wanneer u Azure Front Door gebruikt als onderdeel van een multitenant-oplossing, moet u enkele beslissingen nemen op basis van het ontwerp en de vereisten van uw oplossing. U moet rekening houden met de volgende factoren:
- Hoeveel tenants hebt u en hoeveel verwacht u in de toekomst?
- Deelt u uw toepassingslaag tussen meerdere tenants, implementeert u veel exemplaren van één tenanttoepassing of implementeert u afzonderlijke implementatiestempels die worden gedeeld door meerdere tenants?
- Willen uw tenants hun eigen domeinnamen meenemen?
- Gaat u wildcard-domeinen gebruiken?
- Moet u uw eigen TLS-certificaten gebruiken of beheert Microsoft uw TLS-certificaten?
- Hebt u rekening gehouden met de quota en limieten die van toepassing zijn op Azure Front Door? Weet je welke limieten je nadert naarmate je groeit? Als u vermoedt dat u deze limieten nadert, kunt u overwegen om meerdere Azure Front Door-profielen te gebruiken. Of overweeg of u de manier waarop u Azure Front Door gebruikt, kunt wijzigen om de limieten te voorkomen. Houd er rekening mee dat de Premium-SKU hogere limieten heeft dan de Standard-SKU.
- Hebben u of uw tenants vereisten voor het filteren van IP-adressen, geo-blokkeren of het aanpassen van WAF-regels?
- Zijn alle toepassingsservers van uw tenants internetgericht?
Functies van Azure Front Door die ondersteuning bieden voor multitenancy
In deze sectie worden verschillende belangrijke functies van Azure Front Door beschreven die nuttig zijn voor multitenant-oplossingen. Hierin wordt beschreven hoe u met Azure Front Door aangepaste domeinen kunt configureren, waaronder informatie over jokertekendomeinen en TLS-certificaten. Ook wordt beschreven hoe u routeringsmogelijkheden van Azure Front Door kunt gebruiken ter ondersteuning van multitenancy.
Aangepaste domeinen
Azure Front Door biedt een standaardhostnaam voor elk eindpunt dat u maakt, bijvoorbeeld contoso.z01.azurefd.net. Voor de meeste oplossingen koppelt u in plaats daarvan uw eigen domeinnaam aan het Azure Front Door-eindpunt. Met aangepaste domeinnamen kunt u uw eigen huisstijl gebruiken en routering configureren op basis van de hostnaam die is opgegeven in de aanvraag van een client.
In een multitenant-oplossing kunt u tenantspecifieke domeinnamen of subdomeinen gebruiken en Azure Front Door configureren om het verkeer van de tenant te routeren naar de juiste oorsprongsgroep voor de workload van die tenant. U kunt bijvoorbeeld een aangepaste domeinnaam configureren, zoals tenant1.app.contoso.com. Met Azure Front Door kunt u meerdere aangepaste domeinen configureren op één Azure Front Door-profiel.
Zie Een aangepast domein toevoegen aan uw Front Door-voor meer informatie.
Wildcard-domeinen
Jokertekendomeinen vereenvoudigen de configuratie van DNS-records en de routeringsconfiguratie van Azure Front Door-verkeer wanneer u een gedeeld stemdomein en tenantspecifieke subdomeinen gebruikt. Stel dat uw tenants toegang hebben tot hun toepassingen met behulp van subdomeinen zoals tenant1.app.contoso.com en tenant2.app.contoso.com. U kunt een domein met jokertekens configureren, *.app.contoso.com, in plaats van elk tenantspecifiek domein afzonderlijk te configureren.
Azure Front Door biedt ondersteuning voor het maken van aangepaste domeinen die gebruikmaken van jokertekens. Vervolgens kunt u een route configureren voor aanvragen die binnenkomen in het domein met jokertekens. Wanneer u een nieuwe tenant onboardt, hoeft u uw DNS-servers niet opnieuw te configureren, nieuwe TLS-certificaten uit te geven of de configuratie van uw Azure Front Door-profiel bij te werken.
Jokertekendomeinen werken goed als u al uw verkeer naar één oorspronkelijke groep verzendt. Maar als u afzonderlijke stempels van uw oplossing hebt, is een domein met jokertekens op één niveau niet voldoende. U moet stemdomeinen met meerdere niveaus gebruiken of extra configuratie opgeven door bijvoorbeeld de routes te overschrijven die moeten worden gebruikt voor het subdomein van elke tenant. Zie Overwegingen bij het gebruik van domeinnamen in een multitenant-oplossingvoor meer informatie.
Azure Front Door geeft geen beheerde TLS-certificaten uit voor jokertekendomeinen, dus u moet uw eigen certificaat kopen en leveren.
Zie Wildcard-domeinenvoor meer informatie.
Beheerde TLS-certificaten
Het verkrijgen en installeren van TLS-certificaten kan complex en foutgevoelig zijn. En TLS-certificaten verlopen na een bepaalde periode, meestal één jaar, en moeten opnieuw worden uitgegeven en opnieuw worden geïnstalleerd om onderbreking van toepassingsverkeer te voorkomen. Wanneer u beheerde TLS-certificaten van Azure Front Door gebruikt, is Microsoft verantwoordelijk voor het uitgeven, installeren en vernieuwen van certificaten voor uw aangepaste domein.
Uw oorspronkelijke toepassing kan worden gehost op een andere Azure-service die ook beheerde TLS-certificaten biedt, zoals Azure App Service. Azure Front Door werkt transparant met de andere service om uw TLS-certificaten te synchroniseren.
Als u uw huurders toestaat hun eigen aangepaste domeinen te gebruiken en u wilt dat Azure Front Door certificaten voor deze domeinnamen uitgeeft, moeten uw huurders geen CAA-records configureren op hun DNS-servers, omdat dit zou kunnen voorkomen dat Azure Front Door certificaten namens hen uitgeeft. Zie TLS/SSL-certificatenvoor meer informatie.
Zie End-to-end TLS met Azure Front Doorvoor meer informatie over TLS-certificaten.
Routering
Een multitenant-toepassing kan een of meer toepassingsstempels hebben die de tenants dienen. Stempels worden vaak gebruikt om implementaties in meerdere regio's mogelijk te maken en ondersteuning te bieden voor het schalen van een oplossing naar een groot aantal tenants.
Azure Front Door heeft een krachtige set routeringsmogelijkheden die ondersteuning bieden voor een aantal multitenant-architecturen. U kunt routering gebruiken om verkeer tussen oorsprongen binnen een stempel te distribueren of om verkeer naar de juiste stempel voor een specifieke tenant te verzenden. U kunt routering configureren op basis van afzonderlijke domeinnamen, jokertekens en URL-paden. En u kunt de regelengine gebruiken om het routeringsgedrag verder aan te passen.
Zie Overzicht van routeringsarchitectuurvoor meer informatie.
Regelengine
U kunt de Azure Front Door-regelengine gebruiken om aan te passen hoe Aanvragen worden verwerkt in Azure Front Door aan de netwerkrand. Met de regelengine kunt u kleine logicablokken uitvoeren binnen de Azure Front Door-aanvraagverwerkingspijplijn. U kunt de regelengine gebruiken voor verschillende taken, waaronder de volgende:
- Informatie ophalen over de HTTP-aanvraag, inclusief segmenten van de URL en het pad, en de informatie doorgeven aan een ander deel van de aanvraag.
- Wijzig elementen van de HTTP-aanvraag voordat deze naar de oorsprong wordt verzonden.
- Wijzig enkele onderdelen van het HTTP-antwoord voordat deze naar de client wordt geretourneerd.
- Overschrijf de routeringsconfiguratie voor een aanvraag, bijvoorbeeld door de oorspronkelijke groep te wijzigen waarnaar een aanvraag moet worden verzonden.
Hier volgen enkele voorbeeldmethoden voor het gebruik van de Azure Front Door-regelengine in een multitenant-oplossing:
- Stel dat u een multitenant-toepassingslaag implementeert waarin u ook tenantspecifieke subdomeinen met jokertekens gebruikt, zoals beschreven in de volgende voorbeeldscenario's. U kunt de regelengine gebruiken om de tenant-id uit het subdomein van de aanvraag te extraheren en toe te voegen aan een aanvraagheader. Met deze regel kan de toepassingslaag bepalen van welke tenant de aanvraag afkomstig is.
- Stel dat u een multitenant-toepassingslaag implementeert en padgebaseerde routering gebruikt (bijvoorbeeld
https://application.contoso.com/tenant1/welcomeenhttps://application.contoso.com/tenant2/welcomevoor tenants 1 en 2). U kunt de regelengine gebruiken om het tenant-id-segment uit het URL-padsegment te extraheren en de URL opnieuw te herschrijven om de tenant-id op te nemen in een queryreeksparameter of aanvraagheader die de toepassing kan gebruiken.
Voor meer informatie, zie Wat is de Azure Front Door-regelengine?.
Voorbeeldscenario's
In de volgende voorbeeldscenario's ziet u hoe u verschillende multitenant-architecturen in Azure Front Door kunt configureren en hoe de beslissingen die u neemt van invloed kunnen zijn op uw DNS- en TLS-configuratie.
Veel multitenant-oplossingen implementeren het patroon implementatiestempels. Wanneer u deze implementatiebenadering gebruikt, implementeert u doorgaans één gedeeld Azure Front Door-profiel en gebruikt u Azure Front Door om binnenkomend verkeer naar de juiste stempel te routeren. Dit implementatiemodel is het meest voorkomende en scenario's 1 tot en met 4 in dit artikel laten zien hoe u het kunt gebruiken om te voldoen aan een reeks vereisten.
In sommige situaties kunt u echter een Azure Front Door-profiel implementeren in elke zegel van uw oplossing. scenario 5 beschrijft dit implementatiemodel.
Scenario 1: Door provider beheerd jokertekendomein, één stempel
Contoso bouwt een kleine multitenant-oplossing. Het bedrijf implementeert één stempel in één regio en die stempel dient alle tenants. Alle aanvragen worden doorgestuurd naar dezelfde toepassingsserver. Contoso heeft besloten om wildcarddomeinen te gebruiken voor alle tenants, zoals tenant1.contoso.com en tenant2.contoso.com.
Contoso implementeert Azure Front Door met behulp van deze configuratie:
DNS-configuratie
eenmalige configuratie: Contoso twee DNS-vermeldingen configureert:
- Een wildcard-TXT-record voor
*.contoso.com. Deze waarde wordt ingesteld op de waarde die is opgegeven door Azure Front Door tijdens het onboardingproces voor aangepaste domeinen. - Een CNAME-record met jokertekens,
*.contoso.com, dat is een alias voor het Azure Front Door-eindpunt van Contoso:contoso.z01.azurefd.net.
Wanneer een nieuwe huurder wordt ingevoerd: Er is geen aanvullende configuratie vereist.
TLS-configuratie
eenmalige configuratie: Contoso een TLS-certificaat met jokertekens koopt, aan een sleutelkluis toevoegt en Azure Front Door toegang verleent tot de kluis.
Wanneer een nieuwe tenant wordt geïntroduceerd: is er geen extra configuratie nodig.
Azure Front Door-configuratie
eenmalige configuratie: Contoso maakt een Azure Front Door-profiel en één eindpunt. Ze voegen één aangepast domein toe aan de naam *.contoso.com en koppelen hun TLS-certificaat met jokertekens aan de resource van het aangepaste domein. Vervolgens configureren ze één origin-groep die één oorsprong voor de toepassingsserver bevat. Ten slotte configureren ze een route om het aangepaste domein te verbinden met de oorspronkelijke groep.
Wanneer een nieuwe tenant wordt onboarded: Er is geen aanvullende configuratie vereist.
Voordelen
- Deze configuratie is relatief eenvoudig te configureren en biedt klanten url's van het merk Contoso.
- De benadering ondersteunt een groot aantal tenants.
- Wanneer een nieuwe tenant wordt geïmplementeerd, hoeft Contoso geen wijzigingen aan te brengen in Azure Front Door-, DNS- of TLS-certificaten.
Nadelen
- Deze benadering kan niet eenvoudig worden geschaald buiten één toepassingsstempel of -regio.
- Contoso moet een wildcard-SSL-certificaat aanschaffen en het certificaat vernieuwen en installeren wanneer het verloopt.
Scenario 2: Door provider beheerd jokertekendomein, meerdere stempels
Proseware bouwt een multitenant-oplossing voor meerdere stempels die zijn geïmplementeerd in zowel Australië als Europa. Alle verzoeken binnen een regio worden afgehandeld door de stempel in die regio. Net als Contoso besloot Proseware jokertekendomeinen te gebruiken voor alle tenants, zoals tenant1.proseware.com en tenant2.proseware.com.
Proseware implementeert Azure Front Door met behulp van deze configuratie:
DNS-configuratie
eenmalige configuratie: Proseware configureert twee DNS-vermeldingen:
- Een wildcard TXT-record voor
*.proseware.com. Deze waarde wordt ingesteld op de waarde die is opgegeven door Azure Front Door tijdens het onboardingproces voor aangepaste domeinen. - Een CNAME-record met jokertekens,
*.proseware.com, dat is een alias voor het Azure Front Door-eindpunt van Proseware:proseware.z01.azurefd.net.
Wanneer een nieuwe tenant wordt geïntegreerd: Er is geen extra configuratie nodig.
TLS-configuratie
eenmalige configuratie: Proseware koopt een TLS-certificaat met jokertekens, voegt dit toe aan een sleutelkluis en verleent Azure Front Door toegang tot de kluis.
Wanneer een nieuwe tenant wordt geïntroduceerd: Er is geen aanvullende configuratie nodig.
Azure Front Door-configuratie
eenmalige configuratie: Proseware maakt een Azure Front Door-profiel en één eindpunt. Het bedrijf configureert meerdere oorsprongsgroepen, één per toepassingsstempel/-server in elke regio.
Wanneer een nieuwe tenant wordt aangemeld: voegt Proseware een aangepaste domeinresource toe aan Azure Front Door. Ze gebruiken de naam *.proseware.com en koppelen hun TLS-certificaat met jokertekens aan de aangepaste domeinresource. Vervolgens maken ze een route om op te geven naar welke oorsprongsgroep (stempel) de aanvragen van de tenant moeten worden omgeleid. In het voorgaande diagram tenant1.proseware.com routes naar de oorspronkelijke groep in de regio Australië en tenant2.proseware.com routes naar de oorspronkelijke groep in de regio Europa.
Voordelen
- Wanneer nieuwe tenants worden geïntroduceerd, zijn er geen DNS- of TLS-configuratiewijzigingen vereist.
- Proseware onderhoudt één exemplaar van Azure Front Door om verkeer te routeren naar meerdere stempels in meerdere regio's.
Nadelen
- Proseware moet Azure Front Door telkens wanneer er een nieuwe tenant wordt geïmplementeerd, opnieuw configureren.
- Proseware moet aandacht besteden aan Azure Front Door-quota en -limieten, met name op het aantal routes en aangepaste domeinen, en de samengestelde routeringslimiet.
- Proseware moet een TLS-certificaat met jokertekens kopen.
- Proseware is verantwoordelijk voor het vernieuwen en installeren van het certificaat wanneer het verloopt.
Scenario 3: Door provider beheerde, op zegels gebaseerde jokertekensubdomeinen
Fabrikam bouwt een multitenant-oplossing. Het bedrijf implementeert stempels in Australië en de Verenigde Staten. Alle aanvragen binnen één regio worden verwerkt door de stempel in die regio. Fabrikam gebruikt stemdomeinen op basis van stempels, zoals tenant1.australia.fabrikam.com, tenant2.australia.fabrikam.comen tenant3.us.fabrikam.com.
Het bedrijf implementeert Azure Front Door met behulp van deze configuratie:
DNS-configuratie
eenmalige configuratie: Fabrikam configureert de volgende twee DNS-vermeldingen voor jokertekens voor elke stempel.
- Een TXT-record met jokertekens voor elke stempel:
*.australia.fabrikam.comen*.us.fabrikam.com. Ze worden ingesteld op de waarden die zijn opgegeven door Azure Front Door tijdens het onboardingproces van het aangepaste domein. - Een CNAME-record met jokertekens voor elke stempel,
*.australia.fabrikam.comen*.us.fabrikam.com, die beide aliassen zijn voor het Azure Front Door-eindpunt:fabrikam.z01.azurefd.net.
Wanneer een nieuwe tenant wordt toegelaten: Er is geen extra configuratie vereist.
TLS-configuratie
eenmalige configuratie: Fabrikam een TLS-certificaat met jokertekens koopt voor elke stempel, voegt deze toe aan een sleutelkluis en verleent Azure Front Door toegang tot de kluis.
Wanneer er een nieuwe tenant wordt ingevoerd: Er is geen aanvullende configuratie vereist.
Azure Front Door-configuratie
eenmalige configuratie: Fabrikam een Azure Front Door-profiel en één eindpunt maakt. Ze configureren een oorsprongsgroep voor elke stempel. Ze maken aangepaste domeinen met behulp van een wildcard voor elk subdomein dat gebaseerd is op stempels: *.australia.fabrikam.com en *.us.fabrikam.com. Ze maken een route voor het aangepaste domein van elke stempel om verkeer naar de juiste oorspronkelijke groep te verzenden.
Wanneer een nieuwe tenant wordt aangenomen: Er is geen aanvullende configuratie nodig.
Voordelen
- Met deze benadering kan Fabrikam opschalen naar grote aantallen huurders over meerdere implementaties.
- Wanneer er nieuwe tenants worden toegelaten, zijn er geen wijzigingen in DNS- of TLS-configuratie vereist.
- Fabrikam onderhoudt één exemplaar van Azure Front Door om verkeer te routeren naar meerdere stempels in meerdere regio's.
Nadelen
- Omdat URL's een structuur met meerdere onderdelen gebruiken, kunnen URL's complexer zijn voor gebruikers om mee te werken.
- Fabrikam moet meerdere TLS-certificaten met jokertekens kopen.
- Fabrikam is verantwoordelijk voor het vernieuwen en installeren van de TLS-certificaten wanneer ze verlopen.
Scenario 4: Vanity-domeinen
Adventure Works Cycles bouwt een multitenant-oplossing. Het bedrijf implementeert stempels in meerdere regio's, zoals Australië en de Verenigde Staten. Alle aanvragen binnen één regio worden verwerkt door de stempel in die regio. Adventure Works stelt de tenants in staat hun eigen domeinnamen mee te nemen. Tenant 1 kan bijvoorbeeld een aangepaste domeinnaam zoals tenant1app.tenant1.comconfigureren.
Het bedrijf implementeert Azure Front Door met behulp van deze configuratie:
DNS-configuratie
eenmalige configuratie: Geen.
Wanneer er een nieuwe tenant wordt geïntroduceerd: De tenant moet twee records maken op zijn eigen DNS-server:
- Een TXT-record voor domeinvalidatie. Tenant 1 moet bijvoorbeeld een TXT-record met de naam
tenant1app.tenant1.comconfigureren en deze instellen op de waarde die is opgegeven door Azure Front Door tijdens het onboardingproces van het aangepaste domein. - Een CNAME-record die is gealiaseerd naar het Azure Front Door-eindpunt van Adventure Works. Tenant 1 moet bijvoorbeeld een CNAME-record met de naam
tenant1app.tenant1.comconfigureren en toewijzen aanadventureworks.z01.azurefd.net.
TLS-configuratie
Adventure Works en de tenants moeten bepalen wie TLS-certificaten uitgeeft:
- De eenvoudigste optie is om Azure Front Door te gebruiken om de certificaten uit te geven en te beheren, maar tenants mogen geen CCA-records op hun DNS-servers configureren. Als dat het gebeurt, kunnen de records verhinderen dat de Azure Front Door-certificeringsinstantie certificaten uitgeeft.
- Tenants kunnen ook hun eigen certificaten opgeven. Ze moeten samenwerken met Adventure Works om het certificaat te uploaden naar een sleutelkluis en toegang te bieden tot Azure Front Door.
Azure Front Door-configuratie
eenmalige configuratie: Adventure Works maakt een Azure Front Door-profiel en één eindpunt. Ze configureren een oorsprongsgroep voor elke stempel. Ze maken geen aangepaste domeinbronnen of routes.
Wanneer er een nieuwe tenant wordt toegevoegd: Adventure Works voegt een aangepaste domeinresource toe aan Azure Front Door. Ze gebruiken de door de tenant geleverde domeinnaam en koppelen het juiste TLS-certificaat aan de aangepaste domeinresource. Vervolgens maken ze een route om op te geven naar welke oorsprongsgroep (stempel) de aanvragen van de tenant moeten worden omgeleid. In het voorgaande diagram wordt tenant1app.tenant1.com doorgestuurd naar de oorspronkelijke groep in de regio Australië en tenant2app.tenant3.com wordt doorgestuurd naar de oorspronkelijke groep in de regio VS.
Voordelen
- Klanten kunnen hun eigen domeinnamen opgeven. Azure Front Door routeert aanvragen transparant naar de multitenant-oplossing.
- Adventure Works onderhoudt één exemplaar van Azure Front Door om verkeer te routeren naar meerdere stempels in meerdere regio's.
Nadelen
- Adventure Works moet Azure Front Door telkens opnieuw configureren wanneer een nieuwe tenant wordt geïmplementeerd.
- Tenants moeten betrokken zijn bij het onboardingproces. Ze moeten DNS-wijzigingen aanbrengen en mogelijk TLS-certificaten uitgeven.
- Tenants beheren hun DNS-records. Wijzigingen in DNS-records kunnen van invloed zijn op de mogelijkheid om toegang te krijgen tot de Adventure Works-oplossing.
- Adventure Works moet aandacht besteden aan quota en limieten van Azure Front Door, met name op het aantal routes en aangepaste domeinen, en de samengestelde routeringslimiet.
Scenario 5: Azure Front Door-profiel per stempel
U kunt voor elke stempel een Azure Front Door-profiel implementeren. Als u 10 stempels hebt, implementeert u 10 exemplaren van Azure Front Door. Deze aanpak kan handig zijn als u de beheertoegang van de Azure Front Door-configuratie van elke stempel wilt beperken. Het kan ook handig zijn als u meerdere Azure Front Door-profielen moet gebruiken om te voorkomen dat resourcequota of limieten worden overschreden.
Tip
Azure Front Door is een wereldwijde resource. Zelfs als u regionale stempels implementeert, wordt elk Azure Front Door-profiel wereldwijd gedistribueerd. U moet overwegen of u echt meerdere Azure Front Door-profielen moet implementeren en welke voordelen u hiermee krijgt.
Als u een stempel hebt dat meerdere tenants bedient, moet u overwegen hoe u verkeer naar elke tenant routeert. Bekijk de benaderingen die in de voorgaande scenario's worden beschreven en overweeg om benaderingen te combineren die aan uw vereisten voldoen.
Voordelen
- Als u uw configuratie uitbreidt over meerdere profielen, bereikt u minder waarschijnlijk de resourcelimieten van Azure Front Door. Als u bijvoorbeeld een groot aantal aangepaste domeinen wilt ondersteunen, kunt u de domeinen verdelen over meerdere Azure Front Door-profielen en binnen de grenzen van elk profiel blijven.
- Met deze aanpak kunt u de machtigingen voor resourcebeheer van Azure Front Door scopen. U kunt op rollen gebaseerd toegangsbeheer van Azure (RBAC) gebruiken om beheerders toegang te verlenen tot één stempelprofiel.
Nadelen
- Bij deze benadering worden doorgaans hoge kosten in rekening gebracht omdat u meer profielen implementeert. Zie Inzicht in de facturering van Front Doorvoor meer informatie.
- Er is een limiet voor het aantal Azure Front Door-profielen dat u in één Azure-abonnement kunt implementeren. Zie Quota en limieten voor Front Doorvoor meer informatie.
- U moet het Azure Front Door-profiel van elke stempel afzonderlijk configureren en u moet dns-configuratie, TLS-certificaten en TLS-configuratie voor elke stempel beheren.
Medewerkers
Dit artikel wordt onderhouden door Microsoft. Het is oorspronkelijk geschreven door de volgende inzenders.
Hoofdauteurs:
- Raj Nemani | Directeur, Partnertechnologiestrateeg
- John Downs | Hoofdsoftware-ingenieur
Andere inzenders:
- Mick Alberts | Technisch schrijver
- Fernando Antivero | Fullstack Ontwikkelaar & Cloud Platform Ingenieur
- Duong Au | Senior Contentontwikkelaar, C+E Skilling Content R&D
- Harikrishnan M B (HARI) | Product Manager 2, Azure-netwerken
- Arsen Vladimirskiy | Hoofdkundige Klanttechnicus, FastTrack voor Azure
Meld u aan bij LinkedIn als u niet-openbare LinkedIn-profielen wilt zien.