Überspringen zu Hauptinhalt

AWS (Amazon Web Services)

Zur Beantwortung dieser Fragen haben wir den Artikel “Public-Cloud-Hosting im E-Commerce: Wann lohnt sich Amazon Web Services – und wann nicht?” auf t3n.de veröffentlicht.

Ihre AWS-Ressourcen liegen – wenn nicht anders vereinbart – im AWS Rechenzentrum in Frankfurt, Deutschland. AWS Dienste außerhalb der EU werden ohne Ihre explizite Aufforderung nicht eingesetzt. Darüber hinaus können wir Ihren Shop oder Ihre Applikation in vielen Regionen weltweit hosten: Irland, USA, Singapur, Japan, Australien, Brasilien und sogar China.

Amazon Web Services hat eine große Anzahl an Zertifizierung / Testierungen absolviert und geht mit vielen internationalen und nationalen Gesetzen und Regelungen konform. Um nur einige zu nennen: C5 Standard des Bundesamtes für Sicherheit in der Informationstechnik (BSI)ISO 27001EU-Datenschutz und PCI DSS. Weitere Informationen zu den Programme zur Bestätigung der Sicherheit von Amazon Web Services finden Sie unter https://aws.amazon.com/de/compliance/.

Speziell für Deutschland finden Sie im German Data Protection Whitepaper (Stand Januar 2017) Erläuterungen, wie Sie AWS-Dienste in Übereinstimmung mit dem Bundesdatenschutzgesetz (BDSG) nutzen können und dabei die Kontrolle über Daten im Generellen und über personenbezogene Daten im Speziellen behalten.

Die Datenschutzgrundverordnung (DSGVO) der Europäischen Union, die mit ihren strengen Anforderungen die Standards für Datenschutz, Sicherheit und Compliance anhebt und vereinheitlicht, erfüllt AWS. Hierzu wurde das Datenschutz-Grundverordnung (DSGVO) Zentrum von AWS eingerichtet.

Für die Mehrheit der AWS-Dienste gilt eine Verfügbarkeit von 99,99%. Detail zu konkreten AWS-Diensten finden Sie in den AWS SLA.

Beim Cloud Hosting für Online-Anwendungen setzen wir im Wesentlichen diese Instanz-Typen ein:

T-Instanzen sind die Allzweck-Waffe von AWS. Ausgestattet mit einem Burst-Modus sammeln sie im Leerlauf “Credits”, die sie dann zur Bearbeitung von Spitzenlasten einsetzen können. Somit sind sie vor allem für Workloads geeignet, bei denen die Nutzung der CPU schwankt – wie z.B. Webserver oder Datenbanken). T3 gibt es ab 1 vCPU mit 0,5 GB RAM bis 8 vCPU mit 32 GB RAM.

M-Instanzen sind allgemeine Instanzen mit ausbalancierten Datenverarbeitungs-, Arbeitsspeicher- und Netzwerkressourcen. Sie werden diese Instanzen benötigen, wenn T-Instanzen nicht mehr ausreicht, jedoch keine speziellen Anforderungen im Bereich RAM oder CPU vorhanden ist. M5 gibt es ab 2 vCPU mit 8 GB RAM bis 96 vCPU mit 384 GB RAM.

C-Instanzen sind für Datenverarbeitung (CPU) optimiert. C-Instanzen nutzen wir für Applikations- bzw. Web-Server mit höheren Leistungsanforderungen. C5 gibt es ab 2 vCPU mit 4 GB RAM bis 72 vCPU mit 144 GB RAM.

X/R-Instanzen sind auf RAM optimiert und eignen sich damit entsprechend für RAM-intensive Anwendungen wie Datenbanken oder Caches. R5/X1 gibt es z.B. ab 2 vCPU mit 16 GB RAM bis 128 vCPU mit 1.952 GB RAM.

Darüber hinaus gibt es noch weitere Instanztypen, die bei Online-Anwendungen seltener ihren Einsatz finden. Im Detail werden die Instanz-Typen und ihre jeweiligen Eigenschaften unter https://aws.amazon.com/de/ec2/instance-types/ erläutert.

Schon bei der RDS MySQL Lösung von AWS gibt es die Möglichkeit, sogenannte Read Replicas einzusetzen. Read Replicas machen dann Sinn, wenn eine Applikation sehr hohe Datenbanklast bei lesenden Anfragen erzeugt und man diese auf mehrere Datenbanken verteilen will. Auf die Read Replicas greift die Applikation dann lesend zu, während (nur noch) die Schreibzugriffe auf der Master-Datenbank ankommen. Bei RDS MySQL muss jedes Read Replica einzeln angesprochen werden. Bei der MySQL-kompatiblen AWS Aurora gibt es hierfür eine Lösung: über einen separaten zentralen Endpunkt kann man verteilt (Load Balancing) auf alle Read Replicas zugreifen. Somit ergibt sich die Möglichkeit, weitere “Read-Only” Datenbanken bei Bedarf hinzuzuschalten und damit die lesenden Anfragen der Applikation zu skalieren (vgl. AWS Blogpost). Diese Skalierung ist jedoch nicht dem horizontalen Autoscaling von Webservern vergleichbar.

Mehr dazu können Sie auf unserer Seite: Wozu Cloud Hosting? nachlesen.

AWS Managed Cloud

AWS stellt Cloud-Infrastruktur zum Selfservice bereit und übernimmt weder Setup noch 247/7 Management. Für Planung, Migration, Betrieb und Optimierung einer AWS-Lösung ist der Kunde selbst verantwortlich. Dazu kommt, dass die Komplexität an Diensten und Funktionen bei AWS ständig zunimmt und zudem speziellen Know-how erfordert. 

Wenn sich nun Ihre IT-Abteilung auf ihre Kernaufgaben konzentrieren soll und/oder spezielle Lösungen (z.B. Spryker Hosting auf AWS) benötigt wird, kann root360 mit seinem Team an zertifizierten AWS-Experten diese Aufgaben insbesondere 24/7 Überwachung mit proaktiver Entstörung übernehmen. 

Ja. Wir haben hier eine Reihe von Lösungen, Ansätzen und vor allem Erfahrungen parat.

Root360 ist ein Hosting-Anbieter einer neuen Generation mit Spezialisierung auf Bereitstellung und den 24/7-Betrieb von skalierbaren und ausfallsicheren Cloud-Architekturen für Online-Unternehmen. Die hierfür notwendigen Serverkapazitäten werden flexibel durch AWS zur Verfügung gestellt. Wir sind Advanced Consulting und Reseller Partner von Amazon Web Services sowie Gewinner des EuroCloud Deutschland Awards 2016. Über 100 namhafte Kunden wie SIXT Leasing, SugarShape, HALLHUBER, Steigenberger oder Bookingkit konnten wir bereits für unsere Lösung überzeugen. Überzeugt das:)?

Zunächst übernehmen wir das technische Monitoring (Erreichbarkeit, Systemauslastung, Festplattenauslastung) aller Server-Instanzen. Enthalten sind auch die Dienst- sowie die Applikationsüberwachung von HTTP(S) und Datenbanken. Erkannte Störungen werden von uns proaktiv bearbeitet und im Bedarfsfall an den Kunden eskaliert. Durch die Kombination verschiedener Redundanzebenen können somit bis zu 99,99% Verfügbarkeit erreicht werden. Die Überwachung von Applikation und Server erfolgt rund um die Uhr (24/7) mit max. 1 h Reaktionszeit.

Generell verstehen wir unter Wartung bzw. Service Management üblich anfallende Tätigkeiten, um Ihre Cloud-Umgebung “up and running” zu halten. Details finden sich unter AWS Managed Services.

Wir überwachen 24/7 laufend und ununterbrochen alle relevanten technischen Parameter wie CPU, RAM, Festplatte und http-Strecke Ihrer Cloud-Umgebungen durch mehrere Monitoring-Systeme. Wenn diese Systeme einen Ausfall melden, leiten wir proaktiv Notfallmaßnahmen zur Behebung des Ausfalls und Wiederherstellung der Verfügbarkeit ein. Sollte das System eingeschränkt verfügbar oder beeinträchtigt sein, so analysieren wir das Problem und halten Rücksprache mit Ihnen.

Ja. Unsere Rufbereitschaft bzw. Support-Hotline ist 24/7 (rund um die Uhr) besetzt und erreichbar. Darüber hinaus kann unser Ticket-System genutzt werden, welches ebenfalls 24/7 betreut wird.

Ja natürlich. Sie haben die Möglichkeit, mit uns eine Auftragsverarbeitungsvereinbarung (kurz: AVV) zu schließen.

Unser Angebot umfasst Consulting, die Implementierung & Umsetzung Ihrer AWS-Infrastruktur (inklusive Unterstützung der Migration) und das Management Ihrer Cloud-Lösung (inklusive 24/7 Monitoring & Support).

Ja. Wir betreiben bereits Cloud Umgebungen bei AWS China und kennen damit die Herausforderungen und Möglichkeiten.

Produkte & Lösungen

Ja. Wir haben Lösungen für Managed Docker bzw. Managed Kubernetes, die auf AWS ECS sowie AWS EKS basieren und sich nahtlos mit anderen AWS Diensten kombinieren lassen.

Nach Bereitstellung Cloud Umgebung erhalten Sie bzw. Ihre Entwickler eine persönliche Einführung in die neue Umgebung, eine Dokumentation sowie persönliche Unterstützung beim Umzug Ihrer Applikation durch unsere Mitarbeiter.

Ja, unbedingt. Wir stellen für Sie beim Setup Ihrer Cloud-Umgebung Mechanismen und Lösungen bereit, damit das Deployment (also Aufspielen bzw. Aktualisieren) Ihrer Applikation (Shop, PHP-App, CMS) einfach und stabil funktioniert – sowohl bei automatisch skalierenden Systemen als auch Docker.

Ja. Wir empfehlen dies sogar, da über GIT die Nachverfolgbarkeit von Änderungen gegeben ist.

Ja, wir unterstützen bei der Anbindung des Cloud-Deployments an Ihre CI bzw. Deployment-Pipeline (z.B. Bitbucket, GitLab, Jenkins).

Bei einer Cloud-Umgebung mit nur einem Web-Server wird das Aufspielen der Software per SSH direkt auf dem Web-Server angeboten. Bei Cloud-Umgebungen mit mehreren Web-Servern (bei Autoscaling bzw. Redundanz-Anforderungen) erfolgt das Deployment über ein Deployment-System, welches die Applikation automatisch auf die Web-Server verteilt. Dabei wird die Software von einer definierten Quelle (GIT, Download, FTP) automatisch bezogen und auf die verfügbaren Server verteilt. Die Installation auf jedem Server kann mittels eines Bash-Scriptes gesteuert werden. Hier gibt es weitere Details zu root360 Code Deploy.

Jede AWS-Umgebung bei root360 verfügt über Standard-Mechanismen, um Angriffe wie DDoS-Attacken zu begegnen. Dazu gehören:

  • netzwerkseitige Trennung von extern erreichbaren und nicht erreichbaren Systemen
  • restriktive Firewall-Regeln zwischen den Server
  • restriktive Netzwerk-ACLs zwischen den Netzwerksegmenten
  • Aktivierung AWS Shield (Managed DDoS Protection)
  • Einsatz von AWS Loadbalancern mit implementierten Erkennungs- und Vermeidungstechniken
  • Monitoring-Systeme zur Erkennung von DDoS Angriffen

Darüberhinaus steht uns ein breites Arsenal an weiteren Werkzeugen zur Verfügung, um Angriffe zu verhindern, zu erkennen und abzuwehren.

Wir sehen unseren Kompetenz-Schwerpunkt bei Web-Applikationen. Hier betreuen wir von Websites bis reichweitenstarken Portalen oder SaaS-Lösungen ein breites Spektrum an Kunden.

Im E-Commerce Bereich haben wir bei Spryker, Shopware, Magento und OXID wesentliche Kompetenzen für Managed Cloud Hosting mit AWS, Lastspitzen und Optimierung aufgebaut.

Unter Up-Scaling verstehen wir die Veränderung des Instanztyps eines AWS Diensts. Ein Beispiel: Es wird eine EC2-Instanz vom Typ “t3.medium” genutzt. Diese soll zu einer “t3.large” verändert werden.

Up-Scaling (also vertikale Skalierung) erfolgt in solchen Fällen manuell. D.h. wenn wir über unsere Metriken erkennen, dass andere Instanztypen für den derzeitigen Workload besser geeignet sind, ändern wir den Instanztyp unterbrechnungsfrei nach Rücksprache mit unserem Kunden. Dabei werden alle Instanzen neu aufgebaut und der alte Instanztyp terminiert.

Im Gegensatz dazu erfolgt die horizontale Skalierung im Rahmen der initial festgelegten Rahmenparameter automatisch. Bei Single Server Umgebungen ist ein Reboot für den Wechsel der Instanzgröße notwendig.

Hardware-Redundanz bedeutet für uns, dass ein Service (z.B. Webserver, Datenbank oder Cache) aus mindestens zwei Instanzen besteht und seine Daten zu jedem Zeitpunkt somit mindestens doppelt vorgehalten werden. Bei uns bedeutet Redundanz somit gleichzeitige erhöhte Ausfallsicherheit, da im Fall des Ausfalls einer Instanz sofort eine andere Instanz die Aufgaben übernimmt. Die ausgefallene Instanz wird dann erneuert und dem Service wieder hinzugefügt.

Ausfallschutz (Ausfallsicherheit) durch automatische Wiederherstellung bezieht sich bei uns auf Services (Webserver, Datenbank, Cache), die nur aus einer Instanz bestehen oder bestehen dürfen. Im Fall des Ausfalls dieser Instanz wird sie innerhalb weniger Minuten mit dem Datenstand vor dem Ausfall automatisch wieder zur Verfügung gestellt. Hierbei kann es in Einzelfällen zu Dateninkonsistenzen kommen, die dann über das Einspielen von Backups behoben werden müssen.

Im Fall des Ausfalls einer Instanz wird sie innerhalb weniger Minuten mit dem Datenstand von vor dem Ausfall automatisch wieder zur Verfügung gestellt. Hierbei kann es in Einzelfällen zu Dateninkonsistenzen kommen, die dann über das Einspielen von Backups behoben werden müssen. Um dieses verbleibende Restrisiko weiter zu reduzieren, empfehlen wir die Nutzung von mindestens zwei parallel laufenden Instanzen – wenn dies wie bei Web-Servern oder Datenbanken möglich ist.

Die Dimensionierung und Zusammenstellung der Hardware kann jederzeit angepasst werden bzw. erfolgt über Automatismen. Dennoch wird oft ein Ausgangspunkt – vor allem für die Einschätzung der Kosten – gewünsch. Daher fragen wir auch die grobe Dimensionierung der Hardware ab. Hier ist wichtig zu wissen, dass dies keine statische Festlegung ist. Ihre Cloud Umgebung wird (nur) mit der Hardware ausgestattet sein, dies sie tatsächlich benötigt.

Standardmäßig führen wir täglich (Nachts) Snapshots von allen Server und Datenbanken. Bei Bedarf kann die Frequenz erhöht werden. Details zum Backup finden Sie hier.

Ja, E-Mails können über mehrere Wege versendet werden:

  • Sendmail(): Der Standard in vielen PHP-Anwendungen. Es ist zu beachten, dass die Vorteile der flexiblen AWS-Infrastruktur bei vielen Spammern zum Einsatz kommen. Daher sind die IP-Bereiche von AWS bei vielen Mail-Server bereits negativ vorbelastet. Dieser Weg wird nicht empfohlen.
  • Externer SMTP-Server: Der Versand über einen Externen SMTP-Server als Mail-Relay ist eine gängige Möglichkeit für einen sicheren E-Mail Versand. Es ist auch hier zu beachten, dass AWS aus Gründen des Spamschutzes den Port 25 überwacht und ggf. reglementiert. Wir empfehlen daher den verschlüsselten Versand über TLS/SSL auf Port 465 oder 487.
  • AWS Simple E-Mail Service: AWS SES ist ein Mail-Relay, welcher bei fast allen großem Mail-Providern “whitelisted” ist. Um dieses Qualitätsmerkmal aufrecht zu erhalten, muss jede Absender-Domain per DNS (TXT-Record) validiert werden.

Auf der AWS Infrastruktur können vorhandenen SSL-Zertifikate importiert und genutzt werden, sofern die Zertifikatsinformationen (Key, Zertifikat, ggf. Chain) vorhanden sind. Alternativ nutzen Sie die kostenfreien SSL-Zertifikate von AWS, die wir selbstverständlich für Sie managen.

Gerade bei Multi-Server Umgebungen kann das Zusammensuchen der einzelnen Logfiles zur Geduldsprobe werden. Bei uns werden die Logfiles automatisch zentral auf einem “Jump-Server” 30 Tage vorgehalten. Dabei werden standardmäßig alle Logs der Applikation (Apache2, NGINX usw.) von allen Servern bereitgestellt. Es ist ebenfalls möglich, dass anwendungsspezifische Logs aufgenommen werden, sofern diese root360 bekannt sind.

Neben dem obligatorischen Zugriff auf die Cloud-Umgebung per SSH stellen wir unseren Kunden das root360 Cloud Dashboard zur Verfügung. Dieses Dashboard stellt Metriken wie CPU, RAM, Zugriffe, Auslastung der einzelnen Cloud-Komponenten im Kontext Ihrer konkreten Cloud-Architektur dar. Weitere Informationen dazu finden sich unter root360 Cloud Plattform.

Rechnung & Vertrag

Root360 richtet für jeden Kunden einen dedizierten Account (Konto) bei Amazon Web Services (AWS) ein. Die Kosten für die verbrauchten Amazon AWS Ressourcen werden von root360 in Rechnung gestellt. Sie erhalten eine deutsche Rechnung in EUR mit deutscher MwSt.

Ihr Vertragsverhältnis mit root360 beginnt mit Unterschrift des Auftraggebers und hat keine Mindestlaufzeit. Eine Kündigung ist somit jederzeit möglich. Auf Wunsch bieten wir Verträge auch mit Laufzeiten (z.B. 6 oder 12 Monate) an. Sofern Sie reservierte Amazon Web Services Ressourcen über root360 einsetzen, dann entspricht die Mindestlaufzeit des Vertrags mit root360 dem Zeitraum der Reservierung der Ressourcen.

Sollte der Vertrag zwischen root360 und dem Kunden beendet werden und/oder nicht mehr fortgesetzt werden können, so kann dieser Account durch Sie übernommen werden.

Load More

An den Anfang scrollen