Delen via

Overwegingen en aanbevelingen voor abonnementen

  • Artikel

Abonnementen vormen een eenheid van beheer, facturering en schaal binnen Azure. Ze spelen een belangrijke rol wanneer u ontwerpt voor grootschalige azure-acceptatie. Dit artikel helpt u bij het vastleggen van abonnementsvereisten en het ontwerpen van doelabonnementen op basis van kritieke factoren die variëren, afhankelijk van:

  • Omgevingstypen
  • Eigendoms- en governancemodellen
  • Organisatiestructuren
  • Toepassingsportfolio's
  • Regio's

Tip

Zie de YouTube-video: Azure-landingszones - Hoeveel abonnementen moet ik gebruiken in Azure voor meer informatie over abonnementen?

Notitie

Als u Enterprise Overeenkomst s, Microsoft-klantovereenkomst s (Enterprise) of Microsoft Partner-overeenkomst s (CSP) gebruikt, controleert u de abonnementslimieten in factureringsaccounts en bereiken in azure Portal.

Overwegingen voor abonnementen

De volgende secties bevatten overwegingen voor het plannen en maken van abonnementen voor Azure.

Ontwerpoverwegingen voor organisatie en governance

  • Abonnementen fungeren als grenzen voor Azure Policy-toewijzingen.

    Voor beveiligde workloads zoals PCI-workloads (Payment Card Industry) zijn doorgaans andere beleidsregels vereist om naleving te bereiken. In plaats van een beheergroep te gebruiken om workloads te verzamelen waarvoor PCI-naleving is vereist, kunt u dezelfde isolatie bereiken met een abonnement, zonder dat er te veel beheergroepen met een paar abonnementen zijn.

    Als u veel abonnementen van hetzelfde workload archetype wilt groeperen, maakt u deze onder een beheergroep.

  • Abonnementen fungeren als een schaaleenheid, zodat werkbelastingen van onderdelen kunnen worden geschaald binnen de limieten van het platformabonnement. Zorg ervoor dat u rekening houdt met abonnementsresourcelimieten tijdens het ontwerpen van uw workloads.

  • Abonnementen bieden een beheergrens voor governance en isolatie die duidelijk zorgen scheidt.

  • Maak afzonderlijke platformabonnementen voor beheer (bewaking), connectiviteit en identiteit wanneer ze vereist zijn.

    • Stel een speciaal beheerabonnement in uw platformbeheergroep in om globale beheermogelijkheden te ondersteunen, zoals Azure Monitor Logs-werkruimten en Azure Automation-runbooks.

    • Stel een toegewezen identiteitsabonnement in uw platformbeheergroep in om Windows Server Active Directory-domeincontrollers te hosten wanneer dat nodig is.

    • Stel een toegewezen connectiviteitsabonnement in uw platformbeheergroep in om een Azure Virtual WAN-hub, een DNS (Private Domain Name System), een Azure ExpressRoute-circuit en andere netwerkresources te hosten. Een toegewezen abonnement zorgt ervoor dat al uw basisnetwerkbronnen samen worden gefactureerd en geïsoleerd van andere workloads.

    • Gebruik abonnementen als een ge democratiseerde beheereenheid die overeenkomt met de behoeften en prioriteiten van uw bedrijf.

  • Gebruik handmatige processen om Microsoft Entra-tenants te beperken tot alleen Enterprise Overeenkomst inschrijvingsabonnementen. Wanneer u een handmatig proces gebruikt, kunt u geen MSDN-abonnementen (Microsoft Developer Network) maken in het bereik van de hoofdbeheergroep.

    Voor ondersteuning dient u een ondersteuning voor Azure-ticket in.

    Zie de Azure-abonnements- en reserveringsoverdrachthub voor informatie over abonnementsoverdracht tussen Azure-factureringsaanbiedingen.

Overwegingen voor meerdere regio's

Belangrijk

Abonnementen zijn niet gekoppeld aan een specifieke regio en u kunt ze behandelen als globale abonnementen. Het zijn logische constructies om facturering, governance, beveiliging en identiteitscontroles te bieden voor Azure-resources die erin zijn opgenomen. Daarom hebt u geen afzonderlijk abonnement nodig voor elke regio.

  • U kunt een benadering met meerdere regio's toepassen op het niveau van één workload voor schaalaanpassing of herstel na noodgevallen op geo-noodgeval of op globaal niveau (verschillende workloads in verschillende regio's).

  • Eén abonnement kan resources uit verschillende regio's bevatten, afhankelijk van de vereisten en architectuur.

  • In een context voor herstel na noodgevallen kunt u hetzelfde abonnement gebruiken om resources uit primaire en secundaire regio's te bevatten, omdat ze logisch deel uitmaken van dezelfde workload.

  • U kunt verschillende omgevingen implementeren voor dezelfde workload in verschillende regio's om de kosten en beschikbaarheid van resources te optimaliseren.

  • In een abonnement dat resources uit meerdere regio's bevat, kunt u resourcegroepen gebruiken om resources per regio te organiseren en te bevatten.

Overwegingen bij het ontwerpen van quota en capaciteit

Azure-regio's hebben mogelijk een beperkt aantal resources. Als gevolg hiervan moet u de beschikbare capaciteit en SKU's voor Azure-acceptaties bijhouden met verschillende resources.

  • Overweeg limieten en quota binnen het Azure-platform voor elke service die uw workloads nodig hebben.

  • Overweeg de beschikbaarheid van vereiste SKU's binnen uw gekozen Azure-regio's. Nieuwe functies kunnen bijvoorbeeld alleen beschikbaar zijn in bepaalde regio's. De beschikbaarheid van bepaalde SKU's voor bepaalde resources, zoals virtuele machines (VM's), kan per regio verschillen.

  • Houd er rekening mee dat abonnementsquota geen capaciteitsgaranties zijn en per regio worden toegepast.

    Zie Capaciteitsreservering op aanvraag voor reserveringen voor virtuele machines.

  • Overweeg ongebruikte of buiten gebruik gestelde abonnementen opnieuw te gebruiken. Zie Azure-abonnementen maken of opnieuw gebruiken voor meer informatie.

Ontwerpoverwegingen voor tenantoverdrachtbeperkingen

Elk Azure-abonnement is gekoppeld aan één Microsoft Entra-tenant, die fungeert als een id-provider (IdP) voor uw Azure-abonnement. Gebruik de Microsoft Entra-tenant om gebruikers, services en apparaten te verifiëren.

Wanneer een gebruiker over de vereiste machtigingen beschikt, kan deze de Microsoft Entra-tenant wijzigen die is gekoppeld aan uw Azure-abonnement. Zie voor meer informatie:

Notitie

U kunt geen overdracht uitvoeren naar een andere Microsoft Entra-tenant voor CSP-abonnementen (Azure Cloud Solution Provider).

Voor Azure-landingszones kunt u vereisten instellen om te voorkomen dat gebruikers abonnementen overdragen naar de Microsoft Entra-tenant van uw organisatie. Zie Azure-abonnementsbeleid beheren voor meer informatie.

Configureer uw abonnementsbeleid door een lijst met uitgesloten gebruikers op te geven. Uitgesloten gebruikers mogen beperkingen omzeilen die zijn ingesteld in het beleid.

Belangrijk

Een uitgesloten gebruikerslijst is geen Azure Policy.

  • Overweeg of u wilt toestaan dat gebruikers met Visual Studio- of MSDN Azure-abonnementen hun abonnement overdragen naar of van uw Microsoft Entra-tenant.

  • Alleen gebruikers met de rol Microsoft Entra Global Administrator kunnen instellingen voor tenantoverdracht configureren. Deze gebruikers moeten verhoogde toegang hebben om het beleid te wijzigen.

    • U kunt alleen afzonderlijke gebruikersaccounts opgeven als uitgesloten gebruikers, niet Microsoft Entra-groepen.

Belangrijk

Microsoft raadt u aan rollen te gebruiken met de minste machtigingen. Dit helpt de beveiliging voor uw organisatie te verbeteren. Globale beheerder is een zeer bevoorrechte rol die moet worden beperkt tot scenario's voor noodgevallen wanneer u geen bestaande rol kunt gebruiken.

  • Alle gebruikers met toegang tot Azure kunnen het beleid bekijken dat is gedefinieerd voor uw Microsoft Entra-tenant.

    • Gebruikers kunnen de lijst met uitgesloten gebruikers niet weergeven.

    • Gebruikers kunnen de globale beheerders in uw Microsoft Entra-tenant bekijken.

  • Azure-abonnementen die u overbrengt naar een Microsoft Entra-tenant, worden in de standaardbeheergroep voor die tenant geplaatst.

  • Als uw organisatie goedkeurt, kan uw toepassingsteam een proces definiëren waarmee Azure-abonnementen kunnen worden overgedragen naar of van een Microsoft Entra-tenant.

Overwegingen bij het ontwerpen van kostenbeheer

Elke grote onderneming heeft de uitdaging om kostentransparantie te beheren. In deze sectie worden de belangrijkste aspecten besproken om kostentransparantie te realiseren in grote Azure-omgevingen.

  • Mogelijk moet u terugstortingsmodellen, zoals App Service Environment en Azure Kubernetes Service (AKS), delen om een hogere dichtheid te bereiken. Terugstortingsmodellen kunnen van invloed zijn op PaaS-resources (Shared Platform as a Service).

  • Gebruik een afsluitschema voor niet-productieve workloads om de kosten te optimaliseren.

  • Gebruik Azure Advisor om aanbevelingen te krijgen voor het optimaliseren van kosten.

  • Stel een terugstortingsmodel in voor een betere verdeling van de kosten in uw organisatie.

  • Implementeer beleid zodat gebruikers geen niet-geautoriseerde resources in de omgeving van uw organisatie kunnen implementeren.

  • Stel een regelmatig schema en frequentie vast om de kosten en rechten voor resources voor workloads te controleren.

Aanbevelingen voor abonnementen

De volgende secties bevatten aanbevelingen om u te helpen abonnementen voor Azure te plannen en te maken.

Aanbevelingen voor organisatie en governance

  • Abonnementen behandelen als een beheereenheid die overeenkomt met de behoeften en prioriteiten van uw bedrijf.

  • Informeer abonnementseigenaren over hun rollen en verantwoordelijkheden.

    • Voer een kwartaal- of jaarlijkse toegangsbeoordeling uit voor Microsoft Entra Privileged Identity Management (PIM) om ervoor te zorgen dat bevoegdheden niet worden verspreid wanneer gebruikers zich binnen uw organisatie verplaatsen.

    • Neem het volledige eigendom van budgetuitgaven en resources.

    • Zorg voor beleidsnaleving en herstel als dat nodig is.

  • Wanneer u vereisten voor nieuwe abonnementen identificeert, raadpleegt u de volgende principes:

    • Schaallimieten: Abonnementen fungeren als een schaaleenheid voor onderdeelworkloads om te schalen binnen de limieten van het platformabonnement. Grote gespecialiseerde workloads, zoals high-performance computing, IoT en SAP, moeten afzonderlijke abonnementen gebruiken om te voorkomen dat deze limieten worden bereikt.

    • Beheergrens: Abonnementen bieden een beheergrens voor governance en isolatie, wat een duidelijke scheiding van zorgen mogelijk maakt. Verschillende omgevingen, zoals ontwikkel-, test- en productieomgevingen, worden vaak verwijderd vanuit het oogpunt van beheer.

    • Beleidsgrens: Abonnementen fungeren als een grens voor de Azure Policy-toewijzingen. Voor beveiligde workloads zoals PCI-workloads is bijvoorbeeld doorgaans ander beleid vereist om naleving te bereiken. De andere overhead wordt niet overwogen als u een afzonderlijk abonnement gebruikt. Ontwikkelomgevingen hebben meer ontspannen beleidsvereisten dan productieomgevingen.

    • Doelnetwerktopologie: u kunt geen virtuele netwerken delen tussen abonnementen, maar u kunt ze verbinden met verschillende technologieën, zoals peering van virtuele netwerken of ExpressRoute. Wanneer u besluit of u een nieuw abonnement nodig hebt, moet u overwegen welke workloads met elkaar moeten communiceren.

  • Groepeer abonnementen samen onder beheergroepen, die zijn afgestemd op uw beheergroepstructuur en beleidsvereisten. Groepeer abonnementen om ervoor te zorgen dat abonnementen met dezelfde set beleidsregels en Azure-roltoewijzingen afkomstig zijn van dezelfde beheergroep.

  • Stel een speciaal beheerabonnement in uw Platform beheergroep in om globale beheermogelijkheden te ondersteunen, zoals Azure Monitor Logs-werkruimten en Automation-runbooks.

  • Stel zo nodig een toegewezen identiteitsabonnement in uw Platform beheergroep in om Windows Server Active Directory-domeincontrollers te hosten.

  • Stel een toegewezen connectiviteitsabonnement in uw Platform beheergroep in om een Virtual WAN-hub, privé-DNS, ExpressRoute-circuit en andere netwerkresources te hosten. Een toegewezen abonnement zorgt ervoor dat al uw basisnetwerkbronnen samen worden gefactureerd en geïsoleerd van andere workloads.

  • Gebruik geen strikt abonnementsmodel. Gebruik in plaats daarvan een set flexibele criteria om abonnementen in uw organisatie te groeperen. Als uw organisatiestructuur en workloadsamenstelling veranderen, kunt u door deze flexibiliteit nieuwe abonnementsgroepen maken in plaats van een vaste set bestaande abonnementen te gebruiken. De ene grootte past niet op alle abonnementen en wat voor één bedrijfseenheid werkt, werkt mogelijk niet voor een andere. Sommige toepassingen kunnen naast elkaar binnen hetzelfde landingszoneabonnement bestaan, terwijl andere hun eigen abonnement nodig kunnen hebben.

    Zie Landingszones voor dev/test/productieworkloads verwerken voor meer informatie.

Aanbevelingen voor meerdere regio's

  • Maak alleen extra abonnementen voor elke regio als u regiospecifieke governance- en beheervereisten hebt, bijvoorbeeld gegevenssoevereine of om buiten quotumlimieten te schalen.

  • Als schalen geen probleem is voor een geo-noodherstelomgeving die meerdere regio's omvat, gebruikt u hetzelfde abonnement voor de primaire en secundaire regio-resources. Sommige Azure-services, afhankelijk van de BCDR-strategie (business continuity and disaster recovery) en hulpprogramma's die u gebruikt, moeten mogelijk hetzelfde abonnement gebruiken. In een actief-actief scenario, waarbij implementaties onafhankelijk worden beheerd of verschillende levenscycluss hebben, raden we u aan verschillende abonnementen te gebruiken.

  • De regio waar u een resourcegroep maakt en de regio van de ingesloten resources moeten overeenkomen, zodat deze geen invloed hebben op de tolerantie en betrouwbaarheid.

  • Eén resourcegroep mag geen resources uit verschillende regio's bevatten. Deze aanpak kan leiden tot problemen met resourcebeheer en beschikbaarheid.

Aanbevelingen voor quota en capaciteit

  • Gebruik abonnementen als schaaleenheden en schaal resources en abonnementen zo nodig uit. Uw workload kan vervolgens de vereiste resources gebruiken om uit te schalen zonder abonnementslimieten in het Azure-platform te bereiken.

  • Gebruik capaciteitsreserveringen om capaciteit in sommige regio's te beheren. Uw workload kan vervolgens de vereiste capaciteit hebben voor resources met een hoge vraag in een specifieke regio.

  • Stel een dashboard in met aangepaste weergaven voor het bewaken van gebruikte capaciteitsniveaus en stel waarschuwingen in als de capaciteit kritieke niveaus nadert, zoals 90% CPU-gebruik.

  • Verhoog ondersteuningsaanvragen voor quotumverhogingen onder abonnementsinrichting, zoals voor het totale aantal beschikbare VM-kernen binnen een abonnement. Zorg ervoor dat uw quotumlimieten zijn ingesteld voordat uw workloads de standaardlimieten overschrijden.

  • Zorg ervoor dat alle vereiste services en functies beschikbaar zijn binnen de gekozen implementatieregio's.

Automatiseringsaan aanbevelingen

  • Bouw een abonnementsautomaat proces om het maken van abonnementen voor toepassingsteams te automatiseren via een aanvraagwerkstroom. Zie Abonnementsverkoop voor meer informatie.

Aanbevelingen voor beperkingen voor tenantoverdracht

  • Configureer de volgende instellingen om te voorkomen dat gebruikers Azure-abonnementen overdragen naar of van uw Microsoft Entra-tenant:

    • Stel Abonnement in waarin u de Microsoft Entra-map verlaat op Permit no one.

    • Stel abonnement in dat u de Microsoft Entra-map invoert op Permit no one.

  • Configureer een beperkte lijst met uitgesloten gebruikers.

    • Neem leden op van een Azure-platformbewerkingsteam.

    • Neem break-glass-accounts op in de lijst met uitgesloten gebruikers.

Volgende stap

Beleidgestuurde kaders aannemen