Januar 2022

Nach einem ruhi­gem Jah­res­wech­sel gab es auch im Januar nur wenige Neue­run­gen in der AWS-Cloud. Die­ser Blog­bei­trag stellt einen Aus­schnitt aus den Neue­run­gen und Ankün­di­gun­gen des Monats Januar dar, erhebt aber nicht den Anspruch auf Voll­stän­dig­keit. Das Haupt­au­gen­merk liegt hier­bei auf Ver­än­de­run­gen, bei denen wir von einem direk­ten Ein­fluss auf unsere Kun­den aus­ge­hen. In die­sem Bei­trag wer­den ins­be­son­dere Ände­run­gen und Ankün­di­gun­gen der Ser­vices AWS Guard­Duty, Ama­zon EFS und der neuen AWS Kon­sole vorgestellt.

UI/UX

Die Neue AWS Konsole

Die wohl auf­fäl­ligste Neue­rung des ver­gan­ge­nen Mona­tes ist die Neu­ge­stal­tung der AWS Konsole.

Für die meis­ten Nut­zer ist der Home-Bild­schirm der AWS Kon­sole der erste Anlauf­punkt, wenn man mit AWS arbei­tet. Bis­her wur­den hier die zuletzt ver­wen­de­ten Ser­vices sowie sta­ti­sche Links auf­ge­lis­tet, doch je nach Pro­fil des Anwen­ders waren dies keine nütz­li­chen Ver­lin­kun­gen. Um die Nut­zer­er­fah­rung zu ver­bes­sern und län­ge­res zusam­men­su­chen von Infor­ma­tio­nen in der AWS Kon­sole zu redu­zie­ren, hat AWS nun die Kon­sole umge­stal­tet und per­so­na­li­sier­bar gemacht.

Die neue Kon­sole besteht nun auf den all­ge­mein bekann­ten „Wid­gets“. Jeder Benut­zer kann sich selbst aus­su­chen, wel­che Wid­gets er in wel­cher Rei­hen­folge auf sei­nem Home­screen ange­zeigt bekom­men möchte, sodass Secu­rity Engi­neers schnel­ler einen Über­blick über poten­zi­elle Gefah­ren erhal­ten kön­nen und Deve­lo­per leich­ter zu den von ihnen genutz­ten Ser­vices navi­gie­ren können.

Zu Release ver­fügt die Kon­sole über acht Wid­gets, wovon 3 sta­ti­sche Links und 5 dyna­mi­sche Inhalte, wie bei­spiels­weise AWS Health, den Trus­ted Advi­sor oder die zuletzt genutz­ten Ser­vices, anzeigen.

Die neue Kon­sole steht allen Nut­zern der AWS Cloud in allen Regio­nen seit Januar 2022 kos­ten­los zur Verfügung.

Secu­rity

AWS Guard­Duty

AWS Guard­Duty ist ein Ser­vice, der es Usern erleich­tern soll, ver­steckte Sicher­heits­lü­cken aus­fin­dig zu machen und zu behe­ben. Der Ser­vice über­wacht neben dem AWS Account des Nut­zers selbst auch Workloads und gespei­cherte Daten im AWS S3-Speicher.

Im Januar ist nun eine wei­tere Funk­tion von AWS Guard­Duty hin­zu­ge­kom­men: Die Über­wa­chung von Ama­zon EC2-Instan­zen bezie­hungs­weise die Über­wa­chung der Cre­den­ti­als von EC2 Instan­zen und ob diese von einem ande­ren AWS Account benutzt werden.

Ama­zon EC2 Cre­den­ti­als sind tem­po­räre Zugangs­da­ten, die vom EC2 Meta­da­ten­ser­vice auto­ma­tisch bereit­ge­stellt wer­den, wenn eine IAM-Rolle an eine EC2-Instanz gekop­pelt ist. Sollte ein unbe­fug­ter Ein­dring­ling Zugriff zu die­sen Meta­da­ten­ser­vice erhal­ten, bei­spiels­weise mit­tels Remote Code Exe­cu­tion, so könnte die­ser die Cre­den­ti­als eben­falls aus­le­sen und nut­zen und so bei­spiels­weise Zugriff auf sen­si­ble Daten in Ama­zon S3, Dyna­moDB oder wei­tere Ser­vices erhalten.

Guard­Duty konnte bereits seit Release erken­nen, wenn sol­che Cre­den­ti­als von einer IP-Adresse außer­halb der IP-Ran­ges von AWS ver­wen­det wurde, doch nun erkennt Guard­Duty auch, wenn die Cre­den­ti­als inner­halb der AWS von einem ande­ren Account ver­wen­det wer­den und alar­miert den User. Der Alarm wird als „Medium“ gekenn­zeich­net, wenn die Cre­den­ti­als von einem wei­te­ren mit AWS Guard­Duty ver­bun­de­nem AWS Account ver­wen­det wer­den – andern­falls als hoch. Soll­ten Nut­zer einen Alarm erhal­ten, so emp­fiehlt es sich, die Instanz zu ter­mi­nie­ren oder, wenn dies nicht mög­lich sein sollte, zumin­dest die Appli­ka­tio­nen her­un­ter­zu­fah­ren. Da die Cre­den­ti­als nur zeit­lich limi­tiert gül­tig sind und so keine neuen mehr erstellt wer­den, ver­hin­dert dies, dass der Angrei­fer neue Cre­den­ti­als aus­le­sen kann, sobald die alten abge­lau­fen sind.

Die­ses neue Fea­ture von Guard­Duty ist in allen Regio­nen seit Januar für Nut­zer des Ser­vices kos­ten­los verfügbar.

AWS Cloud­Trail Lake

Im Januar gab AWS die all­ge­meine Ver­füg­bar­keit von AWS Cloud­Trail Lake bekannt. AWS Cloud­Trail Lake ist ein Secu­rity Data Lake mit wel­chem Akti­vi­täts­pro­to­kolle für Prü­fun­gen, Sicher­heits­un­ter­su­chun­gen und ope­ra­tive Feh­ler agg­re­giert, gespei­chert und abge­fragt wer­den kön­nen. Durch die Ver­bin­dung all die­ser genann­ten Eigen­schaf­ten, ver­ein­facht Cloud­Trail Lake die Ana­lyse von Akti­vi­täts­pro­to­kol­len und macht die Not­wen­dig­keit von sepa­ra­ten Daten­ver­ar­bei­tungs­pipe­lines überflüssig.

Cloud­Trail Lake stellt den Nut­zern vor­de­fi­nierte Bei­spiel­ab­fra­gen zu Ver­fü­gung, aller­dings kön­nen Nut­zer auch mit­tels SQL-arti­gem Syn­tax eigene Abfra­gen erstel­len. Die stan­dard­mä­ßige Auf­be­wah­rungs­frist von Logs, die in Cloud­Trail Lake gespei­chert wer­den, beträgt sie­ben Jahre.

Der Ser­vice kann inner­halb der Cloud­Trail Kon­sole akti­viert wer­den mit­tels SDK oder der AWS CLI und ist in Europa unter ande­rem in Frank­furt, Lon­don und Paris ver­füg­bar. Bei der Nut­zung von Cloud­Trail Lake fal­len Spei­cher­kos­ten von unge­fähr 2,5$/GB an. Abfra­gen auf die Daten wer­den mit 0,005$ pro gescann­tem GB abgerechnet.

Sto­rage

Ama­zon EFS

Das Ela­s­tic File Sys­tem von AWS erlaubt es, EC2-Instan­zen, Lambda-Funk­tio­nen und Con­tai­nern auf ein gemein­sa­mes fully-mana­ged File Sys­tem zuzugreifen.

Die Ände­rung im Januar bezieht sich auf die Erstel­lung von Repli­cas des File Sys­tems, um bei­spiels­weise Com­pli­ance Anfor­de­run­gen zu erfül­len. Die Repli­cas kön­nen in weni­gen Minu­ten von neuen oder bereits bestehen­den EFS File Sys­te­men erstellt wer­den und ent­we­der inner­halb einer AWS Region oder auf meh­re­ren AWS Regio­nen inner­halb einer Par­ti­tion erstellt wer­den. Der hier­bei ent­ste­hende Traf­fic wird über das Back­bone von AWS gelei­tet, sodass Ände­run­gen inner­halb kür­zes­ter Zeit über­tra­gen wer­den können.

Sollte nun der Fall ein­tre­ten, dass ein Fail­over auf ein Replica ein­ge­lei­tet wer­den muss, muss zunächst die Repli­zie­rung selbst been­det wer­den. Dies hat zur Folge, dass Replica nicht mehr als read-only mar­kiert ist und in den Reco­very Pro­zess als Backup inte­griert wer­den kann.

Die Repli­cas sind in Europa in Frank­furt, Irland, Lon­don, Paris und Stock­holm ver­füg­bar. Bei der Nut­zung des neuen Fea­tures fal­len sowohl Gebüh­ren für das Spei­chern des Repli­cas als auch des des Ori­gi­nals an, sowie gege­be­nen­falls Kos­ten für den Cross- oder Intra-Regio­na­len Trans­fer der Daten.

Februar 2022

Eine Viel­zahl der Neue­run­gen, die Ama­zon im Februar ver­öf­fent­licht hat, kon­zen­trie­ren sich auf die The­men Secu­rity, Net­wor­king und Sto­rage inner­halb der AWS. Die­ser Blog­bei­trag stellt einen Aus­schnitt aus den Neue­run­gen und Ankün­di­gun­gen des Monats Februar dar, erhebt aber nicht den Anspruch auf Voll­stän­dig­keit. Das Haupt­au­gen­merk liegt hier­bei auf Ver­än­de­run­gen, bei denen wir von einem direk­ten Ein­fluss auf unsere Kun­den aus­ge­hen. In die­sem Bei­trag wer­den ins­be­son­dere Ände­run­gen und Ankün­di­gun­gen der Ser­vices AWS Pri­v­ate­Link, Ama­zon EFS und AWS S3 vorgestellt.

Secu­rity

AWS SSO

Mit AWS Sin­gle Sign-On ver­wal­ten  Kun­den der AWS Cloud den Zugriff von Mit­ar­bei­tern auf AWS-Kon­ten und Anwen­dun­gen an einer zen­tra­len Stelle.

Im Februar hat AWS die Anfor­de­run­gen an den eige­nen Sicher­heits- und Daten­schutz­stan­dard mit SSO  wei­ter erhöht und die Ein­hal­tung zusätz­li­cher Sicher­heits­richt­li­nien, wie dem Pay­ment Card Indus­try Data Secu­rity Stan­dard (PCI DSS), erreicht. Diese Richt­li­nien sind für die Ein­hal­tung diver­ser Anfor­de­run­gen, wie bei­spiels­weise der der Inter­na­tio­nal Orga­niza­tion for Stan­dar­diza­tion, notwendig.

Durch das Hin­zu­fü­gen neuer Anfor­de­run­gen an den eige­nen Sicher­heits­stan­dard, eröff­net Ama­zon sei­nen Kun­den mehr Mög­lich­kei­ten, die Zugriff­ver­wal­tung für meh­rere Kon­ten und Anwen­der zu ver­ein­fa­chen, ohne hier­bei auf not­wen­dige Sicher­heits­maß­nah­men ver­zich­ten zu müssen.

AWS SSO wird in Europa unter ande­ren in den Regio­nen Frank­furt, Lon­don, Paris und Irland unter­stützt. Die Kom­mu­ni­ka­tion mit dem AWS-sei­ti­gem End­punkt erfolgt aus­schließ­lich über HTTPS.

AWS Code­Guru

Ama­zon Code­Guru Reviewer ist ein Tool für Ent­wick­ler, um Sicher­heits­lü­cken im Code zu ent­de­cken und die Qua­li­tät des geschrie­be­nen Codes zu ver­bes­sern. Bereits wäh­rend der ver­gan­ge­nen re:invent wurde der neue Secrets Detec­tor vor­ge­stellt, der, zusam­men mit dem AWS Secrets Mana­ger, hard­coded Secrets im Code auf­spürt und im Secrets Mana­ger abspei­chert. Im Februar wurde der Ser­vice um zwei wei­tere Fähig­kei­ten erweitert:

Zum einen wurde eine neue Detec­tor Library hin­zu­ge­fügt, wel­che detail­lierte Infor­ma­tio­nen über die Sicher­heits- und Code­qua­li­täts­de­tek­to­ren von Code­Guru Reviewer ent­hält. Jede Seite der Library ent­hält eine Beschrei­bung des jewei­li­gen Detek­tors, kon­forme und nicht-kon­forme Bei­spiel­codes, sowie zusätz­li­che Infor­ma­tio­nen, die der Risi­ko­mi­ni­mie­rung die­nen. AWS ver­spricht sich davon, dass die neue Res­source den Kun­den dabei hilft, ein tie­fer­ge­hen­des Ver­ständ­nis für die Fähig­kei­ten und Mög­lich­kei­ten von Code­Guru Reviewer zu erlangen.

Als zweite Neue­rung wurde ein neue Log-Injec­tion Detek­tor ange­kün­digt, der Java- und Python-Code auf poten­zi­ell unsi­chere Pro­to­kol­lie­rungs­an­wei­sun­gen, wie bei­spiels­weise die, die wäh­rend des Apa­che Log4j-Pro­blems im Dezem­ber des letz­ten Jah­res aus­ge­nutzt wer­den konn­ten, ana­ly­siert. Sollte der Reviewer eine sol­che Schwach­stelle erken­nen, so lie­fert er eine umsetz­bare Emp­feh­lung wäh­rend der Repo­si­tory Ana­lyse oder als Kom­men­tar wäh­rend eines Pull-Requests.

Die Erwei­te­run­gen zu Ama­zon Code­Guru sind in allen Regio­nen ver­füg­bar, in denen auch Code­Guru selbst ver­füg­bar ist. Die Detec­tor Library selbst ist als Teil der Doku­men­ta­tion kos­ten­frei einsehbar.

Sto­rage

Ama­zon EFS

Das Ela­s­tic File Sys­tem (EFS) von AWS erlaubt es, dass EC2-Instan­zen, Lambda-Funk­tio­nen und Con­tai­ner auf ein gemein­sa­mes, fully-mana­ged File Sys­tem zugrei­fen kön­nen, wel­ches das „read-after-write“ Kon­sis­tenz­mo­dell unter­stützt. Durch die fle­xi­ble Ska­lier­bar­keit und ein­fa­che Hand­ha­bung kommt AWS EFS in ver­schie­dens­ten Sze­na­rien zum Ein­satz, wie bei­spiels­weise der Ver­wal­tung von Inhal­ten, DevOps oder auch Machine Learning.

Bis vor kur­zem unter­stützte AWS EFS beim Lesen von Daten und Meta­da­ten ledig­lich eine Latenz von weni­gen Mil­li­se­kun­den, doch getreu dem Motto „schnel­ler ist immer bes­ser“, unter­stützt EFS seit Februar 2022 nun auch Sub-Mil­li­se­cond Read Latency.  Die meis­ten Lese­vor­gänge, die sowohl auf Daten als auch auf Meta­da­ten aus­ge­führt wer­den, sol­len nun nur noch eine Latenz von circa 600 Micro­se­kun­den aufweisen.

Die Ver­bes­se­rung betrifft alle bestehen­den und neuen One-Zone und Gene­ral Pur­pose EFS-Sys­teme und wurde von AWS bereits umge­setzt, sodass Nut­zer des Ser­vices die Ver­bes­se­rung viel­leicht schon bemerkt haben.

Ama­zon S3

Auch bei dem wahr­schein­lich größ­tem und popu­lärs­tem Spei­cher­ser­vice der AWS hat sich wie­der etwas geän­dert: AWS S3 unter­stützt nun die Repli­ka­tion von bereits bestehen­den Objek­ten mit­tels S3 Batch Repli­ca­tion sowie neue Checksum-Algorithmen.

Batch Repli­ca­tion

Ama­zon S3 Repli­ca­tion unter­stützt bereits jetzt diverse Anwen­dungs­fälle, wie bei­spiels­weise die Ver­wal­tung von Kopien von Daten über meh­rere AWS Regio­nen hin­weg, die Ein­hal­tung von Anfor­de­run­gen an die Daten­ho­heit oder ein­fach nur die Erstel­lung von zusätz­li­chen Sicher­hei­ten für den Fall eines Daten­ver­lus­tes inner­halb einer Region. Bis­her unter­stützte der Ser­vice aber nur die Repli­ka­tion von neu-hin­zu­ge­füg­ten Objek­ten . Dies ändert sich nun:

Es gibt eine Viel­zahl von Grün­den, wieso Kun­den bereits exis­tie­rende Objekte repli­zie­ren wol­len. Einer hier­von könnte die bereits oben ange­spro­chene zusätz­li­che Sicher­heit im Falle eines Desas­ters in einer Region sein. Um dies bis­her zu errei­chen, muss­ten Kun­den die bestehen­den Daten manu­ell in die neuen Buckets über­tra­gen. Durch diese manu­elle Repli­ka­tion sind aller­dings Meta­da­ten, wie bei­spiels­weise das Erstel­lungs­da­tum oder die Ver­si­ons­num­mer, ver­lo­ren gegangen.

Mit AWS S3 Batch Repli­ca­tion wird die manu­elle Repli­ka­tion von Daten nun obso­let und AWS-interne Meta­da­ten kön­nen wei­ter­ver­wen­det wer­den. Das neue Fea­ture unter­stützt eine belie­bige Anzahl von Objek­ten, die inner­halb eines Jobs repli­ziert wer­den können.

AWS S3 Batch Repli­ca­tion ist seit Februar in allen Regio­nen ver­füg­bar. Die Kos­ten für die Nut­zung des Fea­tures set­zen sich aus Gebüh­ren für den Daten­ver­kehr, die Bat­ch­ope­ra­tion selbst, die zusätz­lich ent­ste­hende Spei­cher­kos­ten sowie ggfls. Kos­ten für die Nut­zung von AWS KMS zusammen.

Checksum

Der Cloud­ob­jekt­da­ten­spei­cher AWS S3 ist so designt, dass er eine Dura­bi­lity von min­des­tens 99,999999999% für Objekte und Meta­da­ten unter­stützt, die in den Spei­cher gela­den wer­den. Dies hat zur Folge, dass man davon aus­ge­hen kann, dass jeder PUT-Befehl, der auf den Spei­cher aus­ge­führt wird, mit einem GET-Befehl vali­diert wer­den kann und somit jedes hoch­ge­la­dene Objekt auch wie­der heruntergeladen.

AWS nutzt bereits jetzt Checks­ums, um die Anzahl von Objek­ten inner­halb eines Spei­chers zu vali­die­ren. So kann die Put­Ob­ject-Funk­tion des S3-Ser­vices bereits jetzt mit MD5-Checks­ums kom­bi­niert wer­den, um so Feh­ler bei der Daten­über­tra­gung früh­zei­tig zu erken­nen und Ope­ra­tio­nen abzubrechen.

Seit Februar unter­stützt AWS nun wei­tere Checksum-Algo­rith­men, die die Über­prü­fung der Inte­gri­tät der Daten wei­ter ver­ein­fa­chen sol­len. Die Funk­ti­ons­weise der neuen Algo­rith­men basie­ren auf vier Aspek­ten: Dem Upload der Datei, der Unter­stüt­zung von Mul­ti­part-Uploads, dem Sum­men­test selbst, sowie der Rück­gabe des Werts.

Die neu­este Ver­sion der AWS SDK führt den Sum­men­test selbst­stän­dig wäh­rend es Uploads aus und fügt des­sen Resul­tat an einen Trai­ler am Ende des Uploads hinzu. Im nächs­ten Schritt wird die­ser Wert sei­tens des Ser­vices vali­diert und der Upload-Pro­zess been­det. Sollte der Upload als Mul­ti­part-Upload aus­ge­führt wer­den, so wird der Sum­men­test für jede ein­zelne Kom­po­nente aus­ge­führt und vali­diert und auch die Summe der ein­zel­nen Sum­men­tests wird noch ein­mal über­prüft. Die Werte der Tests wer­den zusam­men mit dem ver­wen­de­ten Algo­rith­mus in den Meta­da­ten des Objekts gespei­chert und bei der Nut­zung von ser­ver-sei­ti­ger Ver­schlüs­se­lung mit­tels AWS KMS sogar verschlüsselt.

Die neuen Checksum-Algo­rith­men sind in allen kom­mer­zi­el­len AWS Regio­nen seit Ende Februar 2022 kos­ten­frei verfügbar.

Net­wor­king

AWS Private Link

AWS Pri­v­ate­Link bie­tet Nut­zern die Mög­lich­keit, eine private Ver­bin­dung zwi­schen VPCs, AWS-Ser­vices und on-premises Netz­wer­ken auf­zu­bauen. Dadurch, dass der Ver­kehr nicht mehr über das öffent­li­che Inter­net gelenkt wird, sinkt die Anfäl­lig­keit für Brute-Force oder DDoS-Angriffe. Durch die private IP-Kon­nek­ti­vi­tät kön­nen Ser­vices so funk­tio­nie­ren, als wür­den sie in einem pri­va­ten Netz­werk lie­gen. Secu­rity Groups und End­point Poli­cies erlau­ben die  Zugriffs­steue­rung auf die dar­un­ter­lie­gen­den Services.

Durch die vie­len Sicher­heits­vor­teile, die AWS Pri­v­ate­Link bie­tet, ist es nicht ver­wun­der­lich, dass die Anzahl an Ser­vices, die von Pri­v­ate­Link unter­stützt wer­den, ste­tig steigt. Im Februar 2022 sind die Ser­vices Ama­zon Ela­s­ti­Cache, Ama­zon Memo­ryDB for Redis sowie Ele­men­tal Media­Connect hinzugekommen.

Zur Ver­wen­dung von Pri­v­ate­Link mit einem der oben genann­ten Ser­vices muss ledig­lich ein End­punkt unter Zuhil­fe­nahme der Kon­sole, AWS SDK oder der CLI erstellt wer­den. Die­ses Kon­strukt kann wahl­weise durch VPC Pee­ring oder VPN-Kon­nek­ti­vi­tät ergänzt wer­den, um von ande­ren VPCs aus auf den End­punkt zuzugreifen.

AWS APP Runner

AWS APP Run­ner erlaubt es, schnell und ein­fach Web­ap­pli­ka­tio­nen und APIs in der AWS zu deployen. Für die Nut­zung von APP Run­ner wird ledig­lich der Quell­code oder ein funk­tio­nie­ren­des Con­tai­ner-Image benö­tigt. APP Run­ner über­nimmt dann das Ver­wal­ten der Infrastruktur, des Net­wor­kings und des Load Balan­cings der Applikation.

Seit Februar kön­nen Appli­ka­tio­nen, die über APP Run­ner gehos­tet wer­den, auch mit Ser­vices kom­mu­ni­zie­ren, die inner­halb eines VPCs lie­gen. So kön­nen über APP Run­ner gehos­tet Appli­ka­tio­nen nun auf Ama­zon RDS, Redis oder Mem­cached Caches von Ela­s­ti­Cache, die im eige­nen AWS VPC lie­gen, kom­mu­ni­zie­ren oder auf Res­sour­cen zugrei­fen, die über EC2-Instan­zen zur Ver­fü­gung gestellt werden.

Um dies vor­her zu errei­chen, war es not­wen­dig, dass die jewei­li­gen Appli­ka­tio­nen und Daten­ban­ken frei zugäng­lich im öffent­li­chen Inter­net lie­gen. Mit der neuen Ände­rung kann sich APP Run­ner nun mit Private End­points eines VPCs ver­bin­den und ermög­licht so, eine siche­rere Kom­mu­ni­ka­tion mit die­sen Ressourcen.

Zur Ver­bin­dung muss ein soge­nann­ter VPC Kon­nek­tor inner­halb APP Run­ners erstellt wer­den. Inner­halb die­ses Kon­nek­tors wird spe­zi­fi­ziert, wel­ches VPC, wel­ches Sub­net und wel­che Secu­rity Group genutzt wer­den soll für die Kom­mu­ni­ka­tion. Der aus APP Run­ner aus­ge­hende Traf­fic wird dann anhand der defi­nier­ten VPC Rou­ting Regeln geleitet.

VPC Kon­nek­to­ren sind seit Februar in allen AWS Regio­nen ver­füg­bar, in denen auch AWS APP Run­ner ver­füg­bar ist. Es fal­len für die Nut­zung keine zusätz­li­chen Kos­ten an, aller­dings kön­nen ggfls. Gebüh­ren für die Erstel­lung von NAT Gate­ways oder VPC End­punkte entstehen.

März 2022

AWS hat  nur wenige große Neue­run­gen im ver­gan­ge­nen März ver­öf­fent­licht. Die­ser Blog­bei­trag stellt einen Aus­schnitt aus den Neue­run­gen und Ankün­di­gun­gen des Monats März dar, erhebt aber nicht den Anspruch auf Voll­stän­dig­keit. Das Haupt­au­gen­merk liegt hier­bei auf Ver­än­de­run­gen, bei denen wir von einem direk­ten Ein­fluss auf unsere Kun­den aus­ge­hen. In die­sem Bei­trag wer­den ins­be­son­dere Ände­run­gen und Ankün­di­gun­gen der Ser­vices AWS RDS, Ama­zon Dyna­moDB und AWS Lambda vorgestellt.

Moni­to­ring und Security

AWS Health Dashboard

Im Laufe der Zeit hat Ama­zon immer mehr Tools ver­öf­fent­licht, um Ein­bli­cke in die Ver­füg­bar­keit von Ser­vices zu ver­ein­fa­chen. Bereits 2008 hat AWS bei­spiels­weise das Ser­vice Health Dash­board erst­ma­lig ver­öf­fent­licht. 2016 wurde dann eine per­so­na­li­sier­ba­rere Vari­ante des Ser­vice Health Dash­boards ver­öf­fent­licht: Das Per­so­nal Health Dash­board. Diese wurde in den ver­gan­ge­nen 6 Jah­ren Kon­stant ver­bes­sert. Ein Bei­spiel hier­für ist die Inte­grie­rung in Ama­zon Event­Bridge oder die Mög­lich­keit, auto­ma­tisch Benach­rich­ti­gun­gen zu erstel­len. All dies galt aller­dings nur für das PHD, nicht für das SHD, wel­ches über die Jahre wei­test­ge­hend unver­än­dert blieb.

Im März hat AWS nun ein Update für das SHD ver­öf­fent­licht, wel­ches die Nut­zer­freund­lich­keit erhöht und das PHD und das SHD zusam­men­führt. Diese Zusam­men­füh­rung ist das AWS Health Dash­board. Das AWS Health Dash­board soll ein zen­tra­les Inter­face dar­stel­len, in wel­chem gene­relle so wie per­so­na­li­sierte Ereig­nisse ange­zeigt werden.

Das neue AWS Health Dash­board ist bereits jetzt ver­füg­bar und erzeugt keine wei­te­ren Kos­ten. Die Zusam­men­füh­rung des SHD und PHD ist ein sinn­vol­ler Ver­bes­se­rung, die das Moni­to­ring von AWS Accounts und Orga­ni­sa­tio­nen ver­ein­facht. Im Laufe des Jah­res sol­len noch wei­tere Ver­bes­se­run­gen ver­öf­fent­lich wer­den, über die wir – selbst­ver­ständ­lich – in die­ser Blog­bei­trags­reihe berich­ten werden.

Cloud NGFW für AWS

Mit AWS Fire­wall Mana­ger kön­nen Kun­den die Sicher­heits­ein­stel­lung für meh­rere Appli­ka­tio­nen, die über meh­rere AWS Accounts hin­weg gehos­tet sein kön­nen, zen­tral ver­wal­ten. Um dies zu ermög­li­chen, unter­stützt Fire­wall Mana­ger meh­rere Arten von Fire­walls, wie AWS WAF, Shield Advan­ced oder AWS Net­work Firewall .

Nun ist im März zu die­ser Liste eine wei­tere Fire­wall hin­zu­ge­kom­men: Palo Alto Net­works Cloud NGFW. Die Cloud Next Gene­ra­tion Fire­wall kann nun auch mit­tels Fire­wall Mana­ger – über meh­rere VPCs und AWS Accounts hin­weg – ver­wal­tet und über­wacht werden.

Sowohl AWS Fire­wall Mana­ger als auch Cloud NGFW sind regio­nale Ser­vices. Cloud NGFW ist bis­her zwar nur in den Regio­nen in North Vir­gi­nia und North Cali­for­nia ver­füg­bar, aller­dings soll die Aus­wei­tung auf wei­tere AWS Regio­nen bald fol­gen, sodass auch zukünf­tig in Europa ansäs­sige Fir­men von den Sicher­heits­fea­tures von Cloud NGFW und dem ein­fa­chen Manage­ment durch AWS Fire­wall Mana­ger pro­fi­tie­ren können.

Sto­rage

AWS RDS

Multi-AZ Deploy­ments sind einer der effi­zi­en­tes­ten Wege, um die Hoch­ver­füg­bar­keit von Appli­ka­tio­nen und Ser­vices zu garan­tie­ren und für jedes Unter­neh­men, ins­be­son­dere bei busi­ness-cri­ti­cal Workloads, von essen­zi­el­ler Bedeu­tung. So ist es nicht ver­wun­der­lich, dass Ama­zon eine neue Art des Multi-AZ Deploy­ments für Ama­zon RDS ver­öf­fent­licht hat. Die neue Deploy­ment-Option ver­spricht Fail­overs in unter 35 Sekun­den, les­bare Standby-Instan­zen und eine hal­bierte Latenz bei der Repli­ka­tion von Com­mits. In Summe stellt der neue Deploy­ment-Typus also eine Mischung aus den bis­he­ri­gen Multi-AZ Deploy­ments und den bis­he­ri­gen Read-Repli­cas dar.

Es erge­ben sich aber durch­aus wei­tere Vor­teile für diese Art des Deploy­ments: Multi-AZ Instan­zen ver­wen­den Ama­zon EBS, um die Daten zu spei­chern. Die neuen Multi-AZ DB Instan­zen benut­zen den loka­len Spei­cher der Instanz, um das Tran­sac­tion-Log zu spei­chern und beschleu­ni­gen so das Schrei­ben von Daten, indem Ope­ra­tio­nen erst in das lokale Tran­sac­tion-Log über­nom­men wer­den und dann auf den per­ma­nen­ten Spei­cher der Daten­bank über­ge­ben wer­den. Wei­ter­hin sind die bei­den Read-Repli­cas als soge­nannte „Hot-Repli­cas“ zu ver­ste­hen, d.h. Appli­ka­tio­nen kön­nen diese Instan­zen aktiv nut­zen, um ihre Sel­ect-Befehle auf ihr aus­zu­füh­ren, wodurch eine bes­sere Las­ten­ver­tei­lung mög­lich ist.

Um bis­he­rige Instal­la­tio­nen auf den neuen Deploy­ment-Typ zu wech­seln, müs­sen Nut­zer einen Snapshot der aktu­el­len Daten­bank erstel­len. Aus die­sem Snapshot kann dann eine neue Daten­bank mit der gewünsch­ten Kon­fi­gu­ra­tion erstellt wer­den. In Europa sind die neuen Instan­zen aller­dings zunächst nur in Irland und in Kom­bi­na­tion mit MySQL und Post­greSQL ver­füg­bar. Wei­tere Regio­nen und Optio­nen sol­len aber hinzukommen.

AWS Dyna­moDB

Ama­zon hat auch für Dyna­moDB im ver­gan­ge­nen März zwei neue Updates vor­ge­stellt. Diese betref­fen zum einen eine Erhö­hung der Default-Quo­tas und zum ande­ren die SQL-kom­pa­ti­ble Query-Spra­che Par­tiQL, in wel­cher nun die Anzahl der ver­ar­bei­te­ten Ele­mente als Para­me­ter bei jeder Abfrage mit­ge­ge­ben wer­den kann.

Ama­zon Dyna­moDB hat das Stan­dard­kon­ti­gent an Tabel­len pro AWS Account und Region von 256 auf 2500 Tabel­len und die Anzahl an Ver­wal­tungs­vor­gän­gen von 50 auf 500 erhöht. Dies erlaubt es, grö­ßere CRUD-Ope­ra­tio­nen auf Tabel­len pro Konto pro Region durch­zu­füh­ren und eli­mi­niert die Not­wen­dig­keit, Dyna­moDB-Tabel­len ver­tei­len zu müssen.

Beide Ände­run­gen sind ab sofort in jeder Region, mit Aus­nahme von Gov­Cloud (USA), ver­füg­bar, in wel­cher auch Dyna­moDB ver­füg­bar ist.

Com­pute

AWS Lambda

Ein weit­ge­läu­fi­ges Grund­ver­ständ­nis von ser­ver­less Archi­tek­tu­ren ist, dass die Com­pute Ser­vices event-gesteu­ert arbei­ten und flüch­tig sind, d.h. sie sie kön­nen nach Bedarf hoch- und run­ter­ge­fah­ren wer­den. AWS Lambda ist ein Para­de­bei­spiel die­ses Grund­ge­dan­kens. Aller­dings kann der flüch­tige Spei­cher des Ser­vices stö­rend sein, wenn man bei­spiels­weise große Daten ver­ar­bei­ten möchte. Lambda-Funk­tio­nen ver­fü­gen zwar über einen Spei­cher von 512MB, aller­dings ist die­ser nicht immer aus­rei­chend  und nicht für das dau­er­hafte Spei­chern von Daten gedacht. Um dies zu erzie­len, müs­sen bis­her wei­tere Ser­vices wie AWS EFS hin­zu­ge­zo­gen werden.

AWS Lambda dient heut­zu­tage längst nicht mehr nur noch als Tool, um ver­schie­dene Ser­vices mit­ein­an­der zu ver­bin­den, son­dern wird unter­and­e­rem auch für die Ver­ar­bei­tung und Erstel­lung von Daten ver­wen­det. Diese Workloads benö­ti­gen aller­dings einen per­for­man­ten Spei­cher, um grö­ßere Daten­men­gen effi­zi­ent ver­ar­bei­ten oder cachen zu kön­nen. Die bis­he­rige Limi­tie­rung von 512MB hatte zur Folge, dass die Ver­wen­dung von AWS Lambda in ETL-Pro­zes­sen oder bei der Erstel­lung von Daten zu einem Draht­seil­akt bestehend aus „Wie viel kann ich auf ein­mal aus Ama­zon S3 Laden?“ und „wie hoch kann ich mei­nen Arbeits­spei­cher hoch­ska­lie­ren?“ wurde.

Seit Mitte März erlaubt AWS nun sei­nen Kun­den, die Größe des tem­po­rä­ren Spei­chers zu ska­lie­ren. Nut­zer des Ser­vices kön­nen nun dar­über ent­schei­den, wie viel MB Spei­cher einer Lambda-Funk­tion zur Ver­fü­gung ste­hen sol­len. Der Spei­cher kann bis zu 10240MB hoch­ska­liert wer­den. Dies hat zur Folge, dass AWS Lambda zukünf­tig für ETL, ML oder andere spei­cher­in­ten­sive Workloads noch inter­es­san­ter wird, ohne auf einen wei­te­ren Ser­vice wie AWS EFS zurück­grei­fen zu müssen.

Für wei­tere regel­mä­ßige Updates zum Thema AWS Cloud, fol­gen Sie unse­rer Prä­senz auf  Xing und  Insta­gram oder direkt unse­rem Blog.