9/6/2024, 12:00:00 AM ~ 9/9/2024, 12:00:00 AM (UTC)

Recent Announcements

Amazon Kinesis Data Streams now supports FIPS 140-3 enabled interface VPC endpoint

Starting today, Amazon Kinesis Data Streams supports adding a VPC endpoint using AWS PrivateLink that connects through the regional endpoint that has been validated under the Federal Information Processing Standard (FIPS) 140-3 program. With this new launch, you can easily use AWS PrivateLink with Kinesis Data Streams for those regulated workloads that require a secure connection using a FIPS 140-3 validated cryptographic module.\n FIPS compliant endpoints helps companies contracting with the US federal governments meet the FIPS security requirement to encrypt sensitive data in supported Regions. To create an interface VPC endpoint that connects to a Kinesis Data Streams FIPS endpoint, see using Amazon Kinesis Data Streams with Interface VPC Endpoints. This new capability is available in all AWS Regions in the United States, including the AWS GovCloud (US) Regions. To learn more about AWS PrivateLink, see accessing AWS services through AWS PrivateLink. To learn more about FIPS 140-3 at AWS, visit FIPS 140-3 Compliance.

Amazon RDS Custom for SQL Server is now available in 3 additional AWS Regions

Amazon RDS Custom for SQL Server is a managed database service that allows you to bring your own licensed SQL Server media and have access to the underlying operating system and database environment. This service is now available in the AWS Regions of US West (N. California), Asia Pacific (Osaka), and Europe (Paris).\n By using Amazon RDS Custom for SQL Server, you can benefit from the agility of a managed database service, including features such as managed high availability (MAZ), automated backups and point-in-time recovery, and cross-region snapshot copying. You can choose to deploy RDS Custom for SQL Server using your own licensed SQL Server media or with License Included (LI) instances. It can help you save time on the undifferentiated heavy lifting of database management and focus on more business-impacting tasks. To learn more about Amazon RDS Custom, please see the Amazon RDS Custom for SQL Server User Guide and Amazon RDS Custom Pricing for pricing details and availability in the additional regions.

PostgreSQL 17 RC1 is now available in Amazon RDS Database preview environment

Amazon RDS for PostgreSQL 17 Release Candidate 1 (RC1) is now available in the Amazon RDS Database Preview Environment, allowing you to evaluate the pre-release of PostgreSQL 17 on Amazon RDS for PostgreSQL. You can deploy PostgreSQL 17 RC1 in the Amazon RDS Database Preview Environment that has the benefits of a fully managed database.\n PostgreSQL 17 includes updates to vacuuming that reduces memory usage, improves time to finish vacuuming, and shows progress of vacuuming indexes. With PostgreSQL 17, you no longer need to drop logical replication slots when performing a major version upgrade. PostgreSQL 17 continues to build on the SQL/JSON standard, adding support for JSON_TABLE features that can convert JSON to a standard PostgreSQL table. The MERGE command now supports the RETURNING clause, letting you further work with modified rows. PostgreSQL 17 also includes general improvements to query performance and adds more flexibility to partition management with the ability to SPLIT/MERGE partitions. Please refer to the PostgreSQL community announcement for more details. Amazon RDS Database Preview Environment database instances are retained for a maximum period of 60 days and are automatically deleted after the retention period. Amazon RDS database snapshots that are created in the preview environment can only be used to create or restore database instances within the Preview Environment. You can use the PostgreSQL dump and load functionality to import or export your databases from the Preview Environment. Amazon RDS Database Preview Environment database instances are priced as per the pricing in the US East (Ohio) Region.

CloudWatch Application Signals now supports request based Service Level Objectives (SLOs)

CloudWatch Application Signals, which helps troubleshoot issues quickly by providing out-of-the-box dashboards that correlate telemetry across metrics, traces, and logs for your applications and their dependencies, now supports Service Level Objectives (SLOs) calculated based on the request count i.e. the fraction of good or bad requests of the total operations performed by any service. This allows for more precise tracking of how many requests met the defined SLO criteria (e.g., latency under 200ms) out of the total requests received by a service.\n SLOs represent a commitment to maintain a certain level of service quality, typically expressed as percentage attainment of performance goals within a given time interval. The existing offering of period-based SLOs measures performance during each time period in an interval and aggregates proportion of good periods that meet a specified performance threshold. The release of request-based SLOs allows you to track error tolerance in terms of requests. This enables fine-grained monitoring based on customer traffic, particularly useful for applications prone to high fluctuations in request volume, where performance shortfall during period of low traffic can lead to a quick erosion of the error budget. Request-based SLOs are available in all regions where Application Signals is generally available - 28 commercial AWS Regions except CA West (Calgary) Region. For pricing, see Amazon CloudWatch pricing. See SLO documentation to learn more, or refer to the user guide and AWS One Observability Workshop to get started with Application Signals.

Amazon ECS now supports AWS Graviton-based Spot compute with AWS Fargate

Amazon Elastic Container Service (Amazon ECS) now supports AWS Graviton-based compute with AWS Fargate Spot. This capability helps you run fault-tolerant Arm-based applications with up to 70% discount compared to Fargate prices. AWS Graviton processors are custom-built by AWS to deliver the best price-performance for cloud workloads.\n Amazon ECS with AWS Fargate enables customers to deploy and build workloads at scale in a serverless manner. Customers can get better price-performance by running Arm-based workloads. Starting today, customers can further optimize for costs by running fault-tolerant Arm-based workloads on AWS Fargate Spot. To get started, just configure your task definition just like you do today with cpu-architecture = ARM64 and choose FARGATE_SPOT as the capacity provider to run your Amazon ECS service or a standalone task. Amazon ECS will leverage spare AWS Graviton-based compute capacity available in the AWS cloud for running your service or task. You can now get the simplicity of serverless compute with familiar cost optimization levers of Spot capacity with Graviton-based compute. This capability is now available for Amazon ECS tasks running on AWS Fargate platform version 1.4.0 or higher in all commercial and the AWS GovCloud (US) Regions. To learn more about usage and pricing of AWS Fargate Spot, see Fargate Capacity Providers documentation and the AWS Fargate pricing page.

Amazon Timestream for InfluxDB is now available in the Canada, London and Paris AWS regions

You can now use Amazon Timestream for InfluxDB in the Canada (Central), Europe (London) and Europe (Paris) AWS regions. Timestream for InfluxDB makes it easy for application developers and DevOps teams to run fully managed InfluxDB databases on AWS for real-time time-series applications using open-source APIs.\n To migrate to Timestream for InfluxDB from a self-managed InfluxDB instance, you can use our sample migration script by following this guide. Timestream for InfluxDB offers the full feature set available in the InfluxDB 2.7 release of the open-source version, and adds deployment options with Multi-AZ high availability and enhanced durability. For high availability, Timestream for InfluxDB allows you to automatically create a primary database instance and synchronously replicate the data to an instance in a different Availability Zone. When it detects a failure, Amazon Timestream automatically fails over to a standby instance without manual intervention. With the latest release, customers can use Amazon Timestream for InfluxDB in the following regions: US East (Ohio), US East (N. Virginia), US West (Oregon), Canada (Central), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Paris), Europe (Frankfurt), Europe (Ireland), Europe (London), and Europe (Stockholm). To get started with Amazon Timestream, visit our product page.

Amazon RDS for MariaDB supports minors 10.11.9, 10.6.19, 10.5.26

Amazon Relational Database Service (Amazon RDS) for MariaDB now supports MariaDB minor versions 10.11.9, 10.6.19, and 10.5.26. We recommend that you upgrade to the latest minor versions to fix known security vulnerabilities in prior versions of MariaDB, and to benefit from the bug fixes, performance improvements, and new functionality added by the MariaDB community.\n You can leverage automatic minor version upgrades to automatically upgrade your databases to more recent minor versions during scheduled maintenance windows. You can also leverage Amazon RDS Managed Blue/Green deployments for safer, simpler, and faster updates to your MariaDB instances. Learn more about upgrading your database instances, including automatic minor version upgrades and Blue/Green Deployments, in the Amazon RDS User Guide. Amazon RDS for MariaDB makes it straightforward to set up, operate, and scale MariaDB deployments in the cloud. Learn more about pricing details and regional availability at Amazon RDS for MariaDB. Create or update a fully managed Amazon RDS database in the Amazon RDS Management Console.

AWS Blogs

AWS Japan Blog (Japanese)

AWS Cloud Operations Blog

AWS for Industries

AWS Machine Learning Blog

AWS for M&E Blog

Networking & Content Delivery

Open Source Project

AWS CLI

AWS CDK

Amazon EKS Anywhere