Amazon ECS Gateway: Managed Ingress That Shares ALBs Across Up to 25 Services
AWS introduced Amazon ECS Gateway, an account-level resource that provisions and manages ingress for ECS services in your own account: Application Load Balancers, certificates and security groups. It splits the work between two roles. A platform team creates a gateway that sets the shared standards (subnets, security groups, TLS and listener settings, a WAF web ACL) and associates it with clusters. Application teams then opt a service in by adding a --gateway-connectors block to CreateService or UpdateService.
Routing is host-based, and up to 25 services share one ALB. Each service gets its own DNS hostname, listener rule, target group and ACM certificate. ECS adds ALBs as capacity fills, up to a default maxAlbCount of 10, and removes them when no routes remain. A service's security group accepts traffic only from the ALB. At deployment, ECS connects the service to every compatible gateway: one with a matching access type (public or VPC-internal), in the same VPC, covering all of the service's Availability Zones. ECS Gateway works with awsvpc networking on EC2, Fargate and ECS Managed Instances.
The gateway itself is free. You pay for the ALBs, certificates, CloudWatch data and data transfer it creates. It is available in every commercial Region that has ECS. Services that already have their own load balancer can add a connector and run both paths while they validate the migration. Note that a gateway's listener protocol and port can't be changed after creation, so choose them carefully.
Read more — AWS News Blog
AWS Continuum Reaches GA: Exploit-Verified Code Vulnerabilities With Fixes as Pull Requests
AWS Continuum for code vulnerabilities is now generally available in US East (N. Virginia) and US West (Oregon). Continuum builds a context graph from your repositories (through a GitHub integration or an S3 bucket) and, optionally, from an AWS collector running where your code is deployed. It uses that graph to find business-critical systems and their dependencies. Findings are ranked by how close their attack path runs to those systems, not by a generic CVSS-style severity.
Each finding comes with an evidence level, such as "Static proven". When Continuum can reproduce an issue, it runs the exploit in an isolated sandbox and attaches proof-of-concept code and reproduction steps, along with an attack path, source analysis and blast-radius assessment. It also checks whether your existing defenses would detect and stop the validated path.
Fixes arrive as code patches, dependency upgrades or configuration changes, opened as a "Continuum fix" pull request with the risk assessment and proof in the description. A person still has to review and merge each PR, and AWS notes that a generated patch doesn't by itself mean the issue is fixed. Autonomous application of fixes is described as a future capability, gated on test coverage, scope bounds and historical success rate. The blog post gives no pricing details.
Read more — AWS News Blog
PHP2Shell: Two Critical PHP RCEs Patched, and Google Cloud Asks Teams to Rebuild Cloud Run Services
On October 21, PHP shipped 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical remote code execution flaws nicknamed "php2shell" (CVSS v4.0 9.2). CVE-2026-109618 is a memory-safety failure in out-of-memory handling during the request lifecycle. CVE-2026-109619 is a use-after-free-style bug in which state outlives the memory backing it. Sansec says both are present in every unpatched release since PHP 5.4. Amazon Threat Intelligence saw an exploitation attempt dated October 17, four days before the patches. RCE is confirmed on Apache mod_php; for PHP-FPM, only the session-lifecycle case has been validated. A third issue, CVE-2026-115560, is still unpatched; set session.upload_progress.enabled=0 until the next bugfix release.
The cloud fallout continued through the week. On October 22 and 24, Google Cloud published patched runtimes for Cloud Run, Cloud Run functions, App Engine and Buildpacks across Go, Node.js, Java, PHP, Python, Ruby and .NET, plus the google-22 and google-24 stacks. Google's guidance is to rebuild and redeploy your services with the updated dependencies. Docker published its own advisory for customers. InfoQ reports that official Docker images lagged behind some distributions, and that Cloudflare deployed WAF rules about nine hours before the release.
Two operational points from the advisories are easy to miss. First, restart every PHP-FPM and Apache worker, because a running worker keeps the old engine in memory after the package is upgraded. Second, check the full distro package version, not the output of php -v. Distros backport fixes without changing the reported version; Ubuntu 24.04's fixed package still reports 8.3.6. PHP 8.2 reaches end of life on December 31, 2026.
Read more — InfoQ
Google Cloud: Cloud Run Direct VPC Ingress Preview, Firestore DML GA, BigQuery AI.TRANSLATE GA
Several developer-facing changes appeared in the Google Cloud release notes on October 21–22. Cloud Run Direct VPC ingress entered Preview: instances can use their own ephemeral private IP to communicate with other VPC resources, which makes Cloud Run services look more like ordinary VPC workloads to the rest of the network. Firestore data modification language (DML) operations, including insert and upsert, became generally available, which lets you run set-based writes instead of looping over documents in client code.
In BigQuery, the AI.TRANSLATE SQL function is now GA. It covers both standard Neural Machine Translation and Translation LLM workloads, so translation runs inside a query instead of a separate pipeline. Dataflow added a Preview of streaming high availability for Streaming Engine, enabled with the requires_high_availability service option. The CodeMender agent (v0.16.0) in Gemini Enterprise Agent Platform now runs a deep scan by default with cm find, has a --quick mode, and adds a cm health command that checks credentials before a scan.
Teams on Cloud SQL should also act on the October 23 security bulletin GCP-2026-071: upgrade the Cloud SQL Auth Proxy to 2.26.3 or later and the Proxy Operator to 1.8.4 or later, and update the CA certificates used by language connectors.
Read more — Google Cloud Release Notes
TorchTPU Makes TPUs a Native PyTorch Device, With Day-One Support in Transformers and Diffusers
Google and Meta open-sourced TorchTPU at PyTorch Conference 2026. It is a native PyTorch backend that makes TPUs a regular device next to CPU and GPU. Before this, PyTorch on TPU meant PyTorch/XLA, with lazy tensors and frequent graph recompilations. With TorchTPU you write ordinary eager PyTorch and add torch.compile when you want more speed. It includes TPU-tuned Pallas kernels and distributed training support. Install it on a TPU VM with pip install torch-tpu (add the CPU wheel index so pip doesn't pull the CUDA build of torch).
Hugging Face supports it from day one. In Transformers v5, device_map="tpu" loads a model straight onto the TPU, and Optimum TPU is no longer needed. In Diffusers, pipe.to("tpu") works, and a TensorParallelConfig shards large models across chips while they load. The Kernels Hub serves ready-made TPU kernels; a Tokamax ragged-dot kernel plugged into MoE models made decode 21.5× faster on Qwen3-30B-A3B and 12.8× faster on Gemma 4 26B-A4B at batch size 64 on a v6e-8, compared with the default grouped matmul.
Other numbers from Hugging Face: Qwen-Image-2.1 at 1024×1024 with 40 steps takes 3.5 s compiled versus 8.0 s eager on a v6e-4 with tensor parallelism of 4. And 96.5% of the Transformers tests that run on TPU pass. Teams that were tied to CUDA because of PyTorch now have a real option to try Cloud TPU capacity without rewriting their models.
Read more — Hugging Face Blog
Cloudflare Adds On-Demand CPU and Heap Profiling for Production Workers and Durable Objects
Cloudflare now lets developers profile Workers and Durable Objects in production on demand. A capture attaches to an isolate that is already serving real traffic. For CPU profiles, the runtime starts a V8 sampling profiler at a 1 ms interval and releases the isolate lock while requests continue, then reacquires it to collect the results. Heap-allocation profiles show which functions create objects and add memory pressure. The two views often disagree, since a function can dominate one and not appear in the other.
Captures start from the Workers Observability dashboard or the CLI. You choose a deployed Worker version or, for Durable Objects, a specific named instance; the request is routed to the machine that hosts that object. Results appear as interactive flamegraphs and can be downloaded in a format pprof can read. For readable TypeScript function names, enable source maps. The target also needs enough traffic during the capture window to produce useful samples.
Cloudflare's own examples show the kind of problems this finds. A recursive JSON replacer was rewritten to run 2.7× faster. A duplicate metrics call was using about 1% of CPU. Partially disabled Prometheus instrumentation still held memory, and removing it brought a Worker's p99.9 memory from 133 MB to 118 MB, back under the 128 MB limit. Captures are short and won't catch intermittent issues, and Cloudflare says continuous profiling is the next step.
Read more — InfoQ
Links & Sources
- Introducing Amazon ECS Gateway: A fully-managed ingress solution for ECS services
- AWS Continuum for code vulnerabilities is now generally available
- PHP Patches Two Critical RCE Flaws That Were Already Under Attack
- Security Update on PHP2Shell: Impact for Docker Customers
- Google Cloud Release Notes
- Hugging Face ❤️ TorchTPU: TPUs, Natively
- Cloudflare Brings On-Demand CPU and Memory Profiling to Production Workers
You May Also Enjoy
