Dela via


Vanliga frågor och svar om Azure-landningszoner

Den här artikeln besvarar vanliga frågor om Arkitektur för Azure-landningszoner.

Vanliga frågor och svar om hur du implementerar Arkitektur för Azure-landningszoner finns i Vanliga frågor och svar om implementering i Företagsskala.

Vad är azure-landningszonacceleratorn?

Azure-landningszonacceleratorn är en Azure-portalbaserad distributionsupplevelse. Den distribuerar en åsiktsbaserad implementering baserat på den konceptuella arkitekturen för Azure-landningszonen.

Microsoft utvecklar och underhåller aktivt plattforms- och programacceleratorerna och implementeringarna i enlighet med designprinciperna för Azure-landningszonen och designområdesvägledningen.

Läs guiden Distribuera Azure-landningszoner för att lära dig mer om de rekommenderade plattforms- och programlandningszonerna.

Mer information om hur du skräddarsyr distributionen av Azure-landningszoner efter dina behov finns i Anpassa Arkitekturen för Azure-landningszoner för att uppfylla kraven

Dricks

Om du vill begära ett tillägg till acceleratorn och implementeringslistan skapar du ett GitHub-problem på ALZ-lagringsplatsen.

Vad är konceptarkitekturen för Azure-landningszonen?

Konceptarkitekturen i Azure-landningszonen representerar beslut om skalning och mognad. Den baseras på lärdomar och feedback från kunder som har antagit Azure som en del av sin digitala egendom. Den här konceptuella arkitekturen kan hjälpa din organisation att ange en riktning för att utforma och implementera en landningszon.

Vad mappas en landningszon till i Azure i kontexten för Arkitektur för Azure-landningszoner?

Från en Azure-landningszon är landningszoner enskilda Azure-prenumerationer.

Vad betyder principdriven styrning och hur fungerar den?

Principdriven styrning är en av de viktigaste designprinciperna för arkitektur i företagsskala.

Principdriven styrning innebär att du använder Azure Policy för att minska den tid du behöver för vanliga och upprepade operativa uppgifter i din Azure-klientorganisation. Använd många av Azure Policy-effekterna, till exempel Append, Deny, DeployIfNotExistsoch Modify, för att förhindra inkompatibilitet genom att antingen begränsa icke-kompatibla resurser (enligt definitionen i principdefinitionen) från att skapas eller uppdateras eller genom att distribuera resurser eller ändra inställningarna för en begäran om att skapa eller uppdatera resurser för att göra dem kompatibla. Vissa effekter, till exempel Audit, Disabledoch AuditIfNotExists, förhindrar eller vidtar inte åtgärder. De granskar och rapporterar endast om bristande efterlevnad.

Några exempel på principdriven styrning är:

  • Deny effekt: Förhindrar att undernät skapas eller uppdateras så att inga nätverkssäkerhetsgrupper är associerade med dem.

  • DeployIfNotExists effekt: En ny prenumeration (landningszon) skapas och placeras i en hanteringsgrupp i azure-landningszonens distribution. Azure Policy säkerställer att Microsoft Defender för molnet (tidigare kallat Azure Security Center) är aktiverat i prenumerationen. Den konfigurerar också diagnostikinställningarna för aktivitetsloggen för att skicka loggar till Log Analytics-arbetsytan i hanteringsprenumerationen.

    I stället för att upprepa kod eller manuella aktiviteter när en ny prenumeration skapas distribuerar och konfigurerar principdefinitionen DeployIfNotExists dem automatiskt åt dig.

Vad händer om vi inte kan eller ännu inte är redo att använda DINE-principer (DeployIfNotExists) ?

Vi har en dedikerad sida som går igenom de olika faser och alternativ som du har för att antingen "inaktivera" DINE-principer eller använda vår trefasmetod för att införa dem över tid i din miljö.

Se vägledningen Anta principdrivna skyddsräcken

Ska vi använda Azure Policy för att distribuera arbetsbelastningar?

Kort och kort, nej. Använd Azure Policy för att styra, styra och hålla dina arbetsbelastningar och landningszoner kompatibla. Den är inte utformad för att distribuera hela arbetsbelastningar och andra verktyg. Använd Azure-portalen eller erbjudanden för infrastruktur som kod (ARM-mallar, Bicep, Terraform) för att distribuera och hantera din arbetsbelastning och få den autonomi du behöver.

Vad är Cloud Adoption Framework-landningszoner för Terraform (aztfmod)?

Cloud Adoption Framework-landningszonernas projekt med öppen källkod (OSS) (även kallat aztfmod) är ett communitydrivet projekt som ägs och underhålls utanför Azures kärnteam för landningszoner och Azure GitHub-organisationen. Om din organisation väljer att använda det här OSS-projektet bör supporten övervägas eftersom detta drivs av communityarbetet via GitHub.

Vad händer om vi redan har resurser i våra landningszoner och senare tilldelar en Azure Policy-definition som innehåller dem i dess omfång?

Läs följande dokumentationsavsnitt:

Hur hanterar vi "dev/test/production"-arbetsbelastningslandningszoner i Azures landningszonarkitektur?

Mer information finns i Hantera programutvecklingsmiljöer i Azure-landningszoner.

Varför uppmanas vi att ange Azure-regioner under distributionen av Azure-landningszonens accelerator och vad används de till?

När du distribuerar Arkitektur för Azure-landningszoner med hjälp av portalbaserad azure-lösningsaccelerator för landningszon väljer du en Azure-region att distribuera till. Den första fliken Distributionsplats avgör var distributionsdata lagras. Mer information finns i Klientdistributioner med ARM-mallar. Vissa delar av en landningszon distribueras globalt, men deras distributionsmetadata spåras i ett regionalt metadatalager. Metadata för distributionen lagras i den region som valts på fliken Distributionsplats .

Regionväljaren på fliken Distributionsplats används också för att välja vilken Azure-region alla regionspecifika resurser ska lagras, till exempel en Log Analytics-arbetsyta och ett automationskonto, om det behövs.

Om du distribuerar en nätverkstopologi på fliken Nätverkstopologi och anslutning måste du välja en Azure-region att distribuera nätverksresurserna till. Den här regionen kan skilja sig från den region som valts på fliken Distributionsplats .

Mer information om de regioner som landningszonresurser använder finns i Landningszonregioner.

Hur aktiverar vi fler Azure-regioner när vi använder Arkitektur för Azure-landningszoner?

Information om hur du lägger till nya regioner i en landningszon eller hur du flyttar landningszonresurser till en annan region finns i Landningszonregioner.

Ska vi skapa en ny Azure-prenumeration varje gång eller ska vi återanvända Azure-prenumerationer?

Vad är återanvändning av prenumerationer?

Återanvändning av prenumerationer är processen att utfärda en befintlig prenumeration till en ny ägare. Det bör finnas en process för att återställa prenumerationen till ett känt rent tillstånd och sedan tilldelas om till en ny ägare.

Varför bör jag överväga att återanvända prenumerationer?

I allmänhet rekommenderar vi att kunderna antar designprincipen för prenumerationsdemokratisering. Det finns dock särskilda omständigheter där återanvändning av prenumerationer inte är möjligt eller rekommenderas.

Dricks

Titta på YouTube-videon om designprincipen för prenumerationsdemokratisering här: Azure-landningszoner – Hur många prenumerationer ska jag använda i Azure?

Du bör överväga att återanvända prenumerationer om du uppfyller något av följande:

  • Du har en ugovor za preduzeća (EA) och planerar att skapa fler än 5 000 prenumerationer på ett enda EA-kontos ägarkonto (faktureringskonto), inklusive borttagna prenumerationer.
  • Du har en Microsoft korisnički ugovor (MCA) eller Microsoft Partner Agreement MPA och planerar att ha fler än 5 000 aktiva prenumerationer. Mer information om prenumerationsgränser finns i Faktureringskonton och omfång i Azure-portalen.
  • Du är en betala per användning-kund.
  • Du använder en Microsoft Azure-sponsring.
  • Du skapar ofta:
    1. Tillfälliga labb- eller sandbox-miljöer
    2. Demomiljöer för konceptbevis (POCs) eller lägsta livskraftiga produkter (MVP), inklusive oberoende programvaruleverantörer (ISV) för kunddemo-/utvärderingsåtkomst
    3. Utbildningsmiljöer, till exempel MSP:er/Utbildarens elevmiljöer

Hur återanvänder jag prenumerationer?

Om du matchar något av ovanstående scenarier eller överväganden kan du behöva överväga att återanvända befintliga inaktiverade eller oanvända prenumerationer och omtilldela dem till en ny ägare och syfte.

Rensa den gamla prenumerationen

Du måste först rensa den gamla prenumerationen för återanvändning. Du måste utföra följande åtgärder för en prenumeration innan den är redo för återanvändning:

  • Ta bort resursgrupper och inneslutna resurser.
  • Ta bort rolltilldelningar, inklusive PIM-rolltilldelningar (Privileged Identity Management) i prenumerationsomfånget.
  • Ta bort RBAC-definitioner (Custom Role-based Access Control) i prenumerationsomfånget.
  • Ta bort principdefinitioner, initiativ, tilldelningar och undantag i prenumerationsomfånget.
  • Ta bort distributioner i prenumerationsomfånget.
  • Ta bort taggar i prenumerationsomfånget.
  • Ta bort eventuella resurslås i prenumerationsomfånget.
  • Ta bort alla Microsoft Cost Management-budgetar i prenumerationsomfånget.
  • Återställ Microsoft Defender for Cloud-planer till kostnadsfria nivåer om inte organisationens krav kräver att loggarna är inställda på de betalda nivåerna. Du tillämpar normalt dessa krav via Azure Policy.
  • Ta bort vidarebefordran av prenumerationsaktivitetsloggar (diagnostikinställningar) till Log Analytics-arbetsytor, händelsehubbar, lagringskonto eller andra mål som stöds, såvida inte organisationens krav kräver vidarebefordran av loggarna medan en prenumeration är aktiv.
  • Ta bort alla Azure Lighthouse-delegeringar i prenumerationsomfånget.
  • Ta bort dolda resurser från prenumerationen.

Dricks

Om du använder Get-AzResource eller az resource list -o table riktar in dig på prenumerationsomfånget kan du hitta dolda eller återstående resurser att ta bort innan du tilldelar igen.

Tilldela om prenumerationen

Du kan tilldela om prenumerationen när du har rensat prenumerationen. Här följer några vanliga aktiviteter som du kanske vill utföra som en del av omtilldelningsprocessen:

  • Lägg till nya taggar och ange värden för dem i prenumerationen.
  • Lägg till nya rolltilldelningar eller PIM-rolltilldelningar (Privileged Identity Management) i prenumerationsomfånget för de nya ägarna. Vanligtvis skulle dessa tilldelningar vara till Microsoft Entra-grupper i stället för enskilda.
  • Placera prenumerationen i önskad hanteringsgrupp baserat på dess styrningskrav.
  • Skapa nya Microsoft Cost Management-budgetar och ange aviseringar till nya ägare när tröskelvärdena uppfylls.
  • Ange Microsoft Defender for Cloud-planer till önskade nivåer. Du bör tillämpa den här inställningen via Azure Policy när den har placerats i rätt hanteringsgrupp.
  • Konfigurera vidarebefordran av prenumerationsaktivitetsloggar (diagnostikinställningar) till Log Analytics-arbetsytor, händelsehubbar, lagringskonto eller andra mål som stöds. Du bör tillämpa den här inställningen via Azure Policy när den har placerats i rätt hanteringsgrupp.

Den nationella landningszonen är en komponent i Microsoft Cloud for Sovereignty som är avsedd för kunder inom den offentliga sektorn som behöver avancerade suveränitetskontroller. Som en skräddarsydd version av den konceptuella arkitekturen i Azure-landningszonen anpassar den nationella landningszonen Azure-funktioner som tjänsthem, kundhanterade nycklar, Azure Private Link och konfidentiell databehandling. Genom den här justeringen skapar den nationella landningszonen en molnarkitektur där data och arbetsbelastningar erbjuder kryptering och skydd mot hot som standard.

Kommentar

Microsoft Cloud for Sovereignty är inriktat på statliga organisationer med suveränitetsbehov. Du bör noga överväga om du behöver funktionerna i Microsoft Cloud for Sovereignty och först sedan överväga att använda arkitekturen för den nationella landningszonen.

Mer information om den nationella landningszonen finns i Suveränitetsöverväganden för Azure-landningszoner.