Wie man Amazon ECS Fargate mit Terraform aufsetzt

Amazon ECS Fargate ist eine von zwei Optionen, um containerbasierte Anwendungen in der AWS Cloud auszuführen (oft auch Container-Orchestrierung genannt). ECS Fargate ist sozusagen die luxuriösere Option, da die komplette Verwaltung der zugrunde liegenden Infrastruktur wie EC2-Instanzen oder Autoscaling-Gruppen von Amazon übernommen wird. ECS Fargate wird daher oft als serverlos bezeichnet (obwohl technisch gesehen immer noch viel Backend-Infrastruktur dahintersteckt).

Wir haben uns in einem anderen Artikel bereits mit der deutlich komplexeren Konfiguration von ECS auf EC2 beschäftigt und konzentrieren uns hier nun auf ein gleichwertiges, produktionsreifes Setup basierend auf ECS Fargate. Dabei berücksichtigen wir alle wichtigen Sicherheitsbest Practices, Skalierbarkeit sowie den operativen Aufwand. Um mit modernen und effizienten Entwicklungsmethoden wie trunk-based development und Continuous Integration sowie Continuous Deployment arbeiten zu können, verwenden wir ausnahmslos Infrastructure-as-Code mit Terraform zur Bereitstellung der Infrastrukturressourcen.

Die Terraform-Codebeispiele in diesem Artikel sind auf die Änderungen zur EC2-basierten Version von ECS beschränkt. Es wird daher dringend empfohlen, beide Artikel zu studieren, um ein solides Verständnis der technischen Hintergründe aufzubauen. Alle Codequellen für das ECS-Fargate-Setup findest du im entsprechenden GitHub-Repository als funktionierendes Beispiel in produktionsreifer Qualität. Um das Repository zu klonen, führe den folgenden Befehl aus und schau dir die README-Datei an:

Der Aufbau einer Infrastruktur in AWS kann mit Kosten verbunden sein. Alle Ressourcen sollten daher nach dem Ausprobieren wieder entfernt werden, was mit einem einfachen terraform destroy leicht möglich ist.

Bei Gyden unterstützen wir Startups und KMUs beim Aufbau ihrer cloud-nativen Infrastruktur, um maximale Skalierbarkeit, Sicherheit und Flexibilität bei voller Kostenkontrolle zu ermöglichen. In diesem Zusammenhang hat sich ECS Fargate in den letzten Jahren zu einer beliebten Funktionalität entwickelt, die immer häufiger für Anwendungen unterschiedlicher Grössen eingesetzt wird. In dieser Artikelserie über Cloud Computing in AWS werden wir daher alle verschiedenen in der Amazon Cloud verfügbaren Technologien beleuchten.

Was ist Amazon ECS?

Amazon ECS ist eine verwaltete Plattform für die Orchestrierung von Docker-Containern. Sie läuft auf Clustern virtueller Maschinen (VM) innerhalb der AWS Cloud und verwaltet (stellt bereit, skaliert und plant) diese Instanzen innerhalb verschiedener Availability Zones und in den ausgewählten AWS-Regionen. Die Verwaltung von EC2-Instanzen kann entweder eigenständig erfolgen oder mit ECS Fargate vollständig abstrahiert werden. Deine Anwendungen laufen auf Instanzen, auf denen Docker vorinstalliert ist.

ECS bietet eine programmatisch verwaltbare Plattform mit weiteren integrierbaren Extras wie Log-Management über CloudWatch oder ein feingranulares Berechtigungssystem über IAM. Amazon ECS kann für kleine, mittlere und grosse Workloads eingesetzt werden und skaliert mühelos und bedarfsorientiert.

Wie der Name schon sagt, ist Amazon ECS eine Lösung, die auf die AWS Cloud spezialisiert ist. Wenn Du also eine Multi-Cloud-Strategie für Deine Anwendung benötigst oder Portabilität zu anderen Cloud-Anbietern für notwendig erachtest, musst Du bei ECS mit zusätzlichem Aufwand rechnen, der bei Kubernetes geringer ist.

Begriffe und ihre Bedeutung

Im ECS-Universum stösst man auf eine Vielzahl von Begriffen, die für bestimmte Teile dieser Technologie spezifisch sind. Die wichtigsten Begriffe sind die folgenden:

ECS Cluster

Ein ECS Cluster ist der Überbau für das gesamte Setup in ECS. Ein Cluster enthält mehrere EC2-Instanzen oder Container-Instanzen (auch unterschiedlicher Typen wie On-demand-Instanzen oder Spot-Instanzen). Ein ECS-Cluster enthält einen oder mehrere ECS-Services.

ECS Service

Ein ECS Service ist für eine bestimmte Anzahl von ECS Tasks verantwortlich und verwaltet deren Ausführung innerhalb eines ECS Clusters auf den zugehörigen Container Instances. Im einfachen Fall kann ein ECS Service als ein (Mikro-)Service, d.h. eine Anwendung oder ein Webservice, der mit einer definierten Redundanz ausgeführt wird, angesehen werden.

ECS Task

Ein ECS Task entspricht de facto einem ausführbaren Docker-Container, der in der Regel eine Instanz einer Anwendung ausführt. Der zugehörige ECS-Dienst definiert, wie viele Instanzen eines ECS Tasks ausgeführt werden sollen. Jede ECS-Aufgabe verwendet eine spezifische Aufgabendefinition, die wiederum mit einem getaggten Docker-Image verknüpft ist.

ECS Task Definition

Eine ECS Task Definition ist die Definition des zugehörigen Docker-Images mit Informationen über Host-Port, Container-Port, gemountete Laufwerke, Protokollkonfigurationen oder CPU und Speicher. Bei jedem Einsatz wird eine neue Task-Revision erstellt, die eine überarbeitete Task-Definition enthalten kann.

Container Instance

Eine Container Instance ist das Synonym für eine EC2-Instanz, d.h. eine virtuelle Maschine, die als Laufzeitumgebung für ECS-Cluster und damit ECS-Aufgaben dient. Eine EC2-Instanz wird nur im Zusammenhang mit einem ECS-Cluster als Container-Instanz bezeichnet.

ECS Container Agent

Der ECS Container Agent ermöglicht es Container-Instanzen, sich mit dem ECS-Cluster zu verbinden. Der ECS Container Agent ist in allen ECS-optimierten AMIs enthalten, kann aber auch manuell auf jedem kompatiblen Betriebssystem (OS) installiert werden.

Amazon ECS – der Goldstandard für Startups?

An dieser Stelle möchte ich einen kurzen Exkurs zum Thema Overengineering machen. Gerade im Startup-Umfeld ist es nicht selten zu beobachten, wie selbst einfachste technische Lösungen und Anwendungen mit einem massiven Overload an Technologie eingesetzt und betrieben werden. Ein typisches Geschäftsmodell, das entweder auf einer einzigen App oder einem Setup aus einer oder zwei Handvoll Diensten basiert, kann natürlich technisch mit einer Technologie wie Kubernetes betrieben werden. Die brennende Frage ist jedoch, ob das sein muss. Aus der Perspektive eines technischen Leiters sollte man sich daher auch sehr genau überlegen, welche mittel- und langfristigen Verpflichtungen und Aufwände damit verbunden sind, sowohl personell als auch kostenmässig.

Amazon ECS bietet eine kosteneffiziente, skalierbare Technologie, die mit geringen bis mittleren Kenntnissen betrieben werden kann, insbesondere in den ersten Jahren, in denen ein Startup primär mit der (Weiter-)Entwicklung seines Geschäftsmodells beschäftigt ist. Diese Technologie ermöglicht es einem typischerweise kleinen Entwicklungsteam, wertvolle personelle Ressourcen in die Implementierung von Funktionalität statt in eine für den Endanwender unsichtbare Infrastruktur zu investieren. Das Thema Cloud-Infrastruktur für Startups ist also keineswegs nur eine technologische Entscheidung im Hintergrund, sondern kann enorme Auswirkungen auf die Personalkosten oder die Entwicklungsgeschwindigkeit und Time-to-Market haben. Das Unangenehme ist, dass die Entscheidungen sehr schwerwiegend sind und zum Beispiel nach der Entscheidung für Kubernetes der Wechsel zu einer anderen Technologie extrem zeitaufwendig sein kann – aber das Beibehalten kann eine ebenso drastische finanzielle Belastung darstellen.

ECS Fargate als die serverlose Version von EC2

Vergleicht man die benötigte Infrastruktur zwischen ECS on Fargate und ECS on EC2, so fällt sofort auf, dass alle Komponenten wie EC2 Launch Templates, Autoscaling Groups oder Capacity Providers komplett wegfallen. Der Hintergrund ist, dass diese Ressourcen bei der Nutzung von ECS Fargate durch AWS abstrahiert werden und daher nicht von uns konfiguriert, bereitgestellt und gewartet werden müssen.

Unsere Zielarchitektur sieht also im Vergleich zu ECS EC2 viel einfacher aus:

In unserem Beispiel-Szenario erstellen wir die Präsentationsschicht für ein Multi-Tier-Setup, ohne jedoch auf Komponenten wie Datenbanken einzugehen. Wir erstellen einen Dienst, der auf hohe Verfügbarkeit ausgelegt ist und daher in mehreren Availability Zones (AZ) verfügbar sein soll. Ausserdem stellen wir sicher, dass die Skalierbarkeit auf ECS Service-Ebene mit der Target-Tracking-Methode gewährleistet wird.

Die technischen Unterschiede zu ECS auf EC2

Da der Grossteil der Terraform-Infrastrukturressourcen identisch mit unserer bereits beschriebenen Version von ECS auf EC2 ist, verzichten wir darauf, alle Komponenten und Codeblöcke in diesem Artikel erneut zu erwähnen. Der vollständige Code ist natürlich im zugehörigen GitHub-Repository für dieses Beispiel verfügbar.

Die Änderungen sind genau folgende (die vollständigen Codebeispiele folgen):

• Die Ressource aws_ecs_service wird um den Launch-Typ FARGATE erweitert.
• Die Ressource aws_ecs_task_definition benötigt zusätzliche Informationen wie CPU und Speicher.
• Wir benötigen eine andere aws_security_group für die ECS-Container-Instanz im Vergleich zu ECS auf EC2.
• Der target_type für die ALB Target Group muss auf ip statt auf instance gesetzt werden.
• Der Port der ALB Target Group muss dem Container-Port 3000 entsprechen statt Port 80.

Die folgenden Terraform-Ressourcen entfallen komplett:

• Der Key Pair aws_key_pair.default, da die Verwaltung der EC2-Instanzen von AWS übernommen wird und wir somit keinen Zugriff über SSH erhalten können.
• ECS Fargate erlaubt keine Auswahl des Instanztyps. Ein AMI aws_ami.amazon_linux_2 sowie das Launch Template aws_launch_template.ecs_launch_template werden daher nicht mehr benötigt.
• Das user_data.sh-Skript ist ebenfalls nicht mehr notwendig, da die Konfiguration der EC2-Instanzen entfällt.
• Die Ressourcen aws_iam_role.ec2_instance_role, aws_iam_role_policy_attachment.ec2_instance_role_policy, aws_iam_instance_profile.ec2_instance_role_profile und aws_iam_policy_document.ec2_instance_role_policy sind nicht erforderlich, da sie nur für EC2-Instanzen benötigt werden.
• Gleiches gilt für die ECS Service IAM-Rolle sowie Policies: aws_iam_roleecs_service_role, aws_iam_policy_document.ecs_service_policy, aws_iam_role_policy.ecs_service_role_policy und aws_iam_policy_document.ecs_service_role_policy werden von AWS verwaltet.
• Die Ressourcen für Capacity Provider aws_ecs_capacity_provider.cas und aws_ecs_cluster_capacity_providers.cas sind nicht erforderlich.
• Auch die Autoscaling Group aws_autoscaling_group.ecs_autoscaling_group ist nicht erforderlich, da dieser Teil der Infrastruktur ebenfalls von AWS verwaltet wird.

Alle hier nicht aufgeführten Ressourcen können genau so verwendet werden, wie sie für die EC2-basierte Version konfiguriert sind. Schauen wir uns nun die Ressourcen genauer an, die sich ändern.

Der ECS Service

Die offensichtliche Änderung an dieser Ressource ist der launch_type für Fargate. Ausserdem ist der Block network_configuration neu. Da wir den Netzwerkmodus awsvpc für die ECS Task Definition verwenden, müssen wir diesen Block konfigurieren, damit diese Tasks ihre eigene Elastic Network Interface (ENI) erhalten. Hier geben wir auch unsere Private Subnet IDs an, damit wir, obwohl wir AWS die zugrundeliegende Infrastruktur verwalten lassen, sicherstellen können, dass die Tasks in einem Netzwerk laufen, das nicht aus dem Internet erreichbar ist. Ein optionaler, aber dennoch wichtiger Parameter sind die Security Groups (SG), die für die ECS Task Container Instanz verwendet werden. Auf diese SG, die sich im Vergleich zu EC2 geändert hat, werden wir gleich noch genauer eingehen.

Die ECS Task Definition für die Fargate-Umgebung

Die ECS Task Definition weist ebenfalls viele Gemeinsamkeiten mit der EC2-Version auf. Dennoch ist hier einerseits der network_mode von Bedeutung, sowie die Kompatibilität mit Fargate. Die Konfigurationen für CPU und Speicher stellen eine Änderung dar, die für Fargate nicht nur innerhalb der Container-Definition, sondern auch auf Ebene der Task-Definition konfiguriert werden muss.

Der Host-Port für Fargate muss denselben Port wie der Container-Port verwenden. Dies unterscheidet sich von EC2, wo einer der Ephemeral Ports automatisch von AWS für den Host-Port ausgewählt wird. Wenn wir jedoch ECS Fargate verwenden und unser Container-Port 3000 ist, muss der Host-Port ebenfalls auf Port 3000 gesetzt werden. Diese Änderung bildet auch die Überleitung zur Anpassung der Security Group, auf die wir im nächsten Abschnitt eingehen werden.

Die Security Group der ECS Container Instanz

Um die Netzwerksicherheit der Container-Instanzen so hoch wie möglich zu halten, beschränken wir den erlaubten Netzwerkverkehr auf die Herkunft des Application Load Balancers (ALB) auf Port 3000. Dadurch wird es unmöglich, den ALB direkt anzusprechen und die CloudFront-Distribution zu umgehen. Hierbei hilft uns auch der Custom Origin Header, der zwischen CloudFront und dem ALB übergeben werden muss.

Konfiguration der Target Group

Wenn wir eine Target Group für einen ECS Service mit Fargate erstellen, müssen wir das target_type auf ip setzen. Denke daran: Die Target Group ist die Verbindung zwischen dem Application Load Balancer (ALB) und dem eigentlichen Service und fungiert als „Ausgabe“ des ALB, während der ALB Listener den Netzwerkverkehr entgegennimmt.

Die zweite Änderung betrifft den Port der Target Group, der auf den Port des Containers (3000 in unserem Beispiel) gesetzt wird. Mit Fargate müssen sowohl containerPort als auch hostPort in der ECS Task-Definition auf denselben Wert gesetzt werden. Um unseren Verkehr korrekt zum Ziel zu leiten, müssen wir die Target Group entsprechend mit demselben Port aktualisieren.

These are the only changes and additions that need to be made in the resources known from EC2

Mit dieser Codebasis können wir jetzt unseren Tutorial-Service starten und ECS Fargate praktisch kennenlernen.

When to prefer ECS Fargate over EC2

ECS Fargate und ECS EC2 sind in ihrem Aufbau sehr ähnlich. Beide Systeme sind professionelle Cloud-Computing-Umgebungen, die für Skalierbarkeit und hohe Verfügbarkeit entwickelt wurden und ohne Kompromisse bei Sicherheit, Erweiterbarkeit oder Wartbarkeit genutzt werden können. Dennoch gibt es einige Unterschiede, die du für den professionellen Einsatz kennen solltest.

ECS Fargate hat klar die Nase vorn, wenn es um Benutzerfreundlichkeit und geringen Betriebsaufwand geht. Der gesamte Aufwand für das Einrichten und Warten der EC2-basierten Infrastruktur sowie der Autoscaling-Gruppe und anderer Komponenten für die Skalierbarkeit entfällt vollständig. Da dieser Unterbau auch einen entsprechenden operativen Rucksack mit sich bringt, ist ECS Fargate eindeutig für Anwendungsfälle zu empfehlen, in denen die Zeit und/oder das Wissen über Cloud-Computing-Technologien wie EC2 nicht vorhanden sind.

Auch auf der Kostenseite gibt es einige Punkte zu beachten. Als Faustregel kann man sagen, dass ECS Fargate sich für kleine bis mittlere Workloads lohnt, die nicht die Auslastung des gesamten ECS-Clusters von etwa 50 % überschreiten. Dieser Wert ist natürlich nicht fest und hängt von anderen Faktoren ab. Ab einer höheren Auslastung solltest du jedoch prüfen, ob ein Wechsel zu ECS EC2 nicht die kostengünstigere Option ist. Vergiss aber nicht, auch die Zeitersparnis durch den Wegfall des operativen Aufwands zu berücksichtigen.

Gleichzeitig ist diese Tatsache auch ein potenzielles Gegenargument, denn durch den Wegfall der EC2-Infrastruktur und die Nutzung der serverlosen Version entfällt auch die Flexibilität und Konfigurierbarkeit dieser Schicht. Wer also beispielsweise auf den Einsatz von GPUs angewiesen ist, EBS-Volumes integrieren muss oder einen Dienst als Daemon starten möchte, wird mit ECS Fargate nicht das passendste Werkzeug haben.

Aus der Perspektive eines Software-Ingenieurs sollte nicht verschwiegen werden, dass ECS Fargate begrenzte Möglichkeiten bietet, nicht startende Docker-Images direkt auf der EC2-Instanz zu debuggen. Während es mit ECS EC2 möglich ist, sich per SSH auf die betreffende Instanz einzuloggen und eine präzise Fehleranalyse durchzuführen, kann die Fehlersuche mit Fargate zu einer langwierigen Suche werden.

Conclusion

Für alle, die eine einfache, skalierbare Lösung für containerbasiertes Cloud-Computing suchen und für die Kubernetes aufgrund seines deutlich höheren operativen Aufwands keine Option ist, lohnt es sich, AWS ECS Fargate genauer anzuschauen. Amazon hat mit dieser Technologie eine hochprofessionelle Umgebung geschaffen, die Teams viele Kopfschmerzen ersparen kann, während sie vollständig kompatibel mit modernen Softwareentwicklungstechniken und -tools ist, wie z. B. CI/CD, trunk-based Development, Infrastructure-as-Code und einem auf vollständige Automatisierung ausgelegten Setup.

Es sind Technologien wie ECS, die es interdisziplinären Teams ermöglichen, komplexe Geschäftsmodelle schnell und einfach umzusetzen, während sie so wenig Zeit wie möglich mit dem operativen Betrieb der Grundlage verbringen.

Und das war’s vorerst. 🎉

Ich hoffe, dir hat dieser Artikel gefallen und er hat dir geholfen, ECS Fargate zu verstehen. Cloud-Infrastrukturen können manchmal aufgrund ihrer Komplexität überwältigend wirken, aber jetzt solltest du hoffentlich einen guten Überblick über vollautomatisierte Deployments von Amazon ECS Fargate mit Terraform haben.

Denke daran, dass es viele andere Möglichkeiten gibt, ECS Fargate zu konfigurieren. Wir versuchen immer, Lösungen zu finden, die möglichst schlank sind und so wenig Technologien wie möglich nutzen, aber natürlich gibt es viele Alternativen.

Zögere nicht, uns zu kontaktieren, wenn du Fragen oder Feedback hast. Wir würden uns freuen, von dir zu hören! Du kannst dich auch mit uns auf LinkedIn verbinden, um über weitere Artikel auf dem Laufenden zu bleiben. Lass uns in Kontakt bleiben und voneinander lernen! 🚀