Im Novem­ber ver­öf­fent­lichte AWS einige Neue­run­gen. 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 AWS ECS, AWS EKS sowie Aurora und RDS thematisiert.

Infra­struc­ture

Das Land, in dem die Daten gespei­chert wer­den, ist ins­be­son­dere für Unter­neh­men einer der wich­tigs­ten Fak­to­ren, um sich für oder gegen einen Anbie­ter zu ent­schei­den. Ins­be­son­dere für unsere Schwei­zer-Kun­den war der Schritt in die AWS häu­fig pro­ble­ma­tisch, da es keine Region inner­halb der Schweiz gab. Dies hat sich nun aller­dings im Novem­ber geändert.

Neue AWS-Regio­nen

Im ver­gan­ge­nen Monat hat AWS einige neue Regio­nen in Betrieb genom­men. Neben den neuen Regio­nen in Indien und Spa­nien gibt es seit Novem­ber nun – wie bereits ange­teasert – auch eine Region in der Schweiz. Die neue Region wird unter dem Kür­zel eu-cen­tral‑2 lau­fen und ist geo­gra­phisch nahe Zürich ver­an­kert. Inner­halb die­ser Region wird es zukünf­tig drei red­un­dante Avai­la­bi­lity-Zones geben.

Wie immer, wenn eine neue Region erschlos­sen wird, sind zunächst nicht alle Ser­vices in vol­lem Umfang ver­füg­bar, aller­dings wird dies im Laufe der Zeit geän­dert . Bereits zum Start sind mit diver­sen EC2-Instan­zen, Cloud­Watch, Cloud­Trail, Lambda, IAM und vie­len wei­te­ren Ser­vices die rele­van­tes­ten Ser­vices ver­füg­bar und somit kön­nen die meis­ten Use-Cases bedient werden.

Die neuen Regio­nen in Indien, Spa­nien und der Schweiz sind seit Novem­ber ver­füg­bar, sodass bereits erste Workloads erstellt wer­den können.

Com­pute

Auch wenn Docker und Kuber­netes – bezie­hungs­weise Con­tai­ner­tech­no­lo­gien im All­ge­mei­nen – keine Micro­ser­vice­ar­chi­tek­tu­ren garan­tie­ren, so sind sie doch ein ele­men­ta­rer Bestand­teil jener und die Kom­mu­ni­ka­tion zwi­schen den ein­zel­nen Instan­zen ist eine der kri­tischs­ten Kom­po­nen­ten einer jeden Archi­tek­tur. Aus die­sem Grund erleich­tert AWS die Kom­mu­ni­ka­tion zwi­schen ECS-Instan­zen sowie das Deploy­ment von Appli­ka­tio­nen auf EKS aus dem Mar­ket­place heraus.

AWS ECS: Kom­mu­ni­ka­tion zwi­schen Microservices

Die zu Beginn die­ses Abschnit­tes ange­spro­che­nen Micro­ser­vice­ar­chi­tek­tu­ren sind inzwi­schen ein all­ge­gen­wär­ti­ges Kon­strukt in der IT. Sie sol­len große Mono­li­then ablö­sen und diese in klei­nere Berei­che auf­schlüs­seln, wel­che bei­spiels­weise über APIs mit­ein­an­der kom­mu­ni­zie­ren. An die­ser Stelle ent­puppt sich auch eine Schwie­rig­keit, die zumeist in der Pla­nung über­se­hen wird. Durch die Auf­spal­tung des einen gro­ßen Ser­vices in viele kleine Ser­vices ergibt sich schluss­end­lich ein kom­ple­xes Mus­ter von Ser­vicen und um die Funk­ti­ons­tüch­tig­keit der Kom­mu­ni­ka­tion der ein­zel­nen Ser­vices zu gewähr­leis­ten, bedarf es zumin­dest einem zumin­dest soli­den Ver­ständ­nis von Netzwerktechnologien.

Kun­den die AWS ECS zum Hos­ten der Micro­ser­vices ver­wen­den, grei­fen häu­fig auf wei­tere Ser­vices zurück, um die Kom­mu­ni­ka­tion zwi­schen den ein­zel­nen Ser­vices zu gewähr­leis­ten. Dies hat zur Folge, dass neben ECS ent­we­der Ela­s­tic Load Balan­cer, ECS Ser­vice Dis­co­very oder AWS App Mesh ein­ge­setzt wer­den, was – natür­lich – mit zusätz­li­chen Kos­ten, Auf­wand oder Kom­ple­xi­tät einhergeht.

Um die Kom­ple­xi­tät zu redu­zie­ren, hat Ama­zon ECS Ser­vice Con­nect ent­wi­ckelt und ver­öf­fent­licht. ECS Ser­vice Con­nect bie­tet sei­nen Nut­zern nun die Mög­lich­keit, die soeben the­ma­ti­sierte Kom­mu­ni­ka­tion der ein­zel­nen Ser­vices ein­fach zu rea­li­sie­ren. Der Ser­vice stellt ein ver­ein­fach­tes Netz­werk-Setup bereit, wel­ches die Kom­mu­ni­ka­tion meh­re­rer ECS-Clus­ter über meh­rere VPCs hin­weg ermög­licht. Die ein­zel­nen Ser­vices kön­nen mit­tels eines Namens über AWS Cloud Map iden­ti­fi­ziert wer­den. Wei­ter­hin über­nimmt ECS Ser­vice Con­nect das Ver­tei­len von Auf­ga­ben an die ein­zel­nen Ser­vices, eine Auf­gabe, die in „alten“ Kon­fi­gu­ra­tio­nen zumeist von Load Balan­cern über­nom­men wurde, und führt regel­mä­ßige Health Checks durch.

ECS Ser­vice Con­nect ist seit Novem­ber in allen Regio­nen ver­füg­bar, in denen auch ECS ver­füg­bar ist.

Data­base

AWS Aurora und RDS: Blue/Green Deployments

Im Bereich der Soft­ware- bezie­hungs­weise Appli­ka­ti­ons­ent­wick­lung ist das Blue/­Green-Deploy­ment eine Option, um das Risiko, feh­ler­be­haf­tete Ände­run­gen zu deployen, zu mini­mie­ren. Für ein Blue/Green Deploy­ment wer­den schluss­end­lich zwei Umge­bun­gen benö­tigt. Auf der ers­ten Umge­bung läuft die aktu­elle Ver­sion und auf der zwei­ten Umge­bung die Ver­sion mit den auf­zu­spie­len­den Ände­run­gen. Im Kon­text von Ama­zon Aurora bzw. Ama­zon RDS konn­ten Nut­zer ein Blue/­Green-Deploy­ment bis­her über Clo­ning und Repli­cas errei­chen und so eine Art self-mana­ged Blue/­Green-Deploy­ment simulieren.

Seit ver­gan­ge­nem Monat gibt es nun die Mög­lich­keit, AWS die­ses Manage­ment zu über­ge­ben. In weni­gen Klicks kön­nen Nut­zer die aktu­elle Daten­bank­um­ge­bung klo­nen und AWS wird diese mit der aktu­el­len Instanz mit­tels soge­nann­ter „logi­cal repli­ca­tion“ syn­chron hal­ten. In weni­gen Minu­ten kön­nen Nut­zer dann das Sta­ging-Envi­ron­ment als neues Pro­duk­ti­ons­en­vi­ron­ment ernen­nen. Wäh­rend die­ses Zeit­raums wer­den Schreib­pro­zesse auf die bei­den Umge­bun­gen unter­bun­den, sodass keine Daten ver­lo­ren gehen kön­nen. Sobald das Deploy­ment bzw. das „Tau­schen“ der Umge­bun­gen abge­schlos­sen ist, wird AWS auto­ma­tisch den ein­ge­hen­den Traf­fic auf die neue Pro­duk­ti­ons­um­ge­bung umleiten.

Blue/Green Deploy­ments sind seit Novem­ber für Aurora with MySQL, RDS for MySQL und RDS for MariaDB in allen Regio­nen verfügbar.

AWS DMS: Schema Conversion

Viele Wege füh­ren in die Cloud. Mit dem AWS Data­base Migra­tion Ser­vice (DMS) stellt AWS einen Ser­vice zur Ver­fü­gung, um Daten – mehr oder weni­ger – auto­ma­tisch in die Cloud zu repli­zie­ren und so homo­gene sowie hete­ro­gene Migra­tio­nen schnell und ein­fach durch­zu­füh­ren. Der DMS der AWS repli­ziert Quell­da­ten zu einem Ziel, wel­ches eine Daten­bank, ein Stream oder ein Objekt­da­ten­spei­cher sein kann.

Zur Unter­stüt­zung des Data­base Migra­tion Ser­vices kann das soge­nannte Schema Con­ver­sion Tool ein­ge­setzt wer­den. Dies ist ein unab­hän­gi­ger Zusatz zu AWS DMS, wel­ches Daten­bank­ob­jekte wie Views, Pro­ce­du­res oder Func­tions über­führt bzw. bewer­tet, ob diese über­führt wer­den kön­nen. Das Schema Con­ver­sion Tool war bis zuletzt eine eigene Appli­ka­tion, die lokal instal­liert und selbst ver­wal­tet wer­den musste.

Im Novem­ber hat AWS nun DMS Schema Con­ver­sion ange­kün­digt, was schluss­end­lich eine fully mana­ged Abwand­lung des bekann­ten Schema Con­ver­sion Tools ist und nicht mehr lokal, son­dern inner­halb der AWS genutzt wer­den kann. Im Ver­gleich zum Schema Con­ver­sion Tool wer­den aller­dings nur recht wenige Quel­len und Ziele unter­stützt. So sind die ein­zi­gen Quel­len SQL-Ser­ver und Ora­cle und die ein­zi­gen Ziele Ama­zon RDS for MySQL und RDS for Post­greSQL. In nähe­rer Zukunft sol­len aller­dings wei­tere Sys­teme als Quelle und Ziel hin­zu­ge­fügt werden.

AWS DMS Schema Con­ver­sion ist in Europa in Frank­furt, Irland und Stock­holm ver­füg­bar. An die­ser Stelle ver­wei­sen wir gerne auf unser Web­i­nar zum Thema Daten­mi­gra­tion nach AWS und Azure. In die­sem wer­den neben der Azure Data Fac­tory auch der Data­base Migra­tion Ser­vice und das Schema Con­ver­sion Tool vorgestellt.

Sto­rage

Eine Ankün­di­gung in Puncto Sto­rage war im ver­gan­ge­nen Monat beson­ders inter­es­sant – auch wenn es eigent­lich keine klas­si­sche Sto­rage-Solu­tion ist.

Ama­zon Secu­rity Lake

Im Novem­ber hat Ama­zon den soge­nann­ten Secu­rity Lake ange­kün­digt und als Pre­view ver­füg­bar gemacht. Mit AWS S3 und AWS Lake For­ma­tion hat Ama­zon bereits in der Ver­gan­gen­heit mäch­tige Werk­zeuge zur Ver­fü­gung gestellt, um einen Data Lake in der AWS zu erstel­len. Der Ama­zon Secu­rity Lake soll ein Zweck­ge­trie­be­ner Data Lake Ser­vice sein, der als zen­tra­ler Spei­cher­ort für alle Sicher­heits­re­le­van­ten Daten dient, die on-premises, in der AWS oder wei­te­ren Quel­len gene­riert werden.

Inner­halb des Secu­rity Data Lakes kön­nen dann Aggre­ga­tio­nen über die Daten der ver­schie­de­nen Sys­teme erfol­gen. Dies wird unter ande­rem durch die Unter­stüt­zung des Open Cyber­se­cu­rity Schema Frame­works gewähr­leis­tet. Ama­zon Secu­rity Lake par­ti­tio­niert die Daten auto­ma­tisch und kon­ver­tiert sie in eben die­ses ein­heit­li­che Datenformat.

Die Pre­view des Secu­rity Lakes ist in Europa in Frank­furt und Irland ver­füg­bar. Noch ist der Ser­vice zwar sehr jung, trotz­dem hat er aber das Poten­tial, in vie­len Cloud Infra­struk­tu­ren Ver­wen­dung zu finden.

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.