Strategier for flere skyer med Azure

Multisky betyr å kjøre arbeidsbelastninger på tvers av mer enn én skyleverandør – for eksempel å bruke Azure for de fleste tjenestene, samtidig som AWS brukes til en bestemt maskinlæringsplattform eller Google Cloud til BigQuery-analyse. Organisasjoner tar i bruk multisky for å: unngå leverandørbinding, dra nytte av hver leverandørs tjenester i verdensklasse, oppfylle kontraktsmessige eller regulatoriske krav om å unngå avhengighet av én leverandør, eller fordi fusjoner og oppkjøp har samlet selskaper som standardiserte på ulike skyer. Multisky er normen i store virksomheter i dag.

Multisky medfører betydelige driftsmessige utfordringer: Kompetansespredning – teamene trenger ekspertise på flere skyplattformer. Uensartet styring – hver sky har ulike verktøy for IAM, policyer og samsvar. Sikkerhetskompleksitet – ulike trusselmodeller, ulike sikkerhetstjenester og ulike revisjonslogger. Kostnadsstyring – separate faktureringsportaler, ulike prisenheter og ingen samlet kostnadsoversikt på tvers av leverandører. Nettverkskompleksitet – trafikk mellom skyer medfører kostnader for utgående data og forsinkelse. Microsoft håndterer mange av disse utfordringene med Azure Arc og støtte for multisky i Defender for Cloud.

Den samme agenten for tilkoblede maskiner i Azure Arc som registrerer lokale servere, fungerer også på virtuelle maskiner som kjører i AWS EC2, Google Cloud Compute Engine eller en annen sky. Når disse virtuelle maskinene er registrert med Arc, vises de sammen med Azure-ressurser i ARM-portalen. De kan omfattes av Azure Policy, overvåkes med Azure Monitor ved hjelp av de samme KQL-spørringene, og vises med sikkerhetsanbefalinger fra Defender for Cloud for AWS- og GCP-virtuelle maskiner – uten at De trenger å forlate Azure-portalen eller lære AWS-spesifikke verktøy.

Microsoft Defender for Cloud støtter innebygde koblinger for AWS og Google Cloud Platform. Ved å koble til AWS-kontoen eller GCP-prosjektet kan Defender for Cloud vurdere sikkerhetsstillingen til EC2-instanser, S3-bøtter, RDS-databaser og GCP-ressurser ved hjelp av det samme Secure Score-rammeverket som brukes for Azure. Tjenesten knytter funn til standarder som CIS AWS Foundations Benchmark og oppdager feilkonfigureringer, for eksempel offentlig tilgjengelige S3-bøtter og IAM-roller med for vide tillatelser, sammen med Azure-anbefalinger i ett instrumentbord.

Azure Cost Management + Billing kan hente inn AWS-kostnader ved å koble AWS Cost and Usage Report (CUR) til en Azure Connector. Dermed vises AWS-forbruk sammen med Azure-forbruk i en samlet kostnadsanalyse, slik at De kan sammenligne og fordele kostnader på tvers av skyer. De kan opprette budsjetter og varsler som omfatter begge leverandørene, og bruke den samme strategien for tagging ved synliggjøring og intern kostnadsbelastning. Denne kostnadsoversikten på tvers av skyer er verdifull for FinOps-team som håndterer forbruk hos flere leverandører fra ett samlet grensesnitt.

Mange strategier for flere skyer bruker Kubernetes som abstraksjonslaget som kjører likt i alle skyer. AKS på Azure, EKS på AWS og GKE på GCP kjører alle standard Kubernetes. Azure Arc-aktivert Kubernetes kan administrere alle disse fra Azure og bruke GitOps-baserte distribusjoner og Azure Policy (OPA Gatekeeper) på en ensartet måte. Containeravbildninger som er lagret i Azure Container Registry, kan hentes fra Kubernetes-klynger i alle skyer, noe som gjør Azure ACR til et naturlig registersentral for containeravbildninger i flere skyer.

En Azure Landing Zone er et forhåndskonfigurert miljø som implementerer anbefalte fremgangsmåter for styring, identitet, sikkerhet og nettverk. Ved innføring av flere skyer utvides landing zone-konseptet til å definere standarder som gjelder på tvers av alle leverandører. Microsofts Cloud Adoption Framework (CAF) inneholder veiledning for flere skyer om hvordan De kan strukturere hierarkier for administrasjonsgrupper, navnekonvensjoner og taggestrategier som fungerer på samme måte enten ressursen ligger i Azure, AWS eller lokalt.

Å koble sammen arbeidsbelastninger i Azure og AWS (eller GCP) krever nettverk mellom skyer. Vanlige mønstre er: VPN-tunneler mellom Azure VPN Gateway og en AWS Virtual Private Gateway eller GCP VPN – enkelt, men med begrenset båndbredde og varierende forsinkelse. Tredjeparts-SD-WAN (for eksempel Megaport eller Equinix Fabric) – oppretter private forbindelser på tvers av skyer, på samme måte som ExpressRoute. Integrasjon på applikasjonslaget – tjenester kommuniserer over HTTPS via offentlige endepunkter (det enkleste alternativet, men internett brukes). Kostnader for utgående båndbredde i AWS og GCP gjør dataoverføring mellom skyer dyrt ved store datamengder.

Microsoft Entra ID kan fungere som identitetsleverandør (IdP) for tilgang til flere skyer. For AWS kan De konfigurere Entra ID as the SAML 2.0 IdP for AWS IAM Identity Center, slik at brukere får tilgang til AWS-konsollen med Entra ID-legitimasjon og MFA – uten separate AWS IAM-brukere. En tilsvarende føderering er mulig for GCP. Dette sentraliserer identitetsstyringen – brukere som begynner, bytter rolle eller slutter, administreres i Entra ID, og tilgangen videreføres automatisk til alle skyleverandører.

FinOps-praksis (Cloud Financial Operations) blir mer komplisert i flere skyer fordi hver leverandør har ulike prismodeller, rabattordninger og detaljnivåer for fakturering. Anbefalte fremgangsmåter er å standardisere tagging hos alle leverandører for kostnadsfordeling, bruke AWS-koblingen i Azure Cost Management + Billing for samlet oversikt, opprette et FinOps-team som forstår Reserved Instances (Azure), Savings Plans (AWS/Azure) og Committed Use Discounts (GCP), samt gjennomføre regelmessige kostnadsgjennomganger på tvers av leverandører der kostnadene for tilsvarende arbeidsbelastninger sammenlignes.

Flere skyer kan skape problemer hvis de ikke administreres nøye. Vanlige feilmønstre som bør unngås: Utilsiktet bruk av flere skyer – bruk av flere skyer uten en strategi fører til ukontrollert spredning og økte kostnader. Overbelastning av kompetanse – å kreve at alle utviklere skal være eksperter på alle skyer; utpek i stedet skyansvarlige for hver plattform. Uensartet sikkerhet – å bruke ulike sikkerhetsgrunnlinjer for hver sky; bruk Azure Arc og Defender for Cloud for å håndheve enhetlighet. Ignorering av kostnader for utgående data – dataoverføring mellom skyer faktureres etter leverandørenes satser for utgående data og kan overraske FinOps-team.

I denne leksjonen lærte De at Azure Arc utvider Azure-administrasjonen til virtuelle maskiner i AWS og GCP ved hjelp av den samme agenten for tilkoblede maskiner, at Microsoft Defender for Cloud multi-cloud connectors viser sikkerhetsfunn på tvers av leverandører i en samlet Secure Score, og at Microsoft Entra ID federation muliggjør enkel pålogging til AWS- og GCP-konsoller fra én bedriftsidentitet. Dermed er kurset Azure Hybrid and Multi-Cloud fullført – neste tema er Well-Architected Framework, som brukes til å evaluere og forbedre Azure-arkitekturer.