So migrierst du von DigitalOcean zu AWS: Ein umfassender Leitfaden

Wenn du den Begriff Migration von DigitalOcean zu AWShörst, denkst du wahrscheinlich zuerst daran, virtuelle Maschinen und Server von einer Cloud-Plattform auf die andere zu übertragen. Je nachdem, wie deine aktuelle Umgebung bei DigitalOcean aufgebaut ist, kann eine solche Migration jedoch weit mehr umfassen. 

DigitalOcean bietet eine Vielzahl von Cloud-Diensten, darunter Droplets, Volumes, Spaces, verwaltete Datenbanken, Kubernetes, Load Balancer und Netzwerkdienste. AWS stellt für die meisten dieser Funktionen entsprechende Lösungen bereit, allerdings unterscheiden sich die Architektur, die Vernetzung, die Sicherheitskontrollen und das Betriebsmodell erheblich. 

Je nachdem, welche Dienste du auf DigitalOcean nutzt und welche Migrationsstrategie du für die jeweilige Workload wählst, unterscheiden sich die Details der Migration.

Eine erfolgreiche Migration erfordert daher zwei Entscheidungen:

1. Was soll unverändert übernommen werden?
2. Was sollte mithilfe eines nativen AWS - Service neu konzipiert werden?

Beispielsweise kann ein DigitalOcean Droplet im Rahmen einer Lift-and-Shift-Migration zu Amazon EC2 migriert werden. Eine andere Migrationsstrategie (z. B. Refactoring), bei der die Anwendung in eine Microservices-Architektur umgestaltet wird, könnte die Anwendung hingegen vollständig oder teilweise auf ECS, EKS und Lambda verlagern.

Dieser Leitfaden erklärt, wie du die wichtigsten DigitalOcean-Dienste zu AWS migrierst, und umfasst praktische Beispiele, Migrationsstrategien, Befehle, Überlegungen zur Architektur, Minimierung der Ausfallzeit Techniken und Validierung nach der Migration.

1. Zuordnung der DigitalOcean- Dienste zu AWS

Der erste Schritt bei der Vorbereitung der Migration besteht darin, eine Bestandsaufnahme aller Ressourcen zu erstellen, die in DigitalOcean ausgeführt werden. Anschließend kannst du die potenziellen entsprechenden AWS-Dienste auflisten, die verwendet werden können und jeweils dem entsprechenden DigitalOcean-Dienst zugeordnet sind.

Eine typische Zuordnung sieht folgendermaßen aus:

Der wichtige Punkt ist, dass dass es nicht immer eine 1:1-Zuordnung gibt..

Das vergleichsweise einfachere Modell von DigitalOcean hat möglicherweise nicht immer einen direkten AWS-Ersatzdienst mit exakt demselben Funktionsumfang. In diesem Fall solltest du die Migration als Gelegenheit betrachten, eine AWS-Architektur einzurichten die am besten zu jeder Workload passt.

Mit einer vollständigen DigitalOcean-Bestandsaufnahme beginnen

Im nächsten Schritt solltest du die zugehörigen Spezifikationen und Infrastrukturressourcen jeder Workload dokumentieren. 

Für jede Anwendung solltest du Folgendes dokumentieren:

• Name des Droplets
• Größe des Droplets
• Betriebssystem
• Region
• Öffentliche IP-Adresse
• Private IP-Adresse
• Angehängte Volumes
• CPU-Auslastung
• RAM-Auslastung
• Festplattenauslastung
• Netzwerkverkehr
• Offene Ports
• Firewall-Regeln
• Laufende Dienste
• Cronjobs
• Systemd-Dienste
• Umgebungsvariablen
• Geheimnisse
• SSL-Zertifikate
• DNS-Einträge
• Datenbankverbindungen
• Abhängigkeiten vom Objektspeicher
• Container-Images
• Backups
• Monitoring
• Externe Integrationen

Zum Beispie:

Anwendung: ecommerce.example.com

DigitalOcean:

  Droplet: web-01

  Size: 4 vCPU / 8 GB RAM

  Betriebssystem: Ubuntu 24.04

  Region: NYC

  Speicherplatz: 200 GB

Datenbank:

  Verwaltetes PostgreSQL

  4 vCPU / 8 GB RAM

  Speicherplatz: 150 GB

Speicher:

  Spaces-Bucket: ecommerce-assets

Netzwerk:

  Cloud Firewall

  Ports: 80, 443, 22

DNS:

  ecommerce.example.com

  www.example.com

Hintergrund-Jobs:

  Cron

  Redis

Container:

  Docker Compose

Dieses Inventar dient als Migrations-Blueprint, auf dessen Basis du das Migrationsziel bewertest und entsprechend planst.

3. Entscheide dich für die Migrationsstrategie

Wie bereits erwähnt, kann die Migrationsstrategie die Wahl des Ziel-AWS-Services beeinflussen. Daher ist die direkte Eins-zu-eins-Zuordnung des passenden AWS-Services zum jeweiligen DigitalOcean-Service nicht immer die beste Wahl.

Es gibt drei gängige Ansätze.

Strategy 1: Rehost

Verlagere den Workload mit minimalen architektonischen Anpassungen.

Zum Beispie:

DigitalOcean Droplet → Amazon EC2

Dies ist in der Regel der schnellste Ansatz.

Er ist geeignet, wenn:

• Du eine schnelle Migration benötigst.
• Die Anwendung stabil läuft.
• Du keine größeren Änderungen an der Anwendung vornehmen möchtest.
• Du zuerst migrieren und erst später modernisieren möchtest.

Strategy 2: Replatform

Verlagere die Anwendung, ersetze jedoch einige Infrastrukturkomponenten durch verwaltete AWS-Services.

Zum Beispie:

DigitalOcean:

Droplet

   │

   Anwendung

   ├── PostgreSQL

   └── uploaded files

             ↓

AWS:

EC2

   │

   Anwendung

   │

   └── Amazon RDS PostgreSQL

Amazon S3

   └── uploaded files

Dies ist häufig der beste Kompromiss.

Du behältst einen Großteil der bestehenden Anwendung bei und reduzierst gleichzeitig den Aufwand für das Verwaltendes der Infrastruktur.

Strategy 3: Refactor

Stelle die Anwendung auf native AWS-Services um und strukturiere sie neu.

Zum Beispie:

                        ┌── CloudFront

                         │

Users ── Route 53 ── ALB ── ECS

                         │

                         ├── RDS/Aurora

                         │

                         ├── ElastiCache

                         │

                         └── S3

Dies kann zwar für eine bessere Skalierbarkeit und Verfügbarkeit sorgen, erfordert jedoch erheblich mehr Entwicklungsaufwand.

4. Migration von DigitalOcean Droplets zu AWS EC2

Ein DigitalOcean Droplet ist im Grunde eine virtuelle Maschine, und Amazon EC2 ist der entsprechende AWS-Service, der bei einer Lift-and-Shift-Strategie für die Migration einer virtuellen Maschine typischerweise das Ziel darstellt.

Es gibt zwei Hauptansätze zur Umsetzung:

Ansatz A — Den Server neu aufbauen

Dies lässt sich einfach durch das Erstellen einer neuen EC2-Instanz und die Installation der Anwendungskomponenten erreichen.

Zum Beispiel angenommen, auf dem DigitalOcean-Server läuft:

Ubuntu

Nginx

PHP 8.3

Laravel

Statt die gesamte Maschine zu kopieren, könntest du Folgendes erstellen:

EC2 Ubuntu / CentOS / Windows

    ↓

Install Nginx

    ↓

Install PHP

    ↓

Deploy Laravel

    ↓

Konfiguration wiederherstellen

Das führt zu einer saubereren AWS-Architektur.

Dies ist normalerweise dann vorzuziehen, wenn sich die Anwendung reproduzieren lässt durch:

• Ansible
• Terraform eingesetzt.
• Cloud-init
• Docker
• Packer
• Configuration-management scripts

Approach B — Rehost the VM

Wenn es wichtig ist, den bestehenden Server zu erhalten, kannst du das Machine Image migrieren.

AWS VM Import/Export unterstützt das Importieren von VM-Images in EC2. Der AWS-Workflow umfasst das Exportieren des VM-Images, das Hochladen nach Amazon S3 und das Importieren nach EC2.

AWS Application Migration Service ist eine weitere Option für unterstützte Workloads und speziell für Lift-and-Shift-Server-Migrationen gedacht. AWS weist ihn in der Migration-Hub-Dokumentation als den primären Migrationsdienst für Lift-and-Shift-Migrationen aus.

Die Auswahl der richtigen EC2-Instanz

Wähle eine EC2-Instanz nicht automatisch auf Basis der CPU- und Arbeitsspeicher-Spezifikationen des DigitalOcean-Droplets aus. Miss stattdessen lieber die tatsächliche Auslastung des Droplets, um den tatsächlichen Bedarf der Anwendung zu ermitteln.

Ein DigitalOcean Droplet mit 4 vCPUs ist nicht zwangsläufig mit einer bestimmten EC2-Instanz mit 4 vCPUs vergleichbar.

Messen:

• CPU-Auslastung
• Arbeitsspeicherauslastung
• Netzwerkdurchsatz
• Festplattendurchsatz
• Disk IOPS
• Anwendungslatenz

Ein Server, der derzeit Folgendes nutzt:

4 vCPU

8 GB RAM

Average CPU: 20%

Average RAM: 45%

benötigt möglicherweise keine große EC2-Instanz.

Umgekehrt benötigt ein Server mit:

4 vCPU

8 GB RAM

CPU: 90%

Disk I/O: high

möglicherweise eine völlig andere Architektur.

5.Migration von DigitalOcean Volumes zu Amazon EBS

DigitalOcean Volumes bieten Block-Speicher, der an Droplets angehängt ist. Das AWS-Äquivalent ist im Allgemeinen Amazon EBS.

Eine einfache Migration läuft wie folgt ab:

DigitalOcean Volume

       ↓

Temporary backup/copy server

       ↓

AWS S3 or transfer mechanism

       ↓

Amazon EBS

       ↓

EC2 Mount

Allerdings solltest du zuerst bestimmen, was das Volume enthält.

Wenn es Anwendungsdateien enthält:

/var/www/uploads

EBS may be appropriate.

If it contains:

Fotos

Videos

Benutzerdokumente

backups

Ist Amazon S3 in der Regel die bessere Wahl.

Wenn es ein gemeinsam genutztes Dateisystem enthält, das von mehreren Servern verwendet wird, ziehe stattdessen Amazon EFS oder einen anderen AWS-Dateispeicherdienst in Betracht.

6. Migration von DigitalOcean Spaces zu Amazon S3

DigitalOcean Spaces ist ein S3-kompatibler Objektspeicher. DigitalOcean dokumentiert Dokumentkompatibilität explizit die Kompatibilität mit der S3-API sowie den AWS S3-Tools und SDKs.

Das macht Spaces zu einem der am einfachsten zu migrierenden DigitalOcean-Dienste.

Die Zielarchitektur sieht wie folgt aus:

DigitalOcean Spaces

        │

        │ S3-kompatibler Transfer

        ↓

Amazon S3

Option 1 — AWS DataSync

AWS DataSync unterstützt DigitalOcean Spaces als Objektspeicher-Quellort und kann Daten zwischen DigitalOcean Spaces und AWS-Speichern übertragen.

Das ist besonders für große Buckets nützlich.

Beispiel:

**Speicherplatz:**

photos-prod

    **Benutzer/**

    **Produkte**

    **Rechnungen**

    **Backups**

              ↓

S3:

Produktionsressourcen des Unternehmens

    **Benutzer/**

    **Produkte**

    **Rechnungen**

    **Backups**

DataSync kann während der Übertragung auch eine Integritätsprüfung durchführen.

Option 2 — AWS CLI

Da Spaces die S3-API unterstützt, können S3-kompatible Tools verwendet werden.

Beispielsweise kannst du einen S3-kompatiblen Endpunkt für DigitalOcean konfigurieren und anschließend Objekte in AWS S3 kopieren.

Konzeptionell:

aws s3 sync \

  s3://digitalocean-bucket \

  s3://aws-s3-bucket \

  –endpoint-url https://nyc3.digitaloceanspaces.com

Der genaue Endpunkt hängt von der Region deines Spaces ab.

Wichtige Aspekte

Prüfen:

• Bucket-Berechtigungen
• Öffentliche/private Objekte
• Objekt-Metadaten
• Content-Type
• Cache-Control
• Objektbesitz
• Lifecycle-Richtlinien
• CDN-Konfiguration
• Anwendungs-URLs

DigitalOcean Spaces verwendet eine S3-kompatible API, aber die Kompatibilität ist nicht vollständig identisch mit Amazon S3. Daher solltest du Anwendungen testen, die auf anbieterspezifisches Verhalten angewiesen sind.

7. Migration von verwaltetem DigitalOcean PostgreSQL zu Amazon RDS

Dies ist einer der wichtigsten Teile der Migration.

Das Ziel kann Folgendes sein:

• Amazon RDS für PostgreSQL
• Amazon Aurora PostgreSQL-kompatibel

AWS DMS unterstützt Migrationen von selbst verwaltetem PostgreSQL zu RDS für PostgreSQL und Aurora PostgreSQL. AWS bietet außerdem Möglichkeiten für homogene Migrationen mithilfe nativer PostgreSQL-Tools.

Eine typische Architektur sieht folgendermaßen aus:

DigitalOcean Managed PostgreSQL

             │

             │ AWS DMS

             ↓

 Amazon RDS PostgreSQL

PostgreSQL-Migration mit pg_dump

Bei kleineren Datenbanken kann ein Dump und anschließendes Wiederherstellen unkompliziert sein.

Auf der Quellseite:

pg_dump \

  -h SOURCE_HOST \

  -U SOURCE_USER \

  -Fc DATABASE_NAME \

  > database.dump

Übertrage den Dump zu AWS und stelle ihn wieder her:

pg_restore \

  -h RDS_ENDPOINT \

  -U TARGET_USER \

  -d DATABASE_NAME \

  database.dump

Dieser Ansatz ist einfach, erfordert jedoch in der Regel einen Schreibstopp während der abschließenden Migration.

PostgreSQL-Migration mit AWS DMS

Bei größeren Produktionsdatenbanken kann AWS DMS die Ausfallzeit reduzieren.

Die allgemeine Architektur sieht folgendermaßen aus:

             ┌───────────────┐

              │ DigitalOcean  │

              │ PostgreSQL    │

              └───────┬───────┘

                      │

                      Initiale Datenübertragung

                      │

                      Replikation von Änderungen

                      ↓

              ┌───────────────┐

              │    AWS DMS    │

              └───────┬───────┘

                      │

                      ↓

              ┌───────────────┐

              │ RDS PostgreSQL│

              └───────────────┘

AWS DMS kann bei unterstützten PostgreSQL-Migrationen sowohl einen vollständigen Ladevorgang als auch eine fortlaufende Replikation durchführen.

Die Migrationsschritte sind:

1. Erstelle die RDS-Datenbank.
2. Konfiguriere das Netzwerk.
3. Konfiguriere den Zugriff auf das PostgreSQL-Quellsystem.
4. Konfiguriere DMS.
5. Starte den vollständigen Ladevorgang.
6. Lass Änderungen replizieren.
7. Überwache den Replikations-Lag.
8. Stoppe Schreibvorgänge der Anwendung.
9. Warte, bis die Replikation aufgeholt hat.
10. Ändere den Datenbank-Endpunkt der Anwendung.
11. Validiere die Anwendung.
12. Setze die Schreibvorgänge fort.

Dadurch lässt sich die endgültige Ausfallzeit auf den Zeitraum des Cutovers reduzieren.

Migration von verwaltetem DigitalOcean MySQL

Dasselbe grundlegende Modell gilt auch für MySQL.

DigitalOcean Managed MySQL

           │

           │

           ↓

       AWS DMS

           │

           ↓

RDS MySQL / Aurora MySQL

AWS bietet Migrations-Workflows für MySQL zu RDS für MySQL und Aurora MySQL.

Für kleinere Datenbanken:

mysqldump \

  -h SOURCE_HOST \

  -u USER \

  -p \

  DATABASE > database.sql

Dann:

mysql \

  -h RDS_ENDPOINT \

  -u USER \

  -p \

  DATABASE < database.sql

Für Produktionssysteme, bei denen Ausfallzeiten eine wichtige Rolle spielen, solltest du Replikation oder AWS DMS verwenden.

9. Migration von Redis

Redis-Workloads von DigitalOcean müssen möglicherweise auf Folgendes migriert werden:

• Amazon ElastiCache für Valkey/Redis
• Redis-kompatible Infrastruktur auf EC2
• Eine andere AWS-Caching-Architektur

Beachte, dass AWS Valkey möglicherweise günstiger als Redis ist.

Bestimme zunächst, ob Redis Folgendes enthält:

Nicht persistente Cache-Daten

Wenn Redis nur zum Caching von Datenbankabfragen verwendet wird, musst du die Daten möglicherweise überhaupt nicht migrieren.

Einfach

Erstelle einfach einen neuen ElastiCache:

       ↓

Anwendung bereitstellen

       ↓

Die Anwendung füllt den Cache erneut.

Persistenter Anwendungsstatus

Wenn Redis Folgendes enthält:

• Warteschlangen
• Sitzungen
• Zähler
• Persistenten Anwendungsstatus

benötigst du eine geeignete Migrationsstrategie.

Zum Beispie:

DigitalOcean Redis

       │

       Sitzungen

       ├── queues

       Anwendungsstatus

              │

              ↓

       Migration/Replikation

              │

              ↓

      AWS ElastiCache

Behandle Redis nicht als entbehrlich, bevor du genau geprüft hast, welche Daten die Anwendung dort speichert.

10. Migration von DigitalOcean Kubernetes zu Amazon EKS

DigitalOcean Kubernetes und Amazon EKS verwenden beide Kubernetes, sind jedoch keine identischen Umgebungen.

Die sicherste Strategie besteht in der Regel nicht darin, den Kubernetes-Cluster selbst zu kopieren. nicht den Kubernetes-Cluster selbst zu kopieren.

Stattdessen:

DigitalOcean Kubernetes

          │

          Kubernetes-Manifeste

          ↓

       Amazon EKS

          │

          ├── Deployments

          ├── Services

          ├── ConfigMaps

          ├── Secrets

          └── Ingress

Exportiere oder rufe Folgendes ab:

• Deployments
• StatefulSets
• Leistungen
• ConfigMaps
• Geheimnisse
• Ingress
• PersistentVolumeClaims
• CronJobs
• RBAC
• Helm-Werte

Passe sie anschließend für AWS an.

Kubernetes-Speicher

Dies erfordert besondere Aufmerksamkeit.

DigitalOcean Persistent Volumes müssen möglicherweise zu Folgendem migriert werden:

• Amazon EBS CSI Volumes
• Amazon EFS
• S3

Zum Beispie:

DigitalOcean PVC

       ↓

Bei Blockspeicher

Bei gemeinsam genutztem DateisystemIf

Bei Objektdaten

Erstelle nicht einfach jedes DigitalOcean-Volume erneut als EBS-Volume.

11. Migration von der DigitalOcean Container Registry zu Amazon ECR

Wenn Anwendungen die DigitalOcean Container Registry verwenden, ist Amazon Elastic Container Registry (ECR) das naheliegende AWS-Pendant.

Beispiel:

DigitalOcean Registry

       │

       ├── app:v1

       ├── app:v2

       └── app:v3

             ↓

          Amazon ECR

             │

             ├── app:v1

             ├── app:v2

             └── app:v3

Du kannst das vorhandene Image abrufen:

docker pull registry.digitalocean.com/myregistry/myapp:v1

Für ECR taggen

docker tag \

  registry.digitalocean.com/myregistry/myapp:v1 \

  AWS_ACCOUNT_ID.dkr.ecr.REGION.amazonaws.com/myapp:v1

Bei ECR authentifizieren

aws ecr get-login-password –region REGION |

docker login \

  –username AWS \

  –password-stdin \

  AWS_ACCOUNT_ID.dkr.ecr.REGION.amazonaws.com

Anschließend pushen

docker push \

  AWS_ACCOUNT_ID.dkr.ecr.REGION.amazonaws.com/myapp:v1

For CI/CD, update the pipeline so future builds go directly to ECR.

12. Migration von DigitalOcean Load Balancern

Konfigurationen von DigitalOcean Load Balancern sollten in der Regel mithilfe von AWS Elastic Load Balancing neu erstellt werden.

Je nach Anwendung kannst du Folgendes verwenden:

• Application Load Balancer
• Network Load Balancer
• Gateway Load Balancer

Für eine normale HTTP/HTTPS-Webanwendung:

Internet

   │

   ↓

Route 53

   │

   ↓

Application Load Balancer

   │

   ├── EC2

   ├── EC2

   └── EC2

Anstatt DNS direkt auf eine EC2-Instanz zu verweisen, solltest du den DNS-Eintrag auf den Load Balancer verweisen lassen.

Das erleichtert auch die zukünftige Einrichtung von Auto Scaling.

13. Migration von DigitalOcean DNS zu Route 53

DigitalOcean bietet Domain- und DNS-Verwaltung als Teil seiner Netzwerkdienste an.

Das AWS-Pendant ist Amazon Route 53.

Bevor du die DNS-Einstellungen änderst, erstelle Folgendes neu:

• A records
• AAAA records
• CNAME records
• MX records
• TXT records
• SPF
• DKIM
• DMARC
• Verifizierungs-Records
• CAA records
• Subdomains

Zum Beispie:

DigitalOcean DNS

example.com

www.example.com

api.example.com

mail.example.com

wird zu

Route 53 Hosted Zone

example.com

 ├── www

 ├── api

 ├── mail

 └── …

DNS-TTL vor der Migration reduzieren

Reduziere einige Tage vor dem Cutover die TTL.

Zum Beispie:

Vorher

TTL = 3600 Sekunden

Migration:

TTL = 60 Sekunden

Ändere anschließend die DNS-Einträge auf AWS.

Nachdem die Migration stabil läuft, erhöhe die TTL wieder.

14. Migration von DigitalOcean Floating IPs

DigitalOcean Floating IPs bieten statische IP-Adressen, die Droplets zugewiesen werden können.

Das AWS-Pendant ist in der Regel eine Elastic IPwobei die bevorzugte AWS-Architektur häufig darin besteht, Anwendungen hinter einem Load Balancer zu betreiben, anstatt von einer einzelnen öffentlichen IP-Adresse abhängig zu sein.

Anstatt

DNS

 │

 ↓

Statische IP-Adresse

 │

 ↓

Ein Server

bevorzugt

DNS

 │

 ↓

ALB

 │

 ├── EC2

 ├── EC2

 └── EC2

Dadurch wird ein einzelner Server als Single Point of Failure vermieden.

15. Migration des DigitalOcean-VPC-Netzwerks

DigitalOcean VPCs ermöglichen eine private Vernetzung zwischen Ressourcen.

AWS bietet mit Amazon VPC deutlich umfangreichere Netzwerkfunktionen.

Eine typische AWS-VPC für Produktionsumgebungen enthält:

                    Internet

                        │

                  Internet Gateway

                        │

             ┌──────────┴──────────┐

             │                     │

       Public Subnet          Public Subnet

             │                     │

            ALB                   NAT

             │

       ┌─────┴─────┐

       │           │

 Private Subnet  Private Subnet

       │           │

      EC2         EC2

       │

       ↓

      RDS

Ein grundlegendes Produktionsdesign umfasst häufig:

• VPC
• Öffentliche Subnetze
• Private Subnetze für Anwendungen
• Private Subnetze für Datenbanken
• Internet Gateway
• NAT Gateway
• Routing-Tabellen
• Security Groups
• Network ACLs, sofern erforderlich

16. Migration von DigitalOcean Cloud Firewalls

DigitalOcean Cloud Firewalls sind zustandsbehaftete Netzwerk-Firewalls für Droplets.

AWS verwendet hauptsächlich:

• Security Groups
• Network ACLs

Security Groups sollten normalerweise die erste Sicherheitsebene sein, die du für EC2 verwendest.

Anstatt beispielsweise Folgendes zu erlauben:

Allow:

22

80

443

5432

von überall, solltest du anwendungsspezifische Regeln erstellen.

Webserver

Eingehend:

80  ← Internet

443 ← Internet

22  ← Admin IP/VPN only

Datenbank

Eingehend:

5432 ← Application Security Group

17. Migration von SSL/TLS-Zertifikaten

Wenn derzeit Zertifikate auf DigitalOcean-Servern vorhanden sind, solltest du entscheiden, ob AWS die TLS-Terminierung übernehmen soll.

Eine typische Architektur sieht folgendermaßen aus:

Internet

   │ HTTPS

   ↓

Application Load Balancer

   │

   │ HTTP/HTTPS

   ↓

EC2

Verwende AWS Certificate Manager für Zertifikate, die mit AWS-Services wie Application Load Balancern verbunden sind.

Dadurch entfällt die Aufgabe, Zertifikate auf einzelnen Servern zu erneuern.

18. Migration von DigitalOcean App Platform

Wenn deine Anwendung derzeit auf der DigitalOcean App Platform läuft, gibt es möglicherweise keinen direkten AWS-Ersatz.

Wähle die passende Lösung abhängig davon, wie die Anwendung funktioniert.

Containerisierte Webanwendung

Ziehe Folgendes in Betracht:

Amazon ECS + Fargate

Route 53

   ↓

ALB

   ↓

ECS/Fargate

   ↓

RDS

Kubernetes-Anwendung

Ziehe Folgendes in Betracht:

Amazon EKS

Route 53

   ↓

ALB

   ↓

EKS

Ereignisgesteuerte Anwendung

Ziehe Folgendes in Betracht:

AWS Lambda

API-Gateway

     ↓

Lambda

     ↓

DynamoDB/RDS/S3

Traditionelle Serveranwendung

Verwende:

EC2

ALB

 ↓

EC2

19. Migration von Backups

Backups sollten getrennt von den Produktionsdaten migriert werden.

DigitalOcean-Backups können während der Migration für ein Rollback hilfreich sein, sind aber nicht unbedingt als langfristige Backup-Strategie für AWS geeignet.

Für AWS solltest du Folgendes in Betracht ziehen:

• EBS snapshots
• AWS Backup
• RDS automated backups
• RDS snapshots
• S3-Versionierung
• S3-Lifecycle-Richtlinien
• Regionsübergreifende Replikation

Zum Beispie:

RDS

 │

 ├── Automatisierte Backups

 ├── Manuelle Snapshots

 └── AWS Backup

For S3:

S3

 ├── Versionierung

 ├── Lifecycle

 Replikation

Migration des Monitorings

Erstelle das Monitoring in Amazon CloudWatch neu.

Überwache:

EC2

• CPU-Auslastung
• Netzwerk
• Festplatte
• Statusprüfungen

RDS

• CPU-Auslastung
• Verbindungen
• Freier Speicher
• Lese-/Schreiblatenz
• IOPS
• Replikation

ALB

• Anzahl der Anfragen
• HTTP-Fehler
• Zustand der Zielinstanzen
• Antwortzeit

Anwendung

Verwende:

• CloudWatch Logs
• CloudWatch Metrics
• CloudWatch Alarms
• AWS X-Ray, sofern geeignet
• Mit OpenTelemetry kompatible Observability-Tools

21. Secrets und Umgebungsvariablen

DigitalOcean-Anwendungen verwenden möglicherweise derzeit Secrets wie:

DATABASE_URL

REDIS_URL

API_KEY

STRIPE_SECRET

JWT_SECRET

SMTP_PASSWORD

Lege diese nicht einfach alle in Umgebungsdateien auf EC2 ab.

AWS bietet:

• AWS Secrets Manager
• Systems Manager Parameter Store
• IAM-Rollen

Zum Beispie:

Anwendung

     │

     ↓

Geheimnismanager

     │

     Datenbankpasswort

     ├── API key

     └── OAuth secret

Dadurch werden auch die Rotation von Secrets und die Zugriffskontrolle erleichtert.

22. Ein vollständiges Beispiel: Migration einer Laravel-Anwendung

Betrachte eine DigitalOcean-Anwendung mit

Droplet

 ├── Nginx

 ├── PHP/Laravel

 ├── Queue-Worker

 └── Cron

Verwaltetes PostgreSQL

Spaces

 └── Benutzer-Uploads

Redis

 └── Cache + queues

Load Balancer

DNS

Eine geeignete AWS-Zielarchitektur wäre:

                        Route 53

                            │

                            ↓

                     CloudFront

                            │

                            ↓

                           ALB

                            │

                  ┌─────────┴─────────┐

                  ↓                   ↓

               EC2/ECS             EC2/ECS

                  │                   │

                  └─────────┬─────────┘

                            │

                    ┌───────┼────────┐

                    ↓       ↓        ↓

                   RDS   ElastiCache S3

                    │

                    ↓

               PostgreSQL

Migrationsablauf:

Schritt 1

Erstelle das AWS-Netzwerk.

Schritt 2

Erstelle RDS für PostgreSQL.

Schritt 3

Starte die Datenbankmigration.

Schritt 4

Erstelle einen S3-Bucket.

Schritt 5

Kopiere die Spaces-Objekte nach S3.

Schritt 6

Erstelle ein ECR-Repository.

Schritt 7

Übertrage das Anwendungs-Image zu ECR.

Schritt 8

Erstelle die EC2- oder ECS-Infrastruktur.

Schritt 9

Konfiguriere den Secrets Manager.

Schritt 10

Stelle die Anwendung bereit.

Schritt 11

Konfiguriere die Anwendung für die Verwendung von RDS.

Schritt 12

Überprüfe das Verhalten der Anwendung.

Schritt 13

Reduziere die DNS-TTL.

Schritt 14

Führe die abschließende Datenbanksynchronisierung durch.

Schritt 15

Stelle den DNS-Eintrag auf AWS um.

Schritt 16

Überwache die Umgebung.

Schritt 17

Halte DigitalOcean für ein Rollback verfügbar.

23. Testen vor dem Cutover

Erstelle einen formellen Migrations-Testplan.

Infrastruktur

Teste:

• Verfügbarkeit von EC2
• Load Balancer
• Security Groups
• NAT
• DNS
• TLS

Anwendung

Teste:

• Anmeldung
• Registrierung
• Checkout
• Suche
• Datei-Uploads
• Datei-Downloads
• E-Mail
• Hintergrundaufgaben
• Webhooks
• API-Integrationen

Datenbank

Teste:

• Anzahl der Datensätze
• Kritische Tabellen
• Indizes
• Gespeicherte Prozeduren/Funktionen
• Berechtigungen
• Transaktionen

Speicher

Teste:

• Anzahl der Objekte
• Objektgrößen
• Berechtigungen
• Metadaten
• Zugriff der Anwendung

Zum Beispie:

DigitalOcean:

users = 1,250,342

AWS:

users = 1,250,342

Vergleiche anschließend wichtige Geschäftstabellen, anstatt dich ausschließlich auf Erfolgsmeldungen auf Infrastrukturebene zu verlassen.

AWS weist darauf hin, dass einige homogene DMS-Migrationen keine integrierte Datenvalidierung bieten. Daher bleibt die Validierung auf Anwendungs- und Datenbankebene wichtig.

Häufige Fehler bei der Migration

Fehler 1: AWS wie DigitalOcean behandeln

AWS ist nicht einfach „DigitalOcean mit mehr Services“.

Du musst Folgendes verstehen:

• VPCs
• Ich bin
• Security Groups
• Subnetze
• Routing-Tabellen
• Availability Zones
• Load Balancer
• IAM-Rollen

Fehler 2: Server migrieren, ohne Abhängigkeiten zu verstehen

Ein Droplet kann von Folgendem abhängig sein:

Droplet

 ├── PostgreSQL

 ├── Redis

 ├── Spaces

 ├── SMTP

 ├── DNS

 └── External API

Wenn du nur das Droplet migrierst, wird die Anwendung nicht vollständig migriert.

Fehler 3: Hintergrund-Worker vergessen

Der Web-Traffic kann funktionieren, während:

Warteschlangen

Cron

Geplante Jobs

Worker

nicht funktionieren.

Fehler 4: URLs des Objektspeichers vergessen

Anwendungen speichern häufig URLs wie:

https://bucket.nyc3.digitaloceanspaces.com/image.jpg

Nach der Migration müssen diese möglicherweise geändert werden in:

https://cdn.example.com/image.jpg

or an S3/CloudFront URL.

Fehler 5: Architektur und Cloud-Anbieter gleichzeitig ändern

Wenn deine DigitalOcean-Anwendung einwandfrei funktioniert, erhöht eine gleichzeitige Migration und vollständige Neuentwicklung das Risiko erheblich.

Ein sichererer Ansatz ist:

Phase 1:

DigitalOcean → AWS mit minimalen Änderungen

Phase 2:

Optimierung auf AWS

Phase 3:

Modernisierung

25. Abschließende Checkliste

Bevor du DigitalOcean abschaltest, überprüfe Folgendes:

Compute

• Alle Droplets migriert
• CPU-/RAM-Dimensionierung validiert
• Services laufen
• Cron-Jobs migriert
• Worker migriert
• SSH-/Admin-Zugriff getestet

Datenbank

• Datenbank migriert
• Anzahl der Datensätze validiert
• Indizes validiert
• Benutzer/Berechtigungen neu erstellt
• Replikation getestet
• Backup konfiguriert
• Anwendung getestet

Speicher

• Spaces kopiert
• Anzahl der Objekte verglichen
• Objekt-Metadaten überprüft
• Berechtigungen getestet
• Anwendungs-URLs aktualisiert
• CDN getestet

Netzwerk

• VPC erstellt
• Subnetze erstellt
• Routen konfiguriert
• Security Groups konfiguriert
• Load Balancer getestet
• TLS konfiguriert

DNS

• DNS-Zone neu erstellt
• MX-Records migriert
• TXT-Records migriert
• SPF/DKIM/DMARC überprüft
• TTL reduziert
• AWS-Endpunkte getestet

Betrieb

• CloudWatch konfiguriert
• Alarme konfiguriert
• Protokollierung aktiviert
• Backups konfiguriert
• IAM überprüft
• Secrets migriert

Cutover

• AWS-Umgebung getestet
• Datenbank synchronisiert
• Speicher synchronisiert
• Rollback-Plan getestet
• DNS umgestellt
• Anwendung überwacht
• DigitalOcean vorübergehend beibehalten

Schlussfolgerung

Eine Migration von DigitalOcean zu AWS sollte nicht einfach als Kopieren von Droplets nach EC2 betrachtet werden. Bei einer erfolgreichen Migration werden Daten, Compute, Netzwerk, Speicher, Datenbanken, DNS und Anwendungsservicesgetrennt betrachtet und anschließend jedem Workload die passende AWS-Architektur zugeordnet.

Das wichtigste Prinzip besteht darin Zustandsdaten sorgfältig zu migrieren und Anwendungen unabhängig davon zu migrieren.Datenbanken und persistenter Speicher erfordern die größte Aufmerksamkeit, da sie maßgeblich bestimmen, wie viel Ausfallzeit erforderlich ist. AWS DMS kann insbesondere bei unterstützten PostgreSQL- und MySQL-Migrationen hilfreich sein, wenn eine kontinuierliche Replikation gewünscht ist. 

Für große Umgebungen ist eine schrittweise Migration –Bestandsaufnahme → AWS aufbauen → Daten replizieren → bereitstellen → testen → Cutover → optimieren– in der Regel sicherer, als zu versuchen, die gesamte Migration in einem einzigen großen Schritt durchzuführen.