News For Dev-ops

The next generation of Amazon OpenSearch Serverless now supports up to 10,000 collections within a single collection group, increased from the previous limit of 1,500. Collection groups organize multiple collections and enable them to share OpenSearch Compute Units (OCUs), even when the collections are encrypted with different AWS KMS keys. With this higher limit, you can consolidate significantly more collections into a single collection group and manage them under a shared set of capacity limits. Customers use collection groups to reduce costs by sharing compute across many collections rather than provisioning separate OCUs for each KMS key, while still maintaining collection-level security and access controls. As customer workloads have grown, particularly for multi-tenant applications that provision a collection per tenant, the previous limit of 1,500 collections per group constrained how many tenants could benefit from a shared compute pool. Raising the limit to 10,000 collectio...

We're back, and this is our first minor version bump: 0.1 to 0.2! It's our biggest release yet. This update adds support for local models , lets you run a different agent in each tab with /agent , brings OpenCode into the built-in agent lineup, runs your agent inside WSL where your work actually lives, and makes the Agent Pane richer to navigate and easier to read. It also sharpens Autofix and fixes a long list of reliability issues. You can grab the update from the Microsoft Store , via winget install Microsoft.IntelligentTerminal , or by heading to the release page on GitHub. Let's dive in! [embed]https://www.youtube.com/watch?v=RA3AtxZPPUY[/embed] Local model support is here! We've heard you: one of the most common requests since our first release has been the ability to use local models. With 0.2, we're adding support for local models in the Agent Pane, so you can run your agent workflows against a model on your own machine, keeping them private, of...

We covered the roles your Azure Cosmos DB app needs in our previous post. Now let’s look at what happens after you’ve assigned those roles, switched identities, disabled keys and suddenly staring at a 403 . As we continue this security series, we’ll walk through the most common causes, how to diagnose them, and how to get back to green quickly. The situation You did everything right. You gave your app a managed identity, assigned a data role, switched your code over to  DefaultAzureCredential , and turned off key-based auth like all the good security guidance told you to. Then you deploy, and every single call comes back with this: Response status code does not indicate success: 403 (Forbidden). Don't panic. I've watched a lot of people hit this exact wall, and it's almost always one of a few things. None of them take long to fix once you know where to look. Let me walk you through them roughly in the order they tend to bite. First, read the error the right way Here...

AWS Elastic Disaster Recovery (AWS DRS) now preserves UEFI boot mode when recovering Linux source servers that boot with UEFI firmware. Previously, DRS launched these Linux servers in legacy BIOS mode, which could require extra configuration after recovery. Now your recovered Linux instances launch with the same UEFI boot mode as your source servers. This means your recovery instances more closely match your source environment, so applications that depend on UEFI boot behavior come back exactly as you expect — with no additional post-recovery steps. Boot mode preservation is automatic, with nothing to configure. This capability is available in all AWS Regions where AWS DRS is offered, at no additional cost. To learn more, visit the AWS Elastic Disaster Recovery User Guide . Post Updated on August 10, 2026 at 02:00PM

Amazon Virtual Private Cloud (VPC) IP Address Manager (IPAM) now supports BGP route protection monitoring and delegated Resource Public Key Infrastructure (RPKI) management for Bring Your Own IP (BYOIP) prefixes. Network administrators can centrally monitor BGP route protection and automate Route Origin Authorization (ROA) management across their organization. Using BGP route monitoring, you can view RPKI validity status, ROA strength, and route overlap detection for all BYOIP prefixes across accounts and regions from a single dashboard. Administrators can identify prefixes with invalid or missing ROAs, detect route overlaps that may indicate hijacking, and distinguish between strict and permissive ROA configurations. With Delegated RPKI, administrators perform a one-time setup with their Regional Internet Registry (ARIN, RIPE, APNIC, or LACNIC), after which IPAM automatically creates ROAs during BYOIP provisioning, renews them before expiration, and manages ROAs for on-premises pref...

Amazon Connect Customer dashboards now support drilling down into real-time queue and routing profile performance. With a single click, supervisors can drill from a summary view into pre-filtered routing profile, queue, agent, or routing step widgets. For example, a supervisor who sees a spike in queue wait times can immediately drill down to agent activity for a specific queue and reassign agents to reduce the backlog. One-click drill-down on real-time metrics dashboards is available in all AWS commercial and AWS GovCloud (US-West) regions where Amazon Connect Customer is offered. To learn more about Amazon Connect Customer analytics dashboards, see the Amazon Connect Customer Administrator Guide . To learn more about Amazon Connect Customer, the AWS cloud-based contact center, please visit the Amazon Connect Customer website . Post Updated on August 6, 2026 at 06:00PM