Today, Amazon Web Services (AWS) announces the availability of Amazon GuardDuty Malware Protection for Amazon EC2 in AWS GovCloud (US) Regions, enabling GuardDuty customers to detect the potential presence of malware by scanning the Amazon Elastic Block Store (Amazon EBS) volumes attached to Amazon Elastic Compute Cloud (Amazon EC2) instances and container workloads running on Amazon EC2. Malware scanning in GuardDuty does not any additional security software to be deployed and is designed to have no performance impact to running workloads. When potential malware is identified, GuardDuty generates actionable security findings with information related to the resource and the detected threat. Malware Protection for EC2 supports two methods of scanning: 1/ GuardDuty-initiated scans, which automatically initiates a malware scan when GuardDuty detects suspicious behavior indicative of malware on the instance, and 2/ On-demand scans, where you can initiate scan by providing the Amazon Resource Name (ARN) of the Amazon EC2 instance.

Tens of thousands of customers across many industries and geographies use GuardDuty. GuardDuty can identify unusual or unauthorized activity like cryptocurrency mining, access to data stored in Amazon Simple Storage Service (Amazon S3) from unusual locations, or unauthorized access to Amazon Elastic Kubernetes Service (Amazon EKS) clusters. If you’re new to GuardDuty, you can try it at no cost for 30 days on the AWS Free Tier.

To learn more and get started:

• Refer to the documentation to learn about the new capability
• Get updates on new features and threat detections with the Amazon GuardDuty SNS topic

 

​Today, Amazon Web Services (AWS) announces the availability of Amazon GuardDuty Malware Protection for Amazon EC2 in AWS GovCloud (US) Regions, enabling GuardDuty customers to detect the potential presence of malware by scanning the Amazon Elastic Block Store (Amazon EBS) volumes attached to Amazon Elastic Compute Cloud (Amazon EC2) instances and container workloads running on Amazon EC2. Malware scanning in GuardDuty does not any additional security software to be deployed and is designed to have no performance impact to running workloads. When potential malware is identified, GuardDuty generates actionable security findings with information related to the resource and the detected threat. Malware Protection for EC2 supports two methods of scanning: 1/ GuardDuty-initiated scans, which automatically initiates a malware scan when GuardDuty detects suspicious behavior indicative of malware on the instance, and 2/ On-demand scans, where you can initiate scan by providing the Amazon Resource Name (ARN) of the Amazon EC2 instance. Tens of thousands of customers across many industries and geographies use GuardDuty. GuardDuty can identify unusual or unauthorized activity like cryptocurrency mining, access to data stored in Amazon Simple Storage Service (Amazon S3) from unusual locations, or unauthorized access to Amazon Elastic Kubernetes Service (Amazon EKS) clusters. If you’re new to GuardDuty, you can try it at no cost for 30 days on the AWS Free Tier. To learn more and get started:

Refer to the documentation to learn about the new capability
Get updates on new features and threat detections with the Amazon GuardDuty SNS topic  

Amazon VPC has enhanced CloudTrail logging to include VPC resources created by default during a VPC creation. This enhancement offers improved visibility of VPC resources and aids in auditing and governance.

Prior to this, CloudTrail logs only included resources that were explicitly created by the customer. Customers had to manually curate list of default resources across their environment to comply with auditing requirements. With this launch, customers can view events that trigger the creation or deletion of default resources such as Security Group, Network ACL, Route Table, at the time of creation or deletion of the VPC. These events are logged under CloudTrail in the AWS Management Console.

CloudTrail logging for default VPC resources is available in all AWS commercial and the AWS GovCloud (US) Regions at no additional cost. To learn more about this feature, please refer to our documentation.
 

 

​Amazon VPC has enhanced CloudTrail logging to include VPC resources created by default during a VPC creation. This enhancement offers improved visibility of VPC resources and aids in auditing and governance.
Prior to this, CloudTrail logs only included resources that were explicitly created by the customer. Customers had to manually curate list of default resources across their environment to comply with auditing requirements. With this launch, customers can view events that trigger the creation or deletion of default resources such as Security Group, Network ACL, Route Table, at the time of creation or deletion of the VPC. These events are logged under CloudTrail in the AWS Management Console. CloudTrail logging for default VPC resources is available in all AWS commercial and the AWS GovCloud (US) Regions at no additional cost. To learn more about this feature, please refer to our documentation.    

Amazon Elastic Container Registry (Amazon ECR) now supports registry policy v2 in AWS GovCloud (US) Regions, allowing customers to manage IAM permissions for all ECR API actions and simplify ECR permission management.

ECR registry policy allows customers to control usage of ECR private registries by granting permissions to perform registry-level actions to an AWS IAM principal. Registry policy version 1 (v1), only supported three actions: ReplicateImage, BatchImportUpstreamImage, and CreateRepository. Now, the new registry policy version 2 (v2) supports every ECR action. Using registry policy v2 makes it easier for customers to control permissions across all repositories in an ECR registry, allowing customers to improve security posture and save time versus configuring permissions individually across multiple repositories.

To get started, customers can migrate from registry policy v1 to v2 using the ECR management console or with the new ECR put-account-setting API. New ECR accounts automatically use registry policy v2. To learn more about ECR’s registry policy and permissions, see our Amazon ECR User Guide.

 

​Amazon Elastic Container Registry (Amazon ECR) now supports registry policy v2 in AWS GovCloud (US) Regions, allowing customers to manage IAM permissions for all ECR API actions and simplify ECR permission management. ECR registry policy allows customers to control usage of ECR private registries by granting permissions to perform registry-level actions to an AWS IAM principal. Registry policy version 1 (v1), only supported three actions: ReplicateImage, BatchImportUpstreamImage, and CreateRepository. Now, the new registry policy version 2 (v2) supports every ECR action. Using registry policy v2 makes it easier for customers to control permissions across all repositories in an ECR registry, allowing customers to improve security posture and save time versus configuring permissions individually across multiple repositories. To get started, customers can migrate from registry policy v1 to v2 using the ECR management console or with the new ECR put-account-setting API. New ECR accounts automatically use registry policy v2. To learn more about ECR’s registry policy and permissions, see our Amazon ECR User Guide.  

Amazon Elastic Container Registry (ECR) now supports the ability to replicate images in private ECR repositories across accounts and/or regions, between the AWS GovCloud (US) Regions. Storing images helps applications start up faster as image download time is reduced due to lower latency from in-region pulls. Geographically dispersed images also help you meet backup and disaster recovery requirements for your applications. Amazon ECR Replication feature provides a simple and reliable way to replicate images, and eliminates the operational burden of manually pushing images across multiple regions and accounts.

With a few clicks in the Amazon ECR Console, or using the Amazon CLI, you can specify the destination account and/or region for a source repository. Once replication is turned on, ECR will automatically replicate all new images pushed in source repository to the destination region. Additionally, ECR offers granular control to replicate specific repositories. You can use repository name prefixes as filters to specify which repositories to replicate. To learn more about using replication in ECR, see our documentation.

 

​Amazon Elastic Container Registry (ECR) now supports the ability to replicate images in private ECR repositories across accounts and/or regions, between the AWS GovCloud (US) Regions. Storing images helps applications start up faster as image download time is reduced due to lower latency from in-region pulls. Geographically dispersed images also help you meet backup and disaster recovery requirements for your applications. Amazon ECR Replication feature provides a simple and reliable way to replicate images, and eliminates the operational burden of manually pushing images across multiple regions and accounts. With a few clicks in the Amazon ECR Console, or using the Amazon CLI, you can specify the destination account and/or region for a source repository. Once replication is turned on, ECR will automatically replicate all new images pushed in source repository to the destination region. Additionally, ECR offers granular control to replicate specific repositories. You can use repository name prefixes as filters to specify which repositories to replicate. To learn more about using replication in ECR, see our documentation.  

Today, Amazon SageMaker and Amazon DataZone added support for multiple domain features through AWS CloudFormation. Customers can now use AWS CloudFormation to model and manage domain units and their owners. Additionally, customers can set the AWS IAM Identity Center instance for a domain. Programmatically deploying these resources through AWS CloudFormation facilitates secure, efficient, and consistent provisioning of Amazon SageMaker and Amazon DataZone domains.

As an Amazon SageMaker or Amazon DataZone administrator, you can now create AWS CloudFormation scripts to assign the domain’s IAM Identity Center instance appropriate for your single sign-on user population. Administrators can then create and manage their domain units and enable users to organize, create, search, and find data assets and projects associated with business units or teams.

AWS CloudFormation support for these features is available in all AWS Regions where Amazon SageMaker and Amazon DataZone are available.

To learn more, visit Amazon SageMaker and get started with AWS CloudFormation documentation.

 

​Today, Amazon SageMaker and Amazon DataZone added support for multiple domain features through AWS CloudFormation. Customers can now use AWS CloudFormation to model and manage domain units and their owners. Additionally, customers can set the AWS IAM Identity Center instance for a domain. Programmatically deploying these resources through AWS CloudFormation facilitates secure, efficient, and consistent provisioning of Amazon SageMaker and Amazon DataZone domains. As an Amazon SageMaker or Amazon DataZone administrator, you can now create AWS CloudFormation scripts to assign the domain’s IAM Identity Center instance appropriate for your single sign-on user population. Administrators can then create and manage their domain units and enable users to organize, create, search, and find data assets and projects associated with business units or teams. AWS CloudFormation support for these features is available in all AWS Regions where Amazon SageMaker and Amazon DataZone are available. To learn more, visit Amazon SageMaker and get started with AWS CloudFormation documentation.  

Today, AWS announced the ability to bring your own image (BYOI) to Amazon SageMaker Unified Studio, part of the next generation of Amazon SageMaker. This feature benefits customers who have regulatory and compliance requirements or who prefer not to use the framework containers that come with the default SageMaker Distribution image.

BYOI provides you the flexibility to customize the image by removing unnecessary frameworks and adding new dependencies or security containers as per your requirement. It also provides the code reproducibility guarantees on the containers that you use across development and production environements. The SageMaker Distribution image is available on GitHub, you can download the image inspect its contents and use it to build your custom image. The base image contains all the necessary packages and extensions which are required to execute the code on SageMaker Unified Studio, therefore we recommend you to build your own image using the SageMaker Distribution version 2.6 and onwards.

The ability to bring your own images is available in all AWS Commercial Regions where the next generation of Amazon SageMaker is available. See the supported regions list for more details. For instructions on how to get started, visit the Amazon SageMaker documentation.
 

 

​Today, AWS announced the ability to bring your own image (BYOI) to Amazon SageMaker Unified Studio, part of the next generation of Amazon SageMaker. This feature benefits customers who have regulatory and compliance requirements or who prefer not to use the framework containers that come with the default SageMaker Distribution image. BYOI provides you the flexibility to customize the image by removing unnecessary frameworks and adding new dependencies or security containers as per your requirement. It also provides the code reproducibility guarantees on the containers that you use across development and production environements. The SageMaker Distribution image is available on GitHub, you can download the image inspect its contents and use it to build your custom image. The base image contains all the necessary packages and extensions which are required to execute the code on SageMaker Unified Studio, therefore we recommend you to build your own image using the SageMaker Distribution version 2.6 and onwards. The ability to bring your own images is available in all AWS Commercial Regions where the next generation of Amazon SageMaker is available. See the supported regions list for more details. For instructions on how to get started, visit the Amazon SageMaker documentation.    

Today, AWS announces two complementary capabilities in the next generation of Amazon SageMaker that enhance the development experience for analytics, machine learning (ML), and GenAI teams: Code Editor and Multiple Spaces support.

The Code Editor, based on Code-OSS (Visual Studio Code – Open Source), provides a lightweight and powerful IDE with familiar shortcuts and terminal access, along with advanced debugging capabilities and refactoring tools. Teams can boost their productivity by accessing thousands of Visual Studio Code–compatible extensions from the Open VSX extension gallery. The Code Editor enables version control and cross-team collaboration through GitHub, GitLab or BitBucket repositories, while offering preconfigured Amazon SageMaker distribution for popular ML frameworks.

To maximize the benefits of Code Editor alongside other coding interfaces in Unified Studio, including JupyterLab , SageMaker now supports multiple spaces per user per project, allowing users to manage parallel work-streams with different computational needs. Each space maintains a 1-to-1 relationship with an application instance, enabling users to efficiently organize their storage and resource requirements. This enhancement provides the flexibility to access multiple applications and instances simultaneously, improving workflow management and productivity.

Code Editor and Multiple Spaces support are available in all Amazon SageMaker Unified Studio domains. For more information about AWS Regions where these features are available, see the AWS Regions table. To learn more, visit the Developer Guide.
 

 

​Today, AWS announces two complementary capabilities in the next generation of Amazon SageMaker that enhance the development experience for analytics, machine learning (ML), and GenAI teams: Code Editor and Multiple Spaces support. The Code Editor, based on Code-OSS (Visual Studio Code – Open Source), provides a lightweight and powerful IDE with familiar shortcuts and terminal access, along with advanced debugging capabilities and refactoring tools. Teams can boost their productivity by accessing thousands of Visual Studio Code–compatible extensions from the Open VSX extension gallery. The Code Editor enables version control and cross-team collaboration through GitHub, GitLab or BitBucket repositories, while offering preconfigured Amazon SageMaker distribution for popular ML frameworks. To maximize the benefits of Code Editor alongside other coding interfaces in Unified Studio, including JupyterLab , SageMaker now supports multiple spaces per user per project, allowing users to manage parallel work-streams with different computational needs. Each space maintains a 1-to-1 relationship with an application instance, enabling users to efficiently organize their storage and resource requirements. This enhancement provides the flexibility to access multiple applications and instances simultaneously, improving workflow management and productivity. Code Editor and Multiple Spaces support are available in all Amazon SageMaker Unified Studio domains. For more information about AWS Regions where these features are available, see the AWS Regions table. To learn more, visit the Developer Guide.    

Today, AWS announced the opening of a new AWS Direct Connect location within the Equinix IL4 data center near Istanbul, Turkey. By connecting your network to AWS at the new location, you gain private, direct access to all public AWS Regions (except those in China), AWS GovCloud Regions, and AWS Local Zones. This site is the first AWS Direct Connect location within Turkey. This Direct Connect location offers dedicated 10 Gbps and 100 Gbps connections with MACsec encryption available.

The Direct Connect service enables you to establish a private, physical network connection between AWS and your data center, office, or colocation environment. These private connections can provide a more consistent network experience than those made over the public internet.

For more information on the over 149 Direct Connect locations worldwide, visit the locations section of the Direct Connect product detail pages. Or, visit our getting started page to learn more about how to purchase and deploy Direct Connect.
 

 

​Today, AWS announced the opening of a new AWS Direct Connect location within the Equinix IL4 data center near Istanbul, Turkey. By connecting your network to AWS at the new location, you gain private, direct access to all public AWS Regions (except those in China), AWS GovCloud Regions, and AWS Local Zones. This site is the first AWS Direct Connect location within Turkey. This Direct Connect location offers dedicated 10 Gbps and 100 Gbps connections with MACsec encryption available. The Direct Connect service enables you to establish a private, physical network connection between AWS and your data center, office, or colocation environment. These private connections can provide a more consistent network experience than those made over the public internet. For more information on the over 149 Direct Connect locations worldwide, visit the locations section of the Direct Connect product detail pages. Or, visit our getting started page to learn more about how to purchase and deploy Direct Connect.    

AWS announces a new EC2 feature for Elastic Network Adapter (ENA) that enables flexible queue allocation per Elastic Network Interface (ENI) on EC2 instances. ENA queues, which are key components of ENIs, efficiently manage network traffic by load-balancing sent and received data across available queues. This network interface feature optimizes networking performance by flexibly allocating multiple transmit and receive ENA queues, efficiently distributing packet processing across vCPUs. Customers now have granular control over their network resources and instance performance, allowing them to align ENA queue allocation with specific workload requirements.

Prior to this announcement, customers could configure additional ENIs for their instances, but ENA queues were statically allocated per ENI without flexibility in distribution. Now, customers can dynamically allocate ENA queues across ENIs from their instance’s total queue pool, with the total available queues varying by instance type and size. This flexible ENA queue allocation enables maximum vCPU utilization through optimized resource distribution. Network-intensive applications can be allocated more queues, while CPU-intensive applications can operate with fewer queues.

EC2 Flexible Queues is available in all AWS Commercial Regions. To learn more and for supported instance types, review the latest EC2 Documentation.
 

 

​AWS announces a new EC2 feature for Elastic Network Adapter (ENA) that enables flexible queue allocation per Elastic Network Interface (ENI) on EC2 instances. ENA queues, which are key components of ENIs, efficiently manage network traffic by load-balancing sent and received data across available queues. This network interface feature optimizes networking performance by flexibly allocating multiple transmit and receive ENA queues, efficiently distributing packet processing across vCPUs. Customers now have granular control over their network resources and instance performance, allowing them to align ENA queue allocation with specific workload requirements. Prior to this announcement, customers could configure additional ENIs for their instances, but ENA queues were statically allocated per ENI without flexibility in distribution. Now, customers can dynamically allocate ENA queues across ENIs from their instance’s total queue pool, with the total available queues varying by instance type and size. This flexible ENA queue allocation enables maximum vCPU utilization through optimized resource distribution. Network-intensive applications can be allocated more queues, while CPU-intensive applications can operate with fewer queues. EC2 Flexible Queues is available in all AWS Commercial Regions. To learn more and for supported instance types, review the latest EC2 Documentation.    

Today, CloudWatch RUM, a real-time monitoring service that visualizes and analyzes user interactions with web applications, announces support for Interaction to Next Paint (INP) web vital monitoring. This crucial metric would help customers measure the latency of a page’s response to user interactions, offering insights into the end-user experience of their web application.

INP is a metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page. The final INP value is the longest interaction observed, ignoring outliers. This new metric joins the existing set of core web vitals tracked by CloudWatch RUM. The time series graph for INP allows customers to instantly assess whether page responsiveness is positive, tolerable, or frustrating based on a percentile aggregate of the metric. Furthermore, customers can click on specific data points to access a list of correlated INP events, leading them directly to affected user sessions for in-depth analysis of issues and their impact on user experience. Users can start capturing INP by upgrading the aws-rum-web to v1.23.0 at minimum, which is now available via NPM and CDN.

The new INP metric is available in all AWS Regions where CloudWatch RUM is available at no additional cost to customers.

To learn how to configure the the CloudWatch RUM web client visit this documentation or get started using the user guide.

 

​Today, CloudWatch RUM, a real-time monitoring service that visualizes and analyzes user interactions with web applications, announces support for Interaction to Next Paint (INP) web vital monitoring. This crucial metric would help customers measure the latency of a page’s response to user interactions, offering insights into the end-user experience of their web application. INP is a metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page. The final INP value is the longest interaction observed, ignoring outliers. This new metric joins the existing set of core web vitals tracked by CloudWatch RUM. The time series graph for INP allows customers to instantly assess whether page responsiveness is positive, tolerable, or frustrating based on a percentile aggregate of the metric. Furthermore, customers can click on specific data points to access a list of correlated INP events, leading them directly to affected user sessions for in-depth analysis of issues and their impact on user experience. Users can start capturing INP by upgrading the aws-rum-web to v1.23.0 at minimum, which is now available via NPM and CDN. The new INP metric is available in all AWS Regions where CloudWatch RUM is available at no additional cost to customers. To learn how to configure the the CloudWatch RUM web client visit this documentation or get started using the user guide.