Auto-scaling schaalt te laat of flapt heen-en-weer
Drie kalibraties: warming-time, scale-out moet sneller dan scale-in, en kies de juiste metriek. Default-CPU-target werkt zelden voor moderne apps.
Probeer dit eerst zelf
- 1Stel scale-out aggressief in, scale-in conservatief. Bijvoorbeeld scale-out bij 60 procent CPU 2 minuten, scale-in bij 30 procent gedurende 15 minuten. Anders krijg je flapping.
- 2Kies een metriek die je echte bottleneck reflecteert. Voor web vaak request-count-per-target via ALB-target-tracking, niet CPU.
- 3Stel cooldown of warm-pool in. Als instance-startup 3 minuten duurt, is een 1-minuut-evaluatie zinloos.
- 4Voor predictive workloads (e-commerce, kantooruur-spike): predictive scaling op basis van patroon. Vult voor de spike aan.
- 5Test je scaling onder load met een tool als k6 of Locust. Een config die nooit getest is, gaat tijdens de eerste piek omvallen.
Wanneer ons inschakelen
Krijg je tijdens piek toch SLA-overschrijdingen ondanks scaling, dan is een korte performance-review zinvol. De fix zit vaak in pool-warmup of in de app, niet in de auto-scaling-config.
Zie ook
- Iedereen logt in met het root-account van AWSHet root-account is voor noodgevallen en facturatie. Dagelijks werk hoort via IAM-users of SSO.
- Iedere developer heeft AdministratorAccessAdministratorAccess overal is gemak nu, drama later. Begin met rolgebaseerde policies.
- Iedereen heeft losse IAM-users met eigen wachtwoordIdentity Center (voorheen AWS SSO) koppelt aan je IdP en geeft tijdelijke credentials per sessie.
Past het bovenstaande niet?
Beschrijf je situatie hieronder. We sturen jouw input plus de stappen die je al zag naar onze AI en geven gericht vervolg-advies. Als het te risicovol is om zelf te doen, zeggen we dat ook.
Of doe het helemaal niet zelf
Onze Managed IT-klanten zoeken dit soort vragen niet op. Eén aanspreekpunt, vaste prijs per maand, en het is binnen werktijd opgelost.