AWS re:Invent is right around the corner, and Webscale engineering squad is flying over to our yearly cloud Christmas event to get the latest tech releases fresh from the source – and to enjoy a week in Vegas as a bonus.

In 2014 we came back home with shiny new toys – Lambda for serverless applications, EC2 Container Service to run Docker clusters and Aurora for massively scaling SQL backend.

This year we come prepared with a wish list of things AWS could do even better.

Creating backups, sending a scheduled newsletter and computing web store predictions are all often required examples of scheduled jobs that need to run on online services.

While AWS offers a brilliant set of services for most other needs, a job scheduler is still something you need to write yourself, from scratch.

Commonly used implementations are using a application server scheduling system – which requires a server – or running them as scripts on a on-schedule autoscaling groups – which requires a server – or lately, scheduling the job on Data Pipeline. Each of these implementations works, but requires extra effort and bunch of boilerplate for a simple job. It is like hammering a nail with a chainsaw – in some cases it works, but it is clear that this is not the right tool for the job.

When you know your service is about to receive a high traffic surge, you need to prepare your environment. Despite being able to scale up your correctly designed AWS environment in minutes, the load balancer service component ELB is a known potential bottleneck for high sudden loads.

Nowadays you need to manually create a support ticket for preparing, “pre-heating”, the load balancer every time you know the service traffic is about to spike. Imagine sending a monthly discount promotion newsletter and having to each and every time send that ticket – or getting lower performance.

We’ve been telling AWS at every turn that this needs to be automated – or gotten rid of the preheating need entirely. In best AWS tradition they tell us it’s being worked on but they can’t really publicly say anything about release plans.

Running your servers without any publicly visible endpoints is done with private subnets, and having a NAT instance controlling the traffic to your infrastructure privates.

This is something you literally need at every single distributed web service stack, and instead of managing NAT server health it should be just another resource that AWS manages for you completely.

From what AWS architects tell me, we are not alone with this wish.

What’s your top wish from AWS this year? Come tell us over a pint or two on us in the Nordic get together!