HOCHSCHULE LANDSHUT Automatisches Ressourcenmanagement für Amazon Web Services - FAKULTÄT INFORMATIK - OPUS 4
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
HOCHSCHULE LANDSHUT
FAKULTÄT INFORMATIK
Automatisches Ressourcenmanagement für Amazon Web
Services
Bachelorarbeit
vorgelegt von
Sebastian Scheibenzuber
Eingereicht: ……………………………..
Betreuer: Prof. Dr.-Ing. Johann Uhrmann
ERKLÄRUNG ZUR BACHELORARBEIT
(gemäß § 11, Abs. (4) 3 APO)
Name, Vorname der/des
Studierenden: ................................................................................
Hochschule Landshut
Fakultät Informatik
Hiermit erkläre ich, dass ich die Arbeit selbständig
verfasst, noch nicht anderweitig für Prüfungszwecke
vorgelegt, keine anderen als die angegebenen Quellen
oder Hilfsmittel benützt sowie wörtliche und sinngemäße
Zitate als solche gekennzeichnet habe.
............................ .........................................................
(Datum) (Unterschrift der/des Studierenden)
Abstract
Abstract (Deutsch)
Das Thema dieser Bachelorarbeit ist das automatische Ressourcenmanagement
für Amazon Web Services. Insbesondere hat sie zur Aufgabe, eine Möglichkeit
zu finden das Problem zu lösen, dass es keinen simplen Weg gibt einem User die
limitierte Erstellung von EC2 Instanzen zu erlauben.
Denn aufgrund der immer weiter verbreiteten Nutzung von AWS und dessen
Service Elastic Compute Cloud wird ein automatisiertes Management der
Ressourcen in immer mehr Unternehmen notwendig.
Nach einer kurzen Einleitung und der Erklärung der für das Thema relevanten
Begriffe, folgt eine Anleitung für die Einrichtung und Installation der benötigten
Software.
Der Hauptteil der Arbeit behandelt drei verschiedene Lösungsansätze mittels
des Amazon Command-Line-Interfaces, eines Python-Skripts und letztendlich
dem Dienst AWS Lambda.
Außerdem wird auf zwei Möglichkeiten eingegangen, wie man ein
automatisiertes Benachrichtigungssytem mittels Amazon Web Services
einrichten kann.
Zuletzt folgt eine Zusammenfassung der Ergebnisse, bei der die einzelnen
Lösungswege gegeneinander abgewogen werden, gefolgt von einem kurzen
Ausblick, was in Zukunft noch in dieser Richtung möglich wäre.
1|Seite
Abstract
Abstract (English)
The theme of this thesis is the automated resource management for Amazon
Web Services. In particular its goal is to find a way to solve the problem, that
there is no simple way to allow a user the limited creation of EC2 instances.
With the rising usage of AWS and its service Elastic Compute Cloud managing
its resources automatically becomes necessary for more and more companies.
After a short introduction and an explanation of the most relevant terms for this
topic, follows a short tutorial on how to set up and install the required software.
The main part of this thesis discusses three possible approaches to find a
solution, through the usage of the Amazon Command-Line-Interface, a python-
script and finally the service AWS Lambda.
Furthermore, it will go into to potential solutions on how to set up an automated
messaging system via Amazon Web Services.
Finally, there will be a summary containing the different approaches and
evaluating them, followed by a short outlook on what might be possible in the
future.
2|Seite
Inhaltsverzeichnis
Inhaltsverzeichnis
Abstract (Deutsch) ................................................................................................................. 1
Abstract (English) ................................................................................................................. 2
Inhaltsverzeichnis ................................................................................................................. 3
1 Einleitung .................................................................................................................... 5
1.1 Motivation ........................................................................................................... 5
1.2 Aufgaben und Zielsetzung .............................................................................. 6
1.3 Aufbau der Arbeit ............................................................................................. 6
2 Grundlagen ..................................................................................................................7
2.1 Cloud-Computing ...............................................................................................7
2.2 Web Service .........................................................................................................7
2.3 Amazon Web Services ..................................................................................... 8
2.3.1 Elastic Compute Cloud............................................................................. 8
2.3.2 Identity and Access Management ........................................................ 8
2.3.2.1 Richtlinien ............................................................................................... 9
2.3.2.2 Rollen ........................................................................................................ 9
2.3.2.3 Nutzer ........................................................................................................ 9
2.3.3 CloudWatch ................................................................................................. 9
2.3.4 Lambda ....................................................................................................... 10
2.3.5 Simple Notification Service.................................................................. 10
2.3.6 Simple EMail Service ............................................................................. 10
2.3.7 CloudTrail .................................................................................................. 10
2.3.8 CloudFormation ...................................................................................... 10
2.3.9 Boto ............................................................................................................... 11
2.3.10 Command-Line-Interface ...................................................................... 11
3 Aufbau und Downloads ......................................................................................... 12
3.1 Umgebung .......................................................................................................... 12
3.2 AWS CLI .............................................................................................................. 12
3.3 Python und Boto ............................................................................................... 13
4 Lösungsansätze ........................................................................................................14
4.1 Limitierung der erstellten EC2-Instanzen ...............................................14
4.1.1 Lösung mittels dem AWS-CLI ..............................................................14
4.1.2 Lösung mittels eines Python Skripts..................................................16
4.1.3 Lösung mittels einer Lambda Funktion............................................19
4.2 Automatische Benachrichtigung................................................................ 28
3|Seite
Inhaltsverzeichnis
4.2.1 Simple Email Service.............................................................................. 28
4.2.2 Simple Notification Service.................................................................. 28
5 Ergebnis ..................................................................................................................... 32
5.1 Zusammenfassung und Fazit ...................................................................... 32
5.2 Ausblick .............................................................................................................. 33
Literaturverzeichnis ............................................................................................................ 34
Glossar ................................................................................................................................. 38
Abkürzungsverzeichnis ....................................................................................................... 40
Abbildungsverzeichnis .........................................................................................................41
Anhang ................................................................................................................................. 42
4|Seite
Einleitung
1 Einleitung
Im folgenden Kapitel wird auf die Motivation, Aufgaben und Zielsetzung der
Arbeit eingegangen. Darüber hinaus beinhaltet es eine Zusammenfassung des
Aufbaus der Arbeit.
1.1 Motivation
Aufgrund der stetig wachsenden IT-Infrastruktur von Unternehmen jeglicher
Größe, wird das Thema Cloud-Computing von Tag zu Tag wichtiger. [IT-
Services - Weltweite Ausgaben bis 2020] Laut Umfragen hat sich die Anzahl der
Unternehmen welche Cloud-Dienste in Anspruch nehmen in den Jahren 2011-
2017 mehr als verdoppelt. Rund zwei Drittel aller befragten Unternehmen
nutzen mittlerweile verschiedenste Cloud-Anwendungen. [Nutzung von Cloud
Computing in deutschen Unternehmen bis 2017] Die beiden Hauptgründe
hierfür sind das Einsparen von Kosten, welche sonst beim Kauf der benötigten
Hardware anfallen würden, und die verkürzte Planungszeit, da die Anschaffung
von Servern oder ähnlichem nicht bereits lange im Voraus miteinberechnet
werden muss, sondern diese spontan innerhalb von wenigen Minuten über die
Cloud hochgefahren werden können. [Informationen zu AWS]
Einer der größten Anbieter von Cloud-Services ist „Amazon“. Mit ihren
„Amazon Web Services“ (Kurz: AWS) stellt dieses seit 2006 verschiedene IT-
Infrastrukturservices in Form von Web-Services bereit, welche in 190 Ländern
genutzt werden können. [Kampf um die Cloud: So balgen sich die Tech-Riesen;
Informationen zu AWS]
Zu den am meist genutzten AWS-Diensten zählt auch die „Amazon Elastic
Compute Cloud“ (Kurz: EC2) [The Three Most Widely Used Amazon Web
Services], welche sichere, skalierbare Rechenkapazitäten zur Verfügung stellt
[Amazon Elastic Compute Cloud]. Wenn ein User eines AWS-Accounts diese
nutzen will, muss er die dafür notwendigen Berechtigungen von einem
Administrator des AWS-Accounts erhalten. Sobald ihm diese zugeteilt wurden,
ist es ihm möglich nach Belieben sogenannte Instanzen zu erstellen und mit
ihnen zu arbeiten.
5|Seite
Einleitung
1.2 Aufgaben und Zielsetzung
Die Hauptaufgabe dieser Bachelorarbeit ist es, eine Möglichkeit zu finden das
Nutzen der EC2 Ressourcen automatisiert zu managen. Aktuell ist der Standard,
dass ein User, dem die Berechtigungen erteilt wurden EC2 Instanzen zu
erstellen, diese Berechtigung in beliebigem Ausmaß nutzen kann. Dies kann
aufgrund von menschlichen Fehlern oder böswilligen Absichten schnell zu
enormen Kosten führen, was es zu verhindern gilt.
Das Ziel ist es also, durch das abwägen verschiedener Lösungsmöglichkeiten,
den optimalen Lösungsweg für dieses Problem zu finden und darzustellen.
Außerdem soll als Nebenziel eine automatische Benachrichtigung integriert
werden, welche beispielsweise Administratoren informiert, sollte jemand diese
Regelung gebrochen haben. Dies ermöglicht ihnen die Verantwortlichen über
mögliche Konsequenzen zu belehren und zukünftige Zwischenfälle zu
vermeiden.
1.3 Aufbau der Arbeit
Diese Bachelorarbeit ist in fünf Abschnitte aufgeteilt.
Das zweite Kapitel beschreibt die wichtigsten Begriffe und erklärt die
notwendigen Grundlagen zur Arbeit mit Amazon Web Services.
Im dritten Teil wird gezeigt, wie man die benötigte Software herunterlädt und
installiert.
Kapitel Nummer Vier befasst sich mit den unterschiedlichen Lösungsansätzen
für das Begrenzen der Instanzenerstellung und dem Aufsetzen eines
automatisierten Benachrichtigungssystems.
Im letzten Kapitel werden nochmals die Lösungsansätze kurz vorgestellt und
dann gegeneinander abgewogen, sowie ein Fazit gebildet. Ein darauffolgender
kurzer Ausblick zeigt mögliche zukünftige Änderungen der Lösungswege dieser
Arbeit auf.
6|SeiteGrundlagen
2 Grundlagen
Im zweiten Kapitel werden die wichtigsten Elemente dieser Bachelorarbeit
vorgestellt und die für diese Arbeit bedeutendsten Begriffe erklärt.
2.1 Cloud-Computing
Unter Cloud-Computing versteht man Mittel, die es einem ermöglichen, auf
eine gemeinschaftlich genutzte Menge an Computing-Ressourcen wie Server,
Speicherplatz oder Anwendungen zuzugreifen. Es ist hierbei vor allem wichtig,
dass man möglichst schnell und simpel auf die Ressourcen zugreifen und sie bei
Bedarf einfach anpassen kann. [The NIST definition of cloud computing]
2.2 Web Service
Viele IT-Spezialisten und Gruppierungen versuchten eine passende Definition
zu finden, welche genau beschreibt, was ein „Web Service“ ist.
Die Gartner Group erklärte es wie folgt: „Web services are software
technologies, making it possible to build bridges between IT systems that
otherwise would require extensive development efforts.”
Und während Forrester Research es kurz als “Sofware designed to be used
by other software via Internet protocols and formats” zusammenfasste,
beschrieb W3C hingegen ausführlicher: “A Web service is a software system
designed to support interoperable machine-to-machine interaction over a
network. It has an interface described in a machine-processable format
(specifically WSDL). Other systems interact with the Web service in a manner
prescribed by its description using SOAP-messages, typically conveyed using
HTTP with an XML serialization in conjunction with other Web-related
standards.”
So sehr sich die Definitionen auch unterscheiden, ist ihnen doch allen gemein,
dass Web Services dafür gedacht sind die Kommunikation von Maschine zu
Maschine zu ermöglichen, welche zwar durch einen Menschen gestartet werden
7|SeiteGrundlagen
kann, dann aber kein weiteres Eingreifen benötigt. [Service-orientierte
Architekturen mit Web Services, S. 54f.]
2.3 Amazon Web Services
Mit AWS bietet das amerikanische Unternehmen
Amazon verschiedenste Web-Services an, welche
heutzutage als Cloud-Computing bekannt sind. Ihre
Abbildung 1 AWS Logo
globale Präsenz verdanken sie Rechenzentren in den
USA, Europa, Brasilien, Singapur, Japan und Australien, welche es ihnen
ermöglichen, flexible, kostengünstige und vor allem sichere Möglichkeiten an
IT-Infrastrukturen anzubieten. [Informationen zu AWS]
2.3.1 Elastic Compute Cloud
Amazon EC2 ist dafür gedacht, Entwickler beim Cloud-Computing zu
unterstützen. Dies erreicht es durch seine verschiedenen Möglichkeiten
Rechenkapazitäten in der Cloud zu starten und an die eigenen Vorstellungen
anzupassen. Durch genaue Einstellungen erlaubt es einem die Kapazitäten
optimal auszunutzen um Kosten zu minimieren. [Amazon Elastic Compute
Cloud]
2.3.2 Identity and Access Management
Identity and Access Management (Kurz: IAM) wurde geschaffen, um das
Kontrollieren der Zugriffsberechtigungen auf AWS-Ressourcen zu erleichtern.
Es gibt verschiedene Entitäten um eine optimale Einstellung zu ermöglichen.
Die wichtigsten für diese Arbeit sind Nutzer, Rollen und Richtlinien. [Was ist
IAM?]
8|SeiteGrundlagen
2.3.2.1 Richtlinien
Über die sogenannten Richtlinien oder „Policies“ kann man festlegen welche
Aktionen erlaubt oder verweigert werden. Man kann diese dann entweder direkt
einem User oder einer Rolle zuteilen. Sie werden meist in AWS oder als JSON-
Dokumente erstellt und gespeichert. [Richtlinien und Berechtigungen]
2.3.2.2 Rollen
Unter einer Rolle oder „Role“ versteht man in IAM eine Identität, welche man
anderen Entitäten zuteilen kann. Einer Rolle können Richtlinien zugewiesen
werden, welche Entitäten mit dieser Rolle zu gewissen Aktionen befähigen oder
das Ausführen dieser verbieten. Wenn man diese Rolle nun später
beispielsweise einem Nutzer zuweist, betreffen ihn also die gleichen Richtlinien.
[IAM-Rollen]
2.3.2.3 Nutzer
Ein Nutzer oder „User“ unter IAM ist eine Entität, welche genutzt wird um eine
Person oder eine Anwendung darzustellen. Dieser können dann die
notwendigen Rechte erteilt werden um mit AWS zu interagieren. [IAM-
Benutzer]
2.3.3 CloudWatch
CloudWatch ist ein Dienst, der zum Überwachen und Kontrollieren von AWS
verwendet werden kann. Seine Hauptaufgabe ist es Daten zu sammeln und zu
speichern. Außerdem kann er so eingestellt werden, dass er seine Nutzer bei
bestimmten Vorkommnissen, wie beispielsweise dem Starten einer EC2-
Instanz, alarmiert. [Amazon CloudWatch]
9|SeiteGrundlagen
2.3.4 Lambda
Lambda ermöglicht es einem User Code auszuführen, ohne sich um notwendige
Server kümmern zu müssen. Es können Anwendungen geschrieben werden,
welche Lambda dann, je nach Einstellung, bei gewissen Events oder nachdem
eine bestimmte Zeit verstrichen ist, automatisiert ausführt. [Was ist AWS
Lambda?]
2.3.5 Simple Notification Service
Amazon Simple Notification Service (Kurz: SNS) ist ein Messaging-Dienst,
durch den man Nachrichten beispielsweise via E-Mail und SMS an die
Subscriber der verschiedenen SNS-Topics versenden kann. [Amazon Simple
Notification Service]
2.3.6 Simple EMail Service
Der Simple Email Service (Kurz: SES) ist ein zuverlässiger und kostengünstiger
Dienst um automatisiert E-Mails an Kunden oder Personal zu verschicken.
[Simple Email Service]
2.3.7 CloudTrail
Mithilfe von CloudTrail kann man verschiedenste Punkte seines AWS-Kontos
überwachen. Es protokolliert Kontoaktivitäten, insbesondere Aktionen, die von
AWS-Services oder ähnlichem ausgeführt werden. [AWS CloudTrail]
2.3.8 CloudFormation
Durch CloudFormation kann man verschiedene Infrastrukturressourcen in
einer simplen Textdatei darstellen und anderen bereitstellen.
[AWS CloudFormation]
10 | S e i t eGrundlagen
2.3.9 Boto
Boto ist das offizielle Software Development Kit für die Interaktion mit Amazon
Web Services in Python. Es erleichtert einem, unter anderem, die Erschaffung
und Bearbeitung von EC2-Instanzen. [Boto 3 Documentation]
2.3.10 Command-Line-Interface
Das AWS-Command-Line-Interface oder auch die AWS-Befehlszeilen-
Schnittstelle ist ein Open-Source-Tool, welches es einem ermöglicht, mit
Amazon Web Services über die Befehlszeile zu interagieren und über Skripte zu
automatisieren. [Was ist die AWS Command Line Interface?; AWS CLI
Command Reference]
11 | S e i t eAufbau und Downloads
3 Aufbau und Downloads
In diesem Teil wird sowohl auf die verwendete Umgebung als auch auf die
notwendigen Installationen eingegangen.
3.1 Umgebung
Sämtliche möglichen Lösungen wurden in einer Windows-Umgebung
entwickelt und getestet. Alle Aktionen mit AWS wurden von einem User-
Account mit vollen Administratorrechten ausgeführt.
3.2 AWS CLI
Um die AWS-Befehlszeilen-Schnittstelle auf einem Windows Rechner zu
installieren, öffnet man in einem Browser folgende Seite:
https://docs.aws.amazon.com/de_de/cli/latest/userguide/install-
windows.html
Nun kann man einfach den Installationsanweisungen dieser Seite folgen und
letztendlich mit dem Befehl „aws --version“ in der Eingabeaufforderung testen,
ob die Installation erfolgreich war. Der Befehl sollte die aktuelle Version der
installierten AWS-CLI zurückgeben. [Installieren der AWS Command Line
Interface unter Microsoft Windows]
Um das CLI noch für den schnellen Gebrauch einzustellen, führt man nun „aws
configure“ aus, woraufhin man aufgefordert wird die „AWS Access Key ID“, den
„AWS Secret Access Key“, den „Default region name“ und das „default output
format“ anzugeben. Die notwendigen Keys wurden für diese Arbeit vom
Systemadministrator gestellt und der „Default region name“ auf „eu-central-1“
geändert. Das „default output format“ wurde bei „none“ belassen.
[Konfigurieren der AWS CLI]
12 | S e i t eAufbau und Downloads
3.3 Python und Boto
Python kann man sich einfach auf der offiziellen Website von Python unter
Downloads herunterladen [Download Python]. Für die Installation von Boto
benötigt man den Dienst „pip“. Hat man sich eine Version von Python
installiert, welche, im Falle von Python 2 mindestens dem Stand von Version
2.7.9, und im Falle von Python 3 mindestens dem Stand von Version 3.4
entspricht, ist pip bereits mitinstalliert. Wenn nicht kann man es über den
Befehl „curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py“ und
anschließendem Ausführen von „python get-pip.py“ installieren. [Installation]
Daraufhin wird die 3. Version von Boto ganz einfach mit „pip install boto3“
heruntergeladen und installiert. [Quickstart]
13 | S e i t eLösungsansätze
4 Lösungsansätze
In diesem Kapitel werden die getesteten Lösungsansätze vorgestellt und
gegeneinander abgewogen.
4.1 Limitierung der erstellten EC2-Instanzen
Die erste Grundidee zur Lösung dieses Problems besteht aus zwei Schritten:
1. Es muss ein Weg gefunden werden, Informationen darüber zu erhalten,
wie viele Instanzen vom selben User-Account aus erstellt wurden.
2. Bei Erreichen oder Überschreiten des Limits braucht man eine
Möglichkeit, entweder dem User die Rechte zu entziehen, neue Instanzen
zu erstellen, oder die bereits erstellten Instanzen des Users
herunterzufahren, um zu verhindern, dass eine zu hohe Anzahl an
Instanzen zur selben Zeit läuft.
4.1.1 Lösung mittels dem AWS-CLI
Zuerst wird auf den zweiten Punkt eingegangen, da dieser mit der CLI sehr
simpel zu realisieren ist. Das Ziel ist es, jemandem die Rechte zu entziehen
Instanzen zu erstellen. Dies kann erreicht werden, indem man seinem User-
Account eine Richtlinie zuweist, welche die notwendigen Aktionen verbietet. Es
ist nicht nötig ihm die Richtlinien, welche es ihm erlauben Instanzen zu
erstellen, zu entziehen, da AWS das Verbieten von Aktionen in jedem Fall
priorisiert und ihm so das Erstellen neuer Instanzen dennoch nicht erlaubt.
Um solch eine Richtlinie mit dem AWS-CLI zu erstellen, muss man zunächst
eine JSON Datei anfertigen. Diese muss folgenden Code enthalten:
14 | S e i t eLösungsansätze
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Deny",
"Action": [
"ec2:PurchaseReservedInstancesOffering",
"ec2:RequestSpotInstances",
"ec2:RunInstances"
],
"Resource": "*"
}
]
}
Hat man diese fertiggestellt, kann man mithilfe des Befehls „aws iam create-
policy –policy-name NameDerPolicy –policy-document DateiPfadDerPolicy“
die Richtlinie von der Befehlszeilen-Schnittstelle erstellen lassen.
Um einem User nun diese Richtlinie zuzuweisen und ihm damit die Rechte zum
Erstellen weiterer Instanzen und ähnlichen Aktionen zu nehmen, führt man
einfach den Befehl „aws iam attach-user-policy --policy-arn ARNDerPolicy --
user-name NameDesUsers“ aus. Den Amazon-Ressource-Name (Kurz: ARN)
der Richtlinie findet man im AWS-IAM-Interface unter Richtlinien indem man
die gewünschte auswählt.
Sollte man einem User das Erstellen von Instanzen wieder erlauben wollen,
funktioniert dies mit „aws iam dettach-user-policy –policy arn ARNDerPolicy
–username NameDesUsers“.
15 | S e i t eLösungsansätze
Nun muss man nur noch einen Weg finden, das erste Problem zu lösen, also
herauszufinden, wenn ein User zu viele erstellten Instanzen hat und wie man
ihm die Richtlinie, die ihm das weitere Erstellen verbietet, dann automatisiert
zuweist.
Für diese Aufgabe ist die AWS-CLI allerdings optimal. Es gibt zwar Befehle mit
deren Hilfe man sich zum Beispiel alle Instanzen auflisten kann, wie „aws ec2
describe-instances“. Dies kann man dann auch mit Filtern auf beispielsweise
alle laufenden Instanzen beschränken „aws ec2 describe-instances --filters
"Name=instance-state-code,Values=16"“ um sie daraufhin mit „sudo aws
terminate-instances –instance-ids IdDerInstanz –region IhreRegion“ zu
terminieren. Jedoch ist das Automatisieren und weitere Arbeiten mit dem CLI
nicht zu empfehlen, da seine niedrige Mächtigkeit tiefergreifende
Lösungsansätze unnötig verkompliziert.
Aus diesem Grund habe ich mich dazu entschieden, nicht weiter ausschließlich
mit dem AWS-CLI zu arbeiten.
4.1.2 Lösung mittels eines Python Skripts
Der zweite Ansatz zum Lösen des Problems baut darauf auf, dass man das
Starten der Instanzen nicht über das AWS-Interface selbst, sondern durch ein
Python Skript regelt. Der Grundgedanke dabei ist es, das Zählen der laufenden
Instanzen jedes Nutzers durch das Taggen dieser zu realisieren.
Beim Starten einer Instanz über ein Python Skript kann man forcieren, dass sie
automatisch mit einem Tag versehen wird, der beinhaltet von welchem User die
Instanz gestartet wurde.
Wird das Skript nun vom User ausgeführt, muss dieser eingeben, welche
ImageID, die festlegt welches Image auf der erstellten Instanz läuft, und
welchen InstanceType, der den Typ der Instanz bestimmt, seine gewünschte
Instanz haben soll. Mithilfe von Boto3 kann das Skript auch automatisch die
AccountID des aktuellen Users in Erfahrung bringen:
16 | S e i t eLösungsansätze
ImageId = input("Enter ImageId: ")
InstanceType = input("EnterInstanceType: ")
AccountID = boto3.client('sts').get_caller_identity().get('Account')
Nun wird über den Boto3 Befehl create_instances die Instanz nach den
Wünschen des Users erstellt und mit einem Tag versehen:
TagSpecifications=[
{
'ResourceType': 'instance',
'Tags': [
{
'Key': 'AccountID',
'Value': AccountID
},
]
},
],
Damit ist der Grundstein für das Zählen der laufenden Instanzen eines Users
gelegt.
Um nun zu verhindern, dass zu viele Instanzen erstellt werden, muss man
mithilfe eines Filters zählen, wie viele Instanzen bereits den Tag des Nutzers
haben, bevor eine weitere erstellt wird. Hierfür lässt man sich alle Instanzen
auflisten und mit einer simplen Variable durchzählen. Das Erstellen der Instanz
wird nur dann ausgeführt, wenn der Nutzer maximal fünf laufende Instanzen
hat:
17 | S e i t eLösungsansätze
KeyCount = 0
instances = ec2.instances.filter(
Filters=[{'Name': 'tag:'+'AccountID', 'Values': [AccountID]}, {'Name':
'instance-state-name', 'Values': ['running']}])
for instance in instances:
KeyCount = KeyCount + 1
if KeyCount < 5:
Unter der Voraussetzung, dass der User sämtliche seiner Instanzen unter
Nutzung des Skripts erstellt hat, ist es ihm nun nichtmehr möglich eine Instanz
hochzufahren, wenn er bereits fünf laufende Instanzen hat.
Das Hauptproblem dieses Ansatzes ist es, dass jeder Nutzer, der dieses Skript
starten will, natürlich auch die Rechte zum Starten von Instanzen besitzen
muss, und dies daher auch problemlos im AWS-Interface kann. Damit kann er
ganz leicht die Überprüfung seiner bisher erstellten Instanzen und das Taggen
der neuen umgehen. Außerdem erlaubt das Skript aktuell nur eine minimale
Anpassung der Instanz seitens des Users, da er nur die ImageID und den
InstanceType auswählen kann und der Rest von AWS mit Standartwerten
befüllt wird. Will man die Anpassung des Nutzers ausweiten wird es allerdings
für diesen schnell unübersichtlich, da er möglicherweise dutzende von
Attributen beim Ausführen angeben muss. Auch lässt sich auf diese Weise
immer nur lediglich eine Instanz auf einmal erstellen.
Der komplette Code des Skripts liegt im Anhang sowie auf der CD angefügten
bei.
18 | S e i t eLösungsansätze
4.1.3 Lösung mittels einer Lambda Funktion
Der letzte Weg wird mithilfe des AWS-Dienstes Lambda realisiert. Die
grundsätzliche Lösungsidee für das Zählen der erstellten Instanzen pro User ist
die gleiche, wie im vorherigen Beispiel. Man stellt sicher, dass jede von einem
User erstellte Instanz mit seinen Accountdetails getaggt wird und kann dadurch
später sicherstellen, dass er die erlaubten Limits nicht überschreitet. Durch die
Nutzung von Lambda kann man sicherstellen, dass jede Instanz, egal wie der
Nutzer sie erstellt hat, korrekt getaggt wird.
Der Aufbau hierfür ist wie folgt:
Abbildung 2 AutoTagger
19 | S e i t eLösungsansätze
Zunächst führt der User einen RunInstance Befehl aus (1). Ob nun über das
AWS-Interface, die AWS-CLI oder ein selbstgeschriebenes Skript ist egal, da die
Aktion immer als Event an Amazon CloudWatch gesendet wird (2). Amazon
CloudWatch benachrichtigt (3) nun das Lambda Programm (4), dass jemand
eine Instanz gestartet hat, worauf dieses sofort Tags anfügt, welche die UserID
beinhalten (5). Daraufhin wird die Instanz fertiggestellt und es lässt sich
jederzeit feststellen, wer sie erstellt hat, indem man ihre Tags abruft.
Amazon stellt hierfür ein CloudFormation Template bereit, welches als Basis
verwendet, und für die genauen Spezifikationen abgeändert wurde. Dieses
Template kann man sich auf der folgenden Seite unter dem Link
„CloudFormation template“ herunterladen:
https://aws.amazon.com/de/blogs/security/how-to-automatically-tag-amazon-
ec2-resources-in-response-to-api-events/
Sobald der Download abgeschlossen ist, öffnet man einfach die AWS Konsole
und sucht den Dienst Amazon CloudFormation.
Mit dem Button „Create Stack“ kommt man auf eine Seite, bei der man nun die
Wahl hat unter „Choose a template“ eine Datei auszuwählen.
Abbildung 3 Select Template
20 | S e i t eLösungsansätze
Nachdem man die gerade heruntergeladene Datei als das gewählte Template
hochgeladen hat, gibt man dem Stack noch einen Namen und lässt AWS alle
nötigen Ressourcen automatisch erstellen. [How to Automatically Tag Amazon
EC2 Resources in Response to API Events]
Im Folgenden wird kurz auf die für die Arbeit Wichtigeren eingegangen.
Es wird eine CloudWatch Regel mit dem Namen „New-EC2Resource-Event“
erstellt, die bei bestimmten Events wie z.B. RunInstance die Lambda Funktion,
welche für das Taggen zuständig ist, benachrichtigt.
Die vom Template erstellte Rolle „AutoTagEC2Instances-LambdaAutoTagRole“
ist die Rolle, die später von dem Lambda Programm angenommen wird, und die
die notwendigen Richtlinien enthält, die Lambda benötigt, um auf die
Ressourcen zuzugreifen und sie zu taggen.
Die Richtlinie „LambdaGetLatestWindowsAmildPolicy“ wird der eben
genannten Rolle angehängt und erlaubt allen Entitäten, denen die Rolle
zugeteilt wird, verschiedenste Aktionen, die fürs automatische Taggen
notwendig sind, wie z.B. ec2:CreateTags.
Und letztendlich die Lambda Funktion „AutoTagEC2Instances-CFAutoTag“,
welche jeder erstellten Instanz die Tags „Owner“ und „PrincipalId“ anhängt, die
den Namen und die ID des Users enthalten, der die Instanz erstellt hat.
Hierdurch werden nun alle Instanzen beim Erstellen sofort mit einem Tag
versehen, welcher die UserID des erstellenden Nutzers aufzeigt. Der nächste
Schritt ist es nun, einen ebenfalls automatisierten Weg zu finden, mithilfe dieser
Tags zu erfahren, wann ein User zu viele Instanzen hat und dies zu verhindern.
Hierbei sollte man sich über das CAP-Theorem bewusst sein. Das CAP oder
auch Brewers Theorem besagt, dass man beim Arbeiten mit der Cloud immer an
drei Eigenschaften denken muss:
Konsistenz (Consistency), Verfügbarkeit (Availability) und
Partitionstoleranz (Partition Tolerance).
21 | S e i t eLösungsansätze
Am Beispiel einer Web-Applikation erklärt, bedeuten diese Begriffe:
Wenn eine Applikation konsistent ist, führt sie ihre Arbeit immer korrekt aus.
Eine verfügbare Applikation ist jederzeit verfügbar, es gibt also keinen
Zeitpunkt, zu dem sie nicht auf Anfragen antwortet.
Partitionstoleranz bedeutet für eine Applikation, dass sie, obwohl sie mit
unterschiedlichen Partitionen arbeitet, ihre Arbeit auch weiter ausführt, sollte
eine dieser Partitionen kurzfristig ausfallen.
Es sei laut dem Theorem jedoch nie möglich, alle drei Eigenschaften zu erfüllen,
was dazu führt, dass manche Lösungen nicht möglich sind. [Understanding the
CAP Theorem; Brewer's CAP Theorem]
Ein erster Ansatz wäre es, dass AWS sobald jemand eine Instanz erstellen will,
die das Limit überschreitet, dies entweder verhindert, oder sie sofort wieder
herunterfährt.
Sucht man also zum Beispiel einen Weg, eine gerade erstellte Instanz sofort
wieder herunterzufahren, falls sie dieses Limit überschreitet, kommt das
Problem auf, dass man nicht genau weiß, wann Lambda eine Funktion wie z.B.
den AutoTagger aufruft. Wird sie beispielsweise vor dem Fertigstellen der
Instanz aufgerufen, ist es möglich, dass das Limit zu diesem Zeitpunkt noch
nicht überschritten wurde, und deswegen das Erstellen der Instanz erlaubt wird.
Wird das Limit dann erst durch das Erstellen der Instanz überschritten, würde
die Funktion dies erst bemerken, wenn erneut Instanzen erstellt werden
würden. Insbesondere beim gleichzeitigen Erstellen mehrerer Instanzen ist dies
sehr problematisch.
Eine andere Lösung ist es, nicht bei gewissen Events zu testen, ob die Regelung
gebrochen wird, sondern dies in gewissen zeitlichen Abständen zu überprüfen.
Man schreibt also eine Funktion, welche überprüft, ob ein User existiert, der zu
viele laufende Instanzen besitzt, und startet diese in einem festen Zeitabstand.
Dies führt allerdings dazu, zu viele Instanzen gleichzeitig laufen können, und
dies erst nach einer gewissen Zeit erkannt wird.
22 | S e i t eLösungsansätze
Beide Lösungen wären also nicht vollständig konsistent. Im ersten Fall, weil
man nicht genau weiß, wann die Funktion aufgerufen wird, und dies zu Fehlern
führen kann und im zweiten Fall, weil man explizit auf Konsistenz verzichtet,
indem man die Funktion zeit- statt eventgesteuert startet. Es ist aber auch nicht
unbedingt notwendig eine konsistente Funktion zu haben, solange die
Inkonsistenz für den Anwendungszweck akzeptabel ist.
Ist man sich darüber im Klaren, ist die zweite Lösung dementsprechend
vorzugswürdig, da sie immerhin immer so funktioniert wie man es erwartet und
damit wenigstens ein langzeitiges Laufen von zu vielen Instanzen verhindert.
Bevor man die Lambda Funktion nun erstellt, muss man allerdings noch dafür
sorgen, dass eine Rolle mit den notwendigen Berechtigungen existiert, welche
die Funktion annehmen kann.
Hierfür kreiert man über das AWS-IAM-Interface eine Rolle, wählt Lambda als
Service aus, und fügt dann die Richtlinie an, die es der Funktion erlaubt, auf die
notwendigen Ressourcen zuzugreifen und Instanzen zu stoppen.
Abbildung 4 Select Service
Es benötigt die bereits von Amazon generierte Richtlinie „IAMReadOnlyAccess“
sowie eine selbstgeschriebene Richtlinie, die man erstellen kann, indem man im
selben Fenster, in dem man Richtlinien zuweist, auf „Richtlinie erstellen“ geht
und bei der darauffolgenden Seite diesen JSON Code einfügt:
23 | S e i t eLösungsansätze
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ec2:Describe*"
],
"Resource": "*",
"Effect": "Allow"
},
{
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "arn:aws:logs:*:*:log-group:/aws/lambda/*:*:*",
"Effect": "Allow"
},
{
"Action": [
"ec2:StopInstances"
],
"Resource": "arn:aws:ec2:*:*:instance/*",
"Effect": "Allow"
}
]
}
Hat man der Rolle nun beide Richtlinien angefügt und diese fertiggestellt, kann
man die Lambda Funktion erstellen. Im AWS-Lambda Interface über den
Button „Funktion erstellen“ kommt man zu den Einstellungen.
24 | S e i t eLösungsansätze
Man gibt einen Namen ein, wählt als Laufzeit Python 2.7, wählt unter Rolle die,
die man gerade erstellt hat und klickt auf „Funktion erstellen“.
Beim Schreiben Der Funktion lässt man sich zunächst eine Liste alle User
erstellen, um den Rest der Funktion einmal für jeden User ausführen zu
können.
client = boto3.client('iam')
def lambda_handler(event, context):
users = client.list_users()
for user in users.get('Users', [{}]):
Der nächste Schritt ist es, sich immer für den aktuell betrachteten User einen
Filter zu erstellen, der alle laufenden Instanzen des Users anzeigt.
instancefilters = [
{
'Name': 'instance-state-name',
'Values': ['running']
},
{
'Name': 'tag:PrincipalId',
'Values': [user.get('UserId')]
}
]
instances = ec2.instances.filter(Filters=instancefilters)
Nun kann man zählen, wie viele solcher Instanzen existieren um sie
anschließend zu stoppen, falls der Nutzer zu viele, in diesem Beispiel mehr als
fünf, gleichzeitig laufen hat. [Erstellen einer AWS Lambda-Regel]
25 | S e i t eLösungsansätze
if len(RunningInstances) > 5:
shuttingDown = ec2.instances.filter(InstanceIds=RunningInstances).stop()
Das einzige was nun noch fehlt ist, dass die Funktion in einem definierten
zeitlichen Abstand automatisch ausgeführt wird.
Hierfür erstellt man ein CloudWatch Event. Dies funktioniert über das AWS-
Interface und CloudWatch Regeln, welche unter vorher eingestellten
Bedingungen die Lambda Funktion starten kann, indem man auf „Regel
erstellen“ klickt.
Als Ereignisquelle wählt man ein „Bestimmtes Zeitintervall“ und gibt in diesem
Fall 5 Minuten ein. Unter Ziele fügt man dann noch die Lambda Funktion,
welche das automatisierte Stoppen handelt hinzu, gibt der Regel nur noch einen
Namen und eine kurze Beschreibung und erstellt sie.
Abbildung 5 Ereignisquelle
Abbildung 6 Ziel-Funktion
26 | S e i t eLösungsansätze
Jetzt existiert eine Regel, welche alle 5 Minuten die Lambda Funktion auslöst.
Man muss allerdings auch noch der Lambda Funktion mitteilen, dass sie durch
CloudWatch Events gestartet werden kann. Hierzu fügt man in der
Konfiguration der Lambda Funktion den Auslöser „CloudWatch Events“ hinzu.
Unter „Auslöser konfigurieren“ wählt man die Regel, die man gerade erstellt
hat, aktiviert per Klick den Auslöser und fügt ihn dann über einen Button hinzu.
Abbildung 7 Auslöser konfigurieren
Damit wird alle fünf Minuten die CloudWatch Regel ausgelöst, welche ein Event
an die Lambda Funktion sendet und diese somit startet. Dank der Rolle, die ihr
zugewiesen wurde, hat sie alle notwendigen Rechte um immer, wenn sie
gestartet wird, jeden einzelnen User auf eine zu hohe Anzahl an laufenden
Instanzen zu überprüfen, und seine Instanzen bei einem Verstoß zu stoppen.
[Planen von Ausdrücken für Regeln; AWS Lambda-Funktionen mit
CloudWatch-Ereignisse planen]
Der komplette Code der Lambda Funktion ist im Anhang sowie auf der
beigelegten CD zu finden.
27 | S e i t eLösungsansätze
4.2 Automatische Benachrichtigung
Zusätzlich wird noch eine Möglichkeit gesucht, automatisiert
Benachrichtigungen an Administratoren zu senden, wenn das Limit der
Instanzen von einem User nicht eingehalten wird.
4.2.1 Simple Email Service
Durch den Amazon Simple Email Service ist es möglich, schnell und
kostengünstig Emails durch Lambda Funktionen zu versenden.
Zuerst muss man, um SES einzurichten, unter IAM bei Email Addresses eine
neue E-Mail-Adresse verifizieren. Hat man die Verifizierung über die
Bestätigungsemail abgeschlossen, läuft es wieder ähnlich wie vorher ab. Man
erstellt eine Rolle mit den notwendigen Richtlinien für die Lambda Funktion,
und schreibt dann besagte Funktion so, dass sie über SES Emails versenden
kann. [Sending emails with attachments with AWS Lambda and Node.js]
Zum aktuellen Zeitpunkt wird der Amazon Simple Email Service aber nur in
den Regionen US East (N. Virginia), EU (Ireland) und US West (Oregon)
angeboten. Läuft der genutzte Account also nicht auf einer dieser Regionen,
muss man eine andere Möglichkeit finden. Weshalb hier auch nicht weiter auf
diesen Lösungsweg eingegangen wird. [Regionen und Amazon SES]
4.2.2 Simple Notification Service
Mithilfe des Amazon Notification Services kann man auf schnellem Weg
Nachrichten an mehrere unterschiedliche Entitäten, wie beispielsweise E-Mail-
Adressen oder Smartphones, versenden. Hierfür muss man zunächst ein
sogenanntes SNS Topic erstellen. Dafür geht man einfach im AWS-Interface
unter Topics auf „Create new topic“, gibt dem Topic einen Namen und einen
Display Namen und klickt auf „Create Topic“.
28 | S e i t eLösungsansätze
Hat man nun das Topic, kann man es markieren und dann über „Actions“ und
„Subscribe to topic“ einen neuen Endpunkt hinzufügen, an den alle Nachrichten
gesendet werden, welche in dieses Topic gepostet werden.
Abbildung 8 Subscribe to topic
Man wählt einfach das gewünschte Protokoll, beispielsweise „Email“, und gibt
dann den dazugehörigen Endpunkt, hier die E-Mail-Adresse, an. Wurde die
Subscription bestätigt, in diesem Beispiel per Bestätigungsemail, ist diese
abgeschlossen. [Einrichten von Amazon SNS-Benachrichtigungen; Erste
Schritte mit Amazon Simple Notification Service]
Abbildung 9 Create subscription
29 | S e i t eLösungsansätze
Nun benötigt man nur noch eine Lambda Funktion, die Nachrichten an das
Topic, und damit alle seine Subscriber, sendet. In diesem Fall benötigt man
dafür keine zusätzliche Funktion, sondern kann einfach die, die bereits zum
automatischen Stoppen von Instanzen verwendet wird, anpassen.
Hierfür benötigt die Funktion allerdings mehr Berechtigungen, als die die sie
bisher über Ihre Rolle erhält. Die einfachste Lösung hierfür ist es, die Rolle,
welche die Lambda Funktion angenommen hat so zu erweitern, dass sie alle
Aktionen verwenden kann, die sie zum Senden von Nachrichten über SNS
braucht. Man öffnet also einfach über das AWS-Interface die besagte Rolle und
fügt ihr die von Amazon bereitgestellten Richtlinien „AWSLambdaFullAccess“,
„CloudWatchFullAccess“ und „AmazonSNSFullAcces“ an.
Um nun mit der Lambda Funktion Nachrichten an ein Topic senden zu können
benötigt man einen neuen Client und eine Default-Message.
snsclient = boto3.client('sns', region_name='eu-central-1')
message = {"foo": "bar"}
Danach fügt man der Funktion direkt nach der Stelle, an der die Instanzen
heruntergefahren werden, Code hinzu, welcher die Nachricht an das
gewünschte Topic, welches man über seine ARN spezifiziert, sendet. Hierbei
kann man auch einrichten, dass man je nach Protokoll des Endpunktes
unterschiedliche Nachrichten versendet.
30 | S e i t eLösungsansätze
response = snsclient.publish(
TargetArn='HierDieARNDesTopics,
Message=json.dumps({'default': json.dumps(message),
'sms': str(user.get('UserName')) + ' had to many EC2 Instances.',
'email': str(user.get('UserName')) +' had to many running EC2
Instances, so they have been stopped.'}),
Subject='StoppedEC2Instances',
MessageStructure='json'
)
In diesem Fall werden alle SMS Subscriber des Topics eine Nachricht erhalten
die den Usernamen gefolgt von „had to many EC2 Instances.“ umfasst, während
E-Mail Subscriber die Nachricht „“Username“ had to many running EC2
Instances, so they have been stopped.” Empfangen. Dies kann man nach
Belieben verändern, um eventuell E-Mail Subscribern noch mehr
Informationen zu senden, während man SMS Subscriber nur kurz
benachrichtigt. [Using Lambda Function with Amazon SNS]
31 | S e i t eErgebnis
5 Ergebnis
Nun folgt eine Zusammenfassung der Arbeit. Außerdem wird ein Fazit gebildet
und ein kurzer Ausblick für die Zukunft gegeben.
5.1 Zusammenfassung und Fazit
Das Hauptziel dieser Bachelorarbeit wurde im Prinzip erreicht. Von den drei
vorgestellten Lösungsansätzen war nur die Lösung über das Amazon Command-
Line-Interface aufgrund dessen niedriger Mächtigkeit nicht realisierbar.
Dennoch war das CLI bei der restlichen Arbeit mit AWS von Nutzen.
Die Lösung über ein Python-Skript garantiert in der Theorie zwar, die
Erstellung von EC2 Instanzen so zu limitieren, dass es unmöglich ist, mehr als
eine gewisse Anzahl hochzufahren. Aufgrund des dafür nötigen, hohen Client-
Trust und der Tatsache, dass man sich zwischen geringen
Anpassungsmöglichkeiten und einer benutzerunfreundlichen Eingabe
entscheiden muss, ist diese Lösung für die meisten Anwendungsbereiche aber
nicht zufriedenstellend.
Durch die Verwendung der AWS-Services IAM, CloudWatch, CloudTrail,
CloudFormation und allem voran Lambda, welche miteinander kommunizieren,
ist man jedoch in der Lage zu verhindern, dass zu viele Instanzen über eine zu
lange Zeit laufen. Dennoch ist es hier weiterhin möglich, das Limit kurzfristig zu
überschreiten.
Das Nebenziel Administratoren automatisiert zu benachrichtigen konnte leider
nicht mit dem Amazon Simple Email Service realisiert werden. Dieser ist zwar
sehr gut geeignet für das Lösen der Aufgabe, ist aufgrund der geringen Anzahl
an Regionen, in welchen er verfügbar ist, zum aktuellen Zeitpunkt aber keine
Option.
Der Amazon Simple Notification Service hingegen kann durch Lambda
automatisiert versendete Nachrichten an Endpunkte weiterleiten, welche nicht
nur E-Mail-Adressen, sondern auch Smartphones und viele andere sein können.
Dies eignet sich besonders gut, da die Nachrichten auch für jeden Endpunkt
einzeln spezifiziert werden können, was es ermöglicht beispielsweise per SMS
32 | S e i t eErgebnis
nur kurze Benachrichtigungen zu senden, während E-Mails detailliertere
Informationen enthalten.
Aus diesen Gründen empfehle ich eine Kombination aus der Lambda Lösung
aus Kapitel 4.1.3 und der Benachrichtigung mittels Simple Notification Service
aus Kapitel 4.2.2.
5.2 Ausblick
Um die Limitierung der Instanzen besser personalisierbar zu machen, wäre es
möglich allen Usern Tags anzufügen, welche beinhalten wie viele laufende
Instanzen der jeweilige User gleichzeitig besitzen darf. Dann könnte man,
anstatt das Limit hart zu kodieren, immer abfragen welches spezifische Limit
gerade getestet wird.
Von Seiten Amazons besteht natürlich die Möglichkeit, dass sie selbst ein
Attribut oder ähnliches zu User-Konten hinzufügen, welches direkt die
maximale Anzahl an Instanzen dieser beschränkt und von administrativen
Nutzern bearbeitet werden kann.
Bei der Benachrichtigung können noch mehr Endpunkte hinzugefügt werden,
falls man beispielsweise über http Protokolle oder ähnliches senden will.
Außerdem können die Informationen, welche die Nachrichten beinhalten
ausgeweitet werden um den Administrator zum Beispiel darüber zu informieren
welche Instanzen genau gestoppt worden sind.
33 | S e i t eLiteraturverzeichnis
Literaturverzeichnis
[AWS Lambda-Funktionen mit CloudWatch-Ereignisse planen]; AWS Lambda-
Funktionen mit CloudWatch-Ereignisse planen, 22.02.2019,
https://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/events/RunLamb
daSchedule.html.
Abgerufen am 26.02.2019.
[Planen von Ausdrücken für Regeln]; Planen von Ausdrücken für Regeln, 22.02.2019,
https://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/events/Scheduled
Events.html.
Abgerufen am 26.02.2019.
[Sending emails with attachments with AWS Lambda and Node.js]; Sending emails
with attachments with AWS Lambda and Node.js, 2018,
https://medium.com/@xoor/sending-emails-with-attachments-with-aws-lambda-
and-node-js-e6a78500227c.
Abgerufen am 26.02.2019.
[Einrichten von Amazon SNS-Benachrichtigungen]; Einrichten von Amazon SNS-
Benachrichtigungen, 22.02.2019,
https://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/US_
SetupSNS.html.
Abgerufen am 26.02.2019.
[Regionen und Amazon SES]; Regionen und Amazon SES, 22.02.2019,
https://docs.aws.amazon.com/de_de/ses/latest/DeveloperGuide/regions.html.
Abgerufen am 26.02.2019.
[Erstellen einer AWS Lambda-Regel]; Erstellen einer AWS Lambda-Regel, 22.02.2019,
https://docs.aws.amazon.com/de_de/iot/latest/developerguide/iot-lambda-
rule.html.
Abgerufen am 26.02.2019.
[Quickstart]; Quickstart, 25.02.2019,
https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html.
Abgerufen am 26.02.2019.
[Installation]; Installation, 20.02.2019, https://pip.pypa.io/en/stable/installing/.
Abgerufen am 26.02.2019.
[How to Automatically Tag Amazon EC2 Resources in Response to API Events]; How
to Automatically Tag Amazon EC2 Resources in Response to API Events, 2016,
https://aws.amazon.com/de/blogs/security/how-to-automatically-tag-amazon-ec2-
resources-in-response-to-api-events/.
Abgerufen am 26.02.2019.
[Brewer's CAP Theorem]; Brewer's CAP Theorem, 14.10.2018,
http://www.julianbrowne.com/article/brewers-cap-theorem.
Abgerufen am 26.02.2019.
34 | S e i t eLiteraturverzeichnis
[Understanding the CAP Theorem]; Understanding the CAP Theorem,
https://dzone.com/articles/understanding-the-cap-theorem.
Abgerufen am 26.02.2019.
[Erste Schritte mit Amazon Simple Notification Service]; Erste Schritte mit Amazon
Simple Notification Service, 22.02.2019,
https://docs.aws.amazon.com/de_de/sns/latest/dg/sns-getting-
started.html#SubscribeTopic.
Abgerufen am 26.02.2019.
[Was sind Tags?]; Was sind Tags?, https://praxistipps.chip.de/was-sind-tags-einfach-
erklaert_41634.
Abgerufen am 26.02.2019.
[What is an SDK?]; What is an SDK?, 2017, https://www.braze.com/blog/what-is-an-
sdk-overview/.
Abgerufen am 26.02.2019.
[Template Definition]; Template Definition,
https://techterms.com/definition/template.
Abgerufen am 26.02.2019.
[Using a lambda function, stop all instances that are tagged appropriately.]; Using a
lambda function, stop all instances that are tagged appropriately.,
https://gist.github.com/mlapida/1917b5db84b76b1d1d55.
Abgerufen am 26.02.2019.
[What is a Programming Tool?]; What is a Programming Tool?,
https://www.techopedia.com/definition/8996/programming-tool.
Abgerufen am 26.02.2019.
[What is Network protocol?]; What is Network protocol?,
https://searchnetworking.techtarget.com/definition/protocol.
Abgerufen am 26.02.2019.
[Was ist die Cloud]; Was ist die Cloud, https://azure.microsoft.com/de-
de/overview/what-is-the-cloud/.
Abgerufen am 26.02.2019.
[Using Lambda Function with Amazon SNS]; Using Lambda Function with Amazon
SNS, 18.02.2019,
https://www.tutorialspoint.com/aws_lambda/aws_lambda_using_lambda_functio
n_with_amazon_sns.htm.
Abgerufen am 26.02.2019.
[What is Amazon EC2 instance?]; What is Amazon EC2 instance?,
https://searchaws.techtarget.com/definition/Amazon-EC2-instances.
Abgerufen am 26.02.2019.
[Open Source Definition]; Open Source Definition,
https://www.gruenderszene.de/lexikon/begriffe/open-source?interstitial.
Abgerufen am 26.02.2019.
[JSON]; JSON, 04.02.2019, https://www.json.org/.
Abgerufen am 26.02.2019.
35 | S e i t eLiteraturverzeichnis
[Download Python]; Download Python, https://www.python.org/downloads/.
Abgerufen am 26.02.2019.
[Service-orientierte Architekturen mit Web Services]
Melzer, Ingo; Service-orientierte Architekturen mit Web Services: Konzepte -
Standards - Praxis, 3. Auflage, Heidelberg. Spektrum Akademischer Verlage, 2008.
[The NIST definition of cloud computing]
Mell, P. M.; Grance, T.; The NIST definition of cloud computing, Gaithersburg, MD.
National Institute of Standards and Technology, 2011.
[Was ist IAM?]; Was ist IAM?, 22.02.2019,
https://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/introduction.html.
Abgerufen am 26.02.2019.
[IAM-Rollen]; IAM-Rollen, 22.02.2019,
https://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/id_roles.html.
Abgerufen am 26.02.2019.
[Richtlinien und Berechtigungen]; Richtlinien und Berechtigungen, 22.02.2019,
https://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/access_policies.html.
Abgerufen am 26.02.2019.
[Amazon Elastic Compute Cloud]; Amazon Elastic Compute Cloud, 18.02.2019,
https://aws.amazon.com/de/ec2/.
Abgerufen am 26.02.2019.
[Nutzung von Cloud Computing in deutschen Unternehmen bis 2017]; Nutzung von
Cloud Computing in deutschen Unternehmen bis 2017,
https://de.statista.com/statistik/daten/studie/177484/umfrage/einsatz-von-cloud-
computing-in-deutschen-unternehmen-2011/.
Abgerufen am 26.02.2019.
[IT-Services - Weltweite Ausgaben bis 2020]; IT-Services - Weltweite Ausgaben bis
2020, https://de.statista.com/statistik/daten/studie/184781/umfrage/weltweite-
ausgaben-fuer-it-services/.
Abgerufen am 26.02.2019.
[Informationen zu AWS]; Informationen zu AWS, 16.02.2019,
https://aws.amazon.com/de/about-aws/.
Abgerufen am 26.02.2019.
[The Three Most Widely Used Amazon Web Services]; The Three Most Widely Used
Amazon Web Services, 2014, http://techgenix.com/three-most-widely-used-
amazon-web-services/.
Abgerufen am 26.02.2019.
[Kampf um die Cloud: So balgen sich die Tech-Riesen]
Helen Laube; Kampf um die Cloud: So balgen sich die Tech-Riesen,
https://www.handelszeitung.ch/unternehmen/kampf-um-die-cloud-so-balgen-sich-
die-tech-riesen.
Abgerufen am 26.02.2019.
36 | S e i t eSie können auch lesen
