October 2026 Summaries

AWS App Runner, Amazon ECS, and Amazon EKS address different container needs: App Runner is positioned for small numbers of stateless HTTP services requiring rapid deployment, ECS on Fargate as the default for most AWS production workloads without Kubernetes-specific needs, and EKS for teams that need Kubernetes capabilities such as Helm charts, operators, service meshes, event-driven scaling, or multi-cloud portability. Their costs differ in billing structure, with App Runner charging for provisioned memory and active CPU, Fargate charging per vCPU and memory usage, and EKS adding a cluster control-plane fee plus node costs; networking, load balancing, logging, idle environments, and engineering time may be larger expenses than compute. The central distinction is operational ownership: App Runner abstracts infrastructure heavily, ECS requires management of tasks and supporting AWS services, while EKS requires ongoing responsibility for Kubernetes upgrades, add-ons, networking, identity, autoscaling, ingress, RBAC, and developer workflows. The discussion argues that teams adopting EKS should explicitly choose a platform-operating model, whether through internal platform staff, managed Kubernetes providers, or developer platforms such as Qovery, while AWS Copilot is highlighted as a simpler ECS-focused deployment option. For ECS-to-EKS migrations, it recommends inventorying services and dependencies, translating workloads gradually, running both environments in parallel with weighted traffic routing, and avoiding simultaneous migration of stateful data services.

Heroku alternatives should be assessed by how their total costs scale across production, databases, bandwidth, builds, and especially staging and preview environments, rather than by entry-level compute prices alone. The comparison groups Render, DigitalOcean App Platform, and Upsun as managed platforms with relatively simple fixed or structured pricing; Railway and Fly.io as usage-based options suited to spiky or edge-oriented workloads; and Northflank or Qovery as platforms that can support bring-your-own-cloud deployments. It argues that Heroku remains useful for small teams seeking minimal operational work but can become costly as applications require higher dyno tiers, add-ons, and multiple non-production environments. Managed PaaS services offer convenience but may limit access to cloud-provider discounts, while BYOC models let organizations pay cloud providers directly and use commitments or reservations, though they introduce account, Kubernetes, and control-plane costs that may not suit small deployments. Migration planning should address runtime compatibility, database cutovers, add-on replacements, and preservation of developer workflows such as automated deployments and pull-request previews. The recommended approach is to trial two or three candidates with a representative non-critical service and compare actual invoices, deployment experience, and operational requirements before committing.

Migrating a complex microservices application from a managed platform such as Heroku, Render, or Fly.io to AWS, GCP, Azure, Scaleway, or a self-managed Kubernetes environment requires separate planning for infrastructure provisioning, application delivery, data migration, and replacement of platform features such as add-ons, schedulers, log drains, configuration management, and preview environments. Infrastructure tools including OpenTofu, Terraform, Pulumi, and Crossplane create cloud resources but do not replace developer workflows, while Argo CD and Flux support Kubernetes GitOps for teams with existing platform expertise; internal developer platforms such as Qovery, DuploCloud, and LocalOps aim to combine provisioning and deployment workflows in a customer-owned cloud account. The central technical risk is database cutover rather than application deployment, with streaming PostgreSQL logical replication or cloud migration services enabling a short write freeze and typically less than 10 minutes of downtime, whereas dump-and-restore approaches can create outages lasting hours. Successful cutovers also require advancing database sequences, validating data and extensions, lowering DNS TTLs well in advance, shifting traffic gradually using weighted routing, testing graceful shutdown behavior, and retaining the original environment for rollback. The cited migration timelines range from roughly 6 to 12 weeks when using a platform that manages provisioning and delivery to 4 to 9 months for teams building infrastructure and GitOps capabilities themselves, with developer-experience preservation and early inventory of hidden dependencies identified as major determinants of success.

Platform teams seeking to let coding agents such as Claude Code and Codex deploy self-hosted open-source models are advised to use a layered architecture rather than a single product: vLLM for high-throughput production inference, Kubernetes or KServe for deployment and scaling, LiteLLM for model routing, virtual keys, budgets, and rate limits, and an internal developer platform or policy-controlled infrastructure tooling for audited deployment automation. The central recommendation is to give agents a narrowly scoped deployment interface instead of broad cloud credentials, using environment-specific RBAC, pull-request workflows, OIDC-based ephemeral credentials, and deployment logs to limit risk. GPU costs should be controlled through both infrastructure measures, including scale-to-zero node pools, right-sizing, spot capacity, and automatic shutdown of nonproduction environments, and gateway-level budget caps and rate limits. Self-hosting can be economical for predictable, sustained, high-volume workloads or where data residency and private-network requirements matter, but hosted APIs are generally cheaper for intermittent or low-volume use, making a hybrid approach practical for many organizations.

ISO/IEC 27001 certification applies to an organization’s information security management system rather than transferring from any cloud or deployment vendor, so platform selection primarily determines which Annex A controls a SaaS company must operate and evidence itself. Certified hyperscalers such as AWS, Google Cloud, Azure, and Scaleway provide infrastructure-level assurances and powerful security primitives but leave customers responsible for IAM design, logging retention, configuration, environment separation, and change records, while managed PaaS providers such as Heroku, Render, and Vercel reduce operational burden at the cost of control granularity. Compliance automation products including Drata, Sprinto, and Vanta collect evidence, monitor controls, and support access reviews but do not enforce deployment-pipeline controls. The comparison identifies 11 deployment-related Annex A controls, particularly access management, privileged access, logging, secure development, environment separation, and change management, and argues that auditors commonly seek proof of production access, approvals, deployment history, log retention, secrets management, and isolation between environments. For many mid-sized SaaS companies, the proposed approach combines a certified cloud provider, a compliance automation tool, and a standardized deployment layer such as Qovery or a self-built Backstage and Argo CD stack, with responsibilities, retention settings, and control owners established before migration.

AI agents can assist cloud migrations most reliably with discovery and dependency mapping, code and infrastructure-as-code translation, characterization test generation, documentation, and post-migration cost analysis, where they produce reviewable reports, diffs, or plans. They remain poorly suited to high-context decisions such as target architecture, data cutover, network and identity design, compliance accountability, and defining the operating model, which require human ownership. The recommended control model is “propose-approve-apply,” using read-only agent credentials, pull requests, policy-as-code checks, staged validation in ephemeral environments, approval requirements scaled to production risk, immutable audit trails, and deterministic rollback rather than direct production access. The article argues that no single migration tool covers every task, so teams commonly combine assessment services, code assistants, Terraform and policy tools, and a developer platform such as Qovery or a self-managed Backstage, Argo CD, and Terraform stack. Although vendors report substantial productivity improvements, independent research suggests outcomes vary and can be offset by review, remediation, and incident costs, making net benefit dependent on governance and validation. Lasting modernization also requires a post-migration self-service developer path, standardized deployment practices, cost controls, lifecycle ownership, and RBAC, while regulated or air-gapped deployments require particular attention to model hosting, prompt data residency, and comprehensive auditing.

Managing Kubernetes across AWS, GCP, Azure, Scaleway, and on-premises environments generally requires combining tools rather than relying on a single control plane, because cluster lifecycle, security governance, and application delivery have distinct requirements. The comparison groups eight options into fleet managers such as Spectro Cloud Palette, Rancher, and Platform9; infrastructure-as-code platforms including Crossplane and Spacelift; and application delivery platforms such as Qovery, Devtron, and Northflank. Fleet tools are positioned for bare metal, edge, and cluster operations, while delivery platforms focus on developer self-service, CI/CD, and preview environments; Crossplane and Spacelift address declarative infrastructure but do not provide complete application delivery. Consistent cross-cloud governance is best achieved through Kubernetes-native admission controls such as Kyverno or OPA/Gatekeeper, deployed through GitOps tools like Argo CD or Flux, while portable CI/CD separates standardized container builds from cloud-specific deployment details. The text argues that consolidation savings primarily come from reducing duplicate pipelines, platform-engineering effort, and idle non-production resources rather than avoiding relatively modest managed-cluster control-plane fees, and recommends choosing platforms based on fleet complexity, on-premises needs, provider coverage, existing infrastructure practices, and whether cloud billing and data residency must remain in the organization’s own accounts.

French public-sector SaaS procurement in 2026 is shaped by separate requirements for sovereignty, health-data hosting, privacy, accessibility, and tender documentation, with eligibility often determined before price or product quality are assessed. The “cloud au centre” doctrine directly requires French State bodies to use approved cloud paths and, for sensitive data, SecNumCloud-qualified services protected from non-EU extraterritorial laws; local authorities and hospitals are not legally bound in the same way but commonly include similar conditions in tenders. SecNumCloud is an ANSSI qualification for a specific cloud offering rather than for applications deployed on it, so vendors remain responsible for their software, administrative access, support staff, subprocessors, data location, and reversibility arrangements. HDS certification independently applies to personal health data, while RGPD obligations cover lawful processing and international-transfer safeguards; neither HDS nor EU data residency alone establishes sovereignty. French-qualified providers such as OVHcloud, 3DS Outscale, Cloud Temple, Numspot, and S3NS can meet relevant sovereignty requirements, whereas the main AWS, Azure, and Google Cloud platforms generally offer broader managed-service ecosystems but lack SecNumCloud qualification and retain exposure to US jurisdiction. Although some French providers can be less expensive for comparable workloads, their narrower service catalogues may create operational and engineering costs. The recommended practical approach for many SaaS companies is to maintain one portable codebase and deploy it into a buyer’s or qualified provider’s cloud account, supported by clear evidence of certification scope, security controls, EU-based operations, accessibility, subcontractors, and data-exit plans before a tender closes.

For a 10-person engineering team, container deployment choices generally fall into five categories: serverless containers such as Google Cloud Run and AWS ECS Fargate, vendor-hosted PaaS offerings including Upsun, Render, and Railway, lightweight orchestration with HashiCorp Nomad, self-operated managed Kubernetes such as EKS, GKE, and AKS, and BYOC platforms such as Qovery, Northflank, and Porter that operate Kubernetes within a customer’s cloud account. The comparison argues that managed Kubernetes still leaves teams responsible for substantial cluster work, including node upgrades, networking, ingress, autoscaling, observability, and security configuration, making it the most operationally demanding option despite provider-managed control planes. Serverless platforms are presented as the lowest-operations and often lowest-cost choice for bursty, stateless HTTP workloads, while vendor PaaS products prioritize fast deployments, managed databases, and preview environments but may limit cloud-account control, data residency options, and access to committed-spend discounts. BYOC Kubernetes is positioned as a middle path for teams expecting GPU workloads, Helm charts, operators, compliance requirements, or larger multi-environment deployments, although it retains cloud infrastructure costs alongside platform fees. Nomad remains a simpler but narrower alternative suited mainly to organizations already invested in HashiCorp tooling. The recommended decision process is to choose based on the primary constraint—such as speed, workload type, compliance, cloud billing ownership, or portability—and validate shortlisted services through a practical one-week deployment and incident-response test rather than selecting Kubernetes by default.

For large microservices migrations to AWS, the central choice is often less about Fargate versus EKS than about who will operate the resulting platform over time. EKS on EC2 generally offers greater control, support for DaemonSets, GPUs, custom networking, bin-packing, Spot capacity, and Savings Plans, making it more economical for dense, steady workloads, while Fargate reduces node-management work and can suit bursty, isolated, or small-team workloads but has higher per-pod pricing and feature limitations. Many organizations use a mixed EKS model, placing baseline services on EC2 node groups and bursty or tenant-isolated workloads on Fargate. Migration requires separate tools for discovery, packaging, data transfer, cluster-state restoration, and incremental traffic cutovers, including AWS Migration Hub, App2Container, Velero, AWS DMS, DataSync, and routing options such as Istio, App Mesh, load balancers, or Route 53. The discussion distinguishes supporting tools such as policy engines and API-deprecation scanners from actual migration tools, and recommends phased, rollback-capable migrations that move low-risk stateless services before stateful systems. It also compares post-migration platform options, including OpenShift, Cloud Foundry/Korifi, internally built Kubernetes platforms, and Qovery, emphasizing that upgrades, IAM, networking, observability, CI/CD, cost controls, and non-production environment sprawl can require a dedicated platform team or managed-service subscription long after the initial migration ends.

For teams of 3–10 engineers moving from a managed PaaS to Kubernetes, the central recommendation is to choose portable tools that communicate through the Kubernetes API and install via Helm or Operators, rather than cloud-specific runtimes such as AWS App Runner, ECS/Fargate, Azure Container Apps, or Google Cloud Run. It organizes a practical stack into CI with GitHub Actions or GitLab CI, infrastructure provisioning with Terraform or OpenTofu, delivery through Argo CD, Flux, or a platform layer, a developer-facing interface such as Qovery, Backstage, or Humanitec, and observability through tools including Prometheus, Grafana, Datadog, or Honeycomb. The discussion stresses that leaving a PaaS transfers responsibility for pipelines, networking, TLS, secrets, autoscaling, monitoring, database recovery, rollbacks, upgrades, security patching, and on-call support to the team, making recurring operational effort more consequential than basic cloud infrastructure costs. It advises migrating incrementally by proving the full pipeline on a low-risk service, retaining the former platform during cutover, moving databases last, and measuring outcomes using DORA metrics. Safe recovery requires both rapid application rollback through immutable image versions and Kubernetes deployment revisions, and careful database practices such as expand-contract migrations and tested point-in-time restores. While it presents Kubernetes portability and bring-your-own-cloud platforms such as Qovery as useful for teams seeking cost control, private networking, compliance, or reduced vendor lock-in, it also concludes that teams without such concrete requirements may be better served by remaining on a managed PaaS.

Small engineering teams can reduce time spent on cloud operations by using either a managed platform-as-a-service, which runs applications in a vendor-owned account, or a bring-your-own-cloud internal developer platform that automates infrastructure within the team’s own AWS, GCP, Azure, Scaleway, or Kubernetes environment. The discussion argues that building VPCs, IAM roles, load balancers, Kubernetes clusters, and database configurations manually with Terraform or similar tools is generally better suited to teams with dedicated platform expertise, because ongoing maintenance includes upgrades, security patches, costs, backups, and incident response. For production PostgreSQL, it recommends managed offerings such as Amazon RDS or Aurora, Google Cloud SQL, Azure Database for PostgreSQL, Neon, or Crunchy Bridge, emphasizing automated backups, point-in-time recovery, high availability, monitoring, and tested restoration procedures over self-hosted databases. It distinguishes deployment platforms, infrastructure-as-code frameworks, Kubernetes control planes, and IaC governance tools, noting that each solves different operational problems. The article presents Qovery as a BYOC option that combines git-based deployments, managed cloud databases, preview environments, and automated networking while retaining customer ownership of cloud billing, data residency, discounts, and access to standard Kubernetes and cloud APIs. It also advises teams to manage costs through disposable preview environments, auto-stopping nonproduction workloads, right-sizing resources, and maintaining an escape path through inspectable infrastructure and portable underlying services.

Managing GitOps across multiple Kubernetes clusters is less constrained by reconciliation than by governance consistency, including uniform sync settings, RBAC, secret handling, approvals, and auditable deployment records. Argo CD and Flux are both CNCF-graduated, production-oriented tools, with Argo CD favoring a UI-driven, hub-capable model using ApplicationSets, SSO, and AppProjects, while Flux emphasizes lightweight, composable controllers managed through Git, Kustomize, and Terraform. Neither provides built-in policy enforcement or a complete approval audit trail, so the recommended approach combines generated configuration from a central control-plane repository, admission controls such as Kyverno or OPA Gatekeeper, and separate approval mechanisms such as protected pull requests, GitHub Environments, or commercial pipeline tools. A defensible audit record joins Git and pull-request history, Kubernetes and cloud audit logs showing actual changes, and approval data tied to individual identities, ideally correlated through commit identifiers. Commercial platforms such as Harness offer integrated policy, approval, and audit capabilities on top of Argo CD, while internal developer platforms such as Qovery are presented as complementary control layers for application self-service, environment-level permissions, and centralized deployment history, leaving Argo CD or Flux to manage infrastructure components and cluster reconciliation.

Migrating GPU inference to a European sovereign cloud requires separating GPU capacity selection from the deployment platform layer, with providers such as Scaleway, OVHcloud, Nebius, IONOS, StackIT, and T-Systems offering varying H100, H200, or newer GPU options. The piece argues that hosting workloads in a European region operated by a US hyperscaler provides data residency but not complete jurisdictional sovereignty because US parent companies may remain subject to the CLOUD Act, while European providers can better align legal control, operations, and data processing with EU requirements. It states that inference performance should generally remain comparable because the underlying NVIDIA hardware is identical, and EU-based serving can reduce latency for European users, although interconnect quality, storage speed, GPU availability, and autoscaling capabilities require validation. Recommended migrations use portable containers, Kubernetes, NVIDIA GPU Operator, open serving runtimes such as vLLM, TGI, or Triton, EU-based supporting services, infrastructure as code, and dual-running production traffic before cutover. Published European GPU prices are described as competitive with AWS, but utilization, batching, quantization, scale-to-zero policies, and reservation planning have greater effects on total cost than hourly rates alone. The article presents cloud-agnostic platforms such as Qovery, alongside tools including KServe, SkyPilot, and NVIDIA Run:ai, as ways to preserve deployment workflows across providers while maintaining a direct cloud contract, and emphasizes documenting every component, subprocessor, access path, log, backup, and control-plane interaction to demonstrate sovereignty to auditors.

European organizations are selectively relocating certain workloads from AWS, Azure, and Google Cloud in response to concerns about U.S. extraterritorial access laws such as the CLOUD Act, EU requirements under the Data Act, DORA, and NIS2, provider-concentration risk, and less predictable egress, licensing, and committed-spend costs. Rather than pursuing full cloud exits, they commonly move regulated personal, health, citizen, public-sector, identity, collaboration, backup, CI, and non-production workloads while retaining deeply integrated analytics, machine-learning, and global delivery services on hyperscalers. Destinations include European providers such as OVHcloud, Scaleway, IONOS, Hetzner, StackIT, and Aruba; sovereign-cloud offerings from U.S. hyperscalers; self-managed Kubernetes on European infrastructure; and hybrid architectures that place regulated data in EU-controlled environments while retaining other compute where practical. The text argues that waived exit-egress fees and forthcoming Data Act restrictions on switching charges have reduced transfer-cost barriers, leaving migration engineering, replacement of managed services, and operational staffing as the main expenses. It recommends classifying workloads by risk, reducing proprietary dependencies, using Kubernetes and common deployment workflows for portability, beginning with non-production systems, and regularly testing documented provider-exit plans to support regulatory and operational resilience.

France’s HDS certification is required for organizations hosting personal health data on behalf of third parties and is issued by COFRAC-accredited certification bodies under the ANS framework, while the ANS register is presented as the authoritative source for verifying certified legal entities, service scopes, regions, sites, and expiry dates. As of October 2026, commonly used certified platforms include OVHcloud, Scaleway, 3DS Outscale, Clever Cloud, Scalingo, Exoscale, NumSpot, Cloud Temple, AWS, Microsoft Azure, and Google Cloud, although certification applies only to specified activities and services rather than an entire provider catalogue. The framework distinguishes six hosting activities, covering physical infrastructure, virtual infrastructure, platform hosting, system administration, and backups, meaning teams using certified IaaS or managed Kubernetes may still retain responsibility for operating platforms, administering systems, and managing backups. HDS is separate from GDPR, ISO 27001, SecNumCloud, and HIPAA; SecNumCloud additionally addresses sovereignty and protection from extraterritorial law. The discussion advises health-tech teams to examine certificates and annexes, verify exact regions and services, establish contractual and audit evidence, avoid real patient data in non-production environments, and select managed PaaS, self-managed Kubernetes, or managed cloud services based on their ability to assume operational and compliance responsibilities. Qovery is described as a non-certified deployment control layer that operates within a customer’s existing cloud account or Kubernetes cluster, rather than replacing an HDS-certified host or the customer’s own obligations.