Begin bij je workload, niet bij een hostingplan
Maak een lijst van de journeys die waarde of risico creëren: eerste bezoek, zoeken, inloggen, productdetail, formulierinzending, checkout, bewerkerupdate of API-aanroep. Noteer voor elk piekverzoeken of gelijktijdige gebruikers, payload, personalisatie, afhankelijkheden en bezoekersregio's. Neem geplande en admin-taken op omdat die dezelfde resources verbruiken.
Zet de lijst om in acceptatiematen. Largest Contentful Paint (LCP) meet het laden van de hoofdinhoud; Interaction to Next Paint (INP) meet de reactietijd; en Cumulative Layout Shift (CLS) onverwachte verschuivingen. Google beschrijft goede doelen als LCP binnen 2,5 seconden, INP onder 200 milliseconden en CLS onder 0,1. Voeg routevoltooiing, serverresponstijd en foutpercentaandoelen toe.
Laat een snelle gecachte pagina een geverifieerde of database-ondersteunde transactie niet maskeren.
Bepaal de piekperiode, verwachtte groei, campagnepieken en overlappend batchwerk.
Geef aan of de host, je team of een derde partij elk waarschijnlijk knelpunt beheert.
Vergelijk capaciteit, limieten en schaalgedrag
Vraag naar de limieten achter het aanbod: compute en geheugen, opslagprestaties, databaseverbindingen, worker-limieten, netwerkkosten, request-controls en beperkingen door gedeelde buren. “Onbeperkte bandbreedte” zegt niets over of de app voldoende ongecacheerd werk kan uitvoeren tijdens een piek. Vraag welke metrics zichtbaar zijn en hoe lang ze beschikbaar blijven.
Schaalbaarheid doet ertoe alleen als trigger, vertraging, plafond en prijs bekend zijn. Bevestig of het automatisch is, of sessies en jobs veilig blijven en wat er gebeurt bij het plafond. Geef de voorkeur aan een test bij de verwachte piek en daarbuiten boven een theoretische capaciteitsclaim. Headroom is een zakelijke keuze, geen universeel percentage.
Vergelijk p95- of p99-responstijden, niet alleen een gemiddelde.
Verzamel database-, queue- en upstream-API-timings tijdens de test.
Schat schaal-, leverings-, back-up- en tweede-regiokosten voordat je je vastlegt.
Plaats de origin doelbewust en valideer levering
Kies een origin-regio op basis van publiekslocatie, applicatieafhankelijkheden, gegevenslocatiebehoeften en operationele toegang. Test vanuit representatieve geografische locaties en netwerkcondities. Een content delivery network (CDN) is een gedistribueerde cache die geschikte assets dichter bij bezoekers kan serveren en origin-werk kan verminderen; het vervangt geen gezonde origin, database of applicatie.
Inspecteer headers en gedrag, niet alleen een dashboardinstelling. Gestructureerde (versioned) statische assets kunnen meestal langere levensduur hebben omdat een update een nieuwe URL heeft. Dynamische en gepersonaliseerde responses hebben expliciete regels nodig. HTTP maakt onderscheid tussen gedeelde en private caches; accountgegevens mogen niet herbruikbaar worden voor een andere klant. Oefen een cache-purge en rollback.
Leg een eerste bezoek en een terugkerend bezoek vast omdat cache-statussen verschillen.
Verifieer Cache-Control en cachekeys voor pagina's, assets, cookies, parameters en locale.
Documenteer hoe bevoegde medewerkers een schadelijke regel uitschakelen zonder gevoelige inhoud bloot te geven.
Behandel herstelbewijs als een prestatie-eis
Vraag wat er wordt geback-upt, waar kopieën liggen, retentie, wie kan herstellen en of back-ups databases, uploads, code, configuratie en infrastructuur dekken. Definieer recovery point objective (RPO) als acceptabel dataverlies in tijd en recovery time objective (RTO) als acceptabele hersteltijd. Stel beide vast op basis van zakelijke consequenties, niet een standaardpakket.
Een succesvolle back-up is geen herstelbewijs. CISA raadt geplande hersteltests aan, en AWS zegt dat disaster recovery beoordeeld en getest moet worden. Herstel een recente kopie in isolatie, controleer belangrijke records en media, volg de gedocumenteerde volgorde en registreer verstreken tijd. Een alternatieve regio verlaagt sommige risico's maar voegt kosten en complexiteit toe.
Herstel één bestand of record zonder huidige data te overschrijven.
Beperk hersteltoegang en houd herstelreferenties en runbooks beschikbaar voor geautoriseerde responders.
Een database-snapshot kan instellingen, applicatieversies of leveringsregels niet recreëren.
Evalueer support en gedeelde verantwoordelijkheid voordat je het nodig hebt
Vergelijk supportscope, uren, kanalen, escalatie en het verschil tussen platformincidenten en applicatietroubleshooting. Krijg schriftelijke verantwoordelijkheid voor patches, managed databases, TLS, firewallregels, back-ups en herstel. Een supportbelofte is nuttig wanneer deze een eigenaar en vervolgstap in een realistisch scenario noemt.
Beoordeel toegangsrollen, multi-factor authenticatie, auditlogs, geheimbeheer en accountisolatie. Voor betaalkaarten of gevoelige gereguleerde data stellen hostingfeatures op zichzelf geen naleving vast. Gebruik deze vergelijking als technisch input en laat gekwalificeerde security-, juridische- of compliance-review uitvoeren voor de betaalarchitectuur en toepasselijke verplichtingen.
Vraag hoe de provider omgaat met een mislukte restore, verzadigde database of schadelijke cache-regel.
Controleer wie productie kan wijzigen, back-ups kan lezen, logs kan bekijken en credentials kan aanmaken.
Servicekredieten en managed-dekking kunnen materiële voorwaarden hebben.
Voer realistische, veilige vergelijkende tests uit en houd de scorecard bij
Gebruik voor elke kandidaat dezelfde release, configuratie-intentie en testscript. Voer een baseline, verwachte piek, korte spike, langdurige periode en een veilige herstel- of uitroloefening uit. AWS raadt productieachtige omgevingen, gedefinieerde scenario's, architectuurbrede monitoring, gesaneerde of synthetische data en regelmatige retests aan. Vraag providergoedkeuring en volg het testbeleid van de provider.
Combineer gecontroleerde labtests met veldgegevens na livegang. Labtests zijn reproduceerbaar voor debugging; veldgegevens weerspiegelen echte apparaten, netwerken, geografische spreiding, cache-status en gedrag. Herzie de scorecard na grote releases of wijzigingen in afhankelijkheden. SIU kan bevindingen omzetten in pre-launch hardening, door eigenaren toegewezen herstelacties en rollback-klaar verbeteringen.
Houd locaties, gelijktijdigheid, cache-status en payloads consistent.
Sla routetimings, fouten, resourcemetrics, versies, kosten en observaties op.
Selecteer de optie die aan de gedocumenteerde behoeften voldoet tegen een duurzaam operationeel kostenplaatje.