top of page

AWS Summit London 2026: From Cloud Services to Platform Value

At AWS Summit London, one theme came up again and again across organisations of every size and sector: platform teams are getting much clearer about what they should build, and what they shouldn’t.


From highly regulated financial institutions to global travel platforms, the most effective teams aren’t trying to recreate cloud services. They are deliberately offloading undifferentiated work to providers like AWS, and focusing their effort on the parts of the platform that actually create business value.


This shift, from building everything to blending bought and built capabilities, is quietly redefining what “good” platform engineering looks like today.


Platform stories grounded in reality


Talks from enterprises such as Skyscanner, LSEG, and Legal and General reflected the reality most platform teams face: organisations with a rich history and high expectations from their customers don't get a clean slate. Their systems are complex, and their constraints are real, which makes them focus their energies on the most highly valued parts of their systems.


Thiru Karunanidhi really brought this to life as he shared Legal and General’s journey over the last 3 years. As a leading global financial market provider, L&G operates under strict regulatory controls and cannot afford risky moves, but equally cannot afford to stop innovating. Instead, they invested in advancing their data analytics architecture to leverage AWS-provided infrastructure, allowing them to focus on the business rules that make their exchange unique.



This is a familiar pattern for platforms today. Infrastructure providers are expanding what can be purchased as a commodity, which changes the game in what can be achieved by even small platform engineering teams.


Well-paved roads still matter


Rashid Matin's “well-paved roads” analogy captured the significant investment he and the team at Entain have made in striking this important balance.


Platforms should guide teams towards secure and compliant paths, without blocking progress when teams need to go off-road.



For platform engineers, this often translates into offering strong defaults, as Rashid described, rather than strict mandates. Golden paths that are easy to adopt but not the only option, as some teams may choose to go off-road and contribute their successful experiments back.


What is exciting is how many of those paths can now leverage patterns such as composition and reconciliation that are provided by Kubernetes.


Standardisation is a scaling strategy


Skyscanner’s lessons from a decade of platform evolution were to be opinionated, with standardisation where possible and a reduction in the number of technologies required to support.


At the scale of billions of transitions and thousands of employees, variation becomes a cost multiplier. Every extra tool or framework adds cognitive load and operational overhead.


This is where buying capability becomes important, and if a managed service meets most of your needs, it is often the better choice than building your own. Not because it is perfect, but because it reduces the surface area your platform team needs to support. Removing a lot of the undifferentiated heavy lifting that too many organisations are taking on.


By bringing in 3rd-party commodity tools, such as AWS-provided services, platform teams can spend their time translating those services into a usable, consistent, and compliant workflow within the context of their teams.


Building on top, not rebuilding underneath


Across multiple talks, the same pattern emerged where teams removed the cost of infrastructure primitives by adopting AWS services, enabling them to focus on composition and customisation.

Legal and General’s work with data and AI is a good example. They offloaded the cost of standing up compute and storage on AWS while focusing on pipeline integration, data-flow management, and enabling teams to extract value from large volumes of information.


Similarly, LSEG focused on how to safely adopt cloud services within its regulatory constraints, rather than recreating them.



And Equals Money spoke about how they leverage serverless Lambdas to provide high reliability and low-latency transitions on their payroll and payment platform.


This distinction is important. The value of a platform is not in recreating cloud services. It is in how those services are combined and delivered as a coherent internal product.


Choosing where to invest


A useful way to frame the takeaway from AWS Summit London is to think about where your effort creates the most value.


Cloud providers are very good at solving common infrastructure problems at scale. This is undifferentiated work.


Platform teams create value when they:

  • Shape the internal developer experience

  • Encode organisational constraints and policies

  • Provide paved paths that accelerate delivery

  • Integrate services into workflows that match the business


In many ways, the business model that has made AWS so successful is the one that platform teams need to adopt. Build components as products with a strong vision of what they provide, clear APIs that serve as a contract for easy consumption and composition, and build only what provides an economy of scale.


What this means in practice


For many organisations, the shift to platform engineering is not about adopting new tools; it is about adopting a platform as a product mindset.


Instead of building everything in-house, platform teams are able to depend on commodity pieces from vendors, allowing them to focus on what is unique to their organisation but common to their teams.


This approach allows teams to move faster, while still maintaining control over how systems are used.


Looking ahead


There was also a clear sense that AI will continue to raise expectations. Building on the conversation from QCon and KubeCon, we are again seeing that the industry will need to scale platform capabilities to meet increasing demand. That includes enabling more teams, across more technologies, without increasing cognitive load.


This will only be possible if platform teams continue to offload undifferentiated work and focus on the layers that matter most to their organisation.


AWS Summit London reinforced a shift that has been building for some time: platform teams are deciding between build, buy, and blend, and the answer is becoming clearer: Blend by buying the undifferentiated heavy lifting, build the experience, workflows, and capabilities that are unique to your organisation. That is where platform engineering delivers real impact.

 
 
 

Comments


bottom of page