Een bedrijf draait een REST-gebaseerde applicatie op Amazon EC2 die bijna-realtime gegevens ontvangt van een externe leverancier. De applicatie verwerkt en slaat de gegevens op. De leverancier ontvangt veel 503 Service Unavailable-fouten bij het verzenden van gegevens, omdat de rekencapaciteit piekt en de applicatie de maximale capaciteit bereikt. Welk ontwerp moet een solutions architect aanbevelen om een schaalbaardere oplossing te bieden?

De correcte optie is het gebruik van Amazon Kinesis Data Streams om de gegevens op te nemen en deze te verwerken met AWS Lambda-functies. Kinesis Data Streams is ontworpen voor het opnemen van grote volumes streaminggegevens en fungeert als een buffer, waardoor de applicatie de gegevens asynchroon kan verwerken. Dit voorkomt dat de EC2-instances overbelast raken tijdens pieken, wat de 503-fouten oplost. Lambda is schaalbaar en kosteneffectief voor het verwerken van individuele datarecords. De andere opties zijn minder geschikt: Amazon API Gateway bovenop de bestaande applicatie met een quotumlimiet zou de 503-fouten niet oplossen, maar de leverancier juist beperken. Amazon SNS is een messaging-service, niet primair ontworpen voor het opnemen van hoge volumes streaminggegevens zoals Kinesis. Hoewel een Auto Scaling group met een ALB schaalbaarheid biedt, lost het de initiële buffering van de datastroom niet op. Het herverpakken als een container met ECS en een Auto Scaling group verbetert de schaalbaarheid van de applicatie, maar lost het probleem van de piekbelasting bij de opname van gegevens niet direct op, tenzij er ook een bufferingsmechanisme wordt toegevoegd.