Azure veelgestelde vragen over landingszones

In dit artikel vindt u antwoorden op veelgestelde vragen over Azure architectuur van landingszones.

Zie voor veelgestelde vragen over de implementatie van Azure landing zone-architectuur, de FAQ voor implementatie op ondernemingsschaal.

Wat is de Azure portalversneller voor landingszones?

De Azure portalversneller voor landingszones is een Azure implementatie-ervaring op basis van de portal. Er wordt een sterk gedefinieerde implementatie toegepast op basis van de referentiearchitectuur van de Azure landing zone.

Wat zijn de aanbevolen accelerators en implementaties voor Azure landingszones?

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

Bekijk de richtlijnen Deploy Azure landingszones voor meer informatie over de aanbevolen platform- en toepassingslandingszones.

Zie Pas de architectuur van de Azure-landingszone aan om aan de vereisten te voldoen voor uitleg over hoe u de implementatie van uw Azure-landingszones kunt aanpassen aan uw behoeften.

Wat is de referentiearchitectuur van de Azure landingszone?

De Azure referentiearchitectuur voor landingszones 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 komt een landingszone in Azure in de context van de architectuur van Azure-landingszones mee overeen?

Vanuit een Azure landingszonepunt 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, Deny, DeployIfNotExists en Modify, om te voorkomen dat niet-naleving wordt voorkomen door niet-compatibele resources (zoals gedefinieerd door de beleidsdefinitie) te beperken of door resources te implementeren of door instellingen voor het maken of bijwerken van resources te wijzigen 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 is ingeschakeld voor het abonnement. Het configureert ook de diagnostische instellingen voor activiteitenlogboek 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 nog niet klaar zijn of niet in staat zijn om het DeployIfNotExists-beleid (DINE) te gebruiken?

We hebben een speciale pagina die u stap voor stap door de verschillende fasen en opties begeleidt om ofwel DINE-beleid uit te schakelen, of om onze driefasenaanpak te gebruiken om ze geleidelijk in uw omgeving in te voeren.

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 controleren, te besturen en compliant te houden. Het is niet ontworpen om volledige workloads en andere hulpprogramma's te implementeren. Gebruik de Azure-portal of infrastructuur-als-code-oplossingen (ARM-sjablonen, Bicep, Terraform) om uw workload te implementeren en beheren en de autonomie te verkrijgen die u nodig hebt.

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

De Cloud Adoption Framework landingszones open source project (OSS) (ook wel bekend als aztfmod) is een communitygestuurd project dat eigendom is van en wordt onderhouden buiten het Azure kernteam van de landingszone en de Azure GitHub organisatie. Als uw organisatie ervoor kiest om dit OSS-project te gebruiken, moet er aandacht worden besteed aan 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 waarvan de scope deze omvat?

Bekijk de volgende documentatiesecties:

• Bestaande Azure-omgevingen overzetten naar de Azure landingszone referentiearchitectuur - Sectie Beleid
• Quickstart: Een beleidstoewijzing maken om niet-compatibele resources te identificeren - sectie Niet-compatibele resources identificeren

Heb ik een toegewezen of afzonderlijke AI-landingszone nodig?

Nee, u hebt geen afzonderlijke AI-landingszone nodig. In plaats daarvan kunt u de bestaande Azure landingszonearchitectuur gebruiken om AI-workloads in te implementeren. Zie de richtlijnen en uitleg in AI in Azure landingszones.

Hoe gaan we om met 'dev/test/production' werkbelastingslandingszones in de Azure landingszone-architectuur?

Zie Omgevingen voor het ontwikkelen van toepassingen in Azure landingszones voor meer informatie.

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

Wanneer u Azure architectuur voor landingszones implementeert met behulp van de Azure ervaring voor referentiearchitectuur van landingszones, 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 Deploymentlocatie wordt ook gebruikt om te selecteren welke Azure regio-specifieke resources moeten worden opgeslagen, zoals een Log Analytics werkruimte, indien nodig.

Als u een netwerktopologie implementeert op het tabblad Network-topologie en -connectiviteit, moet u een Azure regio selecteren om de netwerkresources te 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 kunnen we meer Azure regio's inschakelen wanneer we Azure architectuur voor landingszones 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.

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

• U hebt een Enterprise Agreement (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. Zie Billing-accounts en -bereiken in de Azure-portal voor meer informatie over abonnementslimieten.
• U bent een prepaid-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 minimaal levensvatbare producten (MVP's), inclusief onafhankelijke softwareleveranciers (ISV's) voor klantdemo- of proeftoegang.
  3. Trainingsomgevingen, zoals leeromgevingen voor MSP's en trainers

Hoe gebruik ik abonnementen opnieuw?

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, inclusief Privileged Identity Management (PIM)-roltoewijzingen, in het abonnementsbereik.
• Verwijder de aangepaste RBAC-definities (op rollen gebaseerde toegangstoegang) op abonnementsniveau.
• 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 alle Microsoft Cost Management budgetten binnen het abonnementsbereik.
• Stel Microsoft Defender voor Cloud plannen opnieuw in op gratis lagen, tenzij organisatievereisten verplicht stellen dat deze logboeken zijn ingesteld 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 Azure Lighthouse-delegaties op het niveau van het abonnement.
• Verwijder verborgen resources uit het abonnement.

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 Privileged Identity Management (PIM)-roltoewijzingen toe aan het abonnementsbereik voor de nieuwe eigenaren. Typisch zouden deze toewijzingen aan Microsoft Entra-groepen worden gedaan in plaats van aan personen.
• Plaats het abonnement in de gewenste beheergroep op basis van de governancevereisten.
• Maak nieuwe Microsoft Cost Management budget aan en stel waarschuwingen in voor nieuwe eigenaren wanneer drempelwaarden zijn bereikt.
• Configureer Microsoft Defender voor Cloud plannen naar de gewenste niveaus. 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 Sovereign Cloud die is bedoeld voor klanten in de openbare sector die geavanceerde soevereiniteitscontroles nodig hebben. Als een op maat gemaakte versie van de referentiearchitectuur voor een soevereine landingszone, worden Azure-mogelijkheden afgesteld op aspecten zoals service-residentie, door de klant beheerde sleutels, Azure Private Link en vertrouwelijke computing. Door deze uitlijning maakt de onafhankelijke landingszone een cloudarchitectuur waarin gegevens en workloads standaard versleuteling en bescherming bieden tegen bedreigingen.

Zie Soevereine landingszone (SLZ) voor meer informatie over de soevereine landingszone.