April 2021

In die­sem Jahr steht der April in der AWS-Welt ganz im Zei­chen der Ver­bes­se­rung bestehen­der Ser­vices und Tech­no­lo­gien. Die­ser Blog­bei­trag stellt einen Aus­schnitt aus den Neue­run­gen und Ankün­di­gun­gen des Monats April dar, erhebt aber nicht den Anspruch auf Voll­stän­dig­keit. Das Haupt­au­gen­merkt liegt hier­bei auf Ver­än­de­run­gen, bei denen wir von einem direk­ten Ein­fluss auf unsere Kun­den im Versicherungs‑, Finanz- und Retail­sek­tor 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 EC2, AWS Sage­Ma­ker und AWS Reds­hift vorgestellt. 

Data Ware­housing

AWS Reds­hift 

Die Migra­tion von on-premises Daten­ban­ken in die Cloud ist eine der größ­ten Auf­ga­ben und wich­tigs­ten The­men der letz­ten Jahre und so ver­wun­dert es wenig, dass Ama­zon auch die­sen Monat wei­tere Neue­run­gen von Reds­hift bekannt gege­ben hat. Hier­bei ste­chen ins­be­son­dere zwei Neue­run­gen heraus:

Die Unter­stüt­zung semi-struk­tu­rier­ter Daten

Seit die­sem Monat steht die native Unter­stüt­zung von JSON und semi-struk­tu­rier­ten Daten den Nut­zern von AWS Reds­hift nun zur Ver­fü­gung. Die semi-struk­tu­rier­ten Daten kön­nen mit­tels des neuen Daten­ty­pens „SUPER“ gespei­chert und unter Ver­wen­dung von Par­tiQL abge­fragt und ana­ly­siert wer­den. Das direkte Spei­chern und Abfra­gen von semi-struk­tu­rier­ten Daten inner­halb der Struk­tu­ren von Reds­hift ver­ein­facht ETL-Ver­ar­bei­tun­gen im All­ge­mei­nen, da nun keine exter­nen Dienste mehr für das Par­sing not­wen­dig sind. Ein wei­te­res Fea­turen, das nun durch die Ver­wen­dung von Par­tiQL mög­lich ist, ist die dyna­mi­sche Typi­sie­rung und Typ-Prü­fungs­funk­tion, wel­che das expli­zite „Cas­ten“ von Daten­ty­pen obso­let macht.

Die­ses Update hilft Reds­hift, die Lücke zu Snow­flake etwas zu schlie­ßen. Snow­flake unter­stützt schon seit län­ge­rem eine per­for­mante Ver­ar­bei­tung  von semi-struk­tu­rier­ten Daten wie JSON, XML oder Avro mit­tels nati­ver Funk­tio­nen und war somit in Fäl­len, in denen semi-struk­tu­rierte Daten ver­ar­bei­tet wer­den soll­ten, Reds­hift über­le­gen. Noch immer fehlt Reds­hift der Sup­port wei­te­rer Daten­ty­pen wie bei­spiels­weise XML, aller­dings ist hier die Per­for­mance in Snow­flake deut­lich schlech­ter als bei der Ver­ar­bei­tung von JSON, wes­we­gen eine Kon­ver­tie­rung zu JSON meist ohne­hin zu emp­feh­len ist.

Reds­hift AQUA

Um den stei­gen­den Daten­wachs­tum der letz­ten Jahre gerecht wer­den zu kön­nen, hat AWS hin­sicht­lich des Sto­rage und der Per­for­mance des­sel­bi­gen bereits einige Neue­run­gen getrof­fen, wie bei­spiels­weise der Release der SSD-basier­ten RA3-Nodes belegt. Nun ist es aller­dings so, dass die Ver­bes­se­run­gen im Bereich Sto­rage die der CPU-Per­for­mance im All­ge­mei­nen über­tref­fen. Das ste­tige Daten­wachs­tum in Kom­bi­na­tion mit einer ledig­lich end­li­chen Netz­werk­ge­schwin­dig­keit haben offen­ge­legt, dass in eini­gen Fäl­len die Netz­werk– und CPU-Band­breite ein limi­tie­ren­der Fak­tor sein kön­nen. Um die­ses Pro­blem zu lösen, hat AWS für die ra3.4xl und ra3.16xl Kno­ten nun AQUA ver­öf­fent­licht. AQUA funk­tio­niert wie eine Art hori­zon­tal ska­lier­ter Com­pute-Layer unter dem eigent­li­chen Redshift-Cluster.

Sub­queries, die Aggre­ga­tio­nen und Scans auf dem eigent­li­chen Daten ent­hal­ten, wer­den an die­ses Layer über­tra­gen. Das Layer ist dann dafür ver­ant­wort­lich, in par­al­le­li­sier­ter Form diese Sub­queries zu bear­bei­ten und die Ergeb­nisse an das Reds­hift-Clus­ter zur wei­te­ren Pro­zes­sie­rung zu über­ge­ben. Durch das par­al­le­li­sierte initiale Scan­nen der Daten wird die zu über­tra­gende Daten­menge redu­ziert und somit eine per­for­man­tere Abfrage ermöglicht.

Kon­nek­ti­vi­tät

FSx File Gateway

In den letz­ten Jah­ren wur­den immer mehr Workloads in die Cloud migriert und pro­fi­tie­ren dort von den güns­ti­gen Prei­sen, der fle­xi­blen Ska­lier­bar­keit und hohen Ver­füg­bar­keit der Sys­teme. Viele lokale Anwen­dun­gen sind aller­dings von nied­ri­gen Laten­zen abhän­gig, was bei einem direk­ten Zugriff auf Dateien in der Cloud nicht voll­stän­dig garan­tiert ist und somit zu Performance–Einbußen füh­ren kann. 

Aus die­sem Grund hat AWS nun Ama­zon FSx File Gate­way vor­ge­stellt. Dies ist eine neue Art des bereits bekann­ten AWS Sto­rage Gate­ways, wel­cher es Kun­den ermög­licht, in der Cloud gespei­cherte Daten mit­tels Ama­zon FSx for Win­dows File Ser­ver per­for­mant abzu­fra­gen. Der Ser­vice opti­miert hier­bei den loka­len Zugriff, indem es einen Cache für häu­fig abge­ru­fene Daten anlegt und die Netz­werk­ver­bin­dung opti­miert. Dies hat zur Folge, dass die Latenz ver­rin­gert wird und somit die oben beschrie­ben Workloads auch bei einem Zugriff auf Daten, die in einem Cloud-Daten­spei­cher abge­legt sind, per­for­mant laufen. 

Machine Lear­ning 

AWS Sage­Ma­ker – Saving Plans

So wie bis­her in jedem Monat in die­sem Jahr, gibt es auch im April wie­der Neue­run­gen bei AWS Sage­Ma­ker. Im Gegen­satz zu vie­len vor­he­ri­gen Ände­run­gen, wie bei­spiels­weise die im Februar, betref­fen die Ände­run­gen in die­sem Monat aller­dings haupt­säch­lich den finan­zi­el­len Bereich der Nut­zung von SageMaker.

Seit 2019 ist es schon mög­lich, im Bereich der „nor­ma­len“ Com­pute-Res­sour­cen ein Lang­zeit-Com­mit­ment mit AWS ein­zu­ge­hen, um die eige­nen Com­pute-Kos­ten zu opti­mie­ren. Hier­bei geht man einen ein– bzw. drei­jäh­ri­gen Ver­trag mit AWS ein, in wel­chem eine gewisse Com­pute-Kapa­zi­tät reser­viert wird. Im Gegen­zug ver­spricht Ama­zon eine Erspar­nis von bis zu 72%. Diese Form des Saving Plans ver­spricht Ama­zon nun auch, neben einer all­ge­mei­nen Reduk­tion der Kos­ten für Com­pute-Instan­zen der ml-Fami­lie um 14,9%, für die Ver­wen­dung der Com­pute-Res­sour­cen des SageMaker-Services.

Ama­zon Timestream

AWS hat bekannt gege­ben, dass nun die fully-mana­ged Zeit­rei­hen­da­ten­bank Ama­zon Timestream im Stand­ort Frank­furt ver­füg­bar ist. Die Daten, die in Ama­zon Timestream gespei­chert wer­den, wer­den auto­ma­tisch nach vom Benut­zer defi­nier­ten Richt­li­nien ent­we­der im Spei­cher gehal­ten oder auf eine kos­ten­op­ti­mierte Spei­cher­ebene ver­scho­ben. So ist es zum Bei­spiel mög­lich, aktu­elle Daten für ad-hoc Abfra­gen direkt zur Ver­fü­gung zu haben und ältere Zeit­rei­hen­da­ten, auf die auch nur sel­te­ner zuge­grif­fen wer­den, kos­ten­güns­tig abzulegen. 

Die Ana­ly­se­funk­tio­nen des Ser­vices bie­ten viele zeit­rei­hen­spe­zi­fi­sche Funk­tio­na­li­tä­ten, mit denen es mög­lich ist, aktu­elle Trends und Mus­ter in den Daten zu iden­ti­fi­zie­ren. Wei­ter­hin lässt sich Timestream leicht in bereits bestehende Machine Lear­ning Struk­tu­ren inte­grie­ren und zusam­men mit bereits eta­blier­ten Ser­vices wie Kine­sis oder Sage­Ma­ker nutzen.

Cloud-Com­pu­ting 

EC2 – Serial Console

Eine der Haupt­auf­ga­ben im Bereich der Sys­tem- und Netz­werk­ad­mi­nis­tra­tion ist das Behe­ben von Feh­lern auf pro­duk­ti­ven Sys­te­men. Durch die stei­gende Kom­ple­xi­tät die­ser Sys­teme ist diese Auf­gabe, trotz der Nut­zung von Kon­struk­ten wie Infra­struc­ture as Code, noch anspruchs­vol­ler gewor­den. Um das Trou­ble­shoo­ting von Boot und Netz­werk-Pro­ble­men zu erleich­tern, hat AWS nun die EC2 Serial Con­sole ent­wi­ckelt, wel­che einen text­ba­sier­ten Zugriff auf eine Instanz ermög­licht und so die Feh­ler­su­che erleich­tert. Die Nut­zung die­ser Kon­sole bie­tet sich beson­ders in Fäl­len an, in denen es nicht mög­lich ist, eine nor­male Ver­bin­dung über SSH oder RDP zu der jewei­li­gen Instanz aufzubauen 

Die Serial Con­sole ist ver­füg­bar für alle EC2-Instan­zen, die auf dem AWS Nitro Sys­tem basie­ren und unter­stützt alle grö­ße­ren Linux Dis­tri­bu­tio­nen, Free­BSD, Net­BSD, Win­dows und VMWare.

Mai 2021

Im Mai die­ses Jah­res ste­hen die Ver­än­de­run­gen in der AWS Cloud im Zei­chen von Strea­ming, Machine-Lear­ning und Con­tai­ne­ri­sie­rung, um die sich abzeich­nen­den Trend der Bran­che auch wei­ter­hin bedie­nen zu kön­nen. Die­ser Blog­bei­trag stellt einen Aus­schnitt aus den Neue­run­gen und Ankün­di­gun­gen des Monats April 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 im Versicherungs‑, Finanz- und Retail­sek­tor 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 App Run­ner, AWS Kine­sis Data Ana­ly­tics Stu­dio sowie AWS Reds­hift ML vorgestellt. 

Strea­ming 

Ama­zon Kine­sis Data Ana­ly­tics Studio 

Für das Strea­ming von Daten in Echt­zeit und Batch­weise bie­tet AWS die Ser­vices AWS MSK und Ama­zon Kine­sis an. Im Mai ist nun zu letz­te­rem eine Erwei­te­rung hin­zu­ge­kom­men: Ama­zon Kine­sis Data Ana­ly­tics Studio. 

Mit die­sem Ser­vice möchte Ama­zon die Ver­ar­bei­tung und Ana­lyse von Strea­ming Data noch wei­ter ver­ein­fa­chen und erlaubt so die direkte Inter­ak­tion mit den Daten unter der Ver­wen­dung von SQL, Python oder Scala. Hier­für kön­nen Note­books inner­halb der AWS Kon­sole erstellt und an eine Daten­quelle ange­bun­den wer­den. Die Note­books ver­wen­den die Tech­no­lo­gien von Apa­che Zep­pe­lin und Apa­che Flink, um eine inter­ak­tive Ana­lyse der Strea­ming Data zu ermög­li­chen. Daten­quel­len kön­nen bei­spiels­weise Ama­zon Kine­sis oder auch AWS MSK sein, wobei für Letz­te­res auch seit neu­es­tem die Kafka Ver­sio­nen 2.8.0, 2.7.1 und 2.6.2 und die IAM Access Con­trol ver­füg­bar sind. Die Meta­da­ten der jewei­li­gen Sources und Desti­na­ti­ons kön­nen in einer AWS Glue Data­base ange­legt und mit­tels des AWS Glue Data Cata­logs abge­ru­fen werden. 

Der Preis des Ser­vices errech­net sich – neben den Kos­ten, die für Sto­rage und Net­wor­king der Daten anfal­len – aus der durch­schnitt­li­chen Anzahl der Kine­sis Pro­ces­sing Units (KPU) pro Stunde, wobei eine KPU 1vCPU und 4GB RAM beinhaltet. 

Neue APIs in Ama­zon Kine­sis Data Ana­ly­tics for Apa­che Flink

Eine wei­tere Neu­ig­keit aus dem Bereich Strea­ming und AWS Kine­sis betrifft die Ver­füg­bar­keit drei neuer APIs zur Anwen­dungs­ver­wal­tung in Ama­zon Kine­sis Data Ana­ly­tics for Apa­che Flink: Mit der Roll­back­Ap­pli­ca­tion kön­nen nun Anwen­dun­gen auf die letzte funk­tio­nie­rende Ver­sion zurück­ge­setzt und der Anwen­dungs­sta­tus aus einem Snapshot wie­der­her­ge­stellt wer­den. Mit der List­Ap­pli­ca­ti­on­Ver­sion-API kön­nen nun alle Anwen­dungs­ver­sio­nen sowie eine Zusam­men­fas­sung der dazu­ge­hö­ri­gen Kon­fi­gu­ra­tio­nen abge­ru­fen wer­den und mit der Descri­be­Ap­pli­ca­ti­on­Ver­sion kann die Kon­fi­gu­ra­tion einer bestimm­ten Ver­sion auf­ge­ru­fen werden. 

Machine Lear­ning 

AWS Reds­hift

Eine der inter­es­san­tes­ten Ände­run­gen im Bereich Machine Lear­ning betrifft Ama­zon Reds­hift – etwas genauer gesagt Ama­zon Reds­hift ML. 

Als Cloud Data Ware­house ermög­licht es Reds­hift eine nahezu belie­big große Menge an struk­tu­rier­ten und semi-struk­tu­rier­ten Daten mit­tels SQL-Befeh­len abzu­fra­gen und zu kom­bi­nie­ren und mit der Ein­füh­rung von AQUA im letz­ten Monat ist dies sogar noch bedeu­tend schnel­ler mög­lich als zuvor. AWS geht die­sen Monat noch einen Schritt wei­ter und ver­öf­fent­lich Ama­zon Reds­hift ML. Mit die­ser Erwei­te­rung ist es nun mög­lich, Machine Lear­ning Modelle inner­halb der Struk­tu­ren von Reds­hift mit­tels simp­len SQL zu entwickeln. 

Mit der Query wer­den sowohl die Daten ange­ge­ben, mit wel­chen das Model trai­niert wer­den soll, als auch ein Out­put-Value defi­niert. Zur Ver­an­schau­li­chung der Funk­ti­ons­weise hier ein Bei­spiel aus dem Retail-Sek­tor: Ange­nom­men es soll ein Modell ent­wi­ckelt wer­den, mit wel­chem vor­her­ge­sagt wer­den kann, ob ein Kunde in nähe­rer Zukunft sei­nen Ver­trag kün­di­gen möchte. Für ein sol­ches Pro­jekt war es bis­her not­wen­dig, die Daten aus Reds­hift in den S3 Sto­rage zu expor­tie­ren, um von dort aus zum Bei­spiel mit Sage­Ma­ker einen Machine Lear­ning Pro­zess auf­zu­set­zen. Nun ist es so, dass ein­fach die Spal­ten aus der Daten­bank mit den not­wen­di­gen Kun­den­da­ten mit­tels SQL-Query abge­fragt und ver­wen­det wer­den können. 

Betrach­tet man die­sen neuen Ser­vice etwas detail­lier­ter, so sieht man, dass der frü­her manu­elle Kopier­schritt der Daten in den S3 Bucket nun auto­ma­tisch geschieht. In der Tat ist es so, dass nach der Erstel­lung eines Modells die aus­ge­wähl­ten Daten auto­ma­tisch aus Reds­hift her­aus in einen S3-Bucket über­tra­gen und dort mit­tels Ama­zon Sage­Ma­ker Auto­pi­lot vor­be­rei­tet und ver­ar­bei­tet wer­den. Nach­dem das Modell erstellt und trai­niert wor­den ist, wird es anschlie­ßend von Reds­hift ML unter Ver­wen­dung von Ama­zon Sage­Ma­ker Neo opti­miert und schluss­end­lich als SQL-Funk­tion zur Ver­fü­gung gestellt. 

Mit Reds­hift ML ist es aller­dings nicht nur mög­lich, neue Modelle zu erstel­len, son­dern auch bereits bestehende Modelle und End­punkte aus Sage­Ma­ker zu impor­tie­ren und zu ver­wen­den. Ver­füg­bar ist der Ser­vice in nahezu allen grö­ße­ren AWS Regio­nen, inklu­sive Frankfurt. 

Wei­te­res aus dem Bereich Machine Learning 

Auch andere Ser­vices in die­sem Seg­ment haben einige Ver­bes­se­run­gen erfah­ren – so zum Bei­spiel Ama­zon Recognition. 

Ama­zon Reco­gni­tion ist ein Machine Lear­ning gestütz­ter Ser­vice zur Erken­nung von Objek­ten, Kon­struk­tio­nen, Per­so­nen, Gesich­ter oder Text in Bild- und Video­da­teien. Für Letz­te­res gab es nun ein Update sei­tens Ama­zons: Ama­zon Reco­gni­tion kann nun, mit einer höhe­ren Prä­zi­sion und einer um bis zu 70% ver­rin­ger­ten Latenz, Texte erken­nen, die bis zu 100 Wör­ter lang sind. 

Eine wei­tere Neu­ig­keit aus dem Bereich Machine Lear­ning betrifft Ama­zon Fore­cast. Mit Ama­zon Fore­cast kön­nen Bedarfs­pro­gno­sen ohne vor­he­rige Machine Lear­ning Erfah­run­gen erstellt wer­den.  Auf­grund der frü­he­ren Limi­tie­rung der Crea­te­Pre­dic­tor API waren Kun­den aller­dings dar­auf beschränkt, Pro­gno­sen für maxi­mal eine Mil­lio­nen Ein­zel­ar­ti­kel erstel­len zu kön­nen. Dies hatte zur Folge, dass Kun­den, die mehr als eine Mil­lio­nen Ein­zel­ar­ti­kel hat­ten, sich ent­we­der auf eine Teil­menge ihrer Arti­kel beschrän­ken oder sepa­rate Modelle für aus­ge­wählte Kate­go­rien oder eine ähn­li­che Grup­pie­rung erstel­len muss­ten. Die oben ange­spro­che­nen Limi­tie­run­gen der Crea­te­Pre­dic­tor API sind nun aller­dings auf­ge­ho­ben bezie­hungs­weise erhöht wor­den, sodass Pro­gno­sen statt für eine Mil­lion Arti­kel für fünf Mil­lio­nen erstellt wer­den können. 

Cloud-Com­pu­ting  

Lambda Exten­si­ons

Bereits im Okto­ber des ver­gan­ge­nen Jah­res hat AWS Erwei­te­run­gen für AWS Lambda vor­ge­stellt, um eine ein­fa­che Inte­gra­tion von Lambda Funk­tio­nen in bestehende Monitoring‑, Obser­va­bi­lity- und Secu­rity-Tools zu ermög­li­chen. Diese Erwei­te­run­gen sind nun im Mai ver­öf­fent­licht wor­den und nut­zen die Run­time Exten­si­ons API von AWS Lambda, wodurch sie mit dem vol­len Lebens­zy­klus einer Lambda-Funk­tion ver­knüpft sind. Dies legt auch bereits einige Anwen­dungs­mög­lich­kei­ten der Exten­si­ons offen, wie zum Bei­spiel das Sam­meln von dia­gnos­ti­schen Infor­ma­tio­nen eines Sys­tems vor, wäh­rend und nach dem Auf­ru­fen einer Funk­tion oder dem Sen­den eines Logs an einen belie­bi­gen Ziel­ort – wie AWS S3, Kine­sis oder Ela­s­tic­se­arch – über die AWS Run­time Logs API. Da die Erwei­te­run­gen sich die Com­pute-Res­sour­cen mit der eigent­li­chen Lambda Funk­tion tei­len, kann die Ver­wen­dung im All­ge­meine aller­dings zu einer Ver­schlech­te­rung der Per­for­mance führen. 

Die Lambda Exten­si­ons sind bis­her in Europa nur in den Regio­nen Irland und Mai­land ver­füg­bar, sol­len aber auch dem­nächst in Frank­furt nutz­bar sein und besit­zen das­selbe Kos­ten­mo­dell, wie AWS Lambda selbst, d.h. es ent­ste­hen auch hier Kos­ten in Abhän­gig­keit zur Lauf­zeit der Funktion. 

Con­tai­ner 

AWS App Runner 

Die Con­tai­ne­ri­sie­rung von Appli­ka­tio­nen bringt viele Vor­teile mit sich, wie zum Bei­spiel eine effi­zi­en­tere Nut­zung von Res­sour­cen und ein höhe­res Maß an Por­ta­bi­li­tät von Anwen­dun­gen. Ins­be­son­dere in moder­nen Cloud-Archi­tek­tu­ren, in denen ver­mehrt auf Micro­ser­vices gesetzt wird, sind con­tai­ne­ri­sierte Anwen­dun­gen oft­mals ver­tre­ten und kaum zu ersetzen. 

Mit AWS App Run­ner steht nun auch ein wei­te­rer Con­tai­ner-Anwen­dungs­ser­vice in der AWS Cloud bereit. Es han­delt sich hier­bei um einen fully mana­ged Ser­vice, der es ins­be­son­dere Kun­den ohne Con­tai­ner­er­fah­run­gen ermög­li­chen soll, Web­an­wen­dun­gen und APIs in con­tai­ne­ri­sier­ter Form zu erstel­len, bereit­zu­stel­len und aus­zu­füh­ren. Es genügt hier­bei, dem Ser­vice den jewei­li­gen Quell­code oder das Image eines Con­tai­ners zur Ver­fü­gung zu stel­len. AWS App Run­ner erstellt dann auto­ma­tisch eine Web­an­wen­dun­gen und stellt diese inklu­sive Load Balan­cing, Ska­lie­rung und Moni­to­ring des Sys­tems bereit und eli­mi­niert so für Kun­den die Not­wen­dig­keit, selbst einen Con­tai­ner­or­ches­trie­rungs­ser­vice zu ver­wal­ten. Durch diese Funk­tio­na­li­tät kann App Run­ner eine Alter­na­tive zu Archi­tek­tu­ren, wel­che den Ela­s­tic Con­tai­ner Ser­vice von Ama­zon nut­zen, dar­stel­len. Unter­stützt wird AWS App Run­ner auch bereits von der neu­es­ten Ver­sion von AWS Copi­lot sowie von dem Ser­vice AWS App2Container, wel­cher es erlaubt, .NET und Java-Anwen­dun­gen in eine con­tai­ne­ri­sierte Anwen­dung zu konvertieren. 

Juni 2021

Viele Ände­run­gen des Monats Junis sind beson­ders für Ent­wick­ler in der AWS inter­es­sant. Die­ser Blog­bei­trag stellt einen Aus­schnitt aus den Neue­run­gen und Ankün­di­gun­gen des Monats Juni 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 EMR, Ama­zon Athena, AWS Sage­Ma­ker Data Wrang­ler sowie AWS Code­Guru und Ama­zon DevOps Moni­to­ring vorgestellt. 

Com­pute

Ama­zon EMR on EKS

Wäh­rend der ver­gan­ge­nen re:Invent hat AWS bereits die Ver­füg­bar­keit von Ama­zon EMR auf Ama­zon Ela­s­tic Kuber­netes Ser­vice (EKS) ange­kün­digt und bie­tet so die Mög­lich­keit, zur auto­ma­ti­schen Bereit­stel­lung von Apa­che Spark auf Ama­zon EKS. Die Ver­füg­bar­keit von Apa­che Spark auf Kuber­netes inner­halb der AWS Cloud bie­tet die Mög­lich­keit zur ein­fa­chen Migra­tion bereits bestehen­der Spark-Anwen­dun­gen, die auf Kuber­netes basie­ren, in die AWS bezie­hungs­weise auf ein EKS-Clus­ter in wel­chem bereits andere Appli­ka­tio­nen lie­gen, um dort von den geteil­ten Res­sour­cen zu pro­fi­tie­ren und die Infrastruktur zu ver­ein­fa­chen. Des Wei­te­ren bie­tet eine sol­che Migra­tion die Mög­lich­keit, die Appli­ka­tio­nen in Ama­zon EMR Stu­dio oder AWS Step Func­tions, wel­che im Laufe des Arti­kels noch ein­mal auf­ge­grif­fen wer­den, zu integrieren. 

Bei der Über­tra­gung eines Jobs wird die Appli­ka­tion auto­ma­tisch von EMR in einen Con­tai­ner ver­packt und auf einem EKS Clus­ter bereit­ge­stellt und aus­ge­führt. Bis­her war es so, dass Abhän­gig­kei­ten wäh­ren der Über­tra­gung des Jobs auto­ma­tisch hin­zu­ge­fügt wur­den. Dies ändert sich jetzt und es ist nun mög­lich, auch per­so­na­li­sierte Images mit Ama­zon EMR auf EKS zu ver­wen­den, d.h. es kön­nen Images erstellt wer­den, die sowohl die tat­säch­li­che Appli­ka­tion als auch deren Abhän­gig­kei­ten bereits beinhal­ten. Durch diese Ände­rung kann die Erstel­lung eines Images in den Con­ti­nuous Inte­gra­tion Pro­zess inte­griert wer­den. Data Engi­neers kön­nen so bei­spiels­weise ein Basis-Image bereit­stelle, Biblio­the­ken hin­zu­fü­gen und das Image dann im Ela­s­tic Con­tai­ner Regis­try (ECR) von AWS zur Ver­fü­gung stel­len. Nut­zer, wie bei­spiels­weise Data Sci­en­tis­ten, könne auf die­ses Image dann zurück­grei­fen, die not­wen­di­gen Abhän­gig­kei­ten für die jewei­lige Appli­ka­tion mit­tels Docker­file hin­zu­fü­gen und Spark Jobs unter Ver­wen­dung des per­so­na­li­sier­ten Images ausführen. 

Ama­zon EC2

Zum 11.06.2021 hat AWS die Abrech­nung für Win­dows-Ser­ver sowie SQL-Ser­ver-Instan­zen abge­än­dert. Alle Instan­zen die­ser Art, die als On-Demand‑, Reser­ved- oder Spot-Ins­tance erstellt wur­den, wer­den nun, so wie es bereits für die Linux- und Ubuntu-Instan­zen seit län­ge­rem der Fall ist, sekünd­lich abge­rech­net mit einem mini­ma­len Abrech­nungs­in­ter­vall von einer Minute. Die neue Art der Abrech­nung ist sowohl für neue als auch bereits bestehende Instan­zen verfügbar. 

Machine Lear­ning 

Ama­zon Athena

Im laufe des Monats Juni hat Ama­zon die all­ge­meine Ver­füg­bar­keit der zwei­ten Ver­sion der Ama­zon Athena Engine für alle kom­mer­zi­el­len AWS Regio­nen bekannt gege­ben, in denen zuvor auch die Ver­sion 1 ver­füg­bar war. 

Ama­zon Athena ist ein inter­ak­ti­ver Abfra­ge­ser­vices, wel­cher die Ana­lyse von Daten, die in einem S3-Bucket lie­gen, erlaubt. Dies erlaubt es bei­spiels­weise, erste Explo­ra­tion der vor­han­de­nen Daten­sätze mit­tels SQL-Abfrage durch­zu­füh­ren, bevor diese in ein Data Ware­house wie Snow­flake oder Reds­hift gela­den wer­den. Zu den neuen Funk­tio­nen der Ver­sion 2 zäh­len unter ande­rem die soge­nann­ten „Fede­ra­ted Queries“, wel­che es unter Ver­wen­dung zusätz­li­cher Kon­nek­to­ren erlaubt, wei­tere Daten­quel­len abzu­fra­gen – unab­hän­gig davon, ob diese in der Cloud oder on-premises liegt. Wei­ter­hin ist es nun mög­lich UDFs zu hin­ter­le­gen, um so zum Bei­spiel Daten dyna­misch zu mas­kie­ren und dadurch sen­si­ble Daten vor unau­to­ri­sier­ten Zugrif­fen zu sichern oder wei­tere AWS Ser­vices in die Abfrage zu inte­grie­ren, wie bei­spiels­weise AWS Trans­late, um Daten zu übersetzen. 

Neben den hin­zu­ge­kom­me­nen Funk­tio­nen, sind auch die Abfra­ge­funk­tio­na­li­tä­ten von AWS Athena ver­bes­sert wor­den. Unter ande­rem wurde das Grup­pie­ren von Daten ver­bes­sert und somit Abfra­ge­zei­ten redu­ziert, sowie die Ein­füh­rung von Cross Joins vor­ge­nom­men. Eine voll­stän­dige Liste aller Ver­bes­se­run­gen fin­den Sie hier.  

Sage­Ma­ker Data Wrangler

Für Machine Lear­ning ist die Aufbereitung und Zusam­men­füh­rung von Daten eine not­wen­dige Vor­ar­beit, die in der AWS mit dem Ser­vice Sage­Ma­ker Data Wrang­ler für unter­schied­lichste Daten­quel­len bereits aus­ge­führt wer­den kann. Seit ver­gan­ge­nem Monat ist dies nun auch in Kom­bi­na­tion mit dem Cloud Data Ware­house Snow­flake mög­lich, d.h. die Daten kön­nen nun über Sage­Ma­ker Data Wrang­ler auf­be­rei­tet und bei­spiels­weise mit Daten aus S3 oder Reds­hift ange­rei­chert wer­den. Wei­ter­hin kön­nen vor­ge­fer­tigte Trans­for­ma­tio­nen über den Ser­vice auf den Daten aus­ge­führt wer­den und mit­tels der Visua­li­sie­rungs­mög­lich­kei­ten von Sage­Ma­ker Data Wrang­ler Daten­sätze auf Extrema und poten­zi­elle Feh­ler­quel­len unter­sucht werden. 

ETL und Streaming

AWS Glue Studio

Für das AWS eigene ETL-Tool mit gra­fi­scher Ober­flä­che sind im Juni zwei inter­es­sante Ände­run­gen vor­ge­stellt wor­den. Diese sind die Ver­füg­bar­keit eines Code-Edi­tors, sowie die Mög­lich­keit, Ein­stel­lun­gen für Strea­ming-Jobs inner­halb des visu­el­len Inter­faces fest­zu­le­gen. Bei den Ein­stel­lun­gen für die Strea­ming-Jobs ist es nun mög­lich, Eigen­schaf­ten wie die Fens­ter­größe, Sche­maer­ken­nung sowie Ver­bin­dungs­ein­stel­lun­gen manu­ell über die Ober­flä­che des Ser­vices festzulegen. 

Der neu ein­ge­führte Code-Edi­tor erlaubt es, die aus den im gra­fi­schen Inter­face gene­rier­ten ETL-Codes inner­halb des Stu­dios manu­ell zu bear­bei­ten und erleich­tert somit das Edi­tie­ren von Jobs. Zuvor war es not­wen­dig, die Dateien zunächst auf das lokale Sys­tem her­un­ter­zu­la­den und dort dann zu verändern. 

AWS Step Func­tions Work­flow Studio

AWS Step Func­tions ist einer der Schlüs­sel-Ser­vices, um Work­flows in der AWS zu erstel­len und so zum Bei­spiel die Aus­füh­rung von ser­ver­less Ser­vices wie AWS Lambda zu orches­trie­ren. Zur Erstel­lung eines sol­chen Work­flows, musste bis­her eine JSON-Datei unter Ver­wen­dung der Ama­zon State Lan­guage erstellt wer­den, in wel­cher die Rei­hen­folge sowie die Eigen­schaf­ten der ein­zel­nen Schritte defi­niert wer­den musste. 

Zur Ver­ein­fa­chung der Erstel­lung sol­cher Work­flows hat AWS nun das Work­flow Stu­dio ver­öf­fent­licht, in wel­chem inner­halb einer gra­fi­schen Ober­flä­che, unter Anlei­tung von Ama­zon, Work­flows erstellt wer­den kön­nen. Durch die Ein­füh­rung einer gra­fi­schen Ober­flä­che zur Erstel­lung der Step Func­tions wird nun neuen Nut­zern die Not­wen­dig­keit abge­nom­men, die Ama­zon State Lan­guage zu ler­nen, und im All­ge­mei­nen kön­nen Nut­zer nun Work­flows schnel­ler erstellen. 

Deve­lo­p­ment

AWS Code­Guru

Durch die Auto­ma­ti­sie­rung von Pro­zes­sen und die Migra­tion von Archi­tek­tu­ren in die Cloud, ist die Anzahl an Code­zei­len inner­halb von Unter­neh­men rapide gestie­gen. Allein durch die schiere Masse an Code­zei­len ist deren Review ein kom­ple­xes und zeit­auf­wän­di­ges Unter­fan­gen, wel­ches aber unum­gäng­lich und not­wen­dig ist. 

Ama­zon Code­Guru bie­tet auto­ma­ti­sche Code Reviews an und unter­stützt Java sowie Python Ent­wick­ler, die Qua­li­tät ihres Codes zu erhö­hen oder hoch­zu­hal­ten. Nun ist es mög­lich eine sol­che auto­ma­ti­sche Code Review inner­halb des nor­ma­len CI/CD-Vor­gangs mit­tels Git­Hub Actions zu integrieren. 

 Als Ent­wick­ler ist es üblich, jeden Tag neuen Code zu pushen und zu pul­len und Sicher­heits­lü­cken und Bugs soll­ten mög­lichst früh erkannt und aus­ge­bes­sert wer­den, um spä­tere Nach­ar­bei­ten zu mini­mie­ren. Code­Guru unter­stützt bei die­ser zumeist anspruchs­vol­len Auf­gabe und gibt Ver­bes­se­rungs­vor­schläge wäh­rend jeder Pull-Request als Kom­men­tar und wäh­rend jedes Pushes als Anmer­kung im Secu­rity Bereich von Git­Hub aus. Zudem wurde zur wei­te­ren Ver­bes­se­rung des Ser­vices neue Java Detek­to­ren ein­ge­führt, die den Ser­vice hin­sicht­lich sei­ner Funk­tio­na­li­tä­ten zur Auf­de­ckung von Sicher­heits­lü­cken wei­ter verbessert. 

AWS DevOps Monitoring

Ein wich­ti­ger Teil im Bereich des DevOps ist das Moni­to­ring der Lösung und des Pro­zes­ses. Um das Moni­to­ring des Ent­wick­lungs­pro­zes­ses zu ver­ein­fa­chen und Akti­vi­tä­ten zu mes­sen, hat Ama­zon AWS DevOps Moni­to­ring entwickelt. 

Bei der Ent­wick­lung mit AWS Tools erstellt jeder Ent­wick­ler eige­nen Metri­ken, wel­che AWS DevOps Moni­to­ring sam­melt, ana­ly­siert und in einem zen­tra­len Dash­board visua­li­siert, sodass Infor­ma­tio­nen wie die Change-Fail­ure-Rate oder die Deploy­ment-Fre­quency schnell ein­seh­bar sind. Mit der neuen Ver­sion wer­den nun auch die Ser­vices AWS Code­Build sowie AWS Code­Pipe­line unter­stützt, sodass nun auch die Anzahl an aus­ge­lös­ten Builds, sowie Aus­füh­rungs­dauer und ‑häu­fig­kei­ten über­wacht und visua­li­siert wer­den können. 

Sto­rage

Ama­zon FSx for Win­dows File Server

Der Ser­vice Ama­zon FSx for Win­dows File Ser­ver ist ein fully mana­ged Objekt­da­ten­spei­cher, wel­cher über das Ser­ver-Mes­sage-Block-Pro­to­koll abge­fragt wer­den kann und auf Win­dows Ser­ver auf­setzt. Zu den bis­her ver­füg­ba­ren Fea­tures, wie bei­spiels­weise der Mög­lich­keit, Dateien durch End­nut­zer wie­der­her­zu­stel­len oder der Inte­gra­tion in Micro­softs Active Direc­tory, ist nun auch das Audi­ting von Zugrif­fen von End­nut­zern auf Dateien, Ord­ner und Shares mit­tels der Win­dows Event­logs hinzugekommen. 

Die mit­tels File Access Audi­ting erstell­ten Logs kön­nen dann an einen AWS Ser­vice über­ge­ben und wei­ter­ver­ar­bei­tet oder gespei­chert wer­den. So kön­nen diese Logs bei­spiels­weise mit den Ama­zon Cloud­Watch Logs kom­bi­niert wer­den, um ein zen­tra­les Moni­to­ring und Audi­ting zu ermög­li­chen.  Des Wei­te­ren birgt dies die Mög­lich­keit, die Logs aus Cloud­Watch Logs zu expor­tie­ren und in S3 zur wei­te­ren Nut­zung zu spei­chern oder mit­tels Lambda Funk­tion auf bestimmte Events agil zu reagie­ren, um so bei­spiels­weise in real-time auf unau­to­ri­sierte Zugriffe hinzuweisen. 

Das File Access Audi­ting steht kos­ten­frei bei der Ver­wen­dung von Ama­zon FSx for Win­dows File Ser­ver zur Ver­fü­gung und kann von allen neuen File­sys­teme genutzt werden. 

Ama­zon Dyna­moDB Accelerator

Ama­zon Dyn­a­noDB Acce­le­ra­tor ist ein fully mana­ged in-memory Cache zur Ver­bes­se­rung der Per­for­mance von Ama­zon Dyna­moDB und die Abfra­ge­zei­ten dras­tisch redu­zie­ren kann. Seit Juni ist es nun mög­lich, Daten wäh­rend ihrer Über­tra­gung von einer Anwen­dung zu Dyna­moDB Acce­le­ra­tor sowie zwi­schen den Kno­ten des Acce­le­ra­tors zu ver­schlüs­seln und somit die Sicher­heit der Daten in-tran­sit zu erhö­hen. Die Ver­schlüss­lung erfolgt mit­tels Trans­port Layer Secu­rity (TLS) und Ver­bin­dun­gen zum Clus­ter wer­den mit­tels Zer­ti­fi­kats authentifiziert. 

Die Ver­schlüs­se­lung kann ent­we­der in der Dyna­moDB-Kon­sole, über die CLI, SDK oder Cloud­For­ma­tion akti­viert wer­den und ist in Europa in Frank­furt, Irland, Lon­don und Paris 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.