Yhden pilven riippuvuus on strateginen riski puolustusjärjestelmille, joka on analyyttisesti samankaltainen kuin yhden toimittajan riippuvuus missä tahansa muussa kriittisessä kyvykkyysalueessa. Kun puolustusohjelman koko pilvi-infrastruktuuri käy yhdellä tarjoajalla, tämä tarjoaja voi käyttää vipuvoimaa hinnoittelun, palvelun lopettamisen tai sopimusmuutosten kautta ohjelman uusimisessa. Geopoliittiset kehitykset voivat vaikeuttaa tai poistaa pääsyn ulkomaisessa omistuksessa olevaan pilvi-infrastruktuuriin. Suuri pilvikatko — AWS us-east-1 -häiriöt ovat vaikuttaneet suuriin osiin kaupallisesta internetistä — voi heikentää tai poistaa puolustuksen operatiiviset kyvykkyydet, jotka riippuvat siitä infrastruktuurista.
Monipilvistrategia käsittelee tätä strategista riskiä jakamalla työkuormia useiden tarjoajien kesken, ylläpitämällä siirrettävyyttä arkkitehtuuritasolla ja välttämällä syvää kietoutumista omistusoikeudellisiin pilvipalveluihin, jotka tekisivät siirtymisestä kohtuuttoman kallista.
Yhden pilven riippuvuuden strateginen riski
Geopoliittinen riski on puolustuksen kannalta selkeimmin erottuva riski pilvipalveluntarjoajan riippuvuudessa. EU:n dataoikeussäädäntö (GDPR, kansalliset turvallisuuden poikkeukset, EUCS) luo jatkuvaa oikeudellista epävarmuutta yhdysvaltalaisessa omistuksessa olevan tarjoajan infrastruktuurissa puolustustietojen pitkäaikaisesta tallentamisesta. Puolustusohjelmille, joiden elinkaari on 10–20 vuotta, nykyinen pilvi-arkkitehtuuripäätös saattaa muuttua kestämättömäksi ohjelman käyttöiän aikana.
Toimintariski katkoksista on välittömämpi huoli. Suuret pilvipalveluntarjoajat kokevat merkittäviä katkoksia. Puolustusjärjestelmille, joilla on saatavuusvaatimuksia (logistiikanhallintajärjestelmä, jonka on tuettava aktiivista operaatiota; kybertilannetietoisuus-alusta, jonka on oltava toiminnassa uhkavasteessa), yhdestä pilvipalveluntarjoajasta riippuminen ilman varaa on operatiivisesti hyväksymätöntä.
Hinnoitteluvipuvoima on kaupallinen riski, jolla on strategisia vaikutuksia. Pilvipalveluntarjoajat voivat nostaa hintoja sopimuksen uusimisessa; syvästi kietoutuneilla arkkitehtuureilla on vaikea reagoida. DoD:n JEDI- ja JWCC-kilpailut heijastelivat tietoisuutta tästä riskistä — JWCC:n monimyyjärakenne oli nimenomaisesti tarkoitettu estämään yhden toimittajan lukkiutuminen DoD:n pilvi-työkuormille.
Monipilven käyttöönottomalleja
Aktiivi-aktiivi-jaetut työkuormat jakavat eri työkuormatyypit eri pilvipalveluntarjoajille kunkin tarjoajan vertailevan edun perusteella: puolustusohjelma saattaa ajaa luokiteltuja sovelluksia tarjoajalla, jolla on vahvimmat luokiteltujen pilven akkreditoinnit, analytiikka- ja ML-työkuormat tarjoajalla, jolla on paras ML-infrastruktuuri, ja yhteistyötyökalut kolmannella EU-suvereenilla tarjoajalla dataresidenssisyistä.
Ensisijainen-toissijainen katastrofipalautus ajaa tuotantotypökuormia ensisijaisella tarjoajalla lämpimällä valmiusympäristöllä toisella tarjoajalla. Toissijainen ympäristö pidetään riittävän valmiina ottamaan yli määritetyn RTO:n (Recovery Time Objective) sisällä, jos ensisijainen epäonnistuu. Tämä malli on operatiivisesti yksinkertaisempi kuin aktiivi-aktiivi, mutta vaatii säännöllistä failover-testausta.
Pilvi-agnostinen IaC: Terraform ja Crossplane
Terraform (HashiCorpilta, nyt BSL-lisensoitu tuote avoimen lähdekoodin haarukalla OpenTofussa) on vakio-IaC-työkalu pilvi-agnostiseen resurssien provisiointiin. Terraform-palveluntarjoajia on kaikille suurimmille pilvipalvelujen alustoille (AWS, Azure, GCP, OVHcloud ja kymmeniä muita), ja Terraform-konfiguraatiosyntaksi on pilvi-agnostinen — samaa Terraform-konfiguraatiorakennetta käytetään riippumatta siitä, mitä tarjoajaa provisioidaan.
Monipilviarkkitehtuureille Terraformin workspace- ja moduulijärjestelmä mahdollistaa saman sovelluksen infrastruktuurin instantioimisen eri tarjoajilla. Ohjelman infrastruktuulirepositorio vaihtaa tarjoajatoteutusten välillä muuttamalla moduulin lähdettä — sovellustason konfiguraatio ei muutu.
Crossplane on CNCF-hyväksytty projekti, joka tarjoaa Kubernetes-pohjaisen ohjaustason pilviresurssien provisiointiin. Crossplane-Composition-järjestelmä mahdollistaa pilviresurssien abstraktion: Composition määrittelee komposiittiresurssityypin (esim. "DefenceDatabase"), joka kartoitetaan tarjoajakohtaisiin resursseihin, sallien sovellustiimien pyytää DefenceDatabasea tietämättä, onko se tuettu AWS RDS:llä, Azure Database for PostgreSQL:llä vai on-premises PostgreSQL-instanssilla.
Datan siirrettävyys: avoimet formaatit ja S3-yhteensopiva tallennus
Pilvipalveluntarjoajan lukkiutuminen datatasolla — jossa data on tallennettu omistusoikeudellisiin formaatteihin tai palveluihin ilman vakiostandardien vientipalvelua — on vaikein lukkiutumismuoto paeta. Sen välttäminen vaatii eksplisiittistä datan siirrettävyyssuunnittelua:
S3-yhteensopiva objektitallennus on käytännöllinen vakio pilvi-agnostiselle datan tallennukselle. Amazon S3:n API:sta on tullut de facto -vakio objektitallennukselle, S3-yhteensopivilla API:lla Azure Blob Storagesta, GCP Cloud Storagesta, OVHcloud Object Storagesta ja on-premises-ratkaisuista kuten MinIO (air-gap-ympäristöissä laajalti käytetty). Sovellukset, jotka käyttävät S3-yhteensopivia API:ja, voivat siirtyä tarjoajien välillä muuttamalla päätepisteURL:in ja tunnistetiedot — sovelluksen koodi ei muutu.
Vakio SQL hallituissa PostgreSQL-yhteensopivissa tietokannoissa välttää omistusoikeudellisten tietokantapalveluiden lukkiutumisen. PostgreSQL-yhteensopivat hallitut palvelut ovat saatavilla kaikilla suurimmilla pilvipalvelujen alustoilla.
Vaatimustenmukaisuuden monimutkaisuus: luokittelun valvontatoimet useiden tarjoajien välillä
Merkittävin toiminnallinen haaste monipilven puolustusarkkitehtuureissa on luokittelun valvontatoimien ylläpitäminen johdonmukaisesti useiden tarjoajien välillä, joilla kullakin on erilaiset palvelukyvykkyydet, erilaiset vaatimustenmukaisuussertifioinnit ja erilaiset turvallisuusvalvonnan toteuttamistyökalut.
Käytännöllinen lähestymistapa on rakentaa tarjoaja-agnostinen vaatimustenmukaisuuskerros: joukko Terraform/Crossplane-moduuleja ja Kubernetes-pääsynhallintakäytäntöpolitiikoita, jotka toteuttavat vaaditut vaatimustenmukaisuusvalvontatoimet riippumatta siitä, mikä pilvipalveluntarjoaja provisioi taustalla olevat resurssit. Sovellustiimi provisioi infrastruktuurin tämän vaatimustenmukaisuuskerroksen kautta, ei suoraan tarjoajan API:a vastaan, varmistaen, että vaatimustenmukaisuusvalvontatoimia ei voida ohittaa.
Keskeinen oivallus: Monipilvistrategialla on toiminnallinen kustannus. Infrastruktuurin hallinta useiden tarjoajien välillä vaatii enemmän insinöörityötä, laajempaa osaamista ja enemmän työkalujen monimutkaisuutta kuin yhden tarjoajan ympäristön hallinta. Puolustusohjelmille tämä kustannus on perusteltua strategisen riskin vähentämisellä — mutta se on budjetoitava ja miehitettävä eksplisiittisesti. Monipilviarkkitehtuuri, jota ei ole riittävästi resursoitu, ajautuu tekniseen velkaan ja turvallisuusaukkoihin nopeammin kuin hyvin resursoitu yhden pilven arkkitehtuuri.