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.  

Amazon EMR Serverless is now a FedRAMP High authorized service in the AWS GovCloud (US-East) and AWS GovCloud (US-West) Regions. Federal agencies, public sector organizations and other enterprises with FedRAMP High compliance requirements can now leverage EMR Serverless to run Apache Spark and Hive workloads.

Amazon EMR Serverless is a serverless option that makes it simple for data analysts and engineers to run open-source big data analytics frameworks without configuring, managing, and scaling clusters or servers. The Federal Risk and Authorization Management Program (FedRAMP) is a US government-wide program that delivers a standard approach to the security assessment, authorization, and continuous monitoring for cloud products and services.

To get started with Amazon EMR Serverless, visit the User Guide.
 

 

​Amazon EMR Serverless is now a FedRAMP High authorized service in the AWS GovCloud (US-East) and AWS GovCloud (US-West) Regions. Federal agencies, public sector organizations and other enterprises with FedRAMP High compliance requirements can now leverage EMR Serverless to run Apache Spark and Hive workloads. Amazon EMR Serverless is a serverless option that makes it simple for data analysts and engineers to run open-source big data analytics frameworks without configuring, managing, and scaling clusters or servers. The Federal Risk and Authorization Management Program (FedRAMP) is a US government-wide program that delivers a standard approach to the security assessment, authorization, and continuous monitoring for cloud products and services. To get started with Amazon EMR Serverless, visit the User Guide.    

Today, we are excited to announce the general availability of Amazon Data Firehose (Firehose) integration with Amazon S3 Tables, a feature that enables customers to deliver real-time streaming data into Amazon S3 Tables without requiring any code development or multi-step processes.

Firehose can acquire streaming data from Amazon Kinesis Data Streams, Amazon MSK, Direct PUT API, and AWS Services such as AWS WAF web ACL logs, Amazon VPC Flow Logs. It can then deliver this data to destinations like Amazon S3, Amazon Redshift, OpenSearch, Splunk, Snowflake, and others for analytics. Now, with the Amazon S3 Table integration, customers can stream data from any of these sources directly into Amazon S3 Tables. As a serverless service, Firehose allows customers to simply setup a stream by configuring the source and destination properties, and pay based on bytes processed.

The new feature also enables customers to route records in a data stream to different Amazon S3 tables based on the content of the incoming record. Additionally, customers can automate processing for data correction and right-to-forget scenarios by applying row-level update or delete operations in the destination S3 tables.

To get started, visit Amazon Data Firehose documentation and console.
 

 

​Today, we are excited to announce the general availability of Amazon Data Firehose (Firehose) integration with Amazon S3 Tables, a feature that enables customers to deliver real-time streaming data into Amazon S3 Tables without requiring any code development or multi-step processes. Firehose can acquire streaming data from Amazon Kinesis Data Streams, Amazon MSK, Direct PUT API, and AWS Services such as AWS WAF web ACL logs, Amazon VPC Flow Logs. It can then deliver this data to destinations like Amazon S3, Amazon Redshift, OpenSearch, Splunk, Snowflake, and others for analytics. Now, with the Amazon S3 Table integration, customers can stream data from any of these sources directly into Amazon S3 Tables. As a serverless service, Firehose allows customers to simply setup a stream by configuring the source and destination properties, and pay based on bytes processed. The new feature also enables customers to route records in a data stream to different Amazon S3 tables based on the content of the incoming record. Additionally, customers can automate processing for data correction and right-to-forget scenarios by applying row-level update or delete operations in the destination S3 tables. To get started, visit Amazon Data Firehose documentation and console.    

Amazon S3 Access Grants now authenticate based on the union of both Identity Provider (IdP) and AWS Identity and Access Management (IAM) permissions. This means customers can use AWS machine learning and analytics services such as Amazon SageMaker Unified Studio, Amazon Redshift, and AWS Glue to request access to their S3 data, and S3 Access Grants will grant access to their data after evaluating both their IdP and IAM permissions.

Now, S3 Access Grants evaluate both IAM and IdP permissions so you no longer have to choose between identity contexts when requesting access to S3. With just a few clicks in the AWS Management Console or a few lines of code using the AWS SDK, you can map S3 permissions to users and groups in an existing corporate directory, such as Entra ID and Okta, or to an IAM user or role. S3 Access Grants automatically update S3 permissions based on end user group membership as users are added and removed from groups in the IdP.

Amazon S3 Access Grants are available in all AWS Regions where AWS IAM Identity Center is available. For pricing details, visit Amazon S3 pricing. To learn more about S3 Access Grants, visit the S3 User Guide.
 

 

​Amazon S3 Access Grants now authenticate based on the union of both Identity Provider (IdP) and AWS Identity and Access Management (IAM) permissions. This means customers can use AWS machine learning and analytics services such as Amazon SageMaker Unified Studio, Amazon Redshift, and AWS Glue to request access to their S3 data, and S3 Access Grants will grant access to their data after evaluating both their IdP and IAM permissions. Now, S3 Access Grants evaluate both IAM and IdP permissions so you no longer have to choose between identity contexts when requesting access to S3. With just a few clicks in the AWS Management Console or a few lines of code using the AWS SDK, you can map S3 permissions to users and groups in an existing corporate directory, such as Entra ID and Okta, or to an IAM user or role. S3 Access Grants automatically update S3 permissions based on end user group membership as users are added and removed from groups in the IdP. Amazon S3 Access Grants are available in all AWS Regions where AWS IAM Identity Center is available. For pricing details, visit Amazon S3 pricing. To learn more about S3 Access Grants, visit the S3 User Guide.