Beginnen Sie mit Ihrer Arbeitslast, nicht mit einem Hosting-Plan
Listen Sie die Journeys auf, die Wert oder Risiko erzeugen: Erstanfrage, Suche, Anmeldung, Produktdetail, Formularabsendung, Checkout, Editor-Aktualisierung oder API-Aufruf. Für jede Route erfassen Sie Spitzenanfragen oder gleichzeitige Nutzer, Payload, Personalisierung, Abhängigkeiten und Besucherregionen. Schließen Sie geplante und Admin-Arbeiten ein, weil sie die gleichen Ressourcen verbrauchen.
Machen Sie aus der Liste Annahmekriterien. Largest Contentful Paint, oder LCP, misst das Laden des Hauptinhalts; Interaction to Next Paint, oder INP, die Reaktionsfähigkeit; und Cumulative Layout Shift, oder CLS, unerwartete Verschiebungen. Google beschreibt gute Zielwerte als LCP innerhalb von 2,5 Sekunden, INP unter 200 Millisekunden und CLS unter 0,1. Fügen Sie Routenvollständigung, Server-Antwortzeit und Fehlerquote-Ziele hinzu.
Lassen Sie eine schnell gecachte Seite nicht stellvertretend für eine authentifizierte oder datenbankgestützte Transaktion gelten.
Definieren Sie Spitzenperioden, erwartetes Wachstum, Kampagnenspitzen und überlappende Batch-Arbeit.
Kennzeichnen Sie, ob der Host, Ihr Team oder ein Dritter jeden wahrscheinlichen Engpass kontrolliert.
Vergleichen Sie Kapazität, Limits und Skalierungsverhalten
Fragen Sie nach den Limits hinter dem Angebot: Compute und Memory, Storage-Performance, Datenbankverbindungen, Worker-Limits, Netzwerkgebühren, Request-Kontrollen und Einschränkungen durch Nachbarn in Shared-Umgebungen. “Unbegrenzte Bandbreite” sagt nicht aus, ob die App genug uncached Arbeit bei einem Peak leisten kann. Erfragen Sie, welche Metriken sichtbar sind und wie lange sie verfügbar bleiben.
Skalierung ist nur relevant, wenn Auslöser, Verzögerung, Decke und Preis bekannt sind. Bestätigen Sie, ob sie automatisch erfolgt, ob Sessions und Jobs sicher bleiben und was an der Decke geschieht. Bevorzugen Sie einen Test am erwarteten Peak und darüber hinaus gegenüber einer theoretischen Kapazitätsbehauptung. Headroom ist eine Geschäftsentscheidung, keine universelle Prozentzahl.
Vergleichen Sie p95- oder p99-Antwortzeiten, nicht nur einen Durchschnitt.
Sammeln Sie Datenbank-, Queue- und Upstream-API-Zeiten während des Tests.
Schätzen Sie Skalierungs-, Auslieferungs-, Backup- und Second-Region-Kosten vor einer Verpflichtung.
Platzieren Sie den Origin bewusst und validieren Sie die Auslieferung
Wählen Sie eine Origin-Region unter Berücksichtigung von Zielgruppenstandort, Anwendungsabhängigkeiten, Datenort-Anforderungen und Bedienerzugang. Testen Sie aus repräsentativen Geografien und Netzwerkbedingungen. Ein Content Delivery Network, oder CDN, ist ein verteilter Cache, der berechtigte Assets näher an Besucher ausliefern und Origin-Arbeit reduzieren kann; es ersetzt keinen gesunden Origin, keine Datenbank oder Anwendung.
Untersuchen Sie Header und Verhalten, nicht nur eine Dashboard-Einstellung. Versionierte statische Assets können in der Regel längere Lebensdauern haben, weil ein Update eine neue URL bringt. Dynamische und personalisierte Antworten brauchen explizite Regeln. HTTP unterscheidet Shared- von Private-Caches; Kontodaten dürfen nicht für andere Kunden wiederverwendbar werden. Üben Sie das Purgen eines Caches und das Zurückrollen.
Erfassen Sie einen Erstbesuch und einen Wiederkehr-Besuch, weil sich Cache-Zustände unterscheiden.
Verifizieren Sie Cache-Control und Cache-Keys für Seiten, Assets, Cookies, Parameter und Locale.
Dokumentieren Sie, wie berechtigtes Personal eine schädliche Regel deaktiviert, ohne sensible Inhalte offenzulegen.
Behandeln Sie Wiederherstellungsnachweise als Leistungsanforderung
Fragen Sie, was gesichert wird, wo Kopien liegen, Retention, Wiederherstellungsbefugnis und ob Backups Datenbanken, Uploads, Code, Konfiguration und Infrastruktur abdecken. Definieren Sie Recovery Point Objective, oder RPO, als akzeptablen Datenverlust in Zeit, und Recovery Time Objective, oder RTO, als akzeptable Wiederherstellungszeit. Legen Sie beide Werte aus den Geschäftsfolgen fest, nicht aus Default-Paketen.
Ein erfolgreiches Backup ist kein Wiederherstellungsnachweis. CISA empfiehlt geplante Wiederherstellungstests, und AWS sagt, dass Disaster Recovery bewertet und getestet werden sollte. Stellen Sie eine aktuelle Kopie isoliert wieder her, prüfen Sie wichtige Datensätze und Medien, nutzen Sie die dokumentierte Sequenz und protokollieren Sie die verstrichene Zeit. Eine alternative Region kann einige Risiken reduzieren, bringt aber Kosten und Komplexität mit sich.
Stellen Sie eine einzelne Datei oder einen Datensatz wieder her, ohne aktuelle Daten zu überschreiben.
Begrenzen Sie Restore-Zugriff und halten Sie Wiederherstellungs-Zugangsdaten und Runbooks für berechtigte Responder verfügbar.
Ein Datenbanksnapshot stellt möglicherweise Einstellungen, Anwendungsversionen oder Auslieferungsregeln nicht vollständig wieder her.
Bewerten Sie Support und Shared Responsibility, bevor Sie ihn brauchen
Vergleichen Sie Supportumfang, Stunden, Kanäle, Eskalation und den Unterschied zwischen Plattformvorfällen und Anwendungsfehlerbehebung. Holen Sie schriftliche Verantwortung für Patches, gemanagte Datenbanken, TLS, Firewall-Regeln, Backups und Wiederherstellung ein. Ein Support-Versprechen ist nützlich, wenn es den Eigentümer und die nächsten Schritte in einem realistischen Szenario benennt.
Überprüfen Sie Zugriffsrollen, Multi-Faktor-Authentifizierung, Audit-Logs, Geheimnis-Handling und Kontoisolation. Für Zahlungskarten oder sensible regulierte Daten stellen Hosting-Funktionen allein keine Compliance her. Verwenden Sie diesen Vergleich als technischen Input und holen Sie qualifizierte Sicherheits-, Rechts- oder Compliance-Prüfung der Zahlungsarchitektur und der anwendbaren Pflichten ein.
Fragen Sie, wie der Anbieter mit einem fehlschlagenden Restore, einer saturierten Datenbank oder einer schädlichen Cache-Regel umgeht.
Prüfen Sie, wer Produktion ändern, Backups lesen, Logs einsehen und Anmeldeinformationen erstellen kann.
Serviceguthaben und gemanagte Abdeckung können materielle Bedingungen enthalten.
Führen Sie realistische, sichere Vergleichstests durch und führen Sie die Bewertungsmatrix
Verwenden Sie dieselbe Release, Konfigurationsabsicht und Testskript für jeden Kandidaten. Führen Sie ein Baseline-, erwartetes Peak-, kurzen Spike-, anhaltendes Perioden- und eine sichere Wiederherstellungs- oder Deployment-Übung durch. AWS empfiehlt produktionsähnliche Umgebungen, definierte Szenarien, architekturweites Monitoring, bereinigte oder synthetische Daten und regelmäßiges Retesting. Holen Sie sich die Zustimmung des Providers und befolgen Sie dessen Testpolicy.
Kombinieren Sie kontrollierte Labortests mit Felddaten nach dem Launch. Labortests sind wiederholbar für Debugging; Felddaten spiegeln reale Geräte, Netzwerke, Geografie, Cache-Zustand und Verhalten wider. Überarbeiten Sie die Bewertungsmatrix nach größeren Releases oder Abhängigkeitsänderungen. SIU kann Ergebnisse in Pre-Launch-Härtung, eigentümerzugewiesene Behebung und rollback-bereite Verbesserungen umsetzen.
Halten Sie Standorte, Gleichzeitigkeit, Cache-Zustand und Payloads konsistent.
Speichern Sie Routentimings, Fehler, Ressourcenmetriken, Versionen, Kosten und Beobachtungen.
Wählen Sie die Option, die dokumentierte Bedürfnisse zu nachhaltigen Betriebskosten erfüllt.