da Agency

The next generation AgentCore runtime is now the default

Starting today, new runtimes in Amazon Bedrock AgentCore use the next generation of AgentCore runtime by default. The new runtime restores each session from a snapshot of your initialized agent, scales compute and memory with the work, and scales idle agents to zero. Every session still runs in its own hardware-isolated Firecracker microVM. Your agents can run heavy work like compiling a large codebase, driving a browser, or loading a local model inside the session. 
Sessions scale to 8 vCPU and 32 GB of memory and support container images up to 10 GB. On a 2 GB image, sessions start in under 2 seconds at P75, down from 29.7 seconds on the previous generation. Idle agents scale to zero, and memory is reclaimed within minutes of release. For multi-turn agents, that means up to 68% less billed memory per session.
Existing runtimes stay on the current version until you move them. To move an existing runtime, or to use the next generation in a Region where it isn’t the default yet, set platformVersion to V2 when you create or update a runtime. To keep a new runtime on the current version, set platformVersion to V1.
The new AgentCore Runtime is now the default runtime in the following AWS Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Canada (Central), South America (São Paulo), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Milan), Europe (Paris), Europe (Spain), Europe (Stockholm), Asia Pacific (Malaysia), Asia Pacific (Mumbai), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Thailand), and Asia Pacific (Tokyo).  To learn more, visit the AgentCore runtime documentation or the AWS Blog. For pricing details, visit AgentCore pricing.
Quelle: aws.amazon.com

da Agency

EC2 Image Builder console now integrates with the DevOps Agent for troubleshooting and resource creation

EC2 Image Builder now integrates with the AWS DevOps Agent directly in the Image Builder console, enabling you to troubleshoot failed image pipelines and create resources directly from the console chat panel. You can diagnose up to 50 failed pipelines at once and ask follow-up questions in the same conversation. You can also choose to create resources by describing what you want, and the agent populates the console with values the service has already validated.
With this integration, diagnosing a failed pipeline no longer requires manually inspecting build logs, cross-referencing error codes, or iterating through configuration fixes, saving you significant time and expertise. The agent reads build logs, workflow steps, components, and network configuration, then provides the root cause and the steps to fix it. For resource creation,  the agent verifies the configuration before populating the console for you to review and submit. If you troubleshoot or build with your own AI agents, the new EC2 Image Builder skill in the AWS Agent Toolkit provides you the same troubleshooting and creation capabilities.
This feature is available in all commercial regions. To get started, open the EC2 Image Builder console and use the DevOps Agent from the console panel. For more information, see the EC2 Image Builder documentation and for pricing refer DevOps agent Pricing page. 
Quelle: aws.amazon.com

da Agency

Amazon Route 53 Domains now supports self-service restore for expired and deleted domains

Amazon Route 53 Domains now lets you restore an expired or recently deleted domain yourself, using the Amazon Route 53 console, AWS CLI, or AWS SDKs. Previously, restoring a domain required a request to AWS Support. Now you can recover a domain lost to a missed renewal, an expired payment method, or an accidental deletion, and restore the website, email, and applications that depend on it.
To restore a domain, you enter the domain name, review the restoration price, accept the charge, and submit the request. Route 53 works with the top-level domain (TLD) registry to reactivate the registration and return the domain to your AWS account. Most TLD registries support restoration, and each registry sets how long after expiration or deletion a domain can still be restored. Restoring a domain typically costs more than registering or renewing one.
To learn more, see Restoring an expired or deleted domain in the Route 53 Developer Guide, or visit the Amazon Route 53 Domains page. For a complete list of supported TLDs, see the Route 53 TLD list. For pricing, visit the Route 53 pricing page.
Quelle: aws.amazon.com

da Agency

AWS Backup now supports resource modifiers for Amazon EKS restores

Today, AWS Backup announces support for resource modifiers when restoring Amazon Elastic Kubernetes Service (Amazon EKS) backups. Resource modifiers let you transform Kubernetes resources during a restore, so you can adapt a restored cluster to its target environment.
When you restore an EKS backup that has been copied across accounts or across AWS Regions, the restored cluster can carry references tied to the source environment, such as IAM roles, database endpoints, and Amazon ECR registry URIs. Previously, you had to locate and update these references manually after every restore, which was time consuming and error prone. With resource modifiers, you can define transformation rules once via a YAML file, and AWS Backup applies them automatically as part of the restore, improving the reliability of your cross-account and cross-Region disaster recovery workflows.
AWS Backup support for resource modifiers for Amazon EKS backups is available in all commercial AWS Regions and AWS GovCloud (US) Regions. To get started, see the AWS Backup Documentation and read the launch blog.
Quelle: aws.amazon.com

da Agency

Amazon MWAA now supports fine-grained access control with IAM Identity Center and multi-team environments

Amazon Managed Workflows for Apache Airflow (Amazon MWAA) now supports fine-grained access control, giving administrators precise control over who can access which workflows and resources in an Apache Airflow environment. Fine-grained access control is delivered through two new capabilities: IAM Identity Center integration and multi-team environments.
With IAM Identity Center integration, users sign in to the Apache Airflow UI with their corporate identity provider. Authorization is evaluated per request using IAM policies attached to IAM Identity Center Permission Sets, with condition keys that scope access by resource type (DAGs, connections, variables, pools, and more), action, and specific resource ID.
With multi-team environments, several teams can share a single MWAA environment. Each team gets its own DAG folder in Amazon S3, and users see only shared DAGs plus their own teams’ DAGs based on IAM Identity Center group membership. Teams reduce cost through shared infrastructure and simplify management by configuring environment settings once. Multi-team environments are based on the Apache Airflow multi-team feature, which is currently in preview.
These features are available in all AWS Regions where Amazon MWAA is available.
To learn more, visit the IAM Identity Center integration documentation and the multi-team environments documentation.
Quelle: aws.amazon.com