AWS og Google Cloud har brukt de siste ni månedene på å bygge ned noe skyindustrien lenge trodde var permanent: muren mellom to konkurrerende hyperskala-plattformer. Det som startet som en forhåndsvisning under AWS re:Invent 30. november 2025 er nå en produksjonsklar tjeneste, og 29. juli 2026 kom det tredje beviset på at dette ikke var en engangsstunt: Oracle Cloud Infrastructure ble koblet inn i samme nettverk. Microsoft Azure står for tur senere i 2026, ifølge AWS’ egne kunngjøringer.

For norske og nordiske IT-avdelinger, som i årevis har balansert AWS, Azure og Google Cloud parallelt for å unngå leverandørbinding, er dette mer enn en teknisk fotnote. Det er et signal om at multisky er i ferd med å gå fra dyrt kompromiss til støttet arkitektur.

Hva AWS og Google Cloud faktisk har lansert

Kjernen i samarbeidet er to produkter som er bygget til å snakke sammen: AWS Interconnect – multicloud på Amazons side, og Cross-Cloud Interconnect (i praksis levert som Partner Cross-Cloud Interconnect for AWS) på Googles side. Sammen utgjør de det AWS selv kaller en «jointly engineered multicloud networking solution», ifølge selskapets egen blogg fra desember 2025 (AWS Networking Blog).

Teknisk sett gir løsningen private lag 3-forbindelser mellom AWS’ VPC-er (virtuelle nettverk) og tilsvarende nettverk i Google Cloud. Trafikken går ikke over det åpne internett. I stedet rutes den gjennom sertifiserte partnerrutere og de to selskapenes egne ryggradsnett, ifølge dokumentasjon fra Google Cloud (Google Cloud-dokumentasjon). Det betyr i praksis at en bedrift som kjører en database på AWS og en analyseklynge på Google Cloud, kan koble dem sammen som om de satt i samme datasenter, uten å bygge egen fysisk kryssforbindelse.

Løsningen ble først sluppet i forhåndsvisning 30. november 2025, med støtte for fem regionpar: Nord-Virginia, Nord-California, Oregon, London og Frankfurt, ifølge AWS’ offisielle produktside (AWS What’s New). London og Frankfurt er foreløpig de eneste europeiske knutepunktene, noe som betyr at norske selskaper i praksis kobler seg til via Frankfurt-regionen, ikke en lokal node.

Full produksjonsstatus (GA) kom 14. april 2026 på AWS-siden og 16. april 2026 på Google-siden, ifølge både AWS’ egen kunngjøring og gjennomgangen hos InfoQ. Det tok altså rundt fire og en halv måned å gå fra forhåndsvisning til produksjonsklar tjeneste, en relativt rask modningstid for infrastrukturprodukter av denne typen.

Oracle kobles på: hvorfor 29. juli 2026 er dagen som endret bildet

Det som gjør denne saken til noe mer enn en teknisk produktoppdatering, er utvidelsen til Oracle Cloud Infrastructure. 29. juli 2026 kunngjorde AWS at multisky-tilkoblingen med OCI var generelt tilgjengelig, ifølge selskapets egen produktmelding (AWS What’s New, juli 2026). Kunder får «den samme konsistente, enkle opplevelsen» til å koble arbeidslaster mellom OCI og Google Cloud, skriver AWS i meldingen.

Det betyr at tre av de fire store skyleverandørene nå deler et felles, nativt tilkoblingslag, mindre enn tre uker før denne artikkelen ble skrevet. Bare Azure mangler, og selskapet er allerede navngitt som launch-partner «senere i 2026» i AWS’ egne kunngjøringer helt tilbake til forhåndsvisningen i november 2025. Det gjenstår å se om Azure faktisk lander innen nyttår, men mønsteret så langt, tre kunngjøringer på under åtte måneder, tyder på at tempoet er reelt og ikke bare en varslet plan som blir skjøvet på ubestemt tid.

Bransjeanalysen hos CloudMagazin beskriver utviklingen som «den første multisky-veien som er nativt bygget av to hyperskala-leverandører og klar for produksjon, uten en tredjepartsleverandør som Megaport eller Equinix i kjeden», ifølge deres gjennomgang fra april 2026 (CloudMagazin). Det er et viktig poeng: tidligere har bedrifter som ville koble AWS og Google Cloud sammen, måttet leie kapasitet gjennom en nettverksmegler eller bygge egen samlokalisering. Nå tilbyr leverandørene selv veien mellom seg.

Historisk kontekst: fra skyttergraver til brobygging

For å forstå hvor uvanlig dette er, må man se på hvordan de tre store har opptrådt de siste ti årene. AWS, Azure og Google Cloud har historisk konkurrert på nesten alle fronter, fra pris til API-design til datasenterregioner, og har sjelden bygd teknisk infrastruktur sammen. Multisky har frem til nå vært noe kundene har måttet løse selv, gjerne med tredjeparts nettverksleverandører eller egne VPN-tunneler mellom skyene.

Det er også verdt å minne om at «multisky» lenge har vært mer en nødløsning enn en bevisst strategi for mange organisasjoner. En Nordics-rapport fra januar 2026 pekte på at nordiske selskaper beveger seg forbi ren migrasjon og mot suverene skymodeller som garanterer jurisdiksjonell kontroll, et tema vi også har berørt i saken om FinOps og AI-kostnadsstyring i 2026. Samtidig har fragmentering mellom skyer historisk vært en kostnadsdriver, ikke en besparelse, fordi hver overgang mellom plattformer har krevd egen nettverksarkitektur, egne sikkerhetsregler og egne overvåkingsverktøy.

Det AWS og Google Cloud nå gjør, er å erkjenne at kundene uansett kjører på flere skyer, og at det er bedre å eie den koblingen selv enn å overlate den til en tredjepart. Det er også en indirekte innrømmelse av at ren leverandørbinding, «lock-in», ikke lenger er den vinnende strategien den en gang var, i alle fall ikke for nettverkslaget.

Teknisk arkitektur: hva ligger under panseret

På AWS-siden bygger løsningen videre på eksisterende byggeklosser: AWS Direct Connect og Transit Gateway. På Google-siden brukes VPC Network Peering og Network Connectivity Center. Koblingen mellom de to skjer via sertifiserte partnerrutere, ikke en direkte fysisk kabel mellom Amazons og Googles datasentre, ifølge CloudMagazins tekniske gjennomgang.

AWS har i tillegg publisert en åpen spesifikasjon for nettverksinteroperabilitet i et offentlig GitHub-repositorium, ifølge selskapets egen tekniske blogg (AWS Networking Blog, desember 2025). Dette er trolig det mest strategisk interessante grepet: ved å åpne spesifikasjonen kan andre skyleverandører og nettverksutstyrsleverandører bygge kompatible løsninger, uten å måtte forhandle bilaterale avtaler med hver enkelt hyperskala-aktør.

Løsningen er lagt opp som en administrert, on-demand-tjeneste. Google har selv beskrevet målet som å gjøre det mulig for felles AWS- og Google Cloud-kunder å «bygge on-demand-forbindelser mellom Google Cloud og AWS VPC-er på minutter», ifølge omtalen hos Network World, som beskriver dette som en overgang fra «en kompleks byggejobb til en enkel, administrert tjeneste».

Det finnes foreløpig ingen offentlig, konkret prisliste for kryssforbindelsen i noen av de offisielle kildene vi har gjennomgått. Verken AWS’ produktsider eller Googles dokumentasjon oppgir pris per gigabyte eller port i kroner eller dollar. Selskapene omtaler tjenesten som «administrert» og «on-demand», men uten tallfestede satser i den offentlig tilgjengelige dokumentasjonen per skrivende stund.

Nordisk relevans: hvorfor Frankfurt betyr noe for Norge

Ingen av de offisielle kildene nevner spesifikke nordiske regioner eller kunder i sammenheng med lanseringen. De eneste europeiske knutepunktene som er bekreftet i regionlisten, er London og Frankfurt. For norske virksomheter som allerede kjører arbeidslaster i AWS’ Stockholm-region (åpnet i 2018) eller Azures Norge-regioner (åpnet i 2019), betyr det at multisky-trafikk mot Google Cloud må gå via Frankfurt, med den ekstra nettverksforsinkelsen det medfører sammenlignet med en lokal node.

Det er likevel verdt å understreke at Norden allerede er et marked der drift på flere skyer er normen snarere enn unntaket. AWS har hatt en Stockholm-region siden 2018, mens Google Cloud har hatt tilstedeværelse i Finland i årevis, ifølge tidligere dekning fra Cloud Computing News. Bank-, telekom- og offentlig sektor i regionen har lenge vært forsiktige med å samle alt hos én leverandør, delvis av beredskapshensyn og delvis av konkurransehensyn overfor egne kunder. En nordisk rapport fra januar 2026 pekte på at selskaper i regionen beveger seg mot suverene skymodeller med krav til jurisdiksjonell kontroll og krypteringsrammeverk, noe som gjør et standardisert, sikkert tilkoblingslag mellom skyer enda mer relevant.

Vi har tidligere skrevet om hvordan norske og finske selskaper flytter arbeidslaster mellom skyer og lokal drift av kostnadshensyn. Det samme mønsteret, ønsket om fleksibilitet fremfor binding til én plattform, er drivkraften bak at et produkt som AWS Interconnect – multicloud faktisk finner et marked i Norden.

Konkurransedynamikk: hvorfor erkerivaler samarbeider nå

Det kan virke selvmotsigende at AWS, som lenge har bygget produkter for å holde kunder innenfor eget økosystem, nå aktivt bygger bro til Google Cloud. Forklaringen ligger trolig i hvor markedet faktisk beveger seg. Kunder kjører allerede på flere skyer, enten det er bevisst strategi eller resultat av oppkjøp, fusjoner og desentraliserte innkjøpsbeslutninger i store organisasjoner. Spørsmålet for hyperskala-leverandørene er ikke lenger «hvordan hindrer vi multisky», men «hvem eier koblingen mellom skyene».

Ved å bygge og eie tilkoblingslaget selv, i stedet for å la Megaport, Equinix eller andre nettverksmeglere ta den rollen, beholder AWS og Google Cloud kontroll over kundeopplevelsen og fakturerer trafikken selv. Det er en strategi som minner om hvordan telekomselskaper historisk har konkurrert om å eie «siste mil»-forbindelsen til sluttkunden, bare flyttet opp på infrastrukturnivå mellom datasentre.

Samtidig er det ingen fasit for om dette svekker eller styrker leverandørbindingen på sikt. Et standardisert, lavfriksjons tilkoblingslag mellom AWS og Google Cloud gjør det enklere å flytte deler av en arbeidslast ut av én sky uten å miste ytelse, noe som i teorien svekker bindingen. Men det gjør det også enklere å bli værende på begge skyer samtidig i stedet for å konsolidere til én leverandør, noe som i praksis kan øke det totale forbruket hos begge parter. Det er trolig derfor både AWS og Google Cloud finner samarbeidet kommersielt fornuftig, selv om de fortsatt er direkte konkurrenter på nesten alt annet.

Sammenligning: multisky-tilkobling versus tradisjonelle alternativer

LøsningEier av forbindelsenKrever samlokaliseringStatus per august 2026Europeiske knutepunkt
AWS Interconnect – multicloud (til Google Cloud)AWS og Google Cloud i fellesskapNeiGenerelt tilgjengelig siden 14.–16. april 2026London, Frankfurt
AWS Interconnect – multicloud (til OCI)AWS og Oracle i fellesskapNeiGenerelt tilgjengelig siden 29. juli 2026Ikke spesifisert i kunngjøring
Partner Cross-Cloud Interconnect for AWS (Google-siden)Google Cloud og sertifisert partnerruterNei, via partnerruterGenerelt tilgjengelig siden 16. april 2026London, Frankfurt
Tredjeparts nettverksmegler (f.eks. Megaport, Equinix)Uavhengig tredjepartOfte, avhengig av leverandørEtablert løsning i flere årBredt europeisk nærvær
Egenbygget VPN-tunnel mellom skyerKunden selvNeiEtablert, men manuell driftAlle regioner, men lavere ytelse
AWS–Azure multisky-tilkoblingIkke fastsattUkjentVarslet, ingen dato bekreftet per august 2026Ukjent

Tidslinje: fra forhåndsvisning til tre leverandører på under ni måneder

DatoHendelseKilde
30. november 2025AWS kunngjør forhåndsvisning av AWS Interconnect – multicloud, med Google Cloud som første lanseringspartnerAWS What’s New
1. desember 2025AWS og Google Cloud lanserer felles forhåndsvisning av tilkoblingstjenesten offentligCIO Dive, Network World
8. desember 2025AWS publiserer teknisk detaljbeskrivelse og åpen spesifikasjon på GitHubAWS Networking Blog
14. april 2026AWS Interconnect (inkludert multicloud-funksjonen) når generell tilgjengelighetAWS What’s New
16. april 2026Partner Cross-Cloud Interconnect for AWS når generell tilgjengelighet på Google-sidenCloudMagazin
29. juli 2026Oracle Cloud Infrastructure kobles på med generell tilgjengelighetAWS What’s New
Senere i 2026Microsoft Azure ventet som neste lanseringspartner (ingen bekreftet dato)AWS What’s New, gjentatt i flere kunngjøringer

Hva dette betyr for norske og nordiske IT-avdelinger

For virksomheter som allerede har spredt arbeidslaster mellom AWS og Google Cloud, kan et natively integrert tilkoblingslag i teorien redusere behovet for å administrere egne VPN-tunneler eller betale for tredjeparts kryssforbindelser. Det kan også forenkle etterlevelseskrav, siden trafikken ikke forlater de to leverandørenes private nett.

Samtidig er det grunn til å være nøktern. Løsningen dekker foreløpig bare to europeiske knutepunkter, og ingen av dem ligger i Norden. Norske selskaper som vurderer å bruke tjenesten, bør regne inn ekstra nettverksforsinkelse fra Frankfurt-ruten, spesielt for latenskritiske arbeidslaster som sanntidsanalyse eller transaksjonsbehandling. Vi har tidligere dekket hvordan sikkerhetshull i administrerte Kubernetes-tjenester kan spre seg raskt nettopp fordi infrastruktur på tvers av skyer i økende grad kobles tettere sammen. Et felles tilkoblingslag mellom AWS og Google Cloud øker den potensielle angrepsflaten dersom identitets- og tilgangsstyringen ikke følger med, noe sikkerhetsteam bør ta med i risikovurderingen før de tar i bruk tjenesten.

For team som allerede sliter med kostnadskontroll på tvers av skyer, kan et standardisert nettverkslag også gjøre det enklere å spore og fakturere trafikk riktig, et poeng som henger sammen med funnene i vår tidligere sak om at 29 prosent av skyforbruket i praksis kastes bort på grunn av dårlig synlighet i infrastrukturen.

Markedspåvirkning: hva skjer med tredjepartsleverandørene

Den mest umiddelbare markedseffekten rammer trolig nettverksmeglere som Megaport og Equinix, som historisk har tjent på å være broen mellom skyleverandører. CloudMagazins vurdering er direkte: dette er «den første multisky-veien som er nativt bygget av to hyperskala-leverandører» uten en slik mellommann i kjeden. Det betyr ikke at meglerne forsvinner over natten. Mange kunder vil fortsatt trenge fleksibilitet til å koble til mindre skyleverandører, lokale datasentre eller spesialiserte tjenester som ikke er del av AWS–Google-Oracle-alliansen. Men for den spesifikke brukssaken «koble AWS til Google Cloud», er det native alternativet nå tilgjengelig direkte fra leverandørene selv, noe som legger prispress på mellomleddene.

Det er også en effekt for Microsoft. Så lenge Azure står utenfor, er AWS–Google Cloud–OCI-alliansen en konkurransefordel for de tre som er med. Det gir kunder som ønsker en Azure-fri multisky-strategi et sterkere argument for å velge kombinasjonen AWS, Google Cloud og Oracle fremfor å inkludere Azure, i alle fall frem til Microsoft faktisk kobler seg på. Hvor stor denne effekten blir i praksis, avhenger av hvor raskt Azure-integrasjonen kommer, noe ingen av kildene vi har gjennomgått oppgir en konkret dato for.

Konkurransesituasjonen: AWS, Google Cloud, Azure og Oracle side om side

Det er verdt å minne om at dette skjer i en periode der de tre store fortsatt konkurrerer hardt på nesten alle andre fronter, fra AI-infrastruktur til priser på kjernetjenester. Vi har tidligere sett på hvordan de store skyleverandørene håndterer Kubernetes-styring ulikt, og det samme mønsteret av parallell konkurranse og selektivt samarbeid gjenspeiles nå på nettverkssiden. AWS beholder sin dominans innen infrastruktur-som-tjeneste generelt, Google Cloud satser tungt på AI- og dataanalyseverktøy som lokkemiddel for multisky-kunder, og Oracle bruker sin database- og bedriftsprogramvare-arv til å posisjonere OCI som et tredje alternativ for virksomheter som allerede er Oracle-kunder.

Azures fravær fra alliansen er trolig ikke tilfeldig. Microsoft har sin egen etablerte tilnærming til hybrid- og multisky-tilkobling gjennom Azure ExpressRoute, og det er mulig selskapet forhandler om vilkår som sikrer at Azure ikke bare blir en passiv fjerde partner, men får definere egne tekniske krav til hvordan integrasjonen skal se ut. Det ville forklare hvorfor «senere i 2026» har vært den offisielle formuleringen helt siden november 2025, uten at noen konkret dato er bekreftet.

Risikoen ved å stole på nye kryssforbindelser

Enhver ny, direkte forbindelse mellom to store skyplattformer utvider samtidig angrepsflaten. Når trafikk flyter friere mellom AWS og Google Cloud, øker viktigheten av at identitets- og tilgangsstyring er konsistent på begge sider. Dette er ikke en ny problemstilling for skyinfrastruktur generelt, men den blir mer presserende når koblingen mellom leverandører blir enklere å sette opp enn før. Team som setter opp multisky-tilkobling i produksjon, bør behandle det som en utvidelse av det interne nettverket, med samme krav til segmentering, logging og minste privilegium som de ville stilt til et eget datasenter.

Ingen av kildene vi har gjennomgått rapporterer konkrete sikkerhetshendelser knyttet til AWS Interconnect – multicloud eller Cross-Cloud Interconnect siden lanseringen i november 2025. Det er likevel for tidlig å konkludere med at tjenesten er fri for sårbarheter, siden den fortsatt er under ett år gammel i produksjon.

Fem spådommer for resten av 2026 og inn i 2027

  • Azure kobles på innen utgangen av 2026. Gitt at AWS gjentatte ganger har bekreftet Azure som neste partner siden november 2025, er det sannsynlig at en forhåndsvisning kommer i løpet av fjerde kvartal, selv om GA kan strekke seg inn i 2027 basert på tempoet man så mellom Google- og Oracle-lanseringene.
  • Flere europeiske knutepunkter legges til. Med bare London og Frankfurt dekket, er det rimelig å vente at AWS og Google Cloud utvider til flere regioner etter hvert som etterspørselen vokser, mulig med et nordisk knutepunkt dersom Stockholm- eller Norge-trafikken blir stor nok.
  • Nettverksmeglere som Megaport og Equinix flytter fokus. Med hyperskala-leverandørene som nå eier AWS–Google-Oracle-koblingen selv, vil tredjepartsaktørene trolig prioritere tilkoblinger til mindre skyer, lokale datasentre og spesialiserte AI-infrastrukturleverandører der de fortsatt har et fortrinn.
  • Prismodellen blir offentlig i løpet av 2026. Ingen av leverandørene har publisert konkrete satser ennå, men i takt med at flere kunder tar tjenesten i bruk i produksjon, er det sannsynlig at både AWS og Google Cloud må offentliggjøre standardiserte priser for å konkurrere med etablerte alternativer.
  • Sikkerhetsleverandører lanserer egne overvåkingsverktøy for multisky-trafikk. Etter hvert som flere virksomheter tar i bruk direkte tilkobling mellom skyer, vil etterspørselen etter verktøy som gir innsyn i denne trafikken trolig vokse, spesielt blant nordiske banker og offentlige etater med strenge etterlevelseskrav.

Slik kommer du i gang: en teknisk oversikt

For team som vurderer å teste AWS Interconnect – multicloud, er utgangspunktet at man fortsatt bruker kjente byggeklosser på hver side: Direct Connect og Transit Gateway på AWS, og VPC Network Peering eller Network Connectivity Center på Google Cloud. Selve kryssforbindelsen settes opp som en «transport»-ressurs mellom de to, ifølge SDxCentrals tekniske gjennomgang av lanseringen (SDxCentral).

# Eksempel: konseptuell struktur for en multisky-tilkobling
# (illustrativ, ikke offisiell AWS/Google-syntaks)

aws-interconnect create-multicloud-connection \
  --region eu-central-1 \
  --peer-provider google-cloud \
  --peer-region europe-west3 \
  --bandwidth 10Gbps

gcloud compute cross-cloud-interconnects create aws-link \
  --location europe-west3 \
  --partner aws \
  --peer-region eu-central-1

Merk at dette er en forenklet, illustrativ fremstilling av arbeidsflyten, ikke faktisk kommandolinjesyntaks. Team som skal sette opp reell drift, bør følge AWS’ og Googles offisielle dokumentasjon direkte, siden begge produktene har oppdatert seg flere ganger siden forhåndsvisningen i november 2025.

Hvorfor dette ikke er det samme som Kubernetes på tvers av skyer

Det er verdt å presisere hva denne kunngjøringen ikke er. Basert på de offisielle kildene vi har gjennomgått, er dette et nettverkstransport-produkt, ikke en løsning for identitetsføderasjon eller orkestrering av Kubernetes-klynger på tvers av skyer. AWS og Googles egne beskrivelser fokuserer på tilkobling, ruting og båndbredde, ikke på å samle kontrollplan for containere mellom plattformene. For virksomheter som allerede kjører containerorkestrering på tvers av skyer, betyr dette at multisky-tilkoblingen kan gjøre nettverkslaget enklere, men den løser ikke automatisk utfordringer knyttet til hvordan man styrer Kubernetes-klynger som spenner over flere leverandører. Det er fortsatt et separat problem som krever egne verktøy og egen arkitektur.

Vi har tidligere dekket hvordan sikkerhetsfeil i containerlaget, som svakhetene i containerd som rammet både EKS og GKE, kan spre seg raskt nettopp fordi infrastruktur på tvers av skyer allerede deler mange av de samme underliggende komponentene. Et tettere koblet nettverkslag mellom AWS og Google Cloud gjør det enda viktigere å holde styr på hvilke komponenter som faktisk deles mellom plattformene.

Ofte stilte spørsmål

Hva er AWS Interconnect – multicloud?

Det er en administrert tjeneste fra AWS som gir private, høyhastighets lag 3-forbindelser mellom AWS’ virtuelle nettverk (VPC-er) og andre skyleverandørers nettverk, med Google Cloud som første lanseringspartner.

Når ble tjenesten generelt tilgjengelig?

AWS-siden nådde generell tilgjengelighet 14. april 2026, mens Google Cloud-siden (Partner Cross-Cloud Interconnect for AWS) fulgte 16. april 2026.

Er Azure med i samarbeidet?

Ikke ennå. AWS har konsekvent omtalt Microsoft Azure som neste lanseringspartner «senere i 2026» i kunngjøringer helt tilbake til november 2025, men ingen konkret dato er bekreftet per slutten av august 2026.

Hvilke europeiske regioner støtter tjenesten?

Kun London og Frankfurt er bekreftet som europeiske knutepunkter i den offisielle regionlisten. Ingen nordisk region er nevnt i tilgjengelig dokumentasjon.

Koster tjenesten noe ekstra?

Verken AWS eller Google Cloud har publisert konkrete priser for multisky-kryssforbindelsen i offentlig tilgjengelig dokumentasjon per skrivende stund. Begge beskriver tjenesten som administrert og on-demand.

Erstatter dette behovet for nettverksmeglere som Megaport eller Equinix?

Ikke fullstendig. For den spesifikke koblingen mellom AWS, Google Cloud og nå Oracle, tilbyr leverandørene nå et nativt alternativ. Men for tilkobling til mindre skyer, lokale datasentre eller andre tjenester utenfor alliansen, er tredjepartsmeglere fortsatt relevante.

Hva har Oracle med dette å gjøre?

Oracle Cloud Infrastructure ble koblet inn i samme multisky-nettverk 29. juli 2026, slik at kunder kan koble arbeidslaster mellom OCI og Google Cloud gjennom samme type tilkobling som brukes mellom AWS og Google Cloud.

Bør norske virksomheter ta i bruk tjenesten nå?

Det avhenger av arbeidslasten. Virksomheter med latenskritiske systemer bør regne inn forsinkelsen fra å rute via Frankfurt. For batch-jobber, dataflytting og mindre tidssensitive arbeidslaster kan tjenesten redusere kompleksiteten sammenlignet med å bygge egne VPN-tunneler eller leie kapasitet fra en tredjepart.