Just a user story with some acceptance criteria is not enough when estimating stories that you implement in AWS cloud
Scrum way of doing things delays lots of design decisions into planning I - When you work with software defined infrastructure, you need to do a design earlier in the process on, in order to get results that match with reality.
When Scrum and user stories were invented, infrastructure was a given thing and features assumed it to be. At some point in time, a server was purchased or rented and this was a given set of ressources then.
In a cloud based architecture, instrastructure is software or configuration and thus the 'hardware' can be defined newly with each story.
Given software defined infrastrucutre, the implementation of a story can differ vastly and thus cost of operation.
The same goes for the cost of implementation. Given different choices on infrastructure a feature might be require more or less elements and it is vital for a estimate to know the infrastructure beforehand as much as possible.
A simple UML Sequence diagram wiull help greatly how certain elements of the infrastructure are pieced together. Do this as a design session on a whiteboard, with the whole team.
Depending oan what services you choose to solve a problem, there are several service limits that apply. Research all of them, they represent your acceptance criteria.
Depending on your choices for services in the AWS infrastructure and external ones attached (e.g. lambda monitoring) create cost. At least model and calculate the cost for the desired design under the expected conditions.
if you are using new services in the AWS landscape: Do a spike imlmenenting the desired functionality as a prototype. This will vastly improve the match between estimate and actual used time to implement the feature.
When done with the implementation, review time taken / efforttaken vs. estimated time/effort all the time. Share the created insigts with all the team members.
Another possibility would be to scope down the AWS env to particular services/regions/features to reduce the "blast radius" of developer entropy.