Veelgestelde vragen over Azure-landingszones (FAQ)

In dit artikel vindt u antwoorden op veelgestelde vragen over de architectuur van de Azure-landingszone.

Zie Veelgestelde vragen over het implementeren van azure-landingszonearchitectuur voor veelgestelde vragen over de implementatie op ondernemingsniveau.

Wat is de Azure-landingszoneversneller?

De Azure-landingszoneversneller is een implementatie-ervaring op basis van de Azure-portal. Er wordt een geïnformeerde implementatie geïmplementeerd op basis van de conceptuele architectuur van de Azure-landingszone.

Wat zijn de aanbevolen accelerators en implementaties voor Azure-landingszones?

Microsoft ontwikkelt en onderhoudt actief het platform en de toepassingsversnellers en implementaties in overeenstemming met de ontwerpprincipes en richtlijnen voor het ontwerpgebied van Azure-landingszones.

Raadpleeg de richtlijnen voor Het implementeren van Azure-landingszones voor meer informatie over het aanbevolen platform en de landingszones voor toepassingen.

Zie De architectuur van de Azure-landingszone aanpassen aan de vereisten voor meer informatie over het aanpassen van de implementatie van uw Azure-landingszones aan uw behoeften

Tip

Als u een aanvulling op de lijst met accelerators en implementaties wilt aanvragen, moet u een GitHub-probleem indienen in de ALZ-opslagplaats.

Wat is de conceptuele architectuur van de Azure-landingszone?

De conceptuele architectuur van de Azure-landingszone vertegenwoordigt schaal- en volwassenheidsbeslissingen. Het is gebaseerd op lessen die zijn geleerd en feedback van klanten die Azure hebben aangenomen als onderdeel van hun digitale activa. Deze conceptuele architectuur kan uw organisatie helpen een richting in te stellen voor het ontwerpen en implementeren van een landingszone.

Waar wordt een landingszone in Azure in de context van de Architectuur van de Azure-landingszone aan toegewezen?

Vanuit het oogpunt van een Azure-landingszone zijn landingszones afzonderlijke Azure-abonnementen.

Wat betekent beleidgestuurde governance en hoe werkt het?

Governance op basis van beleid is een van de belangrijkste ontwerpprincipes van architectuur op ondernemingsniveau.

Door beleid gestuurd beheer betekent het gebruik van Azure Policy om de tijd te verkorten die u nodig hebt voor algemene en herhaalde operationele taken in uw Azure-tenant. Gebruik veel van de Azure Policy-effecten, zoals Append, Denyen DeployIfNotExistsModify, om te voorkomen dat niet-naleving wordt voorkomen door niet-compatibele resources (zoals gedefinieerd door de beleidsdefinitie) te beperken of te implementeren of door resources te implementeren of door instellingen van een resource te maken of bij te werken om ze compatibel te maken. Sommige effecten, zoals Audit, Disableden AuditIfNotExists, voorkomen of ondernemen geen actie; ze controleren en rapporteren alleen over niet-naleving.

Enkele voorbeelden van beleidsgestuurde governance zijn:

• Deny effect: Hiermee voorkomt u dat subnetten worden gemaakt of bijgewerkt zodat er geen netwerkbeveiligingsgroepen aan zijn gekoppeld.

• DeployIfNotExists effect: Er wordt een nieuw abonnement (landingszone) gemaakt en in een beheergroep geplaatst binnen de implementatie van uw Azure-landingszone. Azure Policy zorgt ervoor dat Microsoft Defender voor Cloud (voorheen Bekend als Azure Security Center) is ingeschakeld voor het abonnement. Ook worden de diagnostische instellingen voor activiteitenlogboek geconfigureerd om logboeken te verzenden naar de Log Analytics-werkruimte in het beheerabonnement.

  In plaats van code of handmatige activiteiten te herhalen wanneer een nieuw abonnement wordt gemaakt, wordt de DeployIfNotExists beleidsdefinitie automatisch voor u geïmplementeerd en geconfigureerd.

Wat gebeurt er als we het DeployIfNotExists-beleid (DINE) nog niet kunnen gebruiken of nog niet kunnen gebruiken?

We hebben een speciale pagina die de verschillende fasen en opties doorloopt die u moet "uitschakelen" DINE-beleid of onze drie fasen gebruiken om ze in de loop van de tijd in uw omgeving te gebruiken.

Zie de richtlijnen voor het aannemen van beleidgestuurde kaders

Moeten we Azure Policy gebruiken om workloads te implementeren?

Kortom, nee. Gebruik Azure Policy om uw workloads en landingszones te beheren, te beheren en te behouden. Het is niet ontworpen om volledige workloads en andere hulpprogramma's te implementeren. Gebruik de Azure-portal of infrastructuur als codeaanbiedingen (ARM-sjablonen, Bicep, Terraform) om uw workload te implementeren en te beheren en de autonomie te krijgen die u nodig hebt.

Wat is Landingszones voor Cloud Adoption Framework voor Terraform (aztfmod)?

Het opensource-project (OSS) van Cloud Adoption Framework (ook wel aztfmod genoemd) is een communitygestuurd project dat eigendom is van en wordt onderhouden buiten het kernteam van de Azure-landingszone en de Azure GitHub-organisatie. Als uw organisatie ervoor kiest dit OSS-project te gebruiken, moet u rekening houden met de beschikbare ondersteuning, omdat dit wordt aangestuurd door de inspanningen van de community via GitHub.

Wat gebeurt er als we al resources in onze landingszones hebben en later een Azure Policy-definitie toewijzen die ze in het bereik bevat?

Bekijk de volgende documentatiesecties:

• Bestaande Azure-omgevingen overschakelen naar de conceptuele architectuur van de Azure-landingszone - sectie Beleid
• Quickstart: Een beleidstoewijzing maken om niet-compatibele resources te identificeren - sectie Niet-compatibele resources identificeren

Hoe verwerken we landingszones voor workload 'dev/test/production' in de Architectuur van de Azure-landingszone?

Zie Toepassingsontwikkelingsomgevingen beheren in Azure-landingszones voor meer informatie.

Waarom wordt u gevraagd om Azure-regio's op te geven tijdens de implementatie van de Azure-landingszoneversneller en waarvoor worden ze gebruikt?

Wanneer u de architectuur van de Azure-landingszone implementeert met behulp van de azure-ervaring voor de landingszoneversneller op basis van de portal, selecteert u een Azure-regio waarin u wilt implementeren. Het eerste tabblad, de implementatielocatie, bepaalt waar de implementatiegegevens worden opgeslagen. Zie Tenantimplementaties met ARM-sjablonen voor meer informatie. Sommige onderdelen van een landingszone worden wereldwijd geïmplementeerd, maar de metagegevens van de implementatie worden bijgehouden in een regionaal metagegevensarchief. De metagegevens met betrekking tot de implementatie worden opgeslagen in de regio die is geselecteerd op het tabblad Implementatielocatie .

De regioselector op het tabblad Implementatielocatie wordt ook gebruikt om te selecteren welke Azure-regio eventuele regiospecifieke resources moeten worden opgeslagen, zoals een Log Analytics-werkruimte en een automation-account, indien nodig.

Als u een netwerktopologie implementeert op het tabblad Netwerktopologie en connectiviteit , moet u een Azure-regio selecteren waarnaar u de netwerkresources wilt implementeren. Deze regio kan afwijken van de regio die is geselecteerd op het tabblad Implementatielocatie .

Zie Landingszoneregio's voor meer informatie over de regio's die resources voor landingszones gebruiken.

Hoe schakelen we meer Azure-regio's in wanneer we azure-landingszonearchitectuur gebruiken?

Zie Landingszoneregio's voor meer informatie over het toevoegen van nieuwe regio's aan een landingszone of het verplaatsen van resources voor landingszones naar een andere regio.

Moeten we elke keer een nieuw Azure-abonnement maken of moeten we Azure-abonnementen opnieuw gebruiken?

Wat is opnieuw gebruiken van abonnementen?

Opnieuw gebruiken van abonnementen is het proces voor het opnieuw uitgeven van een bestaand abonnement aan een nieuwe eigenaar. Er moet een proces zijn om het abonnement opnieuw in te stellen op een bekende schone status en vervolgens opnieuw toe te kennen aan een nieuwe eigenaar.

Waarom zou ik overwegen om abonnementen opnieuw te gebruiken?

Over het algemeen raden we klanten aan om het ontwerpprincipe voor abonnements democratisatie te gebruiken. Er zijn echter specifieke omstandigheden waarin hergebruik van abonnementen niet mogelijk of aanbevolen is.

Tip

Bekijk de YouTube-video over het ontwerpprincipe voor abonnements democratisatie hier: Azure Landing Zones - Hoeveel abonnementen moet ik gebruiken in Azure?

Overweeg het opnieuw gebruiken van abonnementen als u aan een van de volgende omstandigheden voldoet:

• U hebt een Enterprise Overeenkomst (EA) en wilt meer dan 5000 abonnementen maken op één EA-accounteigenaaraccount (factureringsaccount), inclusief verwijderde abonnementen.
• U hebt een Microsoft-klantovereenkomst (MCA) of Microsoft Partner-overeenkomst MPA en wilt meer dan 5000 actieve abonnementen hebben
• U bent een betalen per gebruik-klant
• U gebruikt een Microsoft Azure Sponsorship
• Meestal maakt u het volgende:
  1. Kortstondige lab- of sandboxomgevingen
  2. Demo-omgevingen voor proofs-of-concept (POC's) of minimum viable products (MVP), inclusief onafhankelijke softwareleveranciers (ISV) voor klantdemo-/proeftoegang
  3. Trainingsomgevingen, zoals MSP's/Trainer's leeromgevingen

Hoe kan ik abonnementen opnieuw gebruiken?

Als u overeenkomt met een van de bovenstaande scenario's of overwegingen, moet u overwegen bestaande buiten gebruik gestelde of ongebruikte abonnementen opnieuw te gebruiken en deze opnieuw toe te passen aan een nieuwe eigenaar en een nieuw doel.

Oud abonnement opschonen

U moet eerst het oude abonnement opschonen voor hergebruik. U moet de volgende acties uitvoeren voor een abonnement voordat het klaar is voor hergebruik:

• Resourcegroepen en ingesloten resources verwijderen.
• Verwijder roltoewijzingen, met inbegrip van PIM-roltoewijzingen (Privileged Identity Management), in het abonnementsbereik.
• Verwijder aangepaste RBAC-definities (op rollen gebaseerd toegangsbeheer) op het abonnementsbereik.
• Verwijder beleidsdefinities, initiatieven, toewijzingen en uitzonderingen binnen het abonnementsbereik.
• Verwijder implementaties binnen het abonnementsbereik.
• Verwijder tags in het abonnementsbereik.
• Verwijder resourcevergrendelingen binnen het abonnementsbereik.
• Verwijder microsoft Cost Management-budgetten in het abonnementsbereik.
• Stel Microsoft Defender voor Cloud plannen opnieuw in op gratis lagen, tenzij organisatievereisten deze logboeken verplicht stellen op de betaalde lagen. Normaal gesproken dwingt u deze vereisten af via Azure Policy.
• Verwijder activiteitenlogboeken voor abonnementen (diagnostische instellingen) die worden doorgestuurd naar Log Analytics-werkruimten, Event Hubs, Opslagaccount of andere ondersteunde bestemmingen, tenzij organisatievereisten het doorsturen van deze logboeken verplicht stellen terwijl een abonnement actief is.
• Verwijder eventuele Azure Lighthouse-delegaties in het abonnementsbereik.
• Verwijder verborgen resources uit het abonnement.

Tip

Door Get-AzResource het abonnementsbereik te gebruiken of az resource list -o table te gebruiken, kunt u alle verborgen of resterende resources vinden die u wilt verwijderen voordat u het opnieuw toewijst.

Het abonnement opnieuw toewijzen

U kunt het abonnement opnieuw toewijzen nadat u het abonnement hebt opgeschoond. Hier volgen enkele algemene activiteiten die u mogelijk wilt uitvoeren als onderdeel van het hertoewijzingsproces:

• Voeg nieuwe tags toe en stel er waarden voor in voor het abonnement.
• Voeg nieuwe roltoewijzingen of PIM-roltoewijzingen (Privileged Identity Management) toe aan het abonnementsbereik voor de nieuwe eigenaren. Deze toewijzingen zijn doorgaans voor Microsoft Entra-groepen in plaats van personen.
• Plaats het abonnement in de gewenste beheergroep op basis van de governancevereisten.
• Maak nieuwe Microsoft Cost Management-budgetten en stel waarschuwingen in op nieuwe eigenaren wanneer aan drempelwaarden is voldaan.
• Stel Microsoft Defender voor Cloud plannen in op de gewenste lagen. U moet deze instelling afdwingen via Azure Policy zodra deze in de juiste beheergroep is geplaatst.
• Configureer activiteitenlogboeken voor abonnementen (diagnostische instellingen) die worden doorgestuurd naar Log Analytics-werkruimten, Event Hubs, Opslagaccount of andere ondersteunde bestemmingen. U moet deze instelling afdwingen via Azure Policy zodra deze in de juiste beheergroep is geplaatst.

Wat is een onafhankelijke landingszone en hoe is deze gerelateerd aan de Architectuur van de Azure-landingszone?

De onafhankelijke landingszone is een onderdeel van Microsoft Cloud for Sovereignty dat is bedoeld voor klanten in de openbare sector die geavanceerde soevereiniteitscontroles nodig hebben. Als een op maat gemaakte versie van de conceptuele architectuur van de Azure-landingszone worden azure-mogelijkheden, zoals servicelocatie, door de klant beheerde sleutels, Azure Private Link en confidential computing, uitgelijnd. Door deze uitlijning maakt de onafhankelijke landingszone een cloudarchitectuur waarin gegevens en workloads standaard versleuteling en bescherming bieden tegen bedreigingen.

Notitie

Microsoft Cloud for Sovereignty is gericht op overheidsorganisaties met soevereiniteitsbehoeften. U moet zorgvuldig overwegen of u de Microsoft Cloud for Sovereignty-mogelijkheden nodig hebt en pas vervolgens de architectuur van de soevereine landingszone kunt gebruiken.

Zie Soevereiniteitsoverwegingen voor Azure-landingszones voor meer informatie over de soevereine landingszone.