Deployment einer AWS Multi-Tier-Architektur mit Terraform

- Ziel:

In diesem Abschnitt werden Projekt-Branch, Terraform-Installation und die AWS-Authentifizierung vorbereitet, damit Terraform die Infrastruktur über die AWS API automatisiert provisionieren kann.

- Vorgehen:

1) Projekt klonen & Branch erstellen

• Repository klonen und ins Projekt wechseln:

git clone https://github.com/<username>/profile.git
  cd profile

• Neuen Branch für Terraform anlegen:

git checkout -b terraform-project

2) Terraform installieren (Windows)

• Chocolatey installieren (falls nicht vorhanden):

Set-ExecutionPolicy Bypass -Scope Process -Force
iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))

• Terraform via Chocolatey installieren und Version prüfen:

choco install terraform
 terraform -version

3) AWS Zugriff einrichten (IAM User + Access Keys)

• AWS Console → IAM → Users → Create user
• User: terraform-admin
• Policy: AdministratorAccess
• Access Key über Security credentials von IAMUser erstellen (Use case: CLI) und sicher speichern

4) AWS CLI konfigurieren (lokale Credentials)

Terraform nutzt die lokal gespeicherten AWS Credentials (z.B. unter ~/.aws/credentials), um sich gegenüber AWS zu authentifizieren.

aws configure

• AWS Access Key ID und Secret Access Key vom IAM User eingeben
• Output Format: json

5) Ergebnis

• Terraform ist installiert
• AWS CLI ist konfiguriert
• Terraform kann nun über AWS API Ressourcen erstellen

- Ziel:

Wenn Terraform-Code ausgeführt wird, speichert Terraform alle Informationen über die Infrastruktur im tfstate-File. Standardmäßig wird diese Datei im aktuellen Arbeitsverzeichnis abgelegt. Ziel dieses Schrittes ist es, den Terraform State (terraform.tfstate) zentral und sicher in einem AWS S3 Bucket zu speichern, um Teamarbeit, Reproduzierbarkeit und State-Locking zu ermöglichen.

- Vorgehen:

1) S3 Bucket für den Terraform State erstellen

• AWS Console → S3 → Create bucket
• Bucket Name: terraformstate###
• Region: z. B. us-###
• Ein Ordner terraform in Bucket erstellen

3) Terraform Backend konfigurieren

Die Backend-Konfiguration wird im Terraform Code definiert, z. B. in der Datei backend.tf.

• Das Projekt im VSCode öffnen und im Projektverzeichnis die Datei backend.tf erstellen.



terraform {
  backend "s3" {
    bucket         = "terraformstate###"
    key            = "terraform/backend"
    region         = "us-###"
    dynamodb_table = "terraform-lock"
    encrypt        = true
  }
}

• terraform definiert einen globalen Terraform-Konfigurationsblock, der grundlegende Einstellungen wie Backend oder Provider enthält.
• backend "s3" legt fest, dass der Terraform State nicht lokal, sondern zentral in einem Amazon S3 Bucket gespeichert wird.
• bucket & key bestimmen den Speicherort des States: bucket ist der Name des S3 Buckets und key der Pfad, unter dem die terraform.tfstate-Datei im Bucket abgelegt wird.

4) Terraform Backend initialisieren

Nach dem Hinzufügen oder Ändern der Backend-Konfiguration muss Terraform neu initialisiert werden. Git Bash und im Projektverzeichnis wechseln dann:

terraform init

• Terraform verbindet sich mit S3
• Der State wird im Remote Backend angelegt oder gelesen
• Lokaler State wird nicht mehr verwendet

5) Ergebnis

• Terraform State liegt zentral in S3
• Mehrere Entwickler können sicher zusammenarbeiten
• State-Konflikte werden durch Locking vermieden

- Ziel:

Ziel dieses Schrittes ist es, die Terraform-Konfiguration flexibel, wiederverwendbar und umgebungsunabhängig zu gestalten, indem Variablen definiert und der AWS Provider korrekt konfiguriert werden.

- Vorgehen:

1) AWS Provider konfigurieren

Der Provider definiert, mit welchem Cloud-Anbieter Terraform kommuniziert. In diesem Projekt wird der AWS Provider verwendet, um Ressourcen über die AWS API zu erstellen. Im Projektverzeichnis providers.tf File erstellen:

provider "aws" {
  region = var.AWS_REGION
}

• Der AWS Provider stellt die Verbindung zwischen Terraform und AWS her
• Die Region wird über eine Variable gesteuert

2) Variablen definieren

Variablen ermöglichen es, Werte wie Region, Instanztyp oder Umgebungsnamen zentral zu definieren und mehrfach zu verwenden. Im weiteren Verlauf des Projekts werden zusätzliche Variablen ergänzt. In diesem Schritt wird zunächst die AWS-Region als Variable definiert.

variable "AWS_REGION" {
  default = "us-###"
}

• Variablen werden in der Regel in der Datei vars.tf definiert
• Sie erhöhen die Lesbarkeit, Wartbarkeit und Wiederverwendbarkeit des Codes

• var.<name> greift auf den Variablenwert zu
• Gleiche Konfiguration kann für mehrere Umgebungen genutzt werden

5) Ergebnis

• Terraform-Konfiguration ist flexibel und parametrisierbar
• Provider ist sauber von der Infrastrukturdefinition getrennt
• Code kann einfach für verschiedene Umgebungen wiederverwendet werden

- Ziel:

Ziel dieses Schrittes ist es, einen sicheren SSH-Zugriff auf EC2-Instanzen zu ermöglichen, ohne Passwörter zu verwenden, indem ein SSH Key Pair für die Authentifizierung eingesetzt wird.

- Vorgehen:

1) SSH Key Pair lokal erstellen

Ziel dieses Schrittes ist es, einen sicheren SSH-Zugriff auf EC2-Instanzen (Bastion Host, Elastic Beanstalk) zu ermöglichen, ohne Passwörter zu verwenden. Stattdessen wird eine SSH-Key-basierte Authentifizierung eingesetzt.

Das Key Pair wird lokal im Projektverzeichnis auf dem Entwicklerrechner erzeugt. Der private Schlüssel verbleibt ausschließlich lokal, während der öffentliche Schlüssel später in AWS hinterlegt wird. In Git Bash:

ssh-keygen 
 profilekey

• profilekey → privater Schlüssel (bleibt lokal gespeichert)
• profilekey.pub → öffentlicher Schlüssel (wird in AWS verwendet)

Vorgehen:
Git Bash im Projektverzeichnis öffnen und den obigen ssh-keygen-Befehl ausführen. Dadurch werden der private Schlüssel profilekey und der öffentliche Schlüssel profilekey.pub automatisch im Projektverzeichnis erstellt. Der öffentliche Schlüssel wird anschließend kopiert und für die Registrierung in AWS verwendet.

2) Public Key in AWS registrieren

Der öffentliche Schlüssel wird als Key Pair in AWS hinterlegt, sodass EC2-Instanzen diesen für den SSH-Zugriff akzeptieren. Im Projektverzeichnis keypairs.tf File erstellen:

resource "aws_key_pair" "profilekey" {
  key_name   = "profilekey"
  public_key = "Inhalt von profilekey.pub"
}

Jetzt werden die folgenden Terraform-Befehle im Projektverzeichnis über Git Bash ausgeführt, um die Konfiguration zu prüfen und keypair(profilekey.pub) zu legen.

• terraform init
  Initialisiert das Terraform-Projekt, lädt den AWS Provider, konfiguriert das Remote Backend und bereitet das Arbeitsverzeichnis vor.
• terraform fmt
  Formatiert den Terraform-Code automatisch nach Best Practices, um eine einheitliche und gut lesbare Struktur sicherzustellen.
• terraform validate
  Überprüft die Terraform-Konfiguration auf syntaktische und logische Fehler, ohne Ressourcen zu erstellen oder zu verändern.
• terraform plan
  Erstellt einen Ausführungsplan und zeigt an, welche Ressourcen erstellt, geändert oder gelöscht werden, bevor Änderungen in AWS durchgeführt werden.
• terraform apply
  Führt den zuvor berechneten Plan aus und erstellt das definierte SSH Key Pair in AWS über die AWS API.

- Ziel:

Ziel dieses Schrittes ist es, eine isolierte und sichere Netzwerkbasis in AWS zu schaffen. Dazu wird eine eigene Virtual Private Cloud (VPC) mit Public- und Private-Subnets über ein Terraform-Modul bereitgestellt.

- Vorgehen:

1) Einsatz eines Terraform VPC Moduls

Um Best Practices einzuhalten und den Code übersichtlich zu halten, wird die VPC nicht manuell definiert, sondern über ein wiederverwendbares Terraform-Modul erstellt (Terraform Registry Doc). Im Projektverzeichnis vpc.tf File erstellen:

• Die VPC bildet das private Netzwerk für alle Ressourcen
• Für jede Availability Zone wird ein eigenes Public- und Private-Subnet erstellt
• NAT Gateways ermöglichen Internetzugriff aus Private Subnets
• DNS aktiviert Interne Namensauflösung

In Git Bash werden anschließend die Standard-Terraform-Kommandos ausgeführt: terraform init, terraform fmt, terraform validate, terraform plan und terraform apply.:

2) Ergebnis

• Isolierte AWS VPC mit klarer Netzwerksegmentierung
• Hohe Verfügbarkeit durch Nutzung mehrerer Availability Zones
• Sichere Trennung von öffentlichen und internen Ressourcen

- Ziel:

Ziel dieses Schrittes ist es, die Backend-Services der Java-Webanwendung „Profile“ bereitzustellen. Dazu gehören eine relationale Datenbank (RDS MySQL), ein In-Memory-Cache (ElastiCache) sowie ein Message-Broker (Amazon MQ).

Alle Services werden ausschließlich in Private Subnets betrieben und sind nur für das Application Tier erreichbar.

- Vorgehen:

1) Grundprinzip (Private Backend-Services)

• Backend-Services besitzen keine öffentliche IP
• Zugriff nur über definierte Security Groups
• Isolation durch Private Subnets
• Trennung von Application- und Data-Layer

2) Subnet Groups erstellen

AWS Managed Services wie RDS, ElastiCache und Amazon MQ benötigen eigene Subnet Groups, um festzulegen, in welchen Subnets sie betrieben werden dürfen.

• Subnet Groups enthalten ausschließlich Private Subnets
• Ermöglichen Hochverfügbarkeit und Isolation

Subnet Groups in backend-services.tf

resource "aws_db_subnet_group" "profile-rds-subgrp" {
  name       = "profile-rds-subgrp"
  subnet_ids = [module.vpc.private_subnets[0], module.vpc.private_subnets[1], module.vpc.private_subnets[2]]

  tags = {
    Name = "Subnet group for RDS"
  }
}

resource "aws_elasticache_subnet_group" "profile-ecache-subgrp" {
  name       = "profile-ecache-subgrp"
  subnet_ids = [module.vpc.private_subnets[0], module.vpc.private_subnets[1], module.vpc.private_subnets[2]]

  tags = {
    Name = "Subnet group for Elasticache"
  }
}

• Über subnet_ids wird erzwungen, dass RDS/Cache nur in Private Subnets laufen.

3) RDS MySQL

RDS stellt die relationale Datenbank für die Anwendung bereit und übernimmt Backups, Patching und optional Multi-AZ-Failover.

• Engine: MySQL

RDS Instance in backend-services.tf

resource "aws_db_instance" "profile-rds" {
  allocated_storage      = 20
  storage_type           = "gp3"
  engine                 = "mysql"
  engine_version         = "8.0.39"
  instance_class         = "db.t4g.micro"
  db_name                = var.dbname
  username               = var.dbuser
  password               = var.dbpass
  parameter_group_name   = "default.mysql8.0"
  multi_az               = "false"
  publicly_accessible    = "false"
  skip_final_snapshot    = true
  db_subnet_group_name   = aws_db_subnet_group.profile-rds-subgrp.name
  vpc_security_group_ids = [aws_security_group.profile-backend-sg.id]
}

• Kein Public Access: publicly_accessible = "false" verhindert Internetzugriff auf die Datenbank.
• Netzwerkbindung: db_subnet_group_name platziert RDS in den Private Subnets der VPC.
• Zugriffskontrolle: vpc_security_group_ids begrenzt DB-Zugriff auf die definierte Backend-SG (Port 3306 kommt über SG-Regeln).

4) ElastiCache – In-Memory Cache

ElastiCache reduziert die Last auf der Datenbank und verbessert die Antwortzeiten der Anwendung.

• Engine: Memcached (im Projekt umgesetzt)

ElastiCache Cluster in backend-services.tf

resource "aws_elasticache_cluster" "profile-cache" {
  cluster_id           = "profile-cache"
  engine               = "memcached"
  node_type            = "cache.t3.micro"
  engine_version       = "1.6.22"
  num_cache_nodes      = 1
  parameter_group_name = "default.memcached1.6"
  port                 = 11211
  security_group_ids   = [aws_security_group.profile-backend-sg.id]
  subnet_group_name    = aws_elasticache_subnet_group.profile-ecache-subgrp.name
}

• Privates Placement: subnet_group_name bindet den Cache an Private Subnets (kein direkter Internetzugriff).
• Port & Security: port = 11211 + security_group_ids stellt sicher, dass nur erlaubte interne Clients zugreifen können.
• Ressourcengröße: node_type und num_cache_nodes bestimmen Performance/Kosten

5) Amazon MQ – Message Broker

Amazon MQ ermöglicht asynchrone Verarbeitung und entkoppelt Anwendungskomponenten.

• Broker: RabbitMQ (im Projekt umgesetzt)
• Placement: Private Subnets
• Nutzen: Asynchrone Kommunikation

Amazon MQ Broker in backend-services.tf

resource "aws_mq_broker" "profile-rmq" {
  broker_name                = "profile-rmq"
  engine_type                = "RabbitMQ"
  engine_version             = "3.13"
  host_instance_type         = "mq.t3.micro"
  auto_minor_version_upgrade = true
  security_groups            = [aws_security_group.profile-backend-sg.id]
  subnet_ids                 = [module.vpc.private_subnets[0]]

  user {
    username = var.rmquser
    password = var.rmqpass
  }
}

• Private Subnet: subnet_ids platziert den Broker im Private Subnet (keine öffentliche Erreichbarkeit).
• Security Group: security_groups begrenzt, wer die Broker-Ports erreichen darf (typisch: nur App-Tier).
• Credentials als Variablen: user nutzt var.rmquser/var.rmqpass, damit keine Zugangsdaten im Code hardcodiert sind.

Problem: Die Erstellung des Amazon MQ Brokers (RabbitMQ 3.13) ist fehlgeschlagen, da die Option auto minor version upgrade nicht aktiviert war, obwohl sie für diese Version erforderlich ist.
Lösung: Setzen von auto_minor_version_upgrade = true in der Ressource aws_mq_broker und erneutes Ausführen von terraform apply.

- Ziel:

Ziel dieses Schrittes ist es, ein Elastic Beanstalk Environment für die Java-Webanwendung „Profile“ bereitzustellen. Elastic Beanstalk übernimmt dabei das Application Deployment, das Lifecycle-Management sowie die Integration mit dem Application Load Balancer und den EC2-Instanzen.

Das Environment läuft vollständig innerhalb der bestehenden VPC und nutzt Private Subnets für die EC2-Instanzen.

- Vorgehen:

1) Architekturprinzip

• Elastic Beanstalk verwaltet EC2-Instanzen automatisch (autoscaling)
• Application Load Balancer im Public Subnet
• EC2 Application Server im Private Subnet
• Integration mit bestehenden Security Groups
• Kein direkter Internetzugriff auf EC2

In diesem Projekt gibt es zwei Terraform-Ressourcen: Beanstalk Application (logischer Container) und Beanstalk Environment (reale Laufzeitumgebung). Das Environment erzeugt und verwaltet die eigentlichen AWS-Komponenten wie Load Balancer, Auto Scaling und EC2-Instanzen.

2) Elastic Beanstalk Application (bean-app.tf)

Die Beanstalk Application ist ein logischer Container für ein oder mehrere Environments (z. B. Dev, Test, Prod).

resource "aws_elastic_beanstalk_application" "profile-app" {
  name        = "profile-app"
  description = "Elastic Beanstalk Application for Profile Java WebApp"
}

• Wiederverwendbar: Mehrere Environments (Dev/Prod) möglich.
• Vollständig versionierbar und reproduzierbar.

3) Elastic Beanstalk Environment (bean-env.tf)

Das Environment beschreibt die tatsächliche Laufzeitumgebung: EC2-Instanzen, Load Balancer, Netzwerkeinstellungen und Plattform.

resource "aws_elastic_beanstalk_environment" "profile-env" {
  name                = "profile-prod-env"
  application         = aws_elastic_beanstalk_application.profile-app.name
  solution_stack_name = "64bit Amazon Linux 2 v5.8.4 running Tomcat 9 Corretto 17"

  setting {
    namespace = "aws:ec2:vpc"
    name      = "VPCId"
    value     = module.vpc.vpc_id
  }

  setting {
    namespace = "aws:ec2:vpc"
    name      = "Subnets"
    value     = join(",", module.vpc.private_subnets)
  }

  setting {
    namespace = "aws:ec2:vpc"
    name      = "ELBSubnets"
    value     = join(",", module.vpc.public_subnets)
  }

  ...
}

• VPC-Anbindung: Das Setting VPCId bindet das Elastic-Beanstalk-Environment an die bestehende VPC, die zuvor mit Terraform erstellt wurde.
• Private EC2-Instanzen: Über Subnets werden die Application-Server (EC2) ausschließlich in Private Subnets platziert. Dadurch sind sie nicht direkt aus dem Internet erreichbar.
• Öffentlicher Load Balancer: Das Setting ELBSubnets sorgt dafür, dass der Application Load Balancer in den Public Subnets erstellt wird und als einziger Einstiegspunkt für Benutzeranfragen dient.

In der Datei bean-env.tf sind zusätzlich weitere Settings definiert, unter anderem für Auto Scaling, Security, Deployment-Strategien und Health Checks.

Am Ende der Resource wird ein depends_on-Block verwendet, um sicherzustellen, dass die benötigten Security Groups (Load Balancer SG und Backend/ProdBean SG) bereits existieren, bevor das Elastic-Beanstalk-Environment erstellt wird.

- Ziel:

Ziel dieses Schrittes ist es, einen Bastion Host für den sicheren administrativen Zugriff auf Ressourcen in den Private Subnets bereitzustellen und anschließend die Initialisierung der RDS-Datenbank durchzuführen.

Der Bastion Host fungiert als kontrollierter Einstiegspunkt (SSH Jump Host), über den Administratoren auf interne Systeme zugreifen können, ohne diese direkt aus dem Internet erreichbar zu machen.

- Vorgehen:

1) Architekturprinzip

• Bastion Host befindet sich im Public Subnet
• Private EC2 und RDS bleiben vollständig isoliert
• SSH-Zugriff erfolgt ausschließlich über den Bastion Host
• Datenbank wird einmalig initialisiert (Schema & Basisdaten)

Dieses Schema zeigt den Admin-Zugriff über den Bastion Host (Public Subnet) in das Private Subnet sowie die DB-Initialisierung auf RDS MySQL. Die Datenbank bleibt dabei vollständig privat (kein Internet-Inbound).

2) Bastion Host bereitstellen (bastion-host.tf)

Der Bastion Host ist eine schlanke EC2-Instanz im Public Subnet, die als einziger SSH-Einstiegspunkt dient. In diesem Projekt wird sie zusätzlich genutzt, um die RDS-Datenbank initial zu konfigurieren (DB-Init Script).

• AMI automatisch aktuell: Über data "aws_ami" wird immer die neueste Ubuntu 22.04 AMI von Canonical gewählt (most_recent = true + Owner Canonical).
• Public Subnet + SSH: Die Bastion liegt im public_subnets und ist über SSH erreichbar, damit Terraform per file und remote-exec Provisioner das DB-Init Script ausrollen kann.

• DB-Initialisierung automatisiert: Mit Hilfe von Terraform-Provisioners wird das Script aus einem Template generiert (templatefile), auf die Bastion kopiert und ausgeführt, um die RDS-Datenbank automatisch zu initialisieren (Schema/Basisdaten).

Dafür wird im Projektverzeichnis ein Ordner templates/ angelegt, der das Template db-deploy.tmpl enthält. Dieses Template dient als Vorlage für das Datenbank-Initialisierungsskript.

provisioner "file" {
  content = templatefile("templates/db-deploy.tmpl", {
    rds-endpoint = aws_db_instance.profile-rds.address,
    dbuser       = var.dbuser,
    dbpass       = var.dbpass
  })
  destination = "/tmp/profile-dbdeploy.sh"
}

connection {
  type        = "ssh"
  user        = var.USERNAME
  private_key = file(var.PRIV_KEY_PATH)
  host        = self.public_ip
}

provisioner "remote-exec" {
  inline = [
    "chmod +x /tmp/profile-dbdeploy.sh",
    "sudo /tmp/profile-dbdeploy.sh"
  ]
}

• Template-Struktur: Das Verzeichnis templates/ enthält die Datei db-deploy.tmpl, welche als Vorlage für das Shell-Skript dient.
• Dynamische Generierung: templatefile() ersetzt Platzhalter im Template durch echte Werte wie RDS-Endpunkt und Zugangsdaten.
• Übertragung & Verbindung: Terraform baut per SSH eine Verbindung zur Bastion auf und kopiert das generierte Skript nach /tmp.
• Automatische Initialisierung: Das Skript wird ausführbar gemacht und mit Root-Rechten ausgeführt, um die Datenbank initial zu konfigurieren.

- Ziel:

Ziel dieses Schrittes ist es, das Build-Artefakt der Java-Webanwendung „Profile“ (WAR-Datei) kontrolliert und reproduzierbar in das Elastic Beanstalk Environment zu deployen.

Dabei wird bewusst zwischen Infrastruktur-Provisionierung (Terraform) und Applikations-Deployment (Artefakt-Rollout) getrennt.

- Vorgehen:

1) Git Bash öffnen & Branch prüfen

Zunächst wird sichergestellt, dass im richtigen Projektkontext und im korrekten Branch gearbeitet wird.

• Git Bash im Projektverzeichnis öffnen
• Sicherstellen, dass der Branch terraform-project aktiv ist

2) Terraform Outputs definieren (Endpoints sichtbar machen)

Um die Endpunkte der Backend-Services (RDS, ElastiCache, Amazon MQ) einfach weiterverwenden zu können, wird eine Datei outputs.tf im Projektverzeichnis angelegt.

output "rds_endpoint" {
  value = aws_db_instance.profile-rds.address
}

output "cache_endpoint" {
  value = aws_elasticache_cluster.profile-cache.cache_nodes[0].address
}

output "mq_endpoint" {
  value = aws_mq_broker.profile-rmq.instances[0].endpoints[0]
}

• Warum?
  • Terraform Outputs liefern die echten Service-Endpunkte
  • Vermeidet Hardcoding von IPs oder DNS-Namen
  • Erleichtert die Konfiguration der Anwendung

3) Application-Konfiguration anpassen

Die Anwendung benötigt die realen Endpunkte der Backend-Services. Diese werden in der Datei application.properties hinterlegt.

vim src/main/resources/application.properties

• Ersetzen aller Platzhalter durch die Terraform Outputs
• RDS Endpoint → Datenbank-Konfiguration
• Cache Endpoint → Memcache/Redis
• MQ Endpoint → RabbitMQ

• Warum?
  Die Anwendung muss wissen, wo sich ihre Backend-Services befinden, um korrekt starten zu können.

4) Build des Applikations-Artefakts

Nachdem die Konfiguration aktualisiert wurde, wird die Anwendung lokal gebaut.

mvn clean install

• Erzeugt ein sauberes Build ohne alte Artefakte
• Validiert Abhängigkeiten und Code
• Erstellt das finale WAR-File

Das erzeugte Artefakt befindet sich anschließend im Verzeichnis target/:

target/profile-v2.war

• Warum?
  Elastic Beanstalk benötigt ein deploybares Artefakt (WAR-Datei für Tomcat).

5) Deployment in Elastic Beanstalk

Das erzeugte WAR-File wird nun in das Elastic Beanstalk Environment hochgeladen, das zuvor vollständig mit Terraform erstellt wurde.

• AWS Console → Elastic Beanstalk
• Environment auswählen (prod)
• Upload and Deploy wählen
• profile-v2.war auswählen
• Deployment starten

Ergebnis

• Applikation läuft im produktiven Beanstalk Environment
• Backend-Services sind korrekt angebunden
• Deployment ohne manuelle Server-Konfiguration
• Saubere Trennung von Infrastruktur, Konfiguration und Anwendung

5. Fazit

Dieses Projekt demonstriert eine vollständige Cloud-Architektur auf AWS, die mit Terraform automatisiert bereitgestellt wird. Dabei werden Security- und Netzwerk-Best-Practices umgesetzt, Managed Services integriert und eine funktionsfähige Anwendung deployed.