Posts

Amazon RDS for SQL Server increases the maximum size and provisioned performance of General Purpose (gp3) volumes - devamazonaws.blogspot.com

Amazon Relational Database Service (Amazon RDS) for SQL Server now supports higher volume-level limits for General Purpose (gp3) storage. With this update, each gp3 volume can scale up to 64 TiB in size (4X the previous 16 TiB limit), up to 80,000 IOPS (5X the previous 16,000 IOPS limit), and up to 2,000 MiB/s throughput (2X the previous 1,000 MiB/s limit). With these improvements, customers can now run larger Microsoft SQL Server databases on Amazon RDS. Workloads with demanding I/O requirements such as high-throughput OLTP systems and large-scale analytical workloads can take advantage of higher IOPS and throughput on a single volume with simplified storage management, and get better performance for mission-critical SQL Server workloads. Additionally, you can configure additional storage volumes to add up to three gp3 or io2 volumes per DB instance, increasing total capacity up to 256 TiB per instance. There is no change to pricing - customers pay for storage and any additional I...
Post a Comment
Read more

[MS] Use your own language model key in VS Code - devamazonaws.blogspot.com

Learn how to use bring your own key (BYOK) in VS Code to add models from providers like Azure, Anthropic, Gemini, OpenAI, Huggingface, OpenRouter, or use a local model with Ollama, Foundry Local, and more. Read the full article Post Updated on June 18, 2026 at 01:00AM Thanks for reading from devamazonaws.blogspot.com
Post a Comment
Read more

[MS] Windows stack limit checking retrospective, follow-up - devamazonaws.blogspot.com

Aaron Giles worked on porting Windows to both ARM32 and AArch64, and he noted a missing detail in my retrospective of stack limit checking on arm64 : Every once in a while Raymond Chen does an architectural comparison series and I get to see (a paraphrased version of) some code I wrote way back when. He's right about why we passed stack size/16, but surprised he didn't call out the unconventional x15 usage. — Aaron Giles ( @aarongiles.com ) Mar 20, 2026 at 8:08 PM I'm guessing that by "unconventional x15 usage", Aaron means "Why is the parameter passed in the x15 register? The AArch64 calling convention passes the first parameter in the x0 register, so shouldn't that parameter be in the x0 register?" It seemed so obvious to me that I didn't consider it worth mentioning. The function that needs to do a stack probe is in a bit of a bind: It has inbound parameters, some of which might be passed in registers. If the stack size parame...
Post a Comment
Read more

Amazon FSx for Lustre Intelligent-Tiering storage class is now available in 13 additional AWS Regions - devamazonaws.blogspot.com

You can now create Amazon FSx for Lustre file systems with the Intelligent-Tiering storage class in 13 additional AWS Regions across Africa, Europe, Asia Pacific, and South America. The FSx for Lustre Intelligent-Tiering storage class delivers the lowest-cost and only fully elastic Lustre file storage in the cloud. It is optimized for workloads with a mix of hot and cold data that don't require consistent SSD-level performance. It automatically tiers your data across three storage tiers (Frequent Access, Infrequent Access, and Archive) based on access patterns, and an optional SSD read cache keeps your active data fast. You get high performance for active data in your HPC and AI/ML worklaods and low-cost storage for the data you access less often, paying only for what you store with no capacity to provision upfront. With FSx for Lustre Intelligent-Tiering, you get up to 34% better price-performance compared to on-premises HDD file storage, and reduce storage costs for rarely acce...
Post a Comment
Read more

[MS] GitHub Copilot for JetBrains is moving to Copilot CLI as the default agent harness - devamazonaws.blogspot.com

Copilot CLI is becoming the default agent harness in GitHub Copilot for JetBrains, and our local harness will be deprecated. This change provides greater consistency across all GitHub Copilot surfaces and is an important step toward faster feature parity and higher-quality results in GitHub Copilot for JetBrains. Copilot CLI sessions run independently in the background on your machine and use the Copilot CLI agent harness, while the IDE starts, monitors, and steers them. This is the same architecture used across GitHub Copilot today and adopting it in JetBrains lets us ship the same capabilities to JetBrains developers at a faster pace. Why we're making this change Copilot is not the same product it was a year ago. Agentic coding — long, multi-step sessions that plan, edit, and verify work autonomously — is now the core of the experience, and the harness that runs those sessions matters more than ever. Until recently, JetBrains has used its own local harness. Maintaining a sepa...
Post a Comment
Read more

[MS] The time the x86 emulator team found code so bad that they fixed it during emulation - devamazonaws.blogspot.com

During an exchange of war stories, a colleague of mine told one from back in the days when Windows included a processor emulator for x86-32 on systems that natively ran some other processor. (This has happened many times. And no, I don't know which processor this particular story applied to.) This particular emulator employed binary translation, generating native code to perform the equivalent operations of the original x86-32 code. This offered a significant performance improvement over emulation via interpreter. You can imagine that x86-32 is just a bytecode, and the emulator is a JIT compiler. Anyway, my colleague found that there was one program that needed to allocate around 64KB of memory on the stack and initialize it. The standard way of doing this is to perform a stack probe to ensure that 64KB of memory is available , then subtracting 65536 from the stack pointer, and then initializing the memory in a small, tight loop. But using a loop to initialize the memory was to...
Post a Comment
Read more

Amazon FSx for OpenZFS now supports on-demand data replication across AWS opt-in Regions - devamazonaws.blogspot.com

Amazon FSx for OpenZFS now supports on-demand data replication across AWS opt-in Regions, enabling you to easily and efficiently transfer incremental point-in-time snapshots of your volumes beyond AWS Regions that are enabled by default. On-demand data replication provides a simple and resilient way to implement disaster recovery, replicate production data to a different Region or account, and enable lower latency data access for your global customer base or workforce. Amazon FSx for OpenZFS provides fully managed, cost-effective, shared file storage powered by the popular OpenZFS file system, with rich data management capabilities like snapshots, data cloning, and compression, along with sub-millisecond latencies and up to 10 GB/s of throughput. Opt-in Regions are AWS Regions that are disabled by default, in contrast to regions that are enabled by default. Previously, on-demand data replication was supported only between accounts in AWS Regions that are enabled by default. Starting...
Post a Comment
Read more