Auch in die­sem Monat erfreut Ama­zon die Nut­zer sei­ner Cloud wie­der mit zahl­rei­chen Neue­run­gen und Ver­bes­se­run­gen bestehen­der Ser­vices. Die­ser Blog­bei­trag stellt einen kura­tier­ten Aus­schnitt aus den AWS Ankün­di­gun­gen des Monats Juli dar, erhebt aber nicht den Anspruch auf Voll­stän­dig­keit. Das Haupt­au­gen­merk die­ser Liste liegt auf Ver­än­de­run­gen bei denen wir von direk­tem Ein­fluss auf Kun­den im Versicherungs‑, Finanz- und Retail­be­reich aus­ge­hen. Die größ­ten Neu­ig­kei­ten die­ses Monats beinhal­te­ten einige Ver­bes­se­run­gen und Erwei­te­run­gen von AWS Data­Sync und dem Ela­s­tic File Sys­tem (EFS), der Ankün­di­gung des App2Container Ser­vices, der Ein­füh­rung von Mana­ged Sca­ling für Ama­zon EMR, sowie einem Update des Well Archi­tec­ted Frameworks.

AWS Data­Sync

Mit dem AWS Data­Sync stellt Ama­zon seit 2018 einen leis­tungs­star­ken Mana­ged Data Trans­fer & Migra­tion Ser­vice zur Ver­fü­gung. Data­Sync ermög­licht es Daten von der Cloud und in die Cloud, sowie zwi­schen Spei­cher­me­dien inner­halb der Cloud schnell und sicher zu trans­fe­rie­ren. Der dazu not­wen­dige Agent, bis­lang ledig­lich als VMware und auf EC2 anwend­bar, kann seit die­sem Monat auch auf Linux Ker­nel-based Vir­tual Machine (KVM) und Micro­soft Hyper‑V Hyper­vi­sors lau­fen. Wei­ter­hin wurde Data­Sync die Option hin­zu­ge­fügt auto­ma­tisch Ama­zon Cloud­Watch Logs zu kon­fi­gu­rie­ren, indem eine eigene Cloud­Watch Log­gruppe und die not­wen­dige Policy für das Ver­öf­fent­li­chen der Trans­fer­logs in die Log­gruppe von Data­Sync erstellt wird. Zu guter Letzt wurde die Option hin­zu­ge­fügt auch on-premises Objekt­spei­cher via Data­Sync an S3 anzu­bin­den. Mehr Infor­ma­tio­nen zu AWS Data­Sync gibt es hier.

Ama­zon Ela­s­tic File Sys­tem (EFS)

Auch das Ela­s­tic File Sys­tem, das voll­stän­dig ver­wal­tete elas­ti­sche NFS File­sys­tem der AWS Cloud, erhielt in die­sem Monat eine Viel­zahl von klei­ne­ren Ver­bes­se­run­gen um Kun­den von ver­bes­ser­ter Leis­tung, ein­fa­che­rem Hand­ling und dadurch sin­ken­den Kos­ten pro­fi­tie­ren zu las­sen. Dazu wurde das unter­stützte Daten­durch­satz­li­mit von 250 MB/s um 100% gestei­gert auf bis zu 500 MB/s pro Cli­ent (wobei der Gesamt­durch­satz des EFS File­sys­tems bei 10+ GB/s über alle NFS Cli­ents ver­bleibt). Um von dem erhöh­ten Durch­satz zu pro­fi­tie­ren ist kein wei­te­res Zutun erfor­der­lich. Wei­ter­hin wer­den ab sofort alle EFS File­sys­tems, wel­che über die AWS Manage­ment Kon­sole erstellt wer­den, durch eine ein­fa­che Check­box für auto­ma­ti­schen Backup via AWS Backup kon­fi­gu­riert. Für User der SDK oder CLI Funk­tio­na­li­tät wurde ein ein­fa­cher API Call ergänzt. Die Funk­tio­na­li­tät kann selbst­ver­ständ­lich auch bei exis­tie­ren­den File­sys­tems jeder­zeit an- und abge­schal­tet wer­den. Zu guter Letzt wurde die Ama­zon EFS Kon­sole ver­bes­sert, um die Ver­wal­tung und Erstel­lung von EFS Volu­mes wei­ter zu ver­ein­fa­chen. Dies beinhal­tet unter ande­rem Cus­to­mizable UI Views, sowie die Mög­lich­keit Cloud­Watch Metri­ken für die erstell­ten File­sys­tems nativ in der EFS Kon­sole anzuzeigen.

Nähere Infor­ma­tio­nen zu EFS fin­den sich hier. Die Neue EFS Kon­sole wird in die­sem Blog­bei­trag thematisiert.

AWS App2Container

Mit AWS App2Container kün­digte Ama­zon die­sen Monat ein ein­fa­ches Kom­man­do­zei­len Tool an, um bestehende .NET und Java Anwen­dun­gen in con­tai­ne­ri­sierte Anwen­dun­gen zu über­füh­ren. A2C inven­ta­ri­siert alle Anwen­dun­gen auf einem Sys­tem wel­che in vir­tu­el­len Run­time Envi­ron­ments lau­fen. Anschlie­ßend wer­den Arte­fakte und Abhän­gig­kei­ten von aus­ge­wähl­ten Anwen­dun­gen in Con­tai­ner Images ver­packt, kon­fi­gu­riert und ent­spre­chende ECS Tasks erstellt. Mit­tels Cloud­for­ma­tion wird nun die not­wen­dige Infrastruktur, inklu­sive CI/CD Pipe­line, erstellt die not­wen­dig ist um die Anwen­dun­gen in der Cloud zu deployen.

Nähere Infor­ma­tio­nen zu dem Dienst fin­den sich auf der App2Container Seite.

Ama­zon EMR Mana­ged Scaling

Ama­zon Ela­s­tic Map­Re­duce ist der Mana­ged Hadoop Clus­ter Ser­vice von Ama­zon, der es Kun­den ermög­licht rie­sige Daten­men­gen mit Open Source Tools wie Apa­che Spark, Hive, HBase, Flink, Hudi and Presto zu ver­ar­bei­ten. Bis­lang musste eine Res­ka­lie­rung eines bestehen­den Clus­ters auf der Basis von EMR Auto­ma­tic Sca­ling durch­ge­führt wer­den. Die dazu not­wen­di­gen Ska­lie­rungs­re­geln, basie­rend auf Cloud­Watch Metri­ken, führ­ten mit­un­ter zu kom­pli­zier­ten und schlecht wart­ba­ren Infra­struk­tu­ren. Mit EMR Mana­ged Sca­ling ent­fällt das Erstel­len von selbst­de­fi­nier­ten Ska­lie­rungs­re­geln. Spot- und On-Demand Ins­tances kön­nen dadurch naht­los ska­liert wer­den, auch inner­halb eines EMR Clus­ters. Der Mana­ged Sca­ling Algo­rith­mus ermög­licht es wei­ter­hin, häu­fi­ger nach der Not­wen­dig­keit für Res­ka­lie­rung zu prü­fen als mit­tels selbst­de­fi­nier­ter Sca­ling Poli­cies. Dadurch wird das auto­ma­ti­sche Sklaie­ren der EMR Res­sour­cen noch prä­zi­ser und kos­ten­güns­ti­ger. Die Funk­tio­na­li­tät steht zunächst für Spark, Hive und YARN Workloads zur Verfügung.

Für wei­tere Infor­ma­tio­nen zu EMR Mana­ged Sca­ling emp­fiehlt sich der fol­gende Blog­bei­trag.

AWS Well Archi­tec­ted Framework

Das AWS Well Archi­tec­ted Frame­work beglei­tet seit 2015 Unter­neh­men bei der Imple­men­tie­rung von Workloads in der Cloud und hilft bei der Erstel­lung von sicheren,

effi­zi­en­ten, kos­ten­güns­ti­gen und per­for­man­ten Archi­tek­tu­ren. Natur­ge­mäß ent­wi­ckelt sich das Frame­work stän­dig wei­ter um die aktu­ells­ten Best Prac­tice Gui­de­lines wie­der­zu­ge­ben. In der neus­ten Ver­sion fin­den sich einige Updates zu Fra­ge­stel­lun­gen, Best Prac­ti­ces und Design Prinzipien.

Im Bereich Cost Opti­miza­tion fin­det sich nun das Design Prin­zip zur Imple­men­tie­rung von “Cloud Finan­cial Manage­ment”. Deses Prin­zip zielt dar­auf ab, dedi­zierte Res­sour­cen zur Ver­wal­tung der Cloud Kos­ten bereit­zu­stel­len, um Kos­ten­ef­fi­zi­enz zu gewährleisten.

Im Bereich Relia­bi­lity befin­det sich nun die Best Prac­tice “Workload Archi­tec­ture” mit dem Ziel die initia­len Design­ent­schei­dun­gen stär­ker an dem vor­lie­gen­den Workload zu ori­en­tie­ren um bei­spiels­weise Aus­fäl­len vor­zu­beu­gen und den Ein­fluss von auf­tre­ten­den Aus­fäl­len so gering wie mög­lich zu halten.

Im Bereich Ope­ra­tio­nal Excel­lence ist die Best Prac­tice “Orga­niza­tion” hin­zu­ge­fügt wor­den mit dem Ziel sämt­li­che Teil­ha­ber eines Workloads von Beginn an in den Design­pro­zess mit­ein­zu­be­zie­hen. Jeder Betei­ligte eines Teams, sowie das Team selbst, soll sei­nen genau defi­nier­ten Auf­ga­ben­be­reich ken­nen, um den ent­ste­hen­den Busi­ness Value zu maximieren.

Für wei­tere Infor­ma­tio­nen zum Well Archi­tec­ted Frame­work emp­fiehlt, sich diese Seite, sowie das Well Archi­tec­ted White­pa­per. Wei­ter­hin bie­tet saracus in regel­mä­ßi­gen Abstän­den kos­ten­lose Online Semi­nare zu ver­schie­de­nen The­men rund um die Cloud an. In die­sem Zusam­men­hang sei unser bevor­ste­hen­des Semi­nar zum Thema Well Archi­tec­ted Reviews her­vor­zu­he­ben, zu dem Sie sich hier anmel­den können.

Für wei­tere monat­li­che Updates zum Thema AWS Cloud, fol­gen Sie unse­rer Prä­senz in den sozia­len Medien, oder direkt unse­rem Blog.