AWS announces Amazon Redshift Query Editor V2 now supports increased maximum result set and export size to 100MB of your query result sets with no row limit in AWS GovCloud (US) Regions. Prior to this limit of your query result sets was* 5MB or 100,000 rows. This enhancement provides greater flexibility for you and your team to work with large datasets, enabling you to generate, analyze, and export more comprehensive data without previous constraints.

If you work with large datasets, such as security logs, gaming data, and other big data workloads, that require in-depth analysis, the previous 5MB or 100,000-row limit on result sets and exports often fell short of your needs, forcing you to piece together insights from multiple queries and downloads. With the new 100MB result set size and export capabilities in Amazon Redshift Query Editor, you can now generate a single, more complete view of your data, export it directly as a CSV or JSON file, and conduct richer analysis to drive better-informed business decisions.

The increased 100MB result set and export size capabilities for Amazon Redshift Query Editor V2 are available in AWS GovCloud (US) Regions. For more information about the AWS Regions where Redshift is available, please refer to the AWS Regions table.

To learn more, see the Amazon Redshift documentation.
 

 

​AWS announces Amazon Redshift Query Editor V2 now supports increased maximum result set and export size to 100MB of your query result sets with no row limit in AWS GovCloud (US) Regions. Prior to this limit of your query result sets was* 5MB or 100,000 rows. This enhancement provides greater flexibility for you and your team to work with large datasets, enabling you to generate, analyze, and export more comprehensive data without previous constraints. If you work with large datasets, such as security logs, gaming data, and other big data workloads, that require in-depth analysis, the previous 5MB or 100,000-row limit on result sets and exports often fell short of your needs, forcing you to piece together insights from multiple queries and downloads. With the new 100MB result set size and export capabilities in Amazon Redshift Query Editor, you can now generate a single, more complete view of your data, export it directly as a CSV or JSON file, and conduct richer analysis to drive better-informed business decisions. The increased 100MB result set and export size capabilities for Amazon Redshift Query Editor V2 are available in AWS GovCloud (US) Regions. For more information about the AWS Regions where Redshift is available, please refer to the AWS Regions table. To learn more, see the Amazon Redshift documentation.    

Amazon OpenSearch Service now offers support for managed VPC endpoints (powered by AWS PrivateLink) in two additional regions – AWS GovCloud (US-East), and AWS GovCloud (US-West). Managed VPC endpoints allow to connect to your Amazon OpenSearch Service VPC-enabled domain in a Virtual Private Cloud (VPC). With an Amazon OpenSearch Service managed endpoint, you can now privately access your OpenSearch Service domain within your VPC from your client applications in other VPCs, within the same or across AWS accounts, without using public IPs or requiring traffic to traverse the Internet.

With this release, OpenSearch Service allows you to create an endpoint to an OpenSearch Service domain from another VPC in the same account or in another AWS account. You can either use the OpenSearch Service console or OpenSearch Service APIs to create an OpenSearch Service managed VPC endpoint.

Amazon OpenSearch Service managed VPC endpoints are powered by AWS PrivateLink. If you use OpenSearch Service managed VPC endpoints to access your OpenSearch Service domain from your client applications in another VPC, you will incur standard AWS data transfer charges and the associated cost for the AWS PrivateLink interface endpoint.

Please refer to the AWS Region Table for more information about OpenSearch Service availability. For more information, including instructions on getting started with setting up cross-VPC connectivity, please refer the OpenSearch Service documentation.

 

​Amazon OpenSearch Service now offers support for managed VPC endpoints (powered by AWS PrivateLink) in two additional regions – AWS GovCloud (US-East), and AWS GovCloud (US-West). Managed VPC endpoints allow to connect to your Amazon OpenSearch Service VPC-enabled domain in a Virtual Private Cloud (VPC). With an Amazon OpenSearch Service managed endpoint, you can now privately access your OpenSearch Service domain within your VPC from your client applications in other VPCs, within the same or across AWS accounts, without using public IPs or requiring traffic to traverse the Internet. With this release, OpenSearch Service allows you to create an endpoint to an OpenSearch Service domain from another VPC in the same account or in another AWS account. You can either use the OpenSearch Service console or OpenSearch Service APIs to create an OpenSearch Service managed VPC endpoint. Amazon OpenSearch Service managed VPC endpoints are powered by AWS PrivateLink. If you use OpenSearch Service managed VPC endpoints to access your OpenSearch Service domain from your client applications in another VPC, you will incur standard AWS data transfer charges and the associated cost for the AWS PrivateLink interface endpoint. Please refer to the AWS Region Table for more information about OpenSearch Service availability. For more information, including instructions on getting started with setting up cross-VPC connectivity, please refer the OpenSearch Service documentation.  

AWS Verified Access is a FedRAMP High authorized service in the AWS GovCloud Regions and a FedRAMP Moderate authorized service in the AWS US East and US West commercial regions. Federal agencies, public sector organizations, and other enterprises with FedRAMP compliance requirements can now leverage AWS Verified Access to enable secure VPN-less access to corporate HTTP, non-HTTP applications, and infrastructure resources. Built based on AWS Zero Trust principles, you can use Verified Access to implement a work-from-anywhere model with added security and scalability.

AWS Verified Access allows admins to define fine-grained access policies based upon a user’s identity and device posture. It evaluates access for each and every connection request and continuously monitors active connections, terminating connections when security requirements specified in the access policies aren’t met. For example, you can centrally define access policies granting Finance applications access only to authenticated users of the Finance group using compliant and managed devices. Further, you can also use Verified Access to enable access to non-HTTP(S) applications and resources such as databases, and SAP and git-repositories running on EC2 instances. Verified Access simplifies your security operations by allowing you to centrally create, group, and manage access policies for all applications and resources with similar security requirements from a single interface.

To learn more about AWS Verified Access, visit the product page.

 

​AWS Verified Access is a FedRAMP High authorized service in the AWS GovCloud Regions and a FedRAMP Moderate authorized service in the AWS US East and US West commercial regions. Federal agencies, public sector organizations, and other enterprises with FedRAMP compliance requirements can now leverage AWS Verified Access to enable secure VPN-less access to corporate HTTP, non-HTTP applications, and infrastructure resources. Built based on AWS Zero Trust principles, you can use Verified Access to implement a work-from-anywhere model with added security and scalability. AWS Verified Access allows admins to define fine-grained access policies based upon a user’s identity and device posture. It evaluates access for each and every connection request and continuously monitors active connections, terminating connections when security requirements specified in the access policies aren’t met. For example, you can centrally define access policies granting Finance applications access only to authenticated users of the Finance group using compliant and managed devices. Further, you can also use Verified Access to enable access to non-HTTP(S) applications and resources such as databases, and SAP and git-repositories running on EC2 instances. Verified Access simplifies your security operations by allowing you to centrally create, group, and manage access policies for all applications and resources with similar security requirements from a single interface. To learn more about AWS Verified Access, visit the product page.  

AWS Verified Access is a FedRAMP High authorized service in the AWS GovCloud Regions and a FedRAMP Moderate authorized service in the AWS US East and US West commercial regions. Federal agencies, public sector organizations, and other enterprises with FedRAMP compliance requirements can now leverage AWS Verified Access to enable secure VPN-less access to corporate HTTP, non-HTTP applications, and infrastructure resources. Built based on AWS Zero Trust principles, you can use Verified Access to implement a work-from-anywhere model with added security and scalability.

AWS Verified Access allows admins to define fine-grained access policies based upon a user’s identity and device posture. It evaluates access for each and every connection request and continuously monitors active connections, terminating connections when security requirements specified in the access policies aren’t met. For example, you can centrally define access policies granting Finance applications access only to authenticated users of the Finance group using compliant and managed devices. Further, you can also use Verified Access to enable access to non-HTTP(S) applications and resources such as databases, and SAP and git-repositories running on EC2 instances. Verified Access simplifies your security operations by allowing you to centrally create, group, and manage access policies for all applications and resources with similar security requirements from a single interface.

To learn more about AWS Verified Access, visit the product page.

 

​AWS Verified Access is a FedRAMP High authorized service in the AWS GovCloud Regions and a FedRAMP Moderate authorized service in the AWS US East and US West commercial regions. Federal agencies, public sector organizations, and other enterprises with FedRAMP compliance requirements can now leverage AWS Verified Access to enable secure VPN-less access to corporate HTTP, non-HTTP applications, and infrastructure resources. Built based on AWS Zero Trust principles, you can use Verified Access to implement a work-from-anywhere model with added security and scalability. AWS Verified Access allows admins to define fine-grained access policies based upon a user’s identity and device posture. It evaluates access for each and every connection request and continuously monitors active connections, terminating connections when security requirements specified in the access policies aren’t met. For example, you can centrally define access policies granting Finance applications access only to authenticated users of the Finance group using compliant and managed devices. Further, you can also use Verified Access to enable access to non-HTTP(S) applications and resources such as databases, and SAP and git-repositories running on EC2 instances. Verified Access simplifies your security operations by allowing you to centrally create, group, and manage access policies for all applications and resources with similar security requirements from a single interface. To learn more about AWS Verified Access, visit the product page.  

Today, we announce support for AWS Glue Data Catalog views with AWS Glue 5.0 for Apache Spark jobs. AWS Glue Data Catalog views with AWS Glue 5.0 allows customers to create views from Glue 5.0 Spark jobs that can be queried from multiple engines without requiring access to referenced tables.

AWS Glue is a serverless, scalable data integration service that makes it simple to discover, prepare, move, and integrate data from multiple sources. AWS Glue Data Catalog views are virtual tables in which the contents are defined by a SQL query that references one or more tables. These views support multiple SQL query engines, so you can access the same view across different AWS services. Administrators can control underlying data access using the rich SQL dialect provided by AWS Glue 5.0 Spark jobs. Access is managed with AWS Lake Formation permissions, including named resource grants, data filters, and lake formation tags. All requests are logged in AWS CloudTrail.

AWS Glue Data Catalog views is generally available on AWS Glue 5.0, in all AWS Glue 5.0 regions.

To learn more, visit the AWS Glue product page and our documentation.

 

​Today, we announce support for AWS Glue Data Catalog views with AWS Glue 5.0 for Apache Spark jobs. AWS Glue Data Catalog views with AWS Glue 5.0 allows customers to create views from Glue 5.0 Spark jobs that can be queried from multiple engines without requiring access to referenced tables. AWS Glue is a serverless, scalable data integration service that makes it simple to discover, prepare, move, and integrate data from multiple sources. AWS Glue Data Catalog views are virtual tables in which the contents are defined by a SQL query that references one or more tables. These views support multiple SQL query engines, so you can access the same view across different AWS services. Administrators can control underlying data access using the rich SQL dialect provided by AWS Glue 5.0 Spark jobs. Access is managed with AWS Lake Formation permissions, including named resource grants, data filters, and lake formation tags. All requests are logged in AWS CloudTrail. AWS Glue Data Catalog views is generally available on AWS Glue 5.0, in all AWS Glue 5.0 regions. To learn more, visit the AWS Glue product page and our documentation.  

AWS CodePipeline V2 type pipeline introduces CodeBuild rule and Commands rule that customers can use in their stage level condition to gate a pipeline execution. You can use CodeBuild rule to start a CodeBuild build or Commands rule to run simple shell commands before exiting a stage, when all actions in the stage have completed successfully, or when any action in the stage has failed.

These new rules will provide more flexibility to your deployment process and enable more release safety controls. With these two rules, you can run integration tests as a stage level condition when your deployment completes and automatically roll back or fail your deployment when the integration tests fail. You can also run custom cleanup scripts using these new rules when the stage execution fails.

To learn more about using these rules in stage level conditions in your pipeline, visit our documentation. For more information about AWS CodePipeline, visit our product page. This feature is available in all regions where AWS CodePipeline is supported.
 

 

​AWS CodePipeline V2 type pipeline introduces CodeBuild rule and Commands rule that customers can use in their stage level condition to gate a pipeline execution. You can use CodeBuild rule to start a CodeBuild build or Commands rule to run simple shell commands before exiting a stage, when all actions in the stage have completed successfully, or when any action in the stage has failed. These new rules will provide more flexibility to your deployment process and enable more release safety controls. With these two rules, you can run integration tests as a stage level condition when your deployment completes and automatically roll back or fail your deployment when the integration tests fail. You can also run custom cleanup scripts using these new rules when the stage execution fails. To learn more about using these rules in stage level conditions in your pipeline, visit our documentation. For more information about AWS CodePipeline, visit our product page. This feature is available in all regions where AWS CodePipeline is supported.    

AWS Graviton4-based R8g database instances are now generally available for Amazon Aurora with PostgreSQL compatibility and Amazon Aurora with MySQL compatibility in Europe (Ireland), Europe (Spain), Europe (Stockholm), Asia Pacific (Mumbai), Asia Pacific (Sydney), Asia Pacific (Tokyo) regions. R8g instances offer larger instance sizes, up to 48xlarge and features an 8:1 ratio of memory to vCPU, and the latest DDR5 memory. Graviton4-based instances provide up to a 40% performance improvement and up to 29% price/performance improvement for on-demand pricing over Graviton3-based instances of equivalent sizes on Amazon Aurora databases, depending on database engine, version, and workload.

AWS Graviton4 processors are the latest generation of custom-designed AWS Graviton processors built on the AWS Nitro System. R8g DB instances are available with new 24xlarge and 48xlarge sizes. With these new sizes, R8g DB instances offer up to 192 vCPU, up to 50Gbps enhanced networking bandwidth, and up to 40Gbps of bandwidth to the Amazon Elastic Block Store (Amazon EBS).

You can spin up Gravitona4 R8g database instances in the Amazon RDS Management Console or using the AWS CLI. Upgrading a database instance to Graviton4 requires a simple instance type modification. For more details, refer to the Aurora documentation.

Amazon Aurora is designed for unparalleled high performance and availability at global scale with full MySQL and PostgreSQL compatibility. It provides built-in security, continuous backups, serverless compute, up to 15 read replicas, automated multi-Region replication, and integrations with other AWS services. To get started with Amazon Aurora, take a look at our getting started page.

 

​AWS Graviton4-based R8g database instances are now generally available for Amazon Aurora with PostgreSQL compatibility and Amazon Aurora with MySQL compatibility in Europe (Ireland), Europe (Spain), Europe (Stockholm), Asia Pacific (Mumbai), Asia Pacific (Sydney), Asia Pacific (Tokyo) regions. R8g instances offer larger instance sizes, up to 48xlarge and features an 8:1 ratio of memory to vCPU, and the latest DDR5 memory. Graviton4-based instances provide up to a 40% performance improvement and up to 29% price/performance improvement for on-demand pricing over Graviton3-based instances of equivalent sizes on Amazon Aurora databases, depending on database engine, version, and workload. AWS Graviton4 processors are the latest generation of custom-designed AWS Graviton processors built on the AWS Nitro System. R8g DB instances are available with new 24xlarge and 48xlarge sizes. With these new sizes, R8g DB instances offer up to 192 vCPU, up to 50Gbps enhanced networking bandwidth, and up to 40Gbps of bandwidth to the Amazon Elastic Block Store (Amazon EBS). You can spin up Gravitona4 R8g database instances in the Amazon RDS Management Console or using the AWS CLI. Upgrading a database instance to Graviton4 requires a simple instance type modification. For more details, refer to the Aurora documentation. Amazon Aurora is designed for unparalleled high performance and availability at global scale with full MySQL and PostgreSQL compatibility. It provides built-in security, continuous backups, serverless compute, up to 15 read replicas, automated multi-Region replication, and integrations with other AWS services. To get started with Amazon Aurora, take a look at our getting started page.  

Amazon Relational Database Service (RDS) for PostgreSQL, MySQL, and MariaDB now supports AWS Graviton4-based M8g database instances in the Europe (Spain), Europe (Stockholm), and Europe (London) Regions and R8g database instances in Europe (Ireland), Europe (Spain), Europe (Stockholm), Asia Pacific (Mumbai), Asia Pacific (Sydney), Asia Pacific (Tokyo) regions. 

Graviton4-based instances provide up to a 40% performance improvement and up to 29% price/performance improvement for on-demand pricing over Graviton3-based instances of equivalent sizes on Amazon RDS open source databases, depending on database engine, version, and workload.

M8g and R8g database instances are available on Amazon RDS for PostgreSQL version 17.1 and higher, 16.1 and higher, 15.2 and higher, 14.5 and higher, and 13.8 and higher. M8g and R8g database instances are available on Amazon RDS for MySQL version 8.0.32 and higher, and Amazon RDS for MariaDB version 11.4.3 and higher, 10.11.7 and higher, 10.6.13 and higher, 10.5.20 and higher, and 10.4.29 and higher. For more details on these instances and supported versions for each region, refer to the Amazon RDS User Guide. Get started by creating a fully managed M8g or R8g database instance using the Amazon RDS Management Console.

For complete information on pricing and regional availability, please refer to the Amazon RDS pricing page. For information on specific engine versions that support these DB instance types, please see the Amazon RDS documentation.

 

​Amazon Relational Database Service (RDS) for PostgreSQL, MySQL, and MariaDB now supports AWS Graviton4-based M8g database instances in the Europe (Spain), Europe (Stockholm), and Europe (London) Regions and R8g database instances in Europe (Ireland), Europe (Spain), Europe (Stockholm), Asia Pacific (Mumbai), Asia Pacific (Sydney), Asia Pacific (Tokyo) regions.  Graviton4-based instances provide up to a 40% performance improvement and up to 29% price/performance improvement for on-demand pricing over Graviton3-based instances of equivalent sizes on Amazon RDS open source databases, depending on database engine, version, and workload. M8g and R8g database instances are available on Amazon RDS for PostgreSQL version 17.1 and higher, 16.1 and higher, 15.2 and higher, 14.5 and higher, and 13.8 and higher. M8g and R8g database instances are available on Amazon RDS for MySQL version 8.0.32 and higher, and Amazon RDS for MariaDB version 11.4.3 and higher, 10.11.7 and higher, 10.6.13 and higher, 10.5.20 and higher, and 10.4.29 and higher. For more details on these instances and supported versions for each region, refer to the Amazon RDS User Guide. Get started by creating a fully managed M8g or R8g database instance using the Amazon RDS Management Console. For complete information on pricing and regional availability, please refer to the Amazon RDS pricing page. For information on specific engine versions that support these DB instance types, please see the Amazon RDS documentation.  

Amazon Kinesis Data Streams now allows customers to make API requests over Internet Protocol version 6 (IPv6). Customers now have the option of using either IPv6 or IPv4 when sending requests over dual-stack public endpoints.

Kinesis Data Streams allows users to capture, process, and store data streams in real time at any scale. IPv6 increases the number of available addresses by several orders of magnitude, so customers will no longer need to manage overlapping address spaces. Many devices and networks today already use IPv6, and now they can easily write to and read from data streams.

Support for IPv6 with Kinesis Data Streams is available in all Regions where Kinesis Data Streams is available, except for AWS GovCloud (US) and China Regions. See here for a full listing of our Regions. To learn more about Kinesis Data Streams, please refer to our Developer Guide.

 

​Amazon Kinesis Data Streams now allows customers to make API requests over Internet Protocol version 6 (IPv6). Customers now have the option of using either IPv6 or IPv4 when sending requests over dual-stack public endpoints. Kinesis Data Streams allows users to capture, process, and store data streams in real time at any scale. IPv6 increases the number of available addresses by several orders of magnitude, so customers will no longer need to manage overlapping address spaces. Many devices and networks today already use IPv6, and now they can easily write to and read from data streams. Support for IPv6 with Kinesis Data Streams is available in all Regions where Kinesis Data Streams is available, except for AWS GovCloud (US) and China Regions. See here for a full listing of our Regions. To learn more about Kinesis Data Streams, please refer to our Developer Guide.  

Amazon EMR Serverless is a serverless option in Amazon EMR that makes it simple for data engineers and data scientists to run open-source big data analytics frameworks without configuring, managing, and scaling clusters or servers. Today, we are excited to announce that Amazon EMR Serverless Streaming jobs, which enables you to continuously analyze and process streaming data, is now available in the AWS GovCloud (US) Regions.

Streaming has become vital for businesses to gain continuous insights from data sources like sensors, IoT devices, and web logs. However, processing streaming data can be challenging due to requirements such as high availability, resilience to failures, and integration with streaming services. Amazon EMR Serverless Streaming jobs has built-in features to addresses these challenges. It offers high availability through multi-AZ (Availability Zone) resiliency by automatically failing over to healthy AZs. It also offers increased resiliency through automatic job retries on failures and log management features like log rotation and compaction, preventing the accumulation of log files that might lead to job failures. In addition, Amazon EMR Serverless Streaming jobs support processing data from streaming services like self-managed Apache Kafka clusters, Amazon Managed Streaming for Apache Kafka, and now is integrated with Amazon Kinesis Data Streams using a new built-in Amazon Kinesis Data Streams Connector, making it easier to build end-to-end streaming pipelines.

To get started, visit the Amazon EMR Serverless Streaming jobs page in the Amazon EMR Serverless User Guide.

 

​Amazon EMR Serverless is a serverless option in Amazon EMR that makes it simple for data engineers and data scientists to run open-source big data analytics frameworks without configuring, managing, and scaling clusters or servers. Today, we are excited to announce that Amazon EMR Serverless Streaming jobs, which enables you to continuously analyze and process streaming data, is now available in the AWS GovCloud (US) Regions. Streaming has become vital for businesses to gain continuous insights from data sources like sensors, IoT devices, and web logs. However, processing streaming data can be challenging due to requirements such as high availability, resilience to failures, and integration with streaming services. Amazon EMR Serverless Streaming jobs has built-in features to addresses these challenges. It offers high availability through multi-AZ (Availability Zone) resiliency by automatically failing over to healthy AZs. It also offers increased resiliency through automatic job retries on failures and log management features like log rotation and compaction, preventing the accumulation of log files that might lead to job failures. In addition, Amazon EMR Serverless Streaming jobs support processing data from streaming services like self-managed Apache Kafka clusters, Amazon Managed Streaming for Apache Kafka, and now is integrated with Amazon Kinesis Data Streams using a new built-in Amazon Kinesis Data Streams Connector, making it easier to build end-to-end streaming pipelines. To get started, visit the Amazon EMR Serverless Streaming jobs page in the Amazon EMR Serverless User Guide.