AWS Glue Data Quality makes ETL anomaly detection free and improves anomaly predictions

AWS Glue Data Quality now offers improved anomaly detection with a new observation mode that reduces detection of false anomalies and removes pricing for anomaly detection in ETL jobs. Customers using notebook-based or exploratory workflows now benefit from smarter anomaly detection that gracefully handles irregular data arrival intervals. This new capability avoids over-extrapolating trends by using a constant baseline instead of a linear trend, delivering more accurate alerts and reducing noise so teams can focus on genuine anomalies. The new anomaly detection observation mode is particularly useful for exploratory data analysis, datasets with flat or random patterns, workloads without predictable trends and cases where you run data quality checks on varying schedules or in interactive environments like notebooks. Additionally, anomaly detection for AWS Glue ETL jobs is now available at no additional cost, so you can monitor data quality anomalies across all your Glue pipelines without worrying about pricing. These improvements are available in all AWS commercial regions and AWS GovCloud (US) regions. To get started, visit the AWS Glue Data Quality documentation. To learn more about pricing, see the AWS Glue pricing page.
Quelle: aws.amazon.com

Amazon Keyspaces (for Apache Cassandra) is now available in the Canada West (Calgary) Region (ca-west-1)

Amazon Keyspaces (for Apache Cassandra) is now available in the Canada West (Calgary) Region (ca-west-1), allowing customers in the Canada West Region to build Cassandra-compatible applications with lower latency while keeping their data within the Region to meet data residency requirements. 
Amazon Keyspaces (for Apache Cassandra) is a scalable, highly available, and managed Apache Cassandra–compatible database service. Amazon Keyspaces is serverless, so you pay for only the resources that you use and you can build applications that serve thousands of requests per second with virtually unlimited throughput and storage. 
This regional expansion enables organizations in Canada to build highly scalable, low-latency applications using familiar Cassandra Query Language (CQL) without the operational burden of managing Cassandra clusters.
To learn more about on Keyspaces, visit the Amazon Keyspaces documentation.
Quelle: aws.amazon.com

AWS Lambda announces scalable network bandwidth up to 3,000 Mbps for functions outside a VPC

AWS Lambda now supports scalable network bandwidth for Lambda functions, enabling faster data transfer to and from your execution environment for latency-sensitive workloads. This feature enables functions outside a VPC configured with 2 GB of memory or more to access network bandwidth that scales proportionally, from 625 Mbps at 2 GB up to 3,000 Mbps at 10 GB. Customers use Lambda to build latency-sensitive data processing workloads, which need to transfer large volumes of data – up to several terabytes – from external data sources into the function’s execution environment for processing. As data volume and performance requirements grow, the existing limit of 625 Mbps can constrain data transfer speeds to and from an execution environment. With this launch, network throughput increases proportionally from 625 Mbps at 2 GB up to 3,000 Mbps at 10 GB, helping reduce function execution times and per-invocation costs while improving end-user experience. To get started, submit a request through AWS Service Quotas under the Network bandwidth per execution environment quota to enable scalable network bandwidth on your account. Once enabled, bandwidth will scale automatically based on your function’s memory configuration for all functions outside a VPC in your account. Scalable network bandwidth for functions outside a VPC is available at no additional charge in all commercial AWS Regions. To learn more, visit the Lambda quotas page. 
Quelle: aws.amazon.com

Governance Is a Developer Experience Problem

This is the third post of a 3-part series by Docker Captain Karan Verma. Catch up on Part 1: Your Laptop Is the New Production Environment and Part 2: Runtime Enforcement, Not Runtime Advice.

The conversation around AI governance often starts with security. That’s understandable. When autonomous systems can execute commands, access tools, and interact with production-adjacent environments, organizations naturally focus on risk. But after spending time thinking about agent workflows, I’ve become convinced that governance is about more than security. It’s also a developer experience problem.

The Trust Bottleneck

Most organizations don’t struggle to adopt new tools because the tools are incapable. They struggle because the organization doesn’t trust them yet. The history of software development is full of examples. Cloud adoption accelerated when organizations became comfortable with cloud governance. Containers accelerated when teams gained confidence in isolation and operational controls. CI/CD accelerated when organizations trusted automated deployment pipelines. The pattern repeats. Capability arrives first. Trust arrives later. Adoption follows trust. AI agents are no different.

Caption: Capability alone does not drive adoption. Trust enables organizations to delegate work, expand usage, and realize productivity gains.

The Wrong Tradeoff

Governance is often framed as a choice between speed and control. Move fast and accept risk. Or add controls and slow everyone down. In practice, the most successful developer platforms rarely make this tradeoff. Instead, they create environments where developers can move quickly because boundaries already exist. A developer deploying through a mature platform doesn’t need to think about every networking rule, access policy, or infrastructure safeguard every time they ship code. The platform already provides those guarantees. The same principle applies to agent systems. The goal isn’t to force developers to manually approve every action. The goal is to create environments where useful actions can happen safely by default.

A Tale of Two Teams

Imagine two engineering teams using the same coding agent. The first team allows agent usage only in limited experiments because nobody is completely certain what the agent can access, execute, or modify. Every new workflow requires additional review. Every new capability triggers a discussion about risk.

The second team operates within clearly defined boundaries around execution, tools, and credentials. Developers understand where agents run, what systems they can access, and how activity is observed.

The underlying model is identical. The difference is trust. Over time, that difference may matter more than the model itself. Organizations rarely scale technology they do not trust.

Why Boundaries Create Freedom

This idea sounds counterintuitive at first. Boundaries feel restrictive. But in software systems, boundaries often enable autonomy rather than limiting it.

When organizations know:

where agents run,

what agents can access,

which tools agents can use,

how activity is observed,

They become more comfortable delegating work. Without those boundaries, every workflow becomes an exception process. Every deployment requires discussion. Every new capability triggers concern. Every new tool requires negotiation. Governance reduces uncertainty. Reducing uncertainty increases trust. And trust enables adoption.

The Platform Shift

One thing that stands out in recent discussions around agent infrastructure is that governance is increasingly moving into the platform itself. Developers shouldn’t need to become security experts every time they use an agent. Just as developers rely on platforms to handle identity, networking, deployment, and observability concerns, governance increasingly becomes part of the environment where agents operate. When governance is embedded into the platform, developers spend less time worrying about boundaries and more time focusing on outcomes. That’s a developer experience improvement as much as a security improvement.

Governance as an Enabler

The organizations that adopt agents most successfully may not be the organizations with the fewest controls. They may be the organizations with the clearest controls. Clear boundaries create confidence. Confidence enables delegation. Delegation unlocks productivity. Viewed through that lens, governance is not the thing slowing agent adoption. It is one of the things that makes large-scale adoption possible.

Looking Ahead

The conversation around AI agents often focuses on what models can do. Increasingly, I think the more interesting question is what organizations are willing to trust them to do. That trust won’t come from capability alone. It will come from visibility, accountability, and well-defined boundaries because the future of agentic software is unlikely to be determined solely by the most capable agents. It will also be shaped by the environments that make those agents trustworthy enough to use at scale.

Learn more

Read about why AI Agents need isolation

Read Part and Part 2 of this AI Governance series

Find out how Docker’s AI Governance solutions work across all tools

Quelle: https://blog.docker.com/feed/

Amazon Aurora serverless now scales faster to support agentic AI and other bursty workloads

Amazon Aurora serverless now delivers higher initial capacity during scale-up events, reaching up to 12 ACUs within a second and continuing to scale up to 256 ACUs as your workload grows. When the workload finishes, Aurora serverless automatically scales down to zero. This makes it especially well-suited for agentic AI applications, which typically have bursts of activity, long idle windows, and unpredictable traffic patterns. Aurora serverless handles all of it automatically, scaling capacity with your agents, so you only pay for what you use. This enhancement is enabled by default on all Aurora serverless clusters running on platform version 3 or 4, with no configuration changes required. Existing clusters on platform versions 1 and 2 can upgrade directly to the latest platform version 4 to benefit from these improvements. You can verify your cluster’s platform version in the AWS Management Console under the instance configuration section, or via the RDS API’s ServerlessV2PlatformVersion parameter. For pricing details and Region availability, visit Amazon Aurora Pricing. To learn more, read the Aurora serverless scaling documentation, and get started by creating an Aurora serverless database in just a few steps in the AWS Management Console.
Quelle: aws.amazon.com