Antoher week, another long list of cloud releases.

Instead of covering everything AWS, Azure, Google Cloud and Oracle publishes, this edition focuses on updates that can actuallt affect how we operate infrastructure: troubleshooting, network observability, security, Kubernetes, serverless costs, hybrid infrastructure and disaster recovery.

This edition of Didgii Weekly Cloud covers September 8 through September 14, 2026.

Cloud in 60 seconds

The highlights this week:

• AWS Systems Manager can diagnose more reasons why EC2 instances aren't managed correctly.

• CloudWatch Network Monitoring gained better visibility into Transit Gateway inter-Region connectivity.

• Azure Copilot Troubleshooting Agent reached general availbility.

• Azure stregthened Storage SAS security and expanded Azure Arc management for distributed environments.

• Google Cloud Run introduced delayed job execution for workloads that don't need to run immediatelly.

• Google improved Cloud Monitoring dashboards and Cloud SQL regional API access

• OCI Cache added cross-region replication for disaster recovery and global architectures.

• Oracle Cloud Migrations can now migrate supported ARM-based AWS instances to OCI.

AWS

Systems Manager can diagnose more unmanaged EC2 problems

Status: GA
Date: September 9

AWS Systems Manager expanded its diagnostic capabilities for EC2 instances and hybrid nodes that fail to become managed by Systems Manager.

Previously, diagnosis primarily covered network connectivity. It can now identify problems involving:

• IAM permissions

• SSM Agent versions

• EC2 instance status checks

• Operating-system configuration

• Default Host Management Configuration

• Hybrid activation

Systems Manager also provides remediation guidance, and some problems can be addressed through Automation runbooks.

Why it matters

An EC2 instance that isn't properly registered with Systems Manager loses access to several operational capabilities:

1Unmanaged EC2
2     |
3     +--> No Session Manager
4     +--> No Run Command
5     +--> No centralized patching
6     +--> No inventory collection

Previously, determining why an instance wasn't managed could involve checking IAM, networking, the agent, metadata and the operating system manually.

Giving operators a specific reason significantly reduces troubleshooting time.

For SRE and platform teams managing large EC2 fleets, this is one of the most practical AWS release of the week.

Official source:
AWS Systems Manager announcement

CloudWatch improves Transit Gateway inter-Region troubleshooting

Status: GA
Date: September 10

Amazon CloudWatch Network Monitoring can now provide a Network Health Indicator (NHI) for synthetic-monitor paths that cross an AWS Transit Gateway inter-Region peering connection.

The indicator helps determine whether network degradation originates within the AWS network rather than the application or customer-controlled portion of the path.

Why it matters

Inter-Region network problems are notoriously difficult to isolate.

A latency increase could originate from:

 1Application
 2    |
 3    v
 4Operating system
 5    |
 6    v
 7VPC networking
 8    |
 9    v
10Transit Gateway
11    |
12    v
13Inter-Region AWS network
14    |
15    v
16Remote VPC

Without additional visibility, teams often spend significant time proving where the problem isn't.

Network Health Indicators provide another signal for separating AWS network problems from workload problems.

You can also expose the information through CloudWatch dashboards and alarms.

Official source:
Amazon CloudWatch Network Monitoring announcement

AWS DevOps Agent can now work bidirectionally from Slack

Status: GA
Date: September 11

AWS DevOps Agent now supports bidirectional interaction through Slack.

Engineers can initiate and steer investigations by mentioning the agent inside a connected Slack private channel.

Investigation context, findings and suggested actions can remain inside the incident conversation.

Why it matters

Incident response frequently looks like this:

1Slack
2  |
3  +--> CloudWatch
4  +--> AWS Console
5  +--> deployment system
6  +--> logs
7  +--> dashboards
8  +--> ticketing system

Every context switch costs time during an incident.

Bringing investigation capabilities closer to the communication channel doesn't remove the need for enginnering judgement, but it can reduce some of that operational friction.

The important question for production teams will be how access, permissions, auditability and recommended actions are governed.

Official source:
AWS DevOps Agent Slack announcement

Microsoft Azure

Azure Copilot Troubleshooting Agent reaches GA

Status: GA
Date: September 9

Microsoft announced general availability of the Troubleshooting Agent in Azure Copilot.

The agent is designed to help operators investigate Azure resource problems by combining resource context and diagnostic information instead of requiring engineers to manually move between multiple troubleshooting surfaces.

Why it matters

This is an interesting development for cloud operations.

Troubleshooting commonly starts with:

 1What changed?
 2     |
 3     v
 4What is unhealthy?
 5     |
 6     v
 7Logs / Metrics / Events
 8     |
 9     v
10Dependencies
11     |
12     v
13Likely root cause

AI-assisted troubleshooting becomes useful when it can work with actual infrastructure context rather than simply generating generic troubleshooting suggestions.

It shouldn't replace metrics, logs, traces or engineering knowledge, but it could shorten the investigation phase for common infrastructure problems.

Official source:
Azure Copilot Troubleshooting Agent GA announcement

User-bound User Delegation SAS reaches GA

Status: GA
Date: September 9

Azure Storage's user-bound User Dlegation SAS is now generally available.

The capability allows a user delegation SAS token to be restricted to a specific Microsoft Entra ID identity (Formerly Azure AD).

That means possessing the SAS token alone isn't necessarilly sufficient: the intended user also has to authenticate using the specified identity.

Why it matters

Traditional SAS URLs have one obvious security characteristic:

Anyone who gets the valid token may potentially use it within its permitted scope and lifetime.

Binding the token to an identity adds another security boundary.

Conceptually:

1SAS token
2    +
3Entra identity
4    |
5    v
6Storage access

For organizations using temporary delegated access to Blob, File, Table or Queue storage, this reduces the impact of accidentally exposed SAS tokens.

Official source:
Azure Storage GA announcement

Azure Local workload management enters public review in Arc Site Manager

Status: Public Preview
Date: September 10

Azure Arc Site Manager can now provide centralized workload management for Azure Local virtual machines and Kubernetes clusters.

Operators can organize workloads around physical sites and perform actions against multiple resources.

For VMs, supported bulk operations include actions such as start, restart, stop, pause and delete.

Why it matters

Hybrid and edge environments become difficult to operate when the logical cloud-resource hierarchy doesn't match the physical world.

A company might actually think in terms of:

 1Factory A
 2  +-- Kubernetes cluster
 3  +-- 12 VMs
 4
 5Factory B
 6  +-- Kubernetes cluster
 7  +-- 8 VMs
 8
 9Store 01
10Store 02
11Store 03
12...

rather than subscriptions and resource groups.

Site-oriented management gives operators a view closer to how distributed infrastructure is actually deployed.

Official source:
Azure Arc Site Manager preview announcement

Azure brings Workload Orchestation into the portal

Status: Available
Date: September 10

Microsoft also expapanded the Azure portal experience for Workload Orchestration, which helps define and deploy applications consistently accross distributed Kubernetes, cloud, on-premises and edge environments.

The announcement specifically emphasizes GitOps-style workload deployment across fleets with per-site configuration requirements.

Why it matters

Deploying an application once is easy.

Deploying the same application across hundreds of locations while maintaining controlled configuration differences isn't.

The interesting problem becomes:

 1Common application definition
 2             |
 3             v
 4       Desired state
 5             |
 6      +------+------+ 
 7      |      |      |
 8   Site A Site B Site C
 9      |      |      |
10  local   local   local
11 config  config  config

This is exactly where GitOps and fleet management become valuable.

Official source:
Azure Workload Orchestration announcement

Google Cloud

Cloud Run introduces delayed job execution

Status: Preview
Date: September 8

Google Cloud Run jobs can now defer non-urgent workloads for up to 12 hours.

The feature is designed to take advantage of reduced pricing when a workload doesn't need to begin immediately.

Why it matters

Not every batch job needs to run now.

Examples include:

• nightly processing

• report generation

• asynchronous data transformation

• cleanup tasks

• non-critical ML or analytics jobs

This creates an explicit trade-off:

1Urgency
2  ↑
3  |        Immediate execution
4  |
5  |
6  |        Deferred execution
7  +----------------------------> Cost optimization

If the application can tolerate scheduling flexibility, infrastructure costs can be optimized without redesigning the workload.

That's a simple but useful FinOps capability.

Official source:
Cloud Run release notes

Cloud Monitoring charts can override dashboard time ranges

Status: GA
Date: September 9

Cloud Monitoring now allows individual charts to override the time-range setting configured for the rest of a dashboard.

Why it matters

This sounds small, but it solves a common observability problem.

An operational dashboard might need:

1CPU              → last 30 minutes
2Errors           → last 1 hour
3Deployments      → last 24 hours
4Capacity trend   → last 30 days

Previously, forcing every chart into the same window could make certain metrics significantly less useful.

Independent time ranges make it easier to combine immediate incident data with longer-term trends in a single operational dashboard.

Official source:
Cloud Monitoring release notes

Cloud SQL regional Admin API endpoints reach GA

Status: GA
Date: September 8

Regional endpoints for the Cloud SQL for MySQL Admin API are now generally available.

Why it matters

Regional API endpoints can be important for organizations with regulatory, sovereignty or architecture requirements around where API traffic is processed.

This is especially relevant for environments using stricter regional boundaries or controls around service-management traffic.

Official source:
Google Cloud release notes

Observability API supports VPC Service Controls

Status: GA
Date: September 8

Google Cloud's Observability API now supports VPC Service Controls.

Why it matters

VPC Service Controls are frequently used to reduce the risk of data exfiltration from sensitive Google Cloud environments.

Extending that boundary to observability APIs allows organizations with strict security requirements to use telemetry services while maintaining their service perimeter model.

For security-sensitive environments, observability should not become an exception to the same isolation controls used for application data.

Official source:
Google Cloud Trace and Observability release notes

GKE Regular channel receives Kubernetes version updates

Date: September 8

Google Kubernetes Engine updated its Regular release channel.

Among the changes:

• Kubernetes 1.35.7-gke.1222000 became the default cluster-creation version.

• 1.35.8-gke.1036000 became available.

• 1.36.3-gke.1767000 became available.

• an older 1.36.3 build entered deprecation in the channel.

Google notes that release-channel rollouts can take several days across regions and zones.

Why it matters

Managed Kubernetes doesn't remove Kubernetes lifecycle management.

Platform teams should still monitor:

 1Available versions
 2       |
 3       v
 4Default version
 5       |
 6       v
 7Auto-upgrade target
 8       |
 9       v
10Deprecated versions
11       |
12       v
13End of support

This should be part of normal cluster lifecycle planning rather than something discovered during an unexpected upgrade.

Official source:
GKE Regular channel release notes

Oracle Cloud Infrastructure

OCI Cache adds cross-region replication

Status: GA
Date: September 9

OCI Cache now supports cross-region replication.

The service can asynchronously replicate data from a primary cache cluster to a secondary cluster in another OCI region.

Oracle highlights three primary scenarios:

• disaster recovery

• global application architectures

• planned migrations between regions

Why it matters

A cache frequently becomes an important dependency even when the authoritative data lives somewhere else.

Cross-region replication allows architectures such as:

 1Region A
 2Application
 3    |
 4 Primary Cache
 5    |
 6    | async replication
 7    v
 8 Secondary Cache
 9    |
10Region B

This can reduce recovery time when failing over an application to another region.

As always with asynchronous replication, teams need to understand potential replication lag and design RPO/RTO expectations accordingly.

Official source:
OCI Cache cross-region replication announcement

Oracle Cloud Migrations now supports ARM-based AWS EC2 instances

Status: GA
Date: September 9

Oracle Cloud Migrations can now migrate supported ARM-based Amazon EC2 instances to OCI Compute.

During AWS discovery, the service detects the architecture and uses that information to recommend compatible OCI Compute shapes and images.

A single migration project can contain both x86 and ARM workloads.

Why it matters

ARM is no longer an edge case in cloud infrastructure.

AWS Graviton adoption means organizations considering a cloud migration may have estates containing both architectures.

Migration tooling therefore has to understand:

1x86 workload  ---> compatible OCI x86 shape
2ARM workload  ---> compatible OCI ARM shape

rather than treating every VM as architecturally interchangeable.

Oracle currently lists compatible ARM-based OCI shapes including A1, A2 and A4 Flex families, subject to region capacity and quotas.

Official source:
Oracle Cloud Migrations ARM announcement

Grok 4.6 arrives on OCI Generative AI

Status: Available on demand
Date: September 10

OCI Generative AI added xAI Grok 4.6 as an on-demand model.

Oracle positions the model for coding, agentic workloads, knowledge work and long-running workflows.

It supports a context window of up to 500,000 tokens.

Why it matters

Model availability itself isn't necessarily an infrastructure story.

The more interesting trend is that hyperscalers continue expanding their AI platforms into multi-model environments rather than requiring customers to build against a single model family.

For platform teams, that increasingly means thinking about model access the same way we think about other shared infrastructure:

• IAM

• quotas

• regional availability

• cost

• observability

• data governance

• model lifecycle

Official source:
OCI Generative AI Grok 4.6 release note

Didgii Take

Three themes stand out this week.

Troubleshooting is becoming a first-class managed capability

AWS Systems Manager's expanded diagnostics and Azure Copilot's Troubleshooting Agent are approaching the same problem from different directions.

Traditionally:

 1Alert
 2  |
 3  v
 4Engineer
 5  |
 6  +--> Metrics
 7  +--> Logs
 8  +--> Events
 9  +--> Config
10  +--> Network
11  +--> Deployment history
12  |
13  v
14Hypothesis
15  |
16  v
17Root cause

Cloud providers increasingly want to assist with the middle of that workflow.

That's useful, but SRE teams should be careful not to replace observability fundamentals with AI.

A troubleshooting agent is only as useful as the telemetry and context available to it.

Multi-region resilience continues moving down the stack

OCI Cache cross-region replication is a good example.

Multi-region designs aren't only about databases anymore.

Applications increasingly need to consider regional resilience for:

• databases

• caches

• object storage

• queues

• networking

• configuration

• secrets

• container registries

A multi-region compute architecture isn't truly multi-region if critical dependencies can only recover in one region.

Identity continues replacing bearer-style access

Azure's user-bound SAS release reflects the same trend we discussed last week with Google's Cloud SQL identity improvements.

The direction continues to be:

 1Credential alone
 2       ↓
 3
 4Credential
 5    +
 6Identity
 7    +
 8Policy
 9    +
10Context

The more cloud platforms can associate an action with an actual identity rather than simply possession of a secret, the easier access becomes to control, audit and revoke.

⚠️ Action Required

There isn't a major cross-provider deprecation in this week's selected announcements that warrants creating artificial urgency.

There is, however, one operational item worth checking:

If you operate GKE Regular-channel clusters, review your current Kubernetes versions and auto-upgrade targets. Google introduced new builds and marked one 1.36.3 build for removal from the Regular channel.

This doesn't mean every cluster needs immediate action, but Kubernetes version lifecycle should be part of regular platform maintenance.

Source:
GKE Regular channel release notes

Worth Watching

AWS Systems Manager's unmanaged-instance diagnosis.

It solves a very ordinary operational problem, and those are often the most valuable releases.

When an instance disappears from centralized management, the difference between:

“The instance isn't managed; start checking everything.”

and:

“The instance isn't managed because its IAM configuration is incorrect.”

can save a surprising amount of engineering time.

What release caught your attention this week?