Amazon OpenSearch Service now supports SAML (Security Assertion Markup Language) via IAM federation for the next-generation OpenSearch UI. OpenSearch UI is a modernized operational analytics experience that enables users to gain insights cross data spanning managed domains and serverless collections from a single endpoint. OpenSearch UI already supports authentication via AWS Identity & Access Management (IAM) and IAM Identity Center (IDC). With this feature, you can now configure the SAML identity federation between your identity provider and IAM, so that your end-users can have a Single Sign-On (SSO) experience, to login from your Identity Providers and land directly in OpenSearch UI.

With SAML support, you can define a Default Relay State URL so that your end-users can click on the URL to open the login page from your Identity Provider, complete the SSO, and then land directly on the page you defined in OpenSearch UI. You can also define fine-grained access control (FGAC) by mapping Identity Provider users and roles to IAM roles with different permissions in OpenSearch, so that you can easily manage user permissions as well as to track user activities from the Identity Provider.

OpenSearch UI supports SAML in all regions that OpenSearch UI is available. To get started, create an OpenSearch UI application and follow the instructions to complete the SAML configuration. Learn more at Amazon OpenSearch Service Developer Guide.
 

 

​Amazon OpenSearch Service now supports SAML (Security Assertion Markup Language) via IAM federation for the next-generation OpenSearch UI. OpenSearch UI is a modernized operational analytics experience that enables users to gain insights cross data spanning managed domains and serverless collections from a single endpoint. OpenSearch UI already supports authentication via AWS Identity & Access Management (IAM) and IAM Identity Center (IDC). With this feature, you can now configure the SAML identity federation between your identity provider and IAM, so that your end-users can have a Single Sign-On (SSO) experience, to login from your Identity Providers and land directly in OpenSearch UI. With SAML support, you can define a Default Relay State URL so that your end-users can click on the URL to open the login page from your Identity Provider, complete the SSO, and then land directly on the page you defined in OpenSearch UI. You can also define fine-grained access control (FGAC) by mapping Identity Provider users and roles to IAM roles with different permissions in OpenSearch, so that you can easily manage user permissions as well as to track user activities from the Identity Provider. OpenSearch UI supports SAML in all regions that OpenSearch UI is available. To get started, create an OpenSearch UI application and follow the instructions to complete the SAML configuration. Learn more at Amazon OpenSearch Service Developer Guide.    

Amazon EventBridge announces support for Amazon Key Management Service (KMS) Customer Managed Keys (CMK) in API destinations connections. This enhancement enables you to encrypt your HTTPS endpoint authentication credentials managed by API destinations with your own keys instead of an AWS owned key (which is used by default). With CMK support, you now have more granular security control over your authentication credentials used in API destinations, helping you meet your organization’s security requirements and governance policies.

Customer managed Keys (CMK) are KMS keys that you create and manage by yourself. You can also audit and track usage of your keys via CloudTrail. EventBridge API destinations are private and public HTTPS endpoints that you can invoke as the target of an event bus rule or pipe, similar to how you invoke an AWS service or resource as a target. API destinations provides flexible authentication options for HTTPS endpoints, such as API key and OAuth, storing and managing credentials securely in AWS Secrets Manager on your behalf.

CMK support for EventBridge API destinations connections is now available across all AWS Regions where EventBridge API destinations is available. Please refer to the EventBridge user guide and KMS documentation for details.
 

 

​Amazon EventBridge announces support for Amazon Key Management Service (KMS) Customer Managed Keys (CMK) in API destinations connections. This enhancement enables you to encrypt your HTTPS endpoint authentication credentials managed by API destinations with your own keys instead of an AWS owned key (which is used by default). With CMK support, you now have more granular security control over your authentication credentials used in API destinations, helping you meet your organization’s security requirements and governance policies. Customer managed Keys (CMK) are KMS keys that you create and manage by yourself. You can also audit and track usage of your keys via CloudTrail. EventBridge API destinations are private and public HTTPS endpoints that you can invoke as the target of an event bus rule or pipe, similar to how you invoke an AWS service or resource as a target. API destinations provides flexible authentication options for HTTPS endpoints, such as API key and OAuth, storing and managing credentials securely in AWS Secrets Manager on your behalf. CMK support for EventBridge API destinations connections is now available across all AWS Regions where EventBridge API destinations is available. Please refer to the EventBridge user guide and KMS documentation for details.    

The AWS Well-Architected Generative AI Lens is now available, offering a guidance document to optimize generative AI workloads in the cloud. This new lens is a powerful addition to the Well-Architected Framework, designed to guide organizations through the complexities of implementing generative AI workloads. It provides structured, prescriptive guidance covering the entire generative AI lifecycle – from initial impact scoping to model selection, customization, integration, deployment, and continuous iteration.

The lens offers several key benefits, including cloud-agnostic guidance applicable across various environments and AI tools, comprehensive coverage of all six Well-Architected pillars, and flexible application for organizations at any stage of their AI journey. It enables thorough assessment of architectures using large language models (LLMs) and helps business leaders and data scientists navigate critical decisions in generative AI implementation.

By addressing specific data architecture requirements for generative AI workloads and providing a framework for continuous improvement, this lens promotes a robust, secure, and efficient solutions. Whether you’re exploring your first generative AI project or scaling existing implementations, the Well-Architected Generative AI Lens offers insights to enhance your cloud-based AI initiatives.

The Generative AI Lens is available as an AWS-official lens in the Lens Catalog of the AWS Well-Architected Tool.
 

 

​The AWS Well-Architected Generative AI Lens is now available, offering a guidance document to optimize generative AI workloads in the cloud. This new lens is a powerful addition to the Well-Architected Framework, designed to guide organizations through the complexities of implementing generative AI workloads. It provides structured, prescriptive guidance covering the entire generative AI lifecycle – from initial impact scoping to model selection, customization, integration, deployment, and continuous iteration. The lens offers several key benefits, including cloud-agnostic guidance applicable across various environments and AI tools, comprehensive coverage of all six Well-Architected pillars, and flexible application for organizations at any stage of their AI journey. It enables thorough assessment of architectures using large language models (LLMs) and helps business leaders and data scientists navigate critical decisions in generative AI implementation. By addressing specific data architecture requirements for generative AI workloads and providing a framework for continuous improvement, this lens promotes a robust, secure, and efficient solutions. Whether you’re exploring your first generative AI project or scaling existing implementations, the Well-Architected Generative AI Lens offers insights to enhance your cloud-based AI initiatives. The Generative AI Lens is available as an AWS-official lens in the Lens Catalog of the AWS Well-Architected Tool.    

AWS announces AWS Security Incident Response with AWS PrivateLink integration, enabling customers to manage their service membership directly from their Amazon Virtual Private Cloud (VPC). Now, together with AWS PrivateLink, customers can access AWS Security Incident Response APIs while keeping their traffic off the public internet, adding an extra layer of security when managing and recovering from sensitive security events.

This integration offers several benefits to AWS customers. First, it can improve the security perimeter of incident response processes by keeping all traffic within AWS-supported private networks. Second, it simplifies network architecture by removing the requirement for internet gateways, NAT devices, or firewall rules. Lastly, it helps meet compliance requirements that mandate private connectivity for sensitive security response and recovery, making it easier for organizations in regulated industries to adopt and use AWS Security Incident Response.

AWS Security Incident Response with AWS PrivateLink integration is now available in all service supported regions.

To get started with this new feature, visit the AWS Security Incident Response console or refer to the AWS Security Incident Response documentation. For more information about AWS PrivateLink, please visit the AWS PrivateLink page.

 

​AWS announces AWS Security Incident Response with AWS PrivateLink integration, enabling customers to manage their service membership directly from their Amazon Virtual Private Cloud (VPC). Now, together with AWS PrivateLink, customers can access AWS Security Incident Response APIs while keeping their traffic off the public internet, adding an extra layer of security when managing and recovering from sensitive security events. This integration offers several benefits to AWS customers. First, it can improve the security perimeter of incident response processes by keeping all traffic within AWS-supported private networks. Second, it simplifies network architecture by removing the requirement for internet gateways, NAT devices, or firewall rules. Lastly, it helps meet compliance requirements that mandate private connectivity for sensitive security response and recovery, making it easier for organizations in regulated industries to adopt and use AWS Security Incident Response. AWS Security Incident Response with AWS PrivateLink integration is now available in all service supported regions. To get started with this new feature, visit the AWS Security Incident Response console or refer to the AWS Security Incident Response documentation. For more information about AWS PrivateLink, please visit the AWS PrivateLink page.  

Amazon Bedrock Evaluations allows you to evaluate foundation models and retrieval-augmented generation (RAG) systems, whether hosted on Amazon Bedrock or multicloud and on-prem deployments. Bedrock Evaluations offers human-based evals, programmatic evals such as BERTScore, F1 and other exact match metrics, as well as LLM-as-a-judge for both model and RAG evaluation. For both model and RAG evaluation with LLM-as-a-judge, customers can select from an extensive list of built-in metrics such as correctness, completeness, faithfulness (hallucination detection), as well as responsible AI metrics such as answer refusal, harmfulness, and stereotyping. But, there are times when they want to define these metrics differently, or make new metrics that are relevant to their needs. For example, customers may define a metric that evaluates an application response’s adherence to their specific brand voice, or they want to classify responses according to a custom categorical rubric.

Now, Amazon Bedrock Evaluations offers customers the ability to create and re-use custom metrics for both model and RAG evaluation powered by LLM-as-a-judge. Customers can write their own judge prompts, define their own categorical or numerical rating scales, and use built-in variables to inject data from their dataset or GenAI responses into the judge prompt during runtime to fully customize the data flow in their evaluations. Customers can be inspired to create new judge prompt templates/rubrics with provided quickstart templates or they can make their own from scratch.

To get started, visit the Amazon Bedrock console or use the Bedrock APIs. For more information, see the user guide.
 

 

​Amazon Bedrock Evaluations allows you to evaluate foundation models and retrieval-augmented generation (RAG) systems, whether hosted on Amazon Bedrock or multicloud and on-prem deployments. Bedrock Evaluations offers human-based evals, programmatic evals such as BERTScore, F1 and other exact match metrics, as well as LLM-as-a-judge for both model and RAG evaluation. For both model and RAG evaluation with LLM-as-a-judge, customers can select from an extensive list of built-in metrics such as correctness, completeness, faithfulness (hallucination detection), as well as responsible AI metrics such as answer refusal, harmfulness, and stereotyping. But, there are times when they want to define these metrics differently, or make new metrics that are relevant to their needs. For example, customers may define a metric that evaluates an application response’s adherence to their specific brand voice, or they want to classify responses according to a custom categorical rubric. Now, Amazon Bedrock Evaluations offers customers the ability to create and re-use custom metrics for both model and RAG evaluation powered by LLM-as-a-judge. Customers can write their own judge prompts, define their own categorical or numerical rating scales, and use built-in variables to inject data from their dataset or GenAI responses into the judge prompt during runtime to fully customize the data flow in their evaluations. Customers can be inspired to create new judge prompt templates/rubrics with provided quickstart templates or they can make their own from scratch. To get started, visit the Amazon Bedrock console or use the Bedrock APIs. For more information, see the user guide.    

Amazon Connect Contact Lens dashboards now supports the ability for contact center administrators to enforce granular access control based on a specific agent hierarchy. Assigning hierarchies to a user allows you to define organizational groups that a user belongs to and you can enable granular access controls by allowing users to only view metrics for agents within their hierarchy or a specific assigned hierarchy. For example, you can configure hierarchy groups and levels for a team, and only agents assigned to a hierarchy group within that team will be able to see metrics for those agents.

Amazon Connect Contact Lens dashboards are available in all commercial AWS regions where Amazon Connect is offered. To learn more about dashboards, see the Amazon Connect Administrator Guide. To learn more about Amazon Connect, the AWS cloud-based contact center, please visit the Amazon Connect website.
 

 

​Amazon Connect Contact Lens dashboards now supports the ability for contact center administrators to enforce granular access control based on a specific agent hierarchy. Assigning hierarchies to a user allows you to define organizational groups that a user belongs to and you can enable granular access controls by allowing users to only view metrics for agents within their hierarchy or a specific assigned hierarchy. For example, you can configure hierarchy groups and levels for a team, and only agents assigned to a hierarchy group within that team will be able to see metrics for those agents. Amazon Connect Contact Lens dashboards are available in all commercial AWS regions where Amazon Connect is offered. To learn more about dashboards, see the Amazon Connect Administrator Guide. To learn more about Amazon Connect, the AWS cloud-based contact center, please visit the Amazon Connect website.    

Amazon Connect Cases now provides capabilities to help contact centers track and meet service level agreements (SLAs) on cases. Using the Amazon Connect UI, admins can set up SLA rules based on case attributes and configure target statuses and resolution times. Agents and managers can view the real-time SLA status directly in their case list view to prioritize urgent work, while admins can create rules to automatically escalate or route cases to another team when SLAs are not met. For example, a company can use this feature to monitor whether high-priority cases are reviewed within 4 hours and closed within 24 hours, making it easier to meet case handling service commitments.

Amazon Connect Cases is available in the following AWS regions: US East (N. Virginia), US West (Oregon), Canada (Central), Europe (Frankfurt), Europe (London), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), and Asia Pacific (Tokyo) AWS regions. To learn more and get started, visit the Amazon Connect Cases webpage and documentation.

 

​Amazon Connect Cases now provides capabilities to help contact centers track and meet service level agreements (SLAs) on cases. Using the Amazon Connect UI, admins can set up SLA rules based on case attributes and configure target statuses and resolution times. Agents and managers can view the real-time SLA status directly in their case list view to prioritize urgent work, while admins can create rules to automatically escalate or route cases to another team when SLAs are not met. For example, a company can use this feature to monitor whether high-priority cases are reviewed within 4 hours and closed within 24 hours, making it easier to meet case handling service commitments. Amazon Connect Cases is available in the following AWS regions: US East (N. Virginia), US West (Oregon), Canada (Central), Europe (Frankfurt), Europe (London), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), and Asia Pacific (Tokyo) AWS regions. To learn more and get started, visit the Amazon Connect Cases webpage and documentation.  

Amazon Elastic Container Services (Amazon ECS) is introducing a new account setting, defaultLogDriverMode, allowing you to define whether tasks in your account use «blocking» or «non-blocking» log driver mode by default, when you do not specify or omit it in your applications’ Task Definitions.

A “non-blocking” log driver mode allows your applications to continue operating when log routing destinations become unavailable, therefore increasing availability if getting logs is not critical to your application, whereas “blocking” log driver mode signifies you do not want your applications to continue running if you cannot route logs to their intended destination, e.g. to record business-critical transactions or mandated by regulation. You can override this account setting for each application using the “mode” log configuration parameter in its Task Definition.

The new defaultLogDriverMode Account Setting is enabled in all AWS Regions. Click here and here for more details on how to set the new account setting.

 

​Amazon Elastic Container Services (Amazon ECS) is introducing a new account setting, defaultLogDriverMode, allowing you to define whether tasks in your account use «blocking» or «non-blocking» log driver mode by default, when you do not specify or omit it in your applications’ Task Definitions. A “non-blocking” log driver mode allows your applications to continue operating when log routing destinations become unavailable, therefore increasing availability if getting logs is not critical to your application, whereas “blocking” log driver mode signifies you do not want your applications to continue running if you cannot route logs to their intended destination, e.g. to record business-critical transactions or mandated by regulation. You can override this account setting for each application using the “mode” log configuration parameter in its Task Definition. The new defaultLogDriverMode Account Setting is enabled in all AWS Regions. Click here and here for more details on how to set the new account setting.  

Amazon MemoryDB clusters now support the IPv6 protocol, allowing clients to connect to MemoryDB clusters using IPv6. You can now configure your cluster to accept only IPv6 connections or to accept both IPv4 and IPv6 connections. This allows you to work to meet IPv6 compliance requirements and more efficiently integrate with existing IPv6-based applications.

The continued growth of the internet is rapidly depleting available Internet Protocol version 4 (IPv4) addresses. By supporting IPv6, MemoryDB helps customers simplify their network architecture by providing a significantly larger address space and eliminating the need to manage overlapping address spaces in their VPCs. Customers can now standardize their applications on IPv6 and future-proof their infrastructure while maintaining compatibility with existing IPv4 systems through dual-stack support.

To get started, create your new MemoryDB cluster using the Amazon Web Services Management Console, CLI, or SDKs and choose which protocol(s) it supports by setting its network type. IPv6 is supported when using Valkey 7 and above, Redis OSS version 6.2 and above, in all AWS global regions and at no additional cost.

To learn more about MemoryDB, visit the Amazon MemoryDB product page.
 

 

​Amazon MemoryDB clusters now support the IPv6 protocol, allowing clients to connect to MemoryDB clusters using IPv6. You can now configure your cluster to accept only IPv6 connections or to accept both IPv4 and IPv6 connections. This allows you to work to meet IPv6 compliance requirements and more efficiently integrate with existing IPv6-based applications. The continued growth of the internet is rapidly depleting available Internet Protocol version 4 (IPv4) addresses. By supporting IPv6, MemoryDB helps customers simplify their network architecture by providing a significantly larger address space and eliminating the need to manage overlapping address spaces in their VPCs. Customers can now standardize their applications on IPv6 and future-proof their infrastructure while maintaining compatibility with existing IPv4 systems through dual-stack support. To get started, create your new MemoryDB cluster using the Amazon Web Services Management Console, CLI, or SDKs and choose which protocol(s) it supports by setting its network type. IPv6 is supported when using Valkey 7 and above, Redis OSS version 6.2 and above, in all AWS global regions and at no additional cost. To learn more about MemoryDB, visit the Amazon MemoryDB product page.    

You can now activate deletion protection for your Amazon Verified Permissions policy stores. When you configure a policy store with deletion protection, the policy store cannot be deleted by any user. This provides your applications resiliency as you can ensure that production policy stores are not accidentally deleted during deployments. Deletion protection is active by default for new policy stores created through the AWS Console. You can activate or deactivate deletion protection for an policy store in the AWS Console, the AWS Command Line Interface, and API. Deletion protection prevents you from requesting the deletion of a policy store unless you first explicitly deactivate deletion protection.

Amazon Verified Permissions is a scalable permissions management and fine-grained authorization service for the applications that you build. Using Cedar, an expressive and analyzable open-source policy language, developers and admins can define policy-based access controls using roles and attributes for more granular, context-aware access control. For example, an HR application might call Amazon Verified Permissions to determine if Alice is permitted access to Bob’s performance evaluation, given that she is in the HR Managers group.

Read more in the Deletion Protection section of the Amazon Verified Permissions user guide. This feature is available in all regions where Verified permissions is available. For more information visit the product page.
 

 

​You can now activate deletion protection for your Amazon Verified Permissions policy stores. When you configure a policy store with deletion protection, the policy store cannot be deleted by any user. This provides your applications resiliency as you can ensure that production policy stores are not accidentally deleted during deployments. Deletion protection is active by default for new policy stores created through the AWS Console. You can activate or deactivate deletion protection for an policy store in the AWS Console, the AWS Command Line Interface, and API. Deletion protection prevents you from requesting the deletion of a policy store unless you first explicitly deactivate deletion protection. Amazon Verified Permissions is a scalable permissions management and fine-grained authorization service for the applications that you build. Using Cedar, an expressive and analyzable open-source policy language, developers and admins can define policy-based access controls using roles and attributes for more granular, context-aware access control. For example, an HR application might call Amazon Verified Permissions to determine if Alice is permitted access to Bob’s performance evaluation, given that she is in the HR Managers group. Read more in the Deletion Protection section of the Amazon Verified Permissions user guide. This feature is available in all regions where Verified permissions is available. For more information visit the product page.