Ensituntuma SST-työkaluun


Heikki Ma | 17. huhtikuuta 2025

Päätin tutustua SST-nimiseen työkaluun, joka herätti kiinnostukseni erityisesti sen lupausten ja modernin lähestymistavan vuoksi. Koska toimin työkseni AWS-pilviarkkitehtinä ja käytän IaC-työkaluja päivittäin, päätin kokeilla tätä ratkaisua puhtaasti mielenkiinnosta – ei siis asiakasprojektin tarpeesta, vaan halusta ymmärtää, mitä SST oikeasti tarjoaa ja missä sen vahvuudet tai rajoitteet piilevät.

Mikä SST on – ja mitä uutta v3 tuo mukanaan?

SST on kehys, joka helpottaa full stack -sovellusten rakentamista omalle infrastruktuurille. Se tarjoaa abstraktoidun tavan määritellä koko sovelluksen rakenteen – mukaan lukien sovelluksen backend, frontend, tietokannat, cron-jobit ja ulkoiset integraatiot – yhdellä TypeScript-tiedostolla ( sst.config.ts ).
​Alkujaan SST hyödynsi AWS CDK:ta ja CloudFormationia infrastruktuurin luomiseen. V3-versiossa tiimi kuitenkin päätti siirtyä käyttämään Pulumia ja Terraformin providereita. Tämä muutos tehtiin, koska CDK:n ja CloudFormationin käytössä ilmeni merkittäviä haasteita. Esimerkiksi CloudFormationin läpinäkymättömyys vaikeutti logiikan ja tilanhallinnan ymmärtämistä ja mukauttamista. Lisäksi AWS CDK pyrkii hallitsemaan omaa tilaansa CloudFormationin ohella, mikä voi johtaa ristiriitoihin ja hallinnan monimutkaistumiseen.

Uusi Pulumi-pohjainen toteutus antaa SST:lle mahdollisuuden rakentaa infrastruktuuria suoraan ilman CloudFormation-kerrosta, ja samalla mahdollistaa Pulumin sekä Terraformin laajan ekosysteemin ja modulaarisuuden hyödyntämisen. Tämän koettiin parantavan kehittäjäkokemusta ja laajentavan työkalun käyttökelpoisuutta huomattavasti.

Havaintoja ja fiiliksiä työkalun kokeilun pohjalta

SST tekee infran luonnista yllättävän yksinkertaista. Työkalussa on paljon valmiita kokonaisuuksia perinteisen full stack -sovelluksen rakentamiseen. Esimerkiksi Next.JS -sovelluksen Lambdalla tai ECS-konteilla pystyi määrittelemään muutamalla rivillä koodia.

SST käyttää oletusasetuksia monessa kohtaa, mikä nopeuttaa kehitystä huomattavasti. Näitä oletuksia voi säätää transform-ominaisuuden kautta, jolloin säilytetään helppous, mutta saadaan tarvittava joustavuus.
SST tukee tällä hetkellä suoraan AWS:llä ja Cloudflarella toteutettuja sovelluksia, mutta koska taustalla toimii Pulumi, on käytettävissä yli 150 Terraform-pohjaista provideria. Näin ollen SST soveltuu myös monipalveluympäristöihin, joissa tarvitaan esimerkiksi Stripe-, Azure AD- tai Github-integraatioita.

Yksi SST:n vaikuttavimmista ominaisuuksista on Live Lambda Development. Tämä mahdollistaa Lambda-koodin ajamisen ja testaamisen paikallisesti, aivan kuin se toimisi AWS:n pilvessä. Kun sst dev on käynnissä, SST ohjaa Lambda-kutsut kehittäjän omalle koneelle, jolloin koodimuutokset näkyvät heti ilman uutta deployta. Kehityskokemus on huomattavasti ketterämpi verrattuna perinteiseen CDK:lla toteutettuun kehitykseen.

Toinen yllättävän helppo asia oli bastion-instanssin luonti suljetun VPC-verkon sisään. SST hoitaa tämän yhdellä komponentilla ilman tarvetta manuaalisille EC2-konfiguraatioille tai monimutkaisille security group -asetuksille. Tämä on erityisen arvokasta, jos tarvitset tilapäistä pääsyä esimerkiksi tietokantaan staging-ympäristössä tai haluat pääsyn sisäverkkoon ilman VPN:ää.

AWS-komponenttien kattavuus: hyvä, mutta ei täydellinen

SST tarjoaa valmiita komponentteja keskeisimmille AWS-palveluille, mutta aivan kaikkea ei löydy suoraan. Yritin esimerkiksi luoda Lambda-funktion, joka olisi liitetty Load Balancerin listeneriksi, mutta tätä ei ollut suoraan mahdollista tehdä. Load Balancer näyttäisi olevan saatavilla osana toisia komponentteja, kuten ECS:ää, mutta suoraa tukea sen käytölle Lambdan kanssa ei löytynyt. Tämä on hyvä esimerkki siitä, missä kohtaa SST:n korkea abstraktiotaso voi kääntyä rajoitteeksi. Jos tarvitset tarkempaa kontrollia tai erityisiä AWS-komponentteja, joudut helposti tilanteeseen, jossa SST voi olla enemmän este kuin apu.

SST voi olla loistava työkalu silloin, kun rakennetaan nopeasti full stack -sovellusta, jossa tarvitaan frontend, backend, autentikointi ja tietokanta. Työkalu toimii erinomaisesti prototyyppien ja MVP-projektien kanssa, sekä sisäisten työkalujen rakentamisessa. Monimutkaisissa, erityisesti verkon eristämiseen, VPC-suunnitteluun ja matalan tason infrastruktuuriratkaisuihin liittyvissä tarpeissa turvautuisin edelleen muihin IaC-työkaluihin kuten Terraformiin.

Yhteenveto

SST tarjoaa modernin ja tehokkaan tavan rakentaa sovelluksia infrastruktuurin päälle. Sen kehittäjäystävällisyys, valmiit komponentit ja live-kehitysympäristö tekevät siitä todella kiinnostavan vaihtoehdon. SST on erityisesti suunniteltu kehittäjille, jotka haluavat nopeuttaa full stack -sovellusten kehitystä ilman, että jokainen infra kerros tarvitsee erillistä konfigurointia.

Omassa työssäni SST ei välttämättä korvaa perinteisiä IaC-työkaluja monimutkaisissa projekteissa, mutta se on ehdottomasti kokeilemisen arvoinen ja todennäköisesti tulee vielä vastaan esimerkiksi nopeissa integraatio projekteissa tai proof-of-concept-vaiheissa.

Heikki Ma

Heikki Ma
Cloud Consultant, CloudOps Lead

Pilvi haltuun

Huolehdimme pilvestä kokonaisuutena, jotta asiakkaamme voivat keskittyä kasvuun, kehitykseen ja asiakkaisiinsa.

Varmistamme, että digitaaliset palvelut toimivat luotettavasti ja tukevat liiketoimintaa kaikissa tilanteissa.

Uusimmat kirjoitukset

6. lokakuuta 2026
Webscale Cloud Morning Pilviriskit hallintaan Tiistai 27.10.2026 klo 8.30 Pilven suurimmat riskit eivät aina näy päällepäin. Liian laajat käyttöoikeudet, yhden avainhenkilön varaan jäänyt osaaminen, puutteelliset varmistukset tai harjoittelematon palautuminen voivat tuntua pieniltä asioilta, kunnes jokin niistä häiritsee liiketoimintaa. Mitkä pilviympäristön riskit ovat aidosti merkittäviä liiketoiminnalle? Mistä organisaatio vastaa itse ja mistä pilvipalveluntarjoaja? Ja miten tunnistaa riippuvuudet ja haavoittuvuudet ennen kuin niistä syntyy ongelma? Webscale Cloud Morning -sarjan toisessa webinaarissa käymme läpi käytännönläheisesti: millaiset pilviympäristön riskit voivat vaikuttaa liiketoiminnan jatkuvuuteen missä vastuu pilvipalveluntarjoajan ja oman organisaation välillä kulkee miten tunnistaa teknologiaan, ihmisiin ja toimintamalleihin liittyviä kriittisiä riippuvuuksia miten varautua häiriöihin ja varmistaa, että palautuminen toimii myös käytännössä millä keinoilla pilven riskejä voidaan tunnistaa ja pitää hallinnassa 30 minuutin aamustartti Jos pilvipalvelut ovat liiketoiminnallenne kriittisiä, mutta riskien todellinen taso ei ole täysin kirkas, tämä puolituntinen kannattaa käyttää.
IT- ja digijohtaja
21. syyskuuta 2026
Tekoälyn kehitys, uudet regulaatiot ja muuttunut turvallisuusympäristö nostavat teknologiavalintojen merkitystä. Pilvi- ja infrastruktuuripäätöksissä on huomioitava tämän päivän tarpeiden lisäksi jatkuvuus, riippuvuudet ja tulevaisuuden liikkumavara.
Tekijä Teemu Peräkylä • 19. elokuuta 2026
AI-avusteinen ohjelmistokehitys nopeuttaa kehitystä, mutta tuo mukanaan uusia tietoturvariskejä. CNAPP auttaa tunnistamaan olennaiset riskit ja turvaamaan nopeasti muuttuvat pilviympäristöt.