Kosten AWS en VPC/RDS

[Tom]

Ik heb een kleine webapplicatie bij AWS draaien. Het is een REST API via Lambda en een statische frontend via CloudFront (S3). Verder maak ik gebruik van een PostgreSQL database (RDS).

Nu vereist die laatste dat je het in een VPC draait. Daarmee is de database afgeschermd van de buitenwereld. Ik heb dus twee subnets (een private en een public met een internet gateway) nodig waar ik 24/7 voor betaal. En de RDS is ook niet gratis.

Het werkt allemaal goed, alleen kost die VPC en database relatief veel geld elke maand (paar tientjes per maand). De applicatie wordt heel weinig gebruikt.

Zijn er nog manieren om de kosten te drukken? Alles uitschakelen (wat bij een VPC sowieso al niet kan) in de nacht is wat rigoureus. AWS heeft ook een eigen schaalbare database: Aurora, maar die lijkt ook de VPC eis te hebben. DynamoDB is qua prijs ideaal voor mijn gebruik (puur opslag betalen), maar helaas niet relationeel.

[The Eagle]

Nou is mijn AWS wat roestig, maar ik volg je even niet helemaal. Welke (cloud)provider je ook kiest, je zult een compute instance nodig hebben om je DBMS op te draaien. Alleen Aurora Serverless edition kun je zonder krijgen. En een willekeurige compute instance wil je idd in een wat beveiligde omgeving draaien en dus heb je twee netwerkjes nodig
je moet denk ik een paar dingen afwegen:
- welk DBMS kies ik (PostgreSQL, MySQL)
- welke instance capaciteit heb ik daadwerkelijk nodig?
- welke instance capaciteit kan ik goedkoop krijgen?

Aurora serverless betaal met ACU's, iedere ACU is iets van 2GB ram ofzo. Kan dynamisch schalen tussen limits, kan ook 0 zijn. Je kunt dus ook tijdelijk pauzeren, dan gebruik je niks, en als er een request komt gaat ie weer aan. Meer info: https://www.jeremydaly.co...the-bad-and-the-scalable/ en https://docs.aws.amazon.c...verless.how-it-works.html
Wellicht moet je dar een klein beetje voor coden, dat weet ik niet.
Lijkt mij in jouw geval de makkelijkste optie. ZOlang ie niks doet kost ie ook niks

WIl je toch bij je bestaande instances blijven, kies dan wellicht voor reserved instances, die zijn goedkoper omdat je vastlegt dat je sowieso een bepaalde capaciteit afneemt. Maar da's een kwestie van een rekensommetje.

Persoonlijk zou ik altijd voor serverless gaan; dat doet het gewoon zonder dat je er omkijken naar hebt. Schaalt ook als een dolle. Mocht het echt groot groeien kun je altijd nog kiezen voor een eigen instance.

[Blauwschaap]

Misschien kun je even een overzichtje uit je cost explorer delen? Want VPC's zelf betaal je in principe niet voor (het hebben van een VPC zelf is "gratis"). De vraag is dus waar je nu voor betaald. Is dat bijvoorbeeld outgoing data, NAT Gateway of is het iets anders?

[Tom]

De kosten zitten in de "NAT Gateway Hour", maar ik weet nu even niet goed of ik die wel nodig heb. Het is de eerste keer dat ik dit heb opgezet, dus sowieso een leertraject waarmee ik in aanraking kwam toen ik "even" een database wilde aanmaken.

Mijn private subnet verwijst naar die NAT Gateway.
Mijn public subnet verwijst naar een Internet Gateway.

Ik kwam hier wel een artikel tegen, al is die situatie iets anders (gaat wel om dezelfde kostenpost):
https://medium.com/@balin...-hours-a-day-17c9a5150f45

[Blauwschaap]

Tom schreef op woensdag 7 april 2021 @ 14:35:
De kosten zitten in de "NAT Gateway Hour", maar ik weet nu even niet goed of ik die wel nodig heb. Het is de eerste keer dat ik dit heb opgezet, dus sowieso een leertraject waarmee ik in aanraking kwam toen ik "even" een database wilde aanmaken.

Mijn private subnet verwijst naar die NAT Gateway.
Mijn public subnet verwijst naar een Internet Gateway.

Ik kwam hier wel een artikel tegen, al is die situatie iets anders (gaat wel om dezelfde kostenpost):
https://medium.com/@balin...-hours-a-day-17c9a5150f45

Die NAT Gateway is er dus voor om je resources in je private subnet toch toegang te geven tot het internet. Ik vermoed dat dit niet noodzakelijk is? Je Lambda kan gewoon bij je database neem ik aan en daar heb je geen NAT Gateway voor nodig. Ik zou dus even proberen die NAT Gateway uit te zetten en dan te testen of alles nog werkt.

[Barryvdh]

Misschien niet de meest nette oplossing, maar je kan je RDS instance ook public zetten, dan heb je volgens mij geen NAT gateway nodig.

[teunw]

Blauwschaap schreef op woensdag 7 april 2021 @ 14:46:
[...]

Die NAT Gateway is er dus voor om je resources in je private subnet toch toegang te geven tot het internet. Ik vermoed dat dit niet noodzakelijk is? Je Lambda kan gewoon bij je database neem ik aan en daar heb je geen NAT Gateway voor nodig. Ik zou dus even proberen die NAT Gateway uit te zetten en dan te testen of alles nog werkt.

Dat klopt inderdaad. Een NAT gateway zorgt ervoor dat je je resources toegang kan geven tot het internet zonder dat iets op het internet een connectie starten met je database, lijkt me ook wel zo veilig .

Voor de database zou je kunnen overwegen om EC2 met Postgres te gebruiken, dat is natuurlijk niet helemaal de bedoeling, maar een EC2 is een stuk goedkoper dan de goedkoopste RDS.

[Tom]

Inderdaad. De Lambda moet nu in een subnet draaien, anders kan die niet bij de database komen. Echter heb ik voor m'n Lambda wel internet nodig (ik spreek er ook een externe API mee aan). Daar zit 'm de bottleneck. Opsplitsen in twee Lambda-functies is een optie maar dat vereist behoorlijk wat aanpassingen in de code, en wordt ook afgeraden.

Ik las ook nog iets over een RDS Proxy. Dat ga ik nog even uitzoeken, maar lijkt op het eerste gezicht vooral gericht op availability te zijn.

[Blauwschaap]

teunw schreef op woensdag 7 april 2021 @ 16:37:
[...]


Dat klopt inderdaad. Een NAT gateway zorgt ervoor dat je je resources toegang kan geven tot het internet zonder dat iets op het internet een connectie starten met je database, lijkt me ook wel zo veilig .

Ik betwist de veiligheid ook niet, maar als je DB geen 24/7 toegang nodig heeft tot het internet heeft een NAT gateway toch ook geen nut? Eventueel misschien om software / OS te updaten maar dan kun je even tijdelijk een NAT GW aanmaken, hoeft niet 24/7 te draaien.

Tom schreef op woensdag 7 april 2021 @ 16:41:
Inderdaad. De Lambda moet nu in een subnet draaien, anders kan die niet bij de database komen. Echter heb ik voor m'n Lambda wel internet nodig (ik spreek er ook een externe API mee aan). Daar zit 'm de bottleneck. Opsplitsen in twee Lambda-functies is een optie maar dat vereist behoorlijk wat aanpassingen in de code, en wordt ook afgeraden.

Ik las ook nog iets over een RDS Proxy. Dat ga ik nog even uitzoeken, maar lijkt op het eerste gezicht vooral gericht op availability te zijn.

Welk probleem probeer je nu op te lossen? Je zegt dat de kosten vooral in de NAT Gateway hours zitten. Waarom zou de Lambda opsplitsen dan iets oplossen?

Als je Lambda een externe API moet aanspreken kun je die Lambda toch in een public subnet draaien en je database in een private subnet houden zonder NAT Gateway? Dan ben je die NAT Gateway hours kwijt waar je nu relatief veel voor betaalt.

[ Voor 45% gewijzigd door Blauwschaap op 07-04-2021 17:05 ]

[Tom]

Blauwschaap schreef op woensdag 7 april 2021 @ 17:03:
[...]

Ik betwist de veiligheid ook niet, maar als je DB geen 24/7 toegang nodig heeft tot het internet heeft een NAT gateway toch ook geen nut? Eventueel misschien om software / OS te updaten maar dan kun je even tijdelijk een NAT GW aanmaken, hoeft niet 24/7 te draaien.

[...]

Welk probleem probeer je nu op te lossen? Je zegt dat de kosten vooral in de NAT Gateway hours zitten. Waarom zou de Lambda opsplitsen dan iets oplossen?

Als je Lambda een externe API moet aanspreken kun je die Lambda toch in een public subnet draaien en je database in een private subnet houden zonder NAT Gateway? Dan ben je die NAT Gateway hours kwijt waar je nu relatief veel voor betaalt.

De database heeft geen internettoegang nodig. Maar de Lambda wél. Ik kan die Lambda in m'n VPC laten uitvoeren (zodat die bij de database kan), maar zonder NAT gateway kan m'n Lambda niet bij een externe API die ik gebruik, ondanks dat de route table verwijst naar m'n internet gateway. Net nog een keer geprobeerd en wat je schrijft klinkt logisch, maar ik krijg het niet werkend. Alle artikelen spreken ook over een NAT gateway als je dat wilt:
https://aws.amazon.com/pr...t-access-lambda-function/
https://stackoverflow.com...-function-with-vpc-access
https://stackoverflow.com...s-and-internet-connection
https://gist.github.com/r...0b7b4f515e68e46255ac042a7

Ik heb m'n database nu even in de public subnet gezet en m'n Lambda uit de VPC. Dat werkt, maar is wel een security risico. Wel kan ik via security groups alleen bepaalde IP's toestaan, dat vind ik voldoende beveiliging (beperk je het risico alleen tot AWS gebruikers in dezelfde region). Nadeel is dat die Lambda's natuurlijk een wisselend IP hebben. Dat vereist nogal wat geklooi als ze die lijst met IP's updaten:
https://aws.amazon.com/bl...-ranges-using-aws-lambda/

[Blauwschaap]

@Tom Je hebt gelijk, blijkbaar was mijn AWS kennis wat roestig. Punt is dat ik zelf nooit NAT Gateways gebruik omdat ik AWS in een corporate setting gebruik.

Hier staat wat meer documentatie over het configuren van toegang van je Lambda tot resources in een private subnet in een VPC:

https://docs.aws.amazon.c...dg/configuration-vpc.html

[Tom]

Precies, dat bedoelde ik in één van m'n eerdere posts met twee Lambda-functies. Ik blijf dan een Lambda in de VPC houden (met toegang tot RDS, zonder internet), maar verhuis het stuk code dat de externe API aanspreekt naar een losse Lambda buiten de VPC. Die wordt dan aangesproken via de eerste Lambda. Nadeel is wel cold boot times en je code moet erop aangepast worden, daar heb ik niet zo'n zin in.
Geldt dan ook voor S3 en SES geloof ik, dat zou het helemaal lastig maken om op te splitsen.

Dank voor de link en het meedenken. Ik laat het nu even zo en ga kijken of ik de boel wat verder dicht kan timmeren via de security groups, van m'n NAT gateway ben ik in ieder geval af
Wel bijzonder dat die zo prijzig is eigenlijk.

[ Voor 15% gewijzigd door Tom op 09-04-2021 19:27 ]

[dujeen]

De (hosted) NAT gateway is inderdaad erg duur, maar je kan ook vrij eenvoudig een goedkope NAT gateway plaatsen op een kleine EC2 server met spot: https://www.stephengrier....cost-of-aws-nat-gateways/

Dat doen wij in onze staging en development omgevingen. Productie heeft wel gewoon een NAT gateway.

[Ed Vertijsment]

Is er een reden dat je alles op aws wilt draaien? De beschrijving die je geeft klinkt als iets dat prima op een 10e/maand vps kan draaien?

[Tom]

Ed Vertijsment schreef op zondag 11 april 2021 @ 11:35:
Is er een reden dat je alles op aws wilt draaien? De beschrijving die je geeft klinkt als iets dat prima op een 10e/maand vps kan draaien?

Vooral kennis/ervaring op doen. En een VPS heeft altijd beheer nodig.

[Olaf van der Spek]

Tom schreef op zondag 11 april 2021 @ 12:15:
En een VPS heeft altijd beheer nodig.

Je wilde toch kennis / ervaring opdoen?

[Ed Vertijsment]

Tom schreef op zondag 11 april 2021 @ 12:15:
[...]

Vooral kennis/ervaring op doen. En een VPS heeft altijd beheer nodig.

Eerste is natuurlijk prima, gewoon om te leren. Een VPS hoeft in principe niet heel veel beheer werk te zijn, automatische updates en iets van ansible en je bent er wel.

[Tom]

Ik heb ook een Windows VPS draaien, dat is goed te doen. En ik heb een Linux VPS in beheer, maar daar draait Plesk op die veel uit handen neemt. Nu ben ik niet helemaal vreemd met Linux, maar native komt er toch weer iets meer bij kijken. Vandaar dat ik al een tijdje bezig ben om te experimenteren met (serverless) services. Los van die dingen die 24/7 moeten draaien (zoals die NAT gateway) is dat helemaal schaalbaar, ook in kosten.

[Ed Vertijsment]

Tom schreef op zondag 11 april 2021 @ 17:03:
Ik heb ook een Windows VPS draaien, dat is goed te doen. En ik heb een Linux VPS in beheer, maar daar draait Plesk op die veel uit handen neemt. Nu ben ik niet helemaal vreemd met Linux, maar native komt er toch weer iets meer bij kijken. Vandaar dat ik al een tijdje bezig ben om te experimenteren met (serverless) services. Los van die dingen die 24/7 moeten draaien (zoals die NAT gateway) is dat helemaal schaalbaar, ook in kosten.

Om te leren en voor de ervaring kan ik het alleen maar toejuichen. Probleem natuurlijk is wel dat je een semi vendor lock in creëert. In de praktijk zijn dit soort constructies door de hogere opstartkosten in de praktijk bijna altijd duurder uit bent.

Het schalen is natuurlijk mooi maar zelden nodig en indien nodig vaak duurder dan een simpele load balancer voor een paar vm’s.

[Tom]

Vendor lock in valt mee, dezelfde principes heb je ook bij Azure. Het heet daar anders en als je infra via code gaat bouwen zien de templates er anders uit.

Qua kosten vind ik het meevallen. Die VPC en RDS zijn prijzig voor wat het is, bij de rest betaal je voor compute, data en opslag (en het merendeel is een bedrag ver achter de komma per eenheid). Zonder bezoekers is dat nul, met een handjevol bezoekers is het nog geen paar euro per maand. En alles wat er eenmaal staat kost je niks aan beheer. Je hebt gelijk dat als je alles zelf wilt en kunt doen, dat je dan wellicht goedkoper uit bent.

[Hydra]

Barryvdh schreef op woensdag 7 april 2021 @ 16:20:
Misschien niet de meest nette oplossing, maar je kan je RDS instance ook public zetten, dan heb je volgens mij geen NAT gateway nodig.

Nogal een understatement.