** Azure vanliga frågor och svar om landningszoner (FAQ)

Den här artikeln besvarar vanliga frågor om Azure landningszonsarkitektur.

Vanliga frågor och svar om implementering av Azure landningszonsarkitektur finns i FAQ för företagsomfattande implementering.

Vad är Azure-portalacceleratorn för landningszoner?

Portalacceleratorn Azure landningszon är en Azure portalbaserad distributionsupplevelse. Den distribuerar en opinionsstyrd implementering baserat på referensarkitekturen för Azure landing zone.

Vilka är de rekommenderade acceleratorerna och implementeringarna för Azure landningszoner?

Microsoft utvecklar och underhåller aktivt plattforms- och applikationsacceleratorer och implementeringar i linje med Azure landningszonen designprinciper och designområdes vägledning.

Läs Distribuera Azure landningszoner vägledning för att lära dig mer om de rekommenderade landningszonerna för plattformar och program.

Information om hur du anpassar distributionen av Azure landningszoner efter dina behov finns i Tailor Azure-arkitekturen för landningszoner för att uppfylla kraven

Vad är referensarkitekturen för Azure landningszon?

Referensarkitekturen för Azure landningszon representerar beslut om skalning och mognad. Det baseras på lärdomar och feedback från kunder som antog Azure som en del av deras 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 motsvarar en landningszon i Azure inom ramen för Azure landningszonarkitektur?

Ur ett Azure landningszonsperspektiv är landningszonerna individuella 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 använda 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 effekter, till exempel Append, Deny, DeployIfNotExists och Modify, för att förhindra inkompatibilitet genom att antingen begränsa icke-kompatibla resurser (enligt principdefinitionen) från att skapas eller uppdateras eller genom att distribuera resurser eller ändra inställningarna för en resursskapande eller uppdateringsbegäran 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 din Azure-landningszonsdistribution. Azure Policy ser till att Microsoft Defender för molnet ä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 sagt, 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 arbetslaster 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 landningszoner open-source-projekt (OSS) (kallas även aztfmod) är ett community-drivet projekt som innehas och underhålls utanför Azure landningszoners kärnteam 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 communityns arbete via GitHub.

Vad händer om vi redan har resurser i våra landningszoner och senare tilldelar en Azure-policydefinition som inkluderar dem i sitt omfång?

Läs följande dokumentationsavsnitt:

• Övergång av befintlig Azure-miljö till referensarkitekturen för Azure landningszon – avsnittet "Policy"
• Snabbstart: Skapa en principtilldelning för att identifiera icke-kompatibla resurser – avsnittet "Identifiera icke-kompatibla resurser"

Behöver jag en dedikerad eller separat AI-landningszon?

Nej, du behöver ingen separat AI-landningszon. I stället kan du använda den befintliga Azure landningszonarkitekturen för att distribuera AI-arbetsbelastningar till. Se vägledningen och förklaringen i AI i Azure landningszoner.

Hur hanterar vi "dev/test/production"-arbetsbelastningslandningszoner i Azure landningszonsarkitektur?

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

Varför uppmanas vi att ange Azure regioner under referensarkitekturdistributionen för Azure landningszon och vad används de till?

När du distribuerar Azure landningszonsarkitektur med hjälp av Azure portalbaserad upplevelse för referensarkitektur för landningszoner 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 Distribution används också för att välja vilken Azure region alla regionspecifika resurser ska lagras, till exempel en Log Analytics arbetsyta 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 Azure landningszonsarkitektur?

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 tilldela den 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.

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

• Du har ett Enterprise-avtal (EA) och planerar att skapa fler än 5 000 prenumerationer på ett enda EA-kontos ägarkonto (faktureringskonto), inklusive borttagna prenumerationer.
• Du har en zmluva spoločnosti Microsoft so zákazníkom (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 kontantkortskund.
• Du använder ett Microsoft Azure-bidrag.
• 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 (Privileged Identity Management) rolltilldelningar, på prenumerationsnivå.
• 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 för molnet planer till kostnadsfria nivåer såvida 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, lagringskonton eller andra mål som stöds, såvida inte organisationens krav kräver att loggarna vidarebefordras medan en prenumeration är aktiv.
• Ta bort alla Azure Lighthouse delegeringar i prenumerationsomfånget.
• Ta bort dolda resurser från prenumerationen.

Återskapa prenumerationen

Du kan tilldela om prenumerationen efter att 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 rolltilldelningar för Privileged Identity Management (PIM) på prenumerationsnivå för de nya ägarna. Vanligtvis skulle dessa tilldelningar göras till Microsoft Entra-grupperna i stället än 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 för molnet planer till önskade nivåer. Du bör framtvinga 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 framtvinga den här inställningen via Azure Policy när den har placerats i rätt hanteringsgrupp.

Vad är en nationell landningszon och hur är den relaterad till arkitekturen för Azure landningszon?

Den nationella landningszonen är en komponent i Microsoft Nationella molnet som är avsedd för kunder inom den offentliga sektorn som behöver avancerade suveränitetskontroller. Som en skräddarsydd version av referensarkitekturen för Azure landningszon anpassar den suveräna landningszonen Azure-funktioner såsom tjänstebehörighet, kundhanterade nycklar, Azure Private Link och konfidentiell beräkning. Genom den här justeringen skapar den nationella landningszonen en molnarkitektur där data och arbetsbelastningar erbjuder kryptering och skydd mot hot som standard.

Mer information om den nationella landningszonen finns i Sovereign Landing Zone (SLZ).