da Agency

Amazon CloudWatch SDK supports optimized JSON, CBOR protocols

Amazon CloudWatch announces support for both the JSON and Concise Binary Object Representation (CBOR) protocols in the CloudWatch SDK, enabling lower latency and improved performance for CloudWatch customers. The SDK will automatically use JSON or CBOR as its new default communication protocol, offering customers a lower end-to-end processing latency as well as reduced payload sizes, application client side CPU, and memory usage. Customers use the CloudWatch SDK either directly or through Infrastructure as Code solutions to manage their monitoring resources. Reducing control plane operations latency and payload size helps customer optimize their operational maintenance and resources usage and costs. JSON and the CBOR data formats are standards designed to enable better performance over the traditional AWS Query protocol. The CloudWatch SDK for JSON and CBOR protocols support is available in all AWS Regions where Amazon CloudWatch is available and for all generally available AWS SDK language variants. To leverage the performance improvements, customers can install the latest SDK version here. To learn more about the AWS SDK, see Amazon Developer tools.
Quelle: aws.amazon.com

da Agency

Amazon ElastiCache Serverless now supports same-slot WATCH command

Today, we are announcing that Amazon ElastiCache Serverless now supports the WATCH command for same-slot transactions, helping developers build more reliable applications with improved data consistency in high-concurrency scenarios. With this launch, the WATCH command makes transactions conditional, ensuring they execute only when monitored keys remain unchanged. For ElastiCache Serverless, the WATCH command works with transactions that operate on keys within the same hash slot as the watched keys. When applications attempt to watch keys that are not in the same hash slot, they’ll receive a CROSSSLOT error. Developers can control key placement by using hash tags in their key names to ensure keys hash to the same slot. The transaction will also be aborted when ElastiCache Serverless cannot guarantee the state of watched keys. WATCH command support is available in all AWS regions where ElastiCache Serverless is supported at no additional cost. To get started, create transactions using the WATCH command through your preferred client library. To learn more about conditional transactions and the WATCH command, see the ElastiCache Serverless documentation, and the Valkey transactions documentation.
Quelle: aws.amazon.com

da Agency

Amazon EC2 X8g instances now available in Asia Pacific (Sydney) region

Starting today, Amazon Elastic Compute Cloud (Amazon EC2) X8g instances are available in Asia Pacific (Sydney) region. These instances are powered by AWS Graviton4 processors and deliver up to 60% better performance than AWS Graviton2-based Amazon EC2 X2gd instances. X8g instances offer up to 3 TiB of total memory and increased memory per vCPU compared to other Graviton4-based instance. They have the best price performance among EC2 X-series instances, and are ideal for memory-intensive workloads such as electronic design automation (EDA) workloads, in-memory databases (Redis, Memcached), relational databases (MySQL, PostgreSQL), real-time big data analytics, real-time caching servers, and memory-intensive containerized applications. X8g instances offer larger instance sizes with up to 3x more vCPU (up to 48xlarge) and memory (up to 3TiB) than Graviton2-based X2gd instances. They offer up to 50 Gbps enhanced networking bandwidth and up to 40 Gbps of bandwidth to the Amazon Elastic Block Store (Amazon EBS). Elastic Fabric Adapter (EFA) networking support is offered on 24xlarge, 48xlarge, and bare metal sizes, and Elastic Network Adapter (ENA) Express support is available on instance sizes larger than 12xlarge. To learn more, see Amazon EC2 X8g Instances. To quickly migrate your workloads to Graviton-based instances, see AWS Graviton Fast Start program. To get started, see the AWS Management Console, AWS Command Line Interface (AWS CLI), and AWS SDKs.
Quelle: aws.amazon.com

da Agency

Now generally available: Amazon EC2 C8gb instances

Today, AWS announces the general availability of the new Amazon Elastic Block Storage (Amazon EBS) optimized Amazon Elastic Compute Cloud (Amazon EC2) C8gb instances. These instances are powered by AWS Graviton4 processors to deliver up to 30% better compute performance than AWS Graviton3 processors. At up to 150 Gbps of EBS bandwidth, these instances offer higher EBS performance compared to same-sized equivalent Graviton4-based instances. Take advantage of the higher block storage performance offered by these new EBS optimized EC2 instances to scale the performance and throughput of workloads such as high-performance file systems, while optimizing the cost of running your workloads.
For increased scalability, these instances offer instance sizes up to 24xlarge, including a metal-24xl size, up to 192 GiB of memory, up to 150 Gbps of EBS bandwidth, up to 200 Gbps of networking bandwidth. These instances support Elastic Fabric Adapter (EFA) networking on the 16xlarge, 24xlarge, metal-24xl sizes, which enables lower latency and improved cluster performance for workloads deployed on tightly coupled clusters.
The new C8gb instances are available in US East (N. Virginia) and US West (Oregon) regions. Metal sizes are only available in US East (N. Virginia) region.
To learn more, see Amazon EC2 C8gb Instances. To begin your Graviton journey, visit the Level up your compute with AWS Graviton page. To get started, see AWS Management Console, AWS Command Line Interface (AWS CLI), and AWS SDKs.
Quelle: aws.amazon.com

da Agency

Amazon ECS now supports custom container stop signals on AWS Fargate

Amazon Elastic Container Service (Amazon ECS) now supports custom container stop signals for Linux tasks running on AWS Fargate, honoring the stop signal configured in Open Container Initiative (OCI) images when tasks are stopped. The enhancement improves graceful shutdown behavior by aligning Fargate task termination with each container’s preferred termination signal. Previously, when an Amazon ECS task running on AWS Fargate was stopped, each Linux container always received SIGTERM followed by SIGKILL after the configured timeout. With the new behavior, the Amazon ECS container agent reads the stop signal from the container image configuration and sends that signal when stopping the task. Containers that rely on signals such as SIGQUIT or SIGINT for graceful shutdown can now run on Fargate with their intended termination semantics. If no STOPSIGNAL is configured, Amazon ECS continues to send SIGTERM by default. Customers can use custom stop signals on Amazon ECS with AWS Fargate by adding a STOPSIGNAL instruction (for example, STOPSIGNAL SIGQUIT) to their OCI‑compliant container images. Support for container‑defined stop signals is available in all AWS Regions. To learn more, refer to the ECS Developer Guide.
Quelle: aws.amazon.com