Der Herbst ist ange­bro­chen. Die Tage wer­den kür­zer und das Jahr neigt sich lang­sam, aber sicher dem Ende ent­ge­gen. Trotz des­sen wird Ama­zon nicht müde, wei­tere Neue­run­gen, Ver­bes­se­run­gen und Erwei­te­run­gen zu ent­wi­ckeln und zu publi­zie­ren. Die­ser Blog­bei­trag stellt einen Aus­schnitt aus den 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 die­ser Liste liegt auf Ver­än­de­run­gen, bei denen wir von einem direk­ten 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­ten einige span­nende Erwei­te­rung zu Ama­zon Pri­v­ate­Link, S3, Ama­zon Sage­ma­ker, Ama­zon RDS und AWS SNS, sowie einer kur­zen Zusam­men­fas­sung von Ama­zon Dis­tro for Open­Te­le­me­try, wel­ches sich seit die­sem Monat im Pre­view-Sta­tus befindet.

Ama­zon Simple Sto­rage Ser­vice (S3)

Nach­dem gegen Ende des letz­ten Monats AWS Out­post Kun­den ermög­lich wurde, die API des Simple Sto­rage Ser­vices zu ver­wen­den, um Daten so zu spei­chern und abzu­fra­gen, wie es in jeder nor­ma­len AWS Region mög­lich wäre, wur­den zu Beginn des Monats Okto­ber auch Ände­run­gen zur all­ge­mei­nen Sicher­heit und Access Con­trol dem Simple Sto­rage Ser­vice hinzugefügt.

Bereits vor Jah­ren hat AWS hier­für die IAM-Poli­cies hin­zu­ge­fügt und Nut­zern so die Mög­lich­keit gege­ben, den Zugriff von außer­halb kon­se­quent zu ver­bie­ten. Um diese Sicher­heits­aspekte wei­ter zu erhö­hen, wur­den von AWS nun drei wei­tere Fea­tures ein­ge­führt: Object Owner­ship, Bucket Owner Con­di­tion und Copy API via Access Points.

Object Owner­ship

Sofern geeig­nete Berech­ti­gun­gen gesetzt wur­den, ist es bereits seit län­ge­rer Zeit mög­lich, über meh­rere AWS Accounts hin­weg Dateien in ein und dem­sel­ben S3 Bucket zu laden. Bis dato wur­den sowohl der Besitz als auch die Kon­trolle des Objek­tes dem Account zuge­schrie­ben, der die­ses hin­zu­ge­fügt hat. Diese Form des many-to-one-Uploads kann durch­aus prak­tisch sein, wenn der S3 Bucket als Data Lake für ver­schie­dene Quel­len fun­gie­ren soll, aller­dings bringt es auch den Nach­teil mit sich, dass der Besit­zer des Buckets einen Teil der Kon­trolle abgibt und somit unter Umstän­den nicht in der Lage ist, Objekte mit­tels Bucket Poli­cies zu teilen.

Ein der­ar­ti­ges Sze­na­rio kann mit den neuen Mög­lich­kei­ten zur Object Owner­ship umgan­gen wer­den. Diese gestat­ten es, eine ein­heit­li­che Owner­ship zu erzwin­gen, d.h. es ist mög­lich dem Besit­zer des Buckets den Besitz an jedem Objekt inner­halb des Buckets zuzu­schrei­ben, sodass die­ser frei über die Objekte ver­fü­gen kann.  Um dies zu errei­chen, kann ent­we­der manu­ell dem Put-Befehl die ACL „bucket-owner-full-con­trol“ wäh­rend des Uploads hin­zu­ge­fügt wer­den oder mit­tels Bucket Policy ein auto­ma­ti­sches Hin­zu­fü­gen die­ser ACL erzwun­gen wer­den. Es ist aller­dings zu beach­ten, dass eine Ände­rung der Bucket Policy nicht bereits exis­tie­rende Objekte betrifft, son­dern ledig­lich neu hin­zu­ge­fügte Objekte. Die neuen Mög­lich­kei­ten zur Zuwei­sung der Object Owner­ship wer­den auch bereits von vie­len wei­te­ren AWS Ser­vices unterstützt.

Bucket Owner Condition

Das neue Fea­ture Bucket Owner Con­di­tion erlaubt es, wäh­rend eines Schreib­pro­zes­ses auf einem S3 Bucket den Besit­zer zu veri­fi­zie­ren. Hier­für genügt es dem „expec­ted­Bu­cke­tOw­ner“-Para­me­ter oder dem „x‑amz-expec­ted-bucket-owner“-HTTP-Hea­der die Account ID des ver­meint­li­chen Besit­zers hin­zu­zu­fü­gen. Sollte diese mit der des tat­säch­li­chen Besit­zers über­ein­stim­men, so wird der Schreib­vor­gang ganz nor­mal durch­ge­führt. In dem Fall, dass die IDs nicht über­ein­stim­men, wird der Schreib­vor­gang abge­bro­chen und der Feh­ler­code 403 ausgegeben.

Copy API via Access Points

Die S3 Access Points die­nen der gra­nu­la­ren Kon­trolle über den Zugriff auf Objekte inner­halb eines Buckets. Anstatt eine ein­zige Bucket Policy zu ver­wal­ten, die für jedes ein­zelne Objekt die Zugriff­rechte defi­niert, kön­nen Access Points für jede Appli­ka­tion erstellt und dann mit­tels IAM Poli­cies der Zugriff auf S3 regu­liert wer­den. Hier ist als Neue­rung in die­sem Monat hin­zu­ge­kom­men, dass nun die S3 Access Points mit der Copy­Ob­ject API unter Ver­wen­dung der ARN anstatt des Namens des Buckets benutzt wer­den können.

Ama­zon PrivateLink

Die Ände­run­gen zu Ama­zon Pri­v­ate­Link im Monat Okto­ber bezie­hen sich auf das Zusam­men­spiel mit dem ser­ver­less-com­pute-Ser­vice AWS Lambda. Seit Mitte Okto­ber ist es nun mög­lich, Lambda Funk­tio­nen mit­tels AWS Pri­v­ate­Link von einem VPC oder von einem on-premises-Sys­tem aus auf­zu­ru­fen, ohne dass das öffent­li­che Inter­net hier­für pas­siert wer­den muss.

Die bis­he­rige Archi­tek­tur für ein der­ar­ti­ges Unter­fan­gen beinhal­tete ein Inter­net Gate­way, ein NAT Gate­way oder eine öffent­li­che IP-Adresse. Mit die­ser Neue­rung ent­fal­len diese Not­wen­dig­kei­ten und die Anfrage kann durch das AWS private Net­work direkt zum Ziel gerou­tet wer­den. Dadurch wird nicht nur die Sicher­heit der Anfra­gen erhöht, da die Daten nicht mehr durch das öffent­li­che Inter­net gelei­tet wer­den müs­sen, son­dern es ermög­licht nun auch Usern die Benut­zung von Lambda-Funk­tio­nen, die auf­grund von Sicher­heits­be­stim­mun­gen ihren VPCs den Zugang zum Inter­net ver­weh­ren mussten.

Ama­zon Sagemaker

Ama­zon Sage­ma­ker ist der fully-mana­ged Machine Lear­ning Ser­vice von AWS, wel­cher es erlaubt schnell und ein­fach Modelle zu erstel­len, zu trai­nie­ren und schluss­end­lich auch zu deployen. Kun­den ver­spre­chen sich durch die Ver­wen­dung von Sage­ma­ker unter ande­rem einen Kos­ten­vor­teil gegen­über einer self-mana­ged Machine Lear­ning Infrastruktur. Dies wird bei Sage­ma­ker zum einen dadurch erreicht, dass das zeit­in­ten­sive, und somit auch kost­spie­lige, Ver­wal­ten der Infrastruktur aus­ge­la­gert wird und somit effek­ti­ver an der Lösung von Machine-Lear­ning-Pro­ble­men gear­bei­tet wer­den kann, zum ande­ren über die Preis­po­li­tik. Letz­tere wurde von AWS ver­bes­sert und die Kos­ten für die ml.p2- und ml.p3-GPU-Instanzen gesenkt. Die genauen Ände­run­gen kön­nen der unte­ren Tabelle ent­nom­men werden.

Ama­zon RDS

Auch der Rela­tio­nal Data­base Ser­vice von Ama­zon hat eine Ver­bes­se­rung hin­sicht­lich des Preis-/Leis­tungs­ver­hält­nis­ses erhal­ten. Diese soll im Ver­gleich zur Benut­zung der M5 bzw. R5 Instan­zen-Typen durch die Ver­wen­dung der Graviton2 Pro­zes­so­ren erreicht wer­den. Die neue M6g soll für nor­male Arbeits­vor­gänge ver­wen­det wer­den und die R6g, welch über 100% mehr Memory ver­fügt als ihr M6-Pen­dant, für rechen­in­ten­sive Pro­zesse, wie zum Bei­spiel der Ana­lyse von Big Data.

Ama­zon ver­spricht bei der Ver­wen­dung von Gra­vi­ton2-Instan­zen eine Ver­bes­se­rung der Per­for­mance um bis zu 35% und eine Ver­bes­se­rung des Preis-/Leis­tungs­ver­hält­nis von bis zu 52%. Die Per­for­mance-Ver­bes­se­run­gen sind unter ande­rem auf grö­ßere L1 und L2 Caches pro Kern zurück­zu­füh­ren. Für einen Wech­sel von einer älte­ren RDS Instanz auf eine der neuen Graviton2 Instan­zen ist kein Erstel­len einer neuen Daten­bank nötig. Es genügt die alte Instanz in der Kon­sole zu modifizieren.

In der unte­ren Tabelle kön­nen Details zu eini­gen Kon­fi­gu­ra­tio­nen ein­ge­se­hen werden.

AWS FIFO SNS

Beim Erstel­len einer Infrastruktur in der Cloud ist es unab­ding­bar eine Kom­mu­ni­ka­ti­ons­stre­cke zwi­schen den ein­zel­nen Ser­vices zu ent­wi­ckeln. Diese Kom­mu­ni­ka­tion wird in AWS häu­fig mit der Ver­wen­dung von AWS SNS in Ver­bin­dung mit AWS SQS gelöst.

 AWS Simple Queue Ser­vice (SQS) ist ein fully mana­ged Mes­sage-Queue Ser­vice. SQS spei­chert Nach­rich­ten solange ab, bis diese aus der Queue abge­zo­gen, ver­ar­bei­tet und schluss­end­lich gelöscht werden.

AWS Simple Noti­fi­ca­tion Ser­vice (SNS) ist ein pub/­sub-Mes­sa­ging Ser­vice von AWS, d.h. wenn eine Nach­richt zu einem soge­nann­ten Topic hin­zu­ge­fügt wird, wird diese Nach­richt an alle Sub­scri­ber publi­ziert. Die Über­tra­gung sol­cher Nach­rich­ten war bis­her unge­ord­ne­ter Natur, aller­dings wurde im Ver­lauf des Okto­bers die soge­nann­ten SNS FIFO Topics vorgestellt.

Die AWS FIFO (First In First Out) Topics ermög­li­chen eine Bear­bei­tung der Nach­rich­ten in der strik­ten Rei­hen­folge, in wel­cher diese auch ein­ge­trof­fen sind. Neben der geord­ne­ten Ver­ar­bei­tung von Nach­rich­ten ergibt sich durch die Ver­wen­dung von FIFO Topics ein wei­te­rer Vor­teil: Ver­tei­lungs­sys­teme, wie es SNS auch ist, kön­nen unter Umstän­den Nach­rich­ten dop­pelt erzeu­gen bezie­hungs­weise diese in dop­pel­ter Form an die Sub­scri­ber wei­ter­rei­chen. Um dies zu ver­hin­dern, kön­nen Ein­stel­lun­gen vor­ge­nom­men wer­den, sodass anhand des Bodys der Nach­richt eine ein­deu­tige ID erzeugt und durch das Abglei­chen die­ser, Dupli­kate gefun­den und ent­fernt wer­den können.

Die Ver­wen­dung von FIFO SNS Topics und FIFO Queues erleich­tern die Kom­mu­ni­ka­tion zwi­schen Anwen­dun­gen, bei denen die Rei­hen­folge der Aus­füh­rung ele­men­tar ist oder eine dop­pelte Aus­füh­rung auf­grund von dupli­zier­ten Benach­rich­ti­gun­gen nicht tole­rier­bar ist.

Ama­zon Dis­tro for Open­Te­le­me­try (Pre­view)

Still­stand ist Rück­schritt. In der heu­ti­gen Zeit befin­det sich alles in Bewe­gung. Irgend­et­was pas­siert immer – Sei es die Abfrage von Web­sei­ten, das Bear­bei­ten von Streams oder das Hand­ha­ben von Ereig­nis­sen. Um den Sta­tus eines Sys­tems zu erfas­sen, kann es weit weni­ger ziel­füh­rend sein, ein­zelne Abfra­gen zu beob­ach­ten, als viel­mehr das Gesamt­bild in Form von Sta­tis­ti­ken zu betrachten.

AWS Dis­tro for Open Tele­me­try ist eine sichere Dis­tri­bu­tion von Open­Te­le­me­try, wel­che APIs, Libra­ries und Agents bereit­stellt, um bei­spiels­weise Metri­ken zum Moni­to­ring von Appli­ka­tio­nen zu sam­meln. Der Ser­vice ermög­licht eine ein­ma­lige Instru­men­ta­li­sie­rung von Appli­ka­tio­nen, sodass diese auto­ma­tisch Metri­ken an meh­rere Moni­to­ring Tools wei­ter­rei­chen. AWS Dis­tro for Open­Te­le­me­try sam­melt außer­dem Meta­da­ten von AWS Res­sour­cen und Mana­ged Ser­vices. Dies erlaubt es die Per­for­man­ce­da­ten der Appli­ka­tion mit den Daten der jewei­li­gen Infrastruktur in Ver­bin­dung zu set­zen und ermög­licht so, einen detail­lier­ten Ein­blick in den Zustand des Sys­tems zu erhalten.

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.