Opinion: AWS Outposts is missing a killer feature.

With AWS Outposts companies bring the power of AWS to on-premises locations. A managed, pre-configured solution offering a range of AWS Services, mostly focused around network, compute and data storage, delivered in standard form factors to simply slide into a rack and plug in.
It is, without a doubt, a brilliant solution for enterprise, factories and more, but I believe there’s one service missing that could really broaden Outposts appeal: CloudFront.

A local CloudFront edge node

Outposts is all about processing data on the edge of the network, reducing transfer costs and latency, and improving the security of data by keeping it on-site. This is very similar philosophy to that of CloudFront - delivering content to users as quickly and efficiently as possible. CloudFront even has edge functions, which further serves to highlight the overlap between these services. Yet currently CloudFront is not a supported service on Outposts.

Imagine a large-scale event with an accompanying virtual guide website (or app), rich in media content.
Visitors interact frequently with the guide throughout the day, which is making good use of CloudFronts edge functions and cache behaviours.
However, visitors will still suffer an unnecessarily subpar user experience because each users content is fetched over the internet from the nearest CloudFront node.

The power of a CloudFront Outpost

In situations like this, the need for a CloudFront Outpost is easy to understand. Caching content on-premises, with the full range of features provided by CloudFront would allow us to:

Improve user experience:
Delivering content directly from the premises will of course result in a faster, more enjoyable experience for users. In addition to this, the (partial) removal of the bandwidth constraint would allow developers to create better experiences, with richer media usage, further improving the experience.
Reduce data transfer costs:
While AWS would be sure to charge a hefty fee for such an Outpost, it’s reduction of both bandwidth usage from the internet based CloudFront and reduced congestion of the locations internet connection may still translate to cost savings.
Security
More user data would be kept on site; some processing could also be shifted to CloudFront@Edge functions, which would now be running on premises. The event would also be partially insulated against a loss of internet connectivity.

The use cases extends beyond live events of course. Wherever a large group of people are frequently accessing a given set of internet resources, a local CloudFront node could be beneficial - for example, airports, large stations, even retail chains with loyalty apps might potentially benefit. It would also be applicable in situations where internet connectivity can be expensive or unreliable, for example cruise ships and ferries, or temporary events in remote areas.

How it might work

Such a thing would be easy to set up, as it should simply be applying the same CloudFront configuration that’s also in use on the wider internet. Installation might potentially be limited to specifying the distributions to serve (presumably limited to those in your account, and pre-configured by AWS), and adjusting the routing of the local network to route requests to the domains of those distributions to the Outpost. Users with custom DNS settings or VPNs would presumably continue to use the wider internet versions, but as it’s a literal extension of CloudFront, they would have an identical experience.

Conclusion

The ability to easily deploy a CloudFront Outpost would clearly be beneficial in a variety of use cases, and both broaden the appeal of, and introduce new customers to, the concepts of AWS Outposts and edge computing in general.
However, given that it’s a fairly obvious idea, there are presumably technical, security or business reasons why AWS has not (yet) implemented it.
Nevertheless it’s an exciting product idea that I would love to see realized one day.