Een keten van reisbureaus draait een applicatie op twee vaste Amazon EC2-instances achter een Route 53 multivalue record dat de Elastic IP's van de instances retourneert. De app gebruikt DynamoDB voor primaire opslag en een zelf-gehoste Redis-cache. Bestemmingscontent wordt per kwartaal bijgewerkt; updates veroorzaken piekbelasting en hebben geleid tot downtime. U moet de app zeer beschikbaar maken en in staat stellen de updatebelasting te verwerken. Welke oplossing voldoet aan deze behoeften?

De correcte oplossing pakt alle pijnpunten aan. DAX verbetert de prestaties van DynamoDB, wat cruciaal is voor de primaire opslag. Een Auto Scaling Group achter een ALB zorgt voor hoge beschikbaarheid en schaalbaarheid van de EC2-instances, wat essentieel is om piekbelasting tijdens contentupdates op te vangen. Het bijwerken van het Route 53-record naar een simple routing policy die verwijst naar de ALB-alias, is de juiste manier om verkeer naar de schaalbare EC2-instances te leiden. Geplande schaling (scheduled scaling) is de meest efficiënte manier om proactief te reageren op de bekende piekbelasting van kwartaalupdates. De andere opties zijn minder geschikt: Het gebruik van ElastiCache for Redis of Memcached is een goede stap voor caching, maar DAX is specifiek ontworpen om de prestaties van DynamoDB te verbeteren, wat hier de primaire opslag is. Het gebruik van CloudFront met de Auto Scaling Group als origin is niet optimaal voor een applicatie die dynamische content serveert en geen statische content. Een ALB is hier geschikter. Handmatige schaling is minder betrouwbaar en efficiënt dan geautomatiseerde, geplande schaling voor bekende piekbelasting.