LogiCast AWS News: ECS Consolidation, Amazon Continuum GA, Cloud Capacity, and European Sovereign Cloud

Season 5, Episode 37 of the LogiCast AWS News podcast features hosts Karl Robinson, CEO and co-founder of Logicata, and Jon Goodall, principal cloud engineer at Logicata, joined by guest Dipankar Sarkar, principal consultant at New Labs, a consultancy focused on agentic systems and AI workloads on AWS. The episode covers four topics: ECS managed instance consolidation improvements, the general availability of Amazon Continuum’s code vulnerability scanning, Amazon’s cloud capacity outlook, and the European sovereign cloud isolation test.

Amazon ECS Managed Instance Consolidation

Amazon ECS has added cross-instance and spot consolidation to its managed instances capacity option. For context, Jon outlined the three ways to handle ECS capacity: manage EC2 instances yourself, use Fargate and let ECS handle everything, or use ECS managed instances, which sit in the middle - you get EC2 instances but ECS manages them. The middle option typically appeals to teams optimising for cost, as Fargate carries a management premium.

The new consolidation capability allows ECS to look across the fleet of instances rather than managing each one in isolation, and it also factors in spot instance utilisation. According to the announcement, CPU and memory utilisation can rise from around 40% to around 90% as a result. Jon noted that 40% utilisation is quite poor, and that when managing things manually he always aimed for around 80% as a working target. “If you can get it above 80% and it’s handling it for you automatically, happy days,” he said.

Dipankar framed this in a broader competitive context, arguing that AWS is effectively eating into a category of startups that have built businesses around reducing cloud compute bills. “A lot of startups are making good money out of this - they would just take a percentage of the bill that they would save,” he observed. His view is that this kind of managed optimisation is straightforward for AWS to build and relatively cheap to offer, which puts pressure on those third-party tools.

Amazon Continuum Code Vulnerability Scanning - General Availability

Amazon Continuum’s code vulnerability scanning feature has moved into general availability. The feature is part of the Continuum suite - which also includes a penetration testing tool, formerly known as AWS Security Agent - and is aimed at continuously identifying and remediating vulnerabilities across a codebase.

Jon focused on the pricing now that GA has landed, something he flagged as a gap when the feature was in preview. The model charges a monthly context fee based on lines of code - $200 per million for the first 10 million lines - plus usage-based inference charges billed in Continuum Inference Units at $10 per unit. He described the headline numbers as not offensive, but noted the worked examples are vague on what a single inference unit actually represents in practice. “I’d have to see a worked example,” he said, “but good that we’ve got the data now that we’re in GA.”

By comparison, Jon noted that tools like SonarQube price by line-of-code tiers rather than per line, and that SonarQube is also more focused on defensive coding quality than purely on vulnerability detection - though it is developing AI capabilities of its own. Dipankar raised a more fundamental concern about the scope of what automated remediation can realistically handle. He argued that for simpler, monolithic codebases the tool could be genuinely useful, but that for heterogeneous, multi-codebase setups - a Next.js front end talking to a Python API, for example - the tool runs into a “fundamental limitation” around understanding where architectural boundaries sit and what classes of patch are acceptable.

The broader question of adoption came up too. Jon’s view is that this is less likely to pull developers away from tools they already use, and more likely to succeed through supply chain consolidation. “If the dev team want to start getting some code scanning in… you don’t have to go and onboard a Sneak or a Sonar or a Wiz. You can just use the service in the console because the vendor’s already onboarded.” Dipankar added that in his view the more meaningful question is about the expertise of the people doing the testing, not the software itself - drawing an analogy with medicine: a capable diagnostic tool still doesn’t replace the doctor.

Amazon’s Cloud Capacity Outlook Through 2027

Reports emerged recently, covered across several outlets including Investing.com, that Amazon’s cloud capacity is largely sold out through 2027, with some commitments extending into 2028. The claim came from Amazon’s CEO.

Jon admitted he found the framing difficult to parse from an engineering perspective. His concern was what exactly is being sold - and whether it affects ordinary customers running standard services like EC2, RDS, or EKS. His read was that for typical workloads it probably means very little, but for organisations needing large-scale GPU capacity - the kind used for major AI workloads - availability may be genuinely constrained.

Dipankar suggested the announcement is primarily a signal to the financial markets rather than a practical operational statement. He linked it to data centre build-out challenges, pointing to commentary from others in the industry about difficulties bringing new data centre capacity online fast enough. Karl connected this to discussions the podcast has covered before around resistance to new data centre construction in the US. His interpretation was that the announcement may be aimed at softening that opposition - a public argument that capacity is needed.

AWS European Sovereign Cloud Isolation Test

The AWS European Sovereign Cloud recently conducted a planned test in which it disconnected from the main AWS global network for approximately three hours, operating instead through dedicated connectivity from European ISPs. The test was reported on several outlets including The Cube.

Jon was sceptical about what the test actually proves. Three hours, he argued, is the duration of a technical incident - a cut cable, a dredged undersea link - not the duration of a legal or regulatory challenge that would require permanent disconnection. “Every parent knows a kid who survives one night away hasn’t moved out,” he said, echoing the article’s own analogy, though he felt the publication had pushed that analogy well past its useful life.

His underlying concern with the European Sovereign Cloud more broadly remains that it is still owned by Amazon, and that the US Cloud Act still applies regardless of contractual arrangements, local management structures, or technical isolation capabilities. “The Cloud Act still says it’s owned by Amazon,” he said. Dipankar agreed the test does not prove the sovereign aspect in any material sense. “This doesn’t really prove anything materially,” he said. “You need to be able to say that this is a sovereign organisation that is running it in a completely sovereign fashion - and it has to go much deeper than this.”

Dipankar went further, suggesting the question of sovereign cloud may be less relevant going forward than the question of sovereign agent infrastructure - the idea that governments will increasingly look to build sovereign capabilities at the agent and data layer rather than at the infrastructure layer. He framed this as a prediction rather than a certainty, but it generated agreement that the current framing of sovereign cloud leaves meaningful questions unanswered.

The full episode is available on all major podcast platforms and on the Logicata YouTube channel.

*This is an AI generated piece of content, based on the LogiCast Podcast Season 5, Episode 37.*