Okto­ber 2021

Nach der Viel­zahl an Ankün­di­gun­gen wäh­rend der Sto­rage Days im ver­gan­ge­nen Monat, ist die Quan­ti­tät der Ände­run­gen in die­sem Monat zwar eher gering, ihre Qua­li­tät aber umso grö­ßer. Die­ser Blog­bei­trag stellt einen Aus­schnitt aus den Neue­run­gen und Ankün­di­gun­gen des Monats Okto­ber 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 Ama­zon EC2 und AWS Reds­hift vor­ge­stellt. Wei­ter­hin wer­den auch zwei Ände­run­gen der belieb­ten Ser­vices AWS Lambda und AWS Ste­pFunc­tions vor­ge­stellt, wel­che bereits seit Sep­tem­ber ver­füg­bar sind, aller­dings erst nach Ver­voll­stän­di­gung des dazu­ge­hö­ri­gen Blog­bei­trags publi­ziert wurden. 

Com­pute

Die wahr­schein­lich wich­tigste Neue­rung in puncto Com­pute-Ser­vices der AWS stammt noch aus dem Sep­tem­ber und betrifft den Ser­vice AWS Lambda. Bis­her wur­den Lambda-Funk­tio­nen auf Intel-Pro­zes­so­ren mit einer x86-Archi­tek­tur aus­ge­führt. Dies kön­nen Kun­den nun zukünf­tig ändern. 

AWS Lambda – Graviton2

Für den ser­ver­less Com­pute-Ser­vice AWS Lambda wurde am Ende des Monats Sep­tem­ber ein eigent­lich logi­scher nächs­ter Schritt vor­ge­stellt: Die Ver­wen­dung von Gra­vi­ton2-Pro­zes­so­ren bei der Aus­füh­rung von AWS Lambda-Funk­tio­nen. Bereits jetzt nut­zen viele User der AWS Platt­form die von Graviton2 gestütz­ten EC2-Instan­zen, um von den gerin­ge­ren Kos­ten die­ser, gegen­über denen der klas­si­schen Intel– und Apple M1-Pro­zes­so­ren, zu pro­fi­tie­ren. Laut AWS kön­nen sowohl neue als auch bereits exis­tie­rende Lambda Funk­tio­nen auf die Gra­vi­ton2-Pro­zes­so­ren migriert wer­den und so von bis zu 19% bes­se­rer Per­for­mance und 20 Pro­zent gerin­ge­ren Kos­ten profitieren. 

AWS selbst beschreibt die Migra­tion bereits bestehen­der Funk­tio­nen auf die neuen Gra­vi­ton2-Instan­zen wie das Umle­gen eines Schal­ters. Es sei an die­ser Stelle aller­dings ange­merkt, dass zumin­dest ein­zelne Code-Pas­sa­gen umge­stal­tet wer­den müs­sen, wenn die Funk­tio­nen Binär­ab­häng­kei­ten auf­wei­sen. Bei der Ver­wen­dung einer inter­pre­tier­ten Spra­che wie Python oder auch Node.js sollte dies aber eher sel­ten der Fall sein. 

Die Ska­lie­rungs­mög­lich­kei­ten der Lambda-Funk­tio­nen sind bei der Ver­wen­dung von Gra­vi­ton2-Pro­zes­so­ren iden­tisch mit den bis­her bestehen­den. Dem­entspre­chend kön­nen auch bei der Umstel­lung des Pro­zes­sor­typs bis zu 10 GB RAM und 6 vCPUs für eine Lambda-Funk­tion allo­kiert wer­den. Bis­her wer­den die Spra­chen Node.js 12 und 14, Python 3.8 und 3.9, Java 8 und 11, .NET Core 3.1 und Ruby 2.7 sowie wei­tere Cus­tom Run­times unter­stützt. Ver­füg­bar sind die Funk­tio­nen in Europa in Frank­furt, Irland und Lon­don. Für einen genaue­ren Kos­ten­ver­gleich kann die AWS Doku­men­ta­tion hin­zu­ge­zo­gen wer­den, wobei hier natür­lich poten­zi­elle Zeit­er­spar­nisse nicht ein­kal­ku­liert sind.

Ama­zon EC2 – Gaudi Accelerators

Auch die EC2-Instan­zen erleb­ten im Okto­ber eine Neue­rung, denn für sie ist nun ein neuer Instanz-Typ ver­füg­bar: Die DL1-Ins­tances, die eine Ant­wort auf die TPUs von Google darstellen. 

Machine Lear­ning, und ins­be­son­dere Deep Lear­ning, wird immer prä­sen­ter. Das Erstel­len eines ML-Models ist ein ite­ra­ti­ver Pro­zess bestehend aus dem Kon­stru­ie­ren des Anfangs­mo­dels, dem Trai­nie­ren und Tes­ten mit ent­spre­chen­den Daten­sät­zen und dem Anpas­sen von Para­me­tern. In den mul­ti­plen Layer, die dem Deep Lear­ning sei­nen Namen geben, wer­den eine Viel­zahl von mathe­ma­ti­schen Ope­ra­tio­nen aus­ge­führt, die die die Res­sour­cen einer Instanz, trotz der Ver­wen­dung von zusätz­li­chen GPUs, häu­fig voll­ends ausschöpfen. 

Hier sol­len nun die DL1-Instan­zen Bes­se­rung ver­spre­chen. Die DL1-Instan­zen kön­nen in einer Größe von .24xlarge genutzt wer­den. In die­ser Kon­fi­gu­ra­tion haben die Instan­zen 768GB Ram, 4 TB NVMe Spei­cher, 96vCPUs und 400 GB/s Netz­werk I/O, sowie 8 soge­nannt „Gaudi Acce­le­ra­tors“, die jeweils 32 Giga­byte High Band­width Memory besitzen. 

Im Gegen­satz zu den TPU-Units von Google wird von den AWS DL1-Instan­zen neben Ten­sor­flow auch PyTorch als Frame­work unter­stützt. Durch den Wech­sel von GPU-Basier­ten EC2-Instan­zen auf die neuen DL1-Instan­zen bewirbt Ama­zon eine Kos­ten­er­spar­nis von bis zu 40%. Die Instan­zen sind aller­dings zum jet­zi­gen Stand erst in zwei Regio­nen ver­füg­bar: North Vir­gi­nia und Ore­gon. Für eine detail­lierte Vor­stel­lung von Gaudi und den neuen EC2-Instan­zen sei auf die Inter­net­seite der Ent­wick­ler verwiesen.

Orchestra­tion and Control

AWS Ste­pFunc­tions – AWS SDK Ser­vice Integration

 Auch die im Fol­gen­dem Abschnitt vor­ge­stellte Ände­rung zu den AWS Ste­pFunc­tions wurde bereits im Sep­tem­ber bekannt gege­ben. Bis­her unter­stütz­ten Ste­pFunc­tions eher wenige, aber die wich­tigs­ten AWS Ser­vices, wie bei­spiels­weise AWS Lambda, und dien­ten so zur Orches­trie­rung die­ser Ser­vices, sodass bei­spiels­weise die eben genannte AWS Lambda-Funk­tio­nen in einer kon­trol­lier­ten Rei­hen­folge aus­ge­führt wer­den konn­ten. Neben AWS Lambda wur­den noch 16 wei­tere Ser­vices von dem low-Code Work­flow Ser­vice unter­stützt und konn­ten orches­triert wer­den. Diese Zahl hat sich im Okto­ber mehr als ver­zehn­facht und es wurde bekannt gege­ben, dass nun ins­ge­samt über 200 AWS Ser­vices unter­stützt wer­den und die Zahl der AWS API Actions von 46 auf über 9000 erhöht wurde. Diese Ver­viel­fäl­ti­gung von Mög­lich­kei­ten ist auf die Nut­zung der AWS SDK Ser­vice Inte­gra­tion zurückzuführen. 

Die AWS SDK Ser­vice Inte­gra­tion – und somit auch die erneu­er­ten Ste­pFunc­tions – sind in Europa in den Regio­nen Irland und Mai­land ver­füg­bar, aller­dings soll sie inner­halb der nächs­ten Zeit auch in allen ande­ren Regio­nen – und somit auch in Frank­furt – zur Ver­fü­gung stehen. 

AWS Cloud Con­trol API

Das Port­fo­lio an Ser­vices, die von Ama­zon bereit­ge­stellt wer­den, ist über die Jahre ste­tig gewach­sen. Seit der Ein­füh­rung der ers­ten Ser­vices vor nun über 15 Jah­ren ist die Zahl der nutz­ba­ren Ser­vices auf über 200 ange­stie­gen. Die­ses ste­tige Wachs­tum an Ser­vices brachte aller­dings einen Nach­teil mit sich, denn bis­her war es so, dass jeder Ser­vice seine eigene API samt sei­nes eige­nen Syn­taxes besaß. Zur Ver­deut­li­chung, was das bedeu­tet, ein kur­zes Bei­spiel für diese unter­schied­li­chen Syn­taxe: Möchte man einen S3-Bucket erstel­len, so musste man bis dato die Crea­teBu­cket-API und für die Erstel­lung einer EC2-Instanz die Run­In­s­tances-API verwenden. 

Durch die ver­schie­de­nen Anwen­dungs­ge­biete der APIs der ein­zel­nen Ser­vices, erschwert der unter­schied­li­chen Syn­tax das Manage­ment und die War­tung von Pro­gram­men, die diese nut­zen. Dies macht sich ins­be­son­dere bemerk­bar, wenn man gene­ri­sche Tem­pla­tes erstel­len möchte zur Erstel­lung von Res­sour­cen via API-Abfra­gen. Durch die neue AWS Cloud Con­trol API soll die Kom­ple­xi­tät nun aber redu­ziert werden. 

Die Cloud Con­trol API ist eine Menge von stan­dar­di­sier­ten CRUDL-APIs, also Create, Read, Update, Delete und List-APIs, und ist seit Okto­ber für eine Viel­zahl von Ser­vices ver­füg­bar. Der­zeit besteht sie aus 5 ein­fa­chen Befeh­len – Crea­teR­e­source, Get­Re­source, Upda­te­Re­source, Dele­te­Re­source, Lis­tRe­source – und ver­ein­heit­licht so die Syn­tax. Um auf das obige Bei­spiel von der Erstel­lung eines S3-Buckets und einer EC2-Instanz zurück­zu­kom­men, würde nun in bei­den Fäl­len die Crea­teR­e­source-API auf­ge­ru­fen wer­den mit dem Typ der zu erstel­len­den Res­source und sei­nen Attri­bu­ten als zusätz­li­che Parameter. 

Laut Ama­zon sol­len die neuen und ein­heit­li­che­ren Cloud Con­trol APIs die klas­si­schen APIs nicht voll­stän­dig ablö­sen, son­dern par­al­lel zu die­sen exis­tie­ren. Nichts­des­to­we­ni­ger ist es ein­fa­cher, bei der Erstel­lung neuer Appli­ka­tio­nen zukünf­tig auf die Cloud Con­trol APIs zurück­zu­grei­fen. Die Cloud Con­trol APIs sind seit Anfang Okto­ber in allen AWS Regio­nen, mit Aus­nahme von China, ver­füg­bar und es fal­len keine zusätz­li­chen Kos­ten an, sodass ledig­lich die zugrun­de­lie­gen­den AWS Res­sour­cen bezahlt wer­den müssen.

Data Ware­housing

Ama­zon Reds­hift: Data Exchange

Wenn man die neu hin­zu­ge­kom­me­nen Fea­tures betrach­tet, hat AWS Reds­hift in den ver­gan­ge­nen Wochen und Mona­ten eini­ges an Boden gegen­über sei­nen Kon­tra­hen­ten Big­Query und Snow­flake gut gemacht. Ein Bei­spiel hier­für ist der von uns bereits im Mai vor­ge­stellte Ser­vice Reds­hiftML, mit wel­chem über SQL-Abfra­gen Machine Lear­ning Modelle aus Reds­hift her­aus trai­niert und abge­fragt wer­den kön­nen. Dies war bis dato eigent­lich ein Mar­ken­zei­chen des Google eige­nen OLAP Data Warehou­ses Big­Query. Ana­log hierzu gestal­tet sich auch der Data Exch­ange für Ama­zon Reds­hift, wobei die Vor­rei­ter­rolle im Thema Data Sha­ring bis­her Snow­flake zuzu­spre­chen war. 

Data Exch­ange für Ama­zon Reds­hift basiert schluss­end­lich auf dem bereits 2019 vor­ge­stell­ten AWS Data Exch­ange, mit wel­chem von Dritt­an­bie­tern ver­öf­fent­lichte Daten­töpfe abon­niert und in einen eige­nen S3-Bucket kopiert und wei­ter­ver­ar­bei­tet wer­den konn­ten. Die Neue­run­gen hier liegt nun darin, dass sol­che Daten­töpfe direkt aus Reds­hift her­aus abon­niert und abge­fragt wer­den kön­nen und keine zusätz­li­che ETL-Pro­zes­sie­rung not­wen­dig ist. 

Genau wie bei Snow­flake stel­len die Data Pro­vi­der die Daten zur Ver­fü­gung und wer­den über das Abon­ne­ment ver­gü­tet. Die Trans­ak­tion erfolgt auto­ma­tisch durch Reds­hift Exch­ange und wird mit dem AWS Rech­nungs­konto ver­rech­net. Ver­füg­bar ist Data Exch­ange für Ama­zon Reds­hift in allen Regio­nen, in denen auch RA3-Instan­zen ver­füg­bar sind und somit ins­be­son­dere in Frank­furt, Irland und London. 

Novem­ber 2021

Ins­be­son­dere gegen Ende des Monats Novem­ber war spür­bar, dass die dies­jäh­rige re:invent immer näher rückte und so wur­den immer mehr Neue­run­gen und Ankün­di­gun­gen von AWS ver­öf­fent­lich. Über die gro­ßen Neu­an­kün­di­gun­gen der re:invent wer­den wir in einem sepa­ra­tem Blog­bei­trag berich­ten. Die­ser Blog­bei­trag stellt einen Aus­schnitt aus den Neue­run­gen und Ankün­di­gun­gen des Monats Novem­ber 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 Ama­zon Far­gate und AWS S3 vorgestellt. 

Com­pute 

AWS Far­gate

Erst vor kur­zem erst hat AWS die Ver­füg­bar­keit von Gra­vi­ton2-Pro­zes­so­ren für AWS Lambda bekannt­ge­ge­ben und nun sind diese Pro­zes­so­ren auch für AWS Far­gate mit AWS ECS ver­füg­bar. AWS Far­gate ist ein ser­ver­less-com­pute Ser­vice der AWS, der für die Bereit­stel­lung von Con­tai­nern genutzt wer­den kann und das Manage­ment und die Ska­lie­rung die­ser übernimmt. 

AWS ver­spricht bei der Nut­zung von AWS Gra­ti­ton2-Pro­zes­so­ren ein um bis zu 40 Pro­zent bes­se­res Preis-Leis­tungs-Ver­hält­nis und 20 Pro­zent gerin­gere Kos­ten als bei ver­gleich­ba­ren Intel-Pro­zes­so­ren. Um die Gra­vi­ton-Pro­zes­so­ren zu nut­zen, müs­sen aller­dings unter Umstän­den die Images ange­passt wer­den und zu Multi-Archi­tec­ture Con­tai­ner Images umge­wan­delt werden. 

Multi-Archi­tec­ture Con­tai­ner Images bestehen aus zwei Tei­len: Dem eigent­li­chen Layer und einem Mani­fest. Das Mani­fest bestimmt hier­bei, wel­che Gruppe von Lay­ern schluss­end­lich das Image bil­den, sowie Run­time-Cha­rac­te­ristics wie die Archi­tek­tur. Diese kann ent­we­der ARM64, wie es für die Gra­vi­ton-Pro­zes­so­ren not­wen­dig ist, oder X86_64 sein. Durch das Erstel­len von Multi-Archi­tec­ture Con­tai­ner Images besteht die Mög­lich­keit, das­selbe Repo­si­tory für ver­schie­dene Archi­tek­tu­ren zu verwenden. 

AWS Far­gate mit AWS Graviton2 Pro­zes­so­ren ist in allen Regio­nen ver­füg­bar, in denen auch AWS Far­gate bis­her ver­füg­bar war, aller­dings wer­den die Gra­vi­ton2-Pro­zes­so­ren nur von der Far­gate Platt­form Ver­sion 1.4.0 oder spä­ter unter­stützt. Für eine detail­lierte Auf­lis­tung der Preise, ver­wei­sen wir auf die AWS Doku­men­ta­tion.

Kar­pen­ter

Im vor­an­ge­gan­ge­nen Monat wurde bekannt gege­ben, dass nun Kar­pen­ter bereit ist für pro­duk­tive Use-Cases und der Pre­view-Phase ent­wach­sen ist. Kar­pen­ter ist open-source und ein fle­xi­bler Aut­o­s­ca­ler für Kuber­netes-Clus­ter auf AWS. Die Nut­zung von Kar­pen­ter soll AWS Kun­den dabei unter­stüt­zen, die Ver­füg­bar­keit und Effi­zi­enz von Appli­ka­tio­nen zu erhö­hen, indem es die Menge an zur Ver­fü­gung ste­hen­den Com­pute-Res­sour­cen der der­zei­ti­gen Aus­las­tung anpasst. 

Kar­pen­ter wird auf dem Clus­ter selbst instal­liert und beob­ach­tet die agg­re­gier­ten Res­sour­cen, die von Pods ange­fragt wer­den. Soll­ten diese Anfra­gen einen gewis­sen Schwel­len­wert über­schrei­ten oder unter­schrei­ten, wer­den ein­fach wei­tere Res­sour­cen von Kar­pen­ter zur Ver­fü­gung gestellt oder ter­mi­niert. Dies geschieht, indem Kar­pen­ter Befehle an den unter­lie­gen­den Com­pute-Ser­vice, wie bei­spiels­weise Ama­zon EC2, sendet. 

Kar­pen­ter ist somit eine ein­fa­cher zu nut­zende Alter­na­tive als bis­he­rige Lösun­gen zur dyna­mi­schen Anpas­sung von Kuber­netes Clus­tern, wel­che häu­fig auf Ama­zon EC2 Auto-Sca­ling Groups und Kuber­netes Clus­ter Aut­o­s­ca­ler zurück­grei­fen muss­ten, da ins­be­son­dere die Kon­fi­gu­ra­tion des Kuber­netes Aut­o­s­ca­ler einige Tücken auf­wei­sen konnte.

Sto­rage

EBS Snapshot Archive

Im Novem­ber ist mit Ama­zon EBS Snapshots Archive ist ein neues Sto­rage-Tier für die Lang­zeit­spei­che­rung von Ela­s­tic Block Store Snapshots hinzugekommen. 

EBS selbst ist ein Block Sto­rages Ser­vice, wel­cher zum Bei­spiel von EC2-Ins­tan­cen zur Spei­che­rung von Daten ver­wen­det wer­den kann oder das Boo­ten eines Betriebs­sys­tems ermög­licht. EBS Snapshots kön­nen erstellt wer­den, um eine Kopie der Daten zu einem bestimm­ten Zeit­punkt zu erstel­len. Hier­bei ent­hält der erste Snapshot eines EBS-Volu­mes alle Daten, mit denen das Volu­men beschrie­ben wurde. Fol­gende Screen­shots spei­chern nur noch die Ver­än­de­run­gen, wodurch EBS Snapshots in ihrer Funk­ti­ons­weise schon sehr effizient. 

Durch regu­la­to­ri­sche Vor­ga­ben ist es mög­lich, dass Snapshots über einen lan­gen Zeit­raum gespei­chert wer­den müs­sen. Dies kann, obwohl Snapshots bereits sehr kos­ten­ef­fi­zi­ent sind, zu uner­wünscht hohen Kos­ten füh­ren, wenn sie unter der Ver­wen­dung eines Hot-Data Sto­rage-Tiers abge­legt wer­den. Da die meis­ten Snapshots aller­dings nie benutzt wer­den, bie­tet es sich an, diese unter der Ver­wen­dung eines der Cold-Data Sto­rage-Tiers von AWS S3 abzu­le­gen, um die Spei­cher­kos­ten mög­lichst gering zu hal­ten. Um dies war bis­her zu errei­chen, muss­ten aller­dings selbst­ge­schrie­ben Skripte ver­wen­det wer­den, wel­che unter ande­rem tem­po­räre EC2-Instan­zen erstel­len muss­ten, um die Snapshots wie­der­her­zu­stel­len, zu moun­ten und schluss­end­lich die Daten zu transferieren. 

EBS Snapshots Archive bie­tet nun eine kos­ten­güns­tige Lösung, um Snapshots für min­des­tens 90 Tage zu spei­chern – ohne den zusätz­li­chen Auf­wand, der mit den selbst­ge­schrie­be­nen Skrip­ten ein­her­geht. Um Snapshots zu ver­wen­den, die in Snapshots Archive abge­legt wor­den sind, müs­sen diese zunächst wie­der­her­ge­stellt wer­den. Das Wie­der­her­stel­len eines sol­chen Snapshots kann zwi­schen 24 und 72 Stun­den dau­ern – je nach­dem wie groß der Snapshot ist. 

EBS Snapshot Archive ist ab sofort in ins­ge­samt 17 Regio­nen und ins­be­son­dere in allen Regio­nen in Europa ver­füg­bar. Wie bei allen pay-as-you-go Tari­fen, rich­ten sich die Kos­ten für die Nut­zung die­ses Sto­rage-Tiers zum einen nach der Menge an gespei­cher­ten Daten und zum ande­ren an der Menge an trans­fe­rier­ten Daten. Für die Spei­che­rung von Daten ent­fällt eine Gebührt von 0,0125$/GB pro Monat an und für den Trans­fer 0,03$/GB. Eine genauere Auf­lis­tung aller Preise kann der Preis­ta­belle auf der dazu­ge­hö­ri­gen AWS-Seite ent­nom­men werden.

S3 Event Noti­fi­ca­ti­ons mit EventBridge

Ama­zon Event­Bridge ist ein Ser­vice von AWS, der es erlaubt, event-gesteu­erte Appli­ka­tio­nen zu erstel­len. Seit Novem­ber 2021 ist dies nun auch für AWS S3 mög­lich und stellt somit eine alter­na­tive zu den bis­he­ri­gen S3 Event Noti­fi­ca­ti­ons dar, die es bis­her ermög­licht haben, in SNS Topics oder SQS Queues zu schrei­ben oder eine AWS Lambda Funk­tion zu trig­gern, wenn eine Ver­än­de­rung an einem Objekt in S3 auf­ge­tre­ten ist. 

Die bis­he­ri­gen Mög­lich­kei­ten wur­den dadurch erwei­tert, dass S3 Event Noti­fi­ca­ti­ons direkt zu Event­Bridge über­ge­ben wer­den kön­nen. Dies ermög­licht es, direkt auf die Events zu Fil­tern und Events zu meh­re­ren Ziel­or­ten zu rou­ten und so bei­spiels­weise meh­rere Lambda-Funk­tio­nen zu trig­gern. Wei­ter­hin garan­tiert die Ver­wen­dung von Event­Bridge eine at-least-once-deli­very, wodurch Archi­tek­tu­ren zuver­läs­si­ger werden. 

Event Noti­fi­ca­ti­ons mit Event­Bridge sind ab sofort in allen AWS Regio­nen ver­füg­bar. Bei der Ver­wen­dung fal­len Kos­ten in Höhe von 1$ pro 1 Mil­lio­nen Events an. 

Moni­to­ring

Ama­zon CloudWatch

Ama­zon Cloud­Watch ist ein kos­ten­güns­ti­ges Moni­to­ring Tool, wel­ches out-of-the-box in der AWS ver­wen­det wer­den kann und kei­nen War­tungs­auf­wand mit sich bringt. Seit sei­nem Launch sind viele Fea­tures hin­zu­ge­kom­men, die alle die Moni­to­ring-Mög­lich­kei­ten des Ser­vices wei­ter ver­bes­sert haben. In diese Reihe reiht sich auch das neu­este Fea­ture ein: Im Novem­ber 2021 wurde von AWS das Real-User Moni­to­ring in AWS Cloud­Watch vorgestellt. 

Eine der größ­ten Her­aus­for­de­run­gen, wenn man Appli­ka­tio­nen monit­ort, ist, die Per­for­man­ce­schwan­kun­gen des Sys­tems zu ver­ste­hen und durch Anpas­sun­gen den Nut­zern ein opti­ma­les Nut­zungs­er­leb­nis zu gewähr­leis­ten. Hier­bei ist aller­dings eine Viel­zahl von Varia­blen zu berück­sich­ti­gen, die von User zu User vari­ie­ren kön­nen, wie bei­spiels­weise der Brow­ser Typ und seine Kon­fi­gu­ra­tio­nen, der Stand­ort des Nutzers, …. 

Ama­zon Cloud­Watch Real-User Moni­to­ring (RUM) hilft sei­nen Nut­zern dabei, diese Metri­ken zu sam­meln und aus­zu­wer­ten, um ein bes­se­res Ver­ständ­nis von der Per­for­mance einer Appli­ka­tion für die ein­zel­nen End­nut­zer zu erhal­ten. Um den Ser­vice zu nut­zen, muss ledig­lich die Appli­ka­tion vor­her regis­triert wer­den und ein vor­ge­fer­tig­tes Snip­pet Java­Script-Code an den Hea­der jeder Seite hin­zu­ge­fügt wer­den. Die­ses Snip­pet sen­det dann die Metri­ken der ein­zel­nen Nut­zer zu Cloud­Watch RUM. Dort wer­den diese dann kon­so­li­diert und kön­nen von Nut­zern ana­ly­siert werden. 

Ama­zon Cloud­Watch RUM ist ab sofort ver­füg­bar in ins­ge­samt 10 AWS Regio­nen und unter­and­e­rem in Irland, Lon­don, Frank­furt sowie Stock­holm. Für die Nut­zung von AWS Cloud­Watch RUM fal­len Gebüh­ren in Höhe von 1$ pro 100k Events an. Ins­ge­samt birgt Cloud­Watch RUM, ins­be­son­dere in Kom­bi­na­tion mit AWS X‑Ray, das Poten­tial, Appli­ka­tio­nen durch­sich­ti­ger zu machen und so Per­for­mance-Schwach­stel­len schnel­ler aufzudecken. 

Dezem­ber 2021

Der Dezem­ber stand in der AWS zu einem gro­ßen Teil im Zei­chen des Net­wor­kings. Die­ser Blog­bei­trag stellt einen Aus­schnitt aus den Neue­run­gen und Ankün­di­gun­gen des Monats Dezem­ber 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 Shield, AWS EKS, AWS RDS und Dyna­moDB vorgestellt.

Net­wor­king

VPC Net­work Access Analyzer

Der AWS VPC Net­work Access Ana­ly­zer ist ein neues Fea­ture in der AWs, wel­ches sich ins­be­son­dere bei Net­work- und Secu­rity-Engi­neers einer jeden Orga­ni­sa­tion gro­ßer Beliebt­heit erfreuen wird. Das neue Fea­ture wurde spe­zi­ell dafür kon­zi­piert, Netz­werk­kon­fi­gu­ra­tio­nen, die zu einem unge­woll­ten Zugriff auf das eigene Netz­werk füh­ren, auf­zu­de­cken und erspart den oben genann­ten Engi­neers somit die manu­elle Über­prü­fung jedes ein­zel­nen Ein­trags in den Netz­werk­kon­fi­gu­ra­tio­nen und redu­ziert die Gefahr mensch­li­cher Fehler.

Der AWS VPC Net­work Access Ana­ly­zer nutzt die „Auto­ma­ted Reaso­ning Tech­no­logy“, wel­che bei­spiels­weise bereits im IAM Access Ana­ly­zer und dem VPC Reachab­ility Ana­ly­zer ein­ge­setzt wer­den und Net­work Access Sco­pes, um die gewünsch­ten Ver­bin­dun­gen zwi­schen den AWS Res­sour­cen zu defi­nie­ren.  Die Sco­pes sind unab­hän­gig von dem jewei­li­gen Netz­werk und Kon­fi­gu­ra­tion und kön­nen als all­ge­meine Defi­ni­tion für den Zugriff auf ein Netz­werk und des­sen Ver­bin­dun­gen ver­stan­den wer­den. So kön­nen Nut­zer zum Bei­spiel einen Scope erstel­len, um zu über­prü­fen, dass alle Res­sour­cen des Sales-Teams eines Unter­neh­mens unab­hän­gig von denen des Deve­lo­p­ment-Teams sind.

Die Ana­lyse eines Netz­werks dau­ert nur noch wenige Minu­ten und berück­sich­tigt bei­spiels­weise Secu­rity Groups, CIDR-Ran­ges, Pre­fix-Lists, End­points und viele wei­tere AWS Ressourcen.

Der VPC Net­work Access Ana­ly­zer ist in Europa in Frank­furt, Irland, Lon­don, Mai­land, Paris und Stock­holm ver­füg­bar und kos­tet 0,002 USD pro ENI wel­ches ana­ly­siert wird. In den wei­te­ren Mona­ten soll der Ser­vice noch wei­ter aus­ge­baut wer­den, sodass Ana­ly­sen auto­ma­tisch in regelmäß9gen Abstän­den aus­ge­führt wer­den kön­nen und IPv6 Adres­sen unter­stützt werden.

Ela­s­tic Kuber­netes Service

Die Con­tai­ne­ri­sie­rung von Appli­ka­tio­nen ist in den letz­ten Jah­ren immer wei­ter zum Stan­dard gewor­den und ins­be­son­dere Kuber­netes wird immer häu­fi­ger verwendet.

Kuber­netes selbst ist eine por­ta­ble und erwei­ter­bare Open-Source-Platt­form, die jedem Pod inner­halb eines Clus­ters eine IP-Adresse zuweist. Hier­bei sollte berück­sich­tigt wer­den, dass das Ver­hält­nis von Pods zu ver­füg­ba­ren IP-Adres­sen min­des­tens 2:1 sein sollte, um Pro­bleme bei der Allo­ka­tion von IP-Adres­sen wäh­rend des Updates des Clus­ters umgan­gen wer­den können.

Durch die Viel­zahl an IP-Adres­sen, die so reser­viert wer­den, kann ein klas­si­sches IPv4 Netz­werk mit sei­ner „gerin­gen“ Anzahl an Adres­sen ein Bot­t­len­eck dar­stel­len. Die­ses Pro­blem konnte zwar durch die Vir­tua­li­sie­rung von IP-Adres­sen mit­tels Instal­la­tion eines Con­tai­ner Net­work Plug­ins umgan­gen wer­den, aller­dings ver­lo­ren Admi­nis­tra­to­ren so auch die Mög­lich­kei­ten eines effek­ti­ven Trou­ble­shoo­tings. Wei­ter­hin hat diese Lösung nur schlecht ska­liert, da für die Kom­mu­ni­ka­tion mit einem Ser­vice, der außer­halb des VPCs liegt, der Traf­fic von den Pods über mul­ti­ple Hops gelei­tet wer­den musste, was natür­lich die Latenz der Anwen­dung sowie des­sen Kom­ple­xi­tät erhöht.

Um dies nun zu ver­ein­fa­chen kön­nen nun IPv6-Adres­sen ver­wen­det wer­den, wel­che mehr Adres­sen zur Ver­fü­gung stel­len. Dies bringt min­des­tens zwei Vor­teile mit sich: Zum einen kön­nen mehr Pods ver­wen­det wer­den. Zum ande­ren kann der Traf­fic nun über weni­ger Hops gelei­tet wer­den, da die Umlei­tung über einen extra NAT-Hop wegfällt.

Die IPv6-Adres­sen für Ama­zon EKS sind seit Dezem­ber 2021 in allen AWS Regio­nen ver­füg­bar, in denen auch EKS ver­füg­bar sind. Bei der Ver­wen­dung von IPv6-Adres­sen fal­len zudem keine wei­te­ren Kos­ten an.

AWS Direct Con­nect SiteLink

Bei der Nut­zung eines Cloud-Pro­vi­ders wie AWS ist ins­be­son­dere die Ver­bin­dung zwi­schen dem eige­nen Dat­a­cen­ter und dem des Clou­dan­bie­ters ein heik­les Thema. Mit AWS Direct Con­nect Site­Link besteht nun eine wei­tere Mög­lich­keit, eine Site-2-Site Ver­bin­dung zwi­schen dem eige­nem on-premises Netz­werk und dem glo­ba­len AWS Back­bone herzustellen.

Seit Dezem­ber 2021 kön­nen on-premises Netz­werke mit soge­nann­ten Direct Con­nect Loca­ti­ons ver­bun­den wer­den. Bis­her exis­tie­ren 108 Direct Con­nect Loca­ti­ons, die auf 32 Län­der ver­teilt sind. Da der Ser­vice zu den glo­ba­len Ser­vices der AWS zählt, ist ein Pee­ring zwi­schen unter­schied­li­chen Regio­nen nicht notwendig.

AWS Direct­Con­nect Site­link ist seit Dezem­ber 2021 ver­füg­bar und erlaubt die Ver­bin­dung von jedem belie­bi­gen on-premises Netz­werk zu einer Direct Con­nect Loca­tion und ist somit über­all ver­füg­bar – mit Aus­nahme der bei­den Regio­nen in China. Die Preis­struk­tur ori­en­tiert sich an dem pay-as-you-go Grund­satz der Cloud. Da jedes Unter­neh­men unter­schied­li­che Ansprü­che bezie­hungs­weise Regu­la­rien an die Ver­bin­dung zu AWS hat, ver­wei­sen wir für genauere Infor­ma­tio­nen zu den Kos­ten des Ser­vices auf die dazu­ge­hö­rige Seite von AWS.

AWS Shield

AWS Shield ist ein Secu­rity-Ser­vice in der AWS, der Res­sour­cen effek­tiv gegen DDoS-Angriffe ver­tei­di­gen soll. Im All­ge­mei­nen gibt es zwei Tiers für AWS Shield: Stan­dard und Advanced.

Von den Vor­tei­len des Stan­dard-Tiers, wie der Abwehr von DDoS-Angrif­fen über Layer 3 und 4, pro­fi­tie­ren alle Nut­zer der AWS auto­ma­tisch und ohne zusätz­li­che Kos­ten. Um die­sen Schutz zu erhö­hen und zu per­so­na­li­sie­ren, um sich bei­spiels­weise gegen DDoS Angriffe über Layer 7 zu ver­tei­di­gen, kön­nen Nut­zer der AWS dem Advan­ced Tier bei­tre­ten. Wei­ter­hin bie­tet das Advan­ced Tier einen bes­se­ren Schutz gegen grö­ßere DDoS-Angriffe, Ein­bli­cke in Echt­zeit in eine sol­che Atta­cke und eine Inte­gra­tion in AWS WAF.

Im Dezem­ber ist für das Advan­ced Tier von AWS Shield ein Update ver­öf­fent­licht wor­den, wel­ches auto­ma­tisch Regeln in AWS WAF erstellt, tes­tend und imple­men­tiert, um DDoS Angriffe über das Layer 7 zu ver­hin­dern. Für die Ver­wen­dung fal­len keine zusätz­li­chen Kos­ten an.

Sto­rage

Dynamo DB: Neue Klas­sen für Tabellen

Dyna­moDB ist eine fully-mana­ged, ser­ver­less NoSQL Data­base, wel­che ins­be­son­dere bei Anwen­dun­gen, die eine geringe Latenz besit­zen müs­sen, zum Ein­satz kommt. Nun ist es aller­dings auch hier so wie bei jedem ande­ren Sto­rage-Ser­vice auch, dass nicht alle Daten gleich häu­fig abge­fragt wer­den und so wie in ande­ren Ser­vices auch, bie­tet AWS auch hier seit Dezem­ber 2021 nun die Mög­lich­keit, Daten die sel­te­ner abge­fragt wer­den, in einer ande­ren Spei­cher­klasse abzu­le­gen, wel­che gerin­gere Kos­ten für das Spei­chern aber höhere Kos­ten für die Abfrage von Daten bietet.

Mit der neuen Dynamo DB Stan­dard-IA Table Class ver­spricht Ama­zon Preis­er­spa­run­gen von bis zu 60% gerin­ge­ren Spei­cher­kos­ten gegen­über den nor­ma­len Dyna­moDB Stan­dard Tables bei der­sel­ben Per­for­mance, Ver­füg­bar­keit und Ska­lier­bar­keit und bie­tet so, eine gute Lösung für Daten, die nur sel­ten abge­fragt wer­den, aber inner­halb weni­ger Mil­li­se­kun­den ver­füg­bar sein müssen.

Die neuen Dyna­moDB Stan­dard-IA Tabel­len sind in allen Regio­nen mit Aus­nahme von den bei­den Regio­nen in China und AWS Gov­Cloud verfügbar.

Ama­zon RDS Cus­tom: SQL-Server

SQL-Ser­ver ist eine der wahr­schein­lich am ver­brei­tets­ten Daten­ban­ken in der on-premises Welt und seit Dezem­ber kann SQL Ser­ver auch in Ver­bin­dung mit Ama­zon RDS Cus­tom genutzt werden.

Ama­zon RDS Cus­tom bringt alle Vor­teile von Ama­zon RDS mit sich, aber im Unter­schied zu RDS selbst, kön­nen Nut­zer die Admi­nis­tra­tion der Daten­bank – zumin­dest teil­weise – selbst durch­füh­ren. Admi­nis­tra­to­ren kön­nen so bei­spiels­weise wei­tere third-party Anwen­dun­gen auf der Daten­bank oder modi­fi­zierte OS Packa­ges auf der Daten­bank installieren.

Mit RDS Cus­tom for SQL-Ser­ver kön­nen Fea­tures hin­zu­ge­fügt wer­den, wie bei­spiels­weise bestimmte Trei­ber oder eine erhöhte Anzahl von Daten­ban­ken pro Instanz. RDS Cus­tom for SQL Ser­ver bie­tet sowohl Moni­to­ring als auch Reco­very Funk­tio­na­li­tä­ten, High-Avai­la­bi­lity-Kon­fi­gu­ra­tio­nen mit Always On Avai­la­bi­lity Groups und auto­ma­ti­schen Back-Ups an.

Ama­zon RDS Cus­tom for SQL-Ser­ver ist in Europa in Frank­furt, Irland und Stock­holm verfügbar.

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.