Amazon Rds | Techlist.io

awsJun 8, 20263 min readCurated summary

AWS Weekly Roundup: BYOM for Amazon RDS for SQL Server, AWS IoT Device SDK for Swift, and more (June 8, 2026) | Amazon Web Services

The AWS roundup highlights the general availability of the AWS IoT Device SDK for Swift, bringing MQTT 5, Device Shadow, Jobs, and fleet provisioning to Apple platforms and Linux. It also covers major AWS releases involving SQL Server licensing, Cognito resilience, OpenAI models on Bedrock, Kubernetes, AI agents, cost reporting, and location services. Together, the announcements show AWS expanding support for Swift edge computing, enterprise AI, multi-Region architectures, and specialized infrastructure. ## AWS IoT Device SDK for Swift - Now generally available for macOS, iOS, tvOS, and Linux. - Provides production-ready support for: - MQTT 5 connectivity - Device Shadow - IoT Jobs - Fleet provisioning - Reflects Swift’s growing use across server-side development, IoT, and edge computing. - Projects such as WendyOS are also bringing Swift to NVIDIA Jetson and Raspberry Pi hardware. ## Major AWS Headlines ### Amazon RDS for SQL Server BYOM - Amazon RDS for SQL Server now supports Bring Your Own Media. - Customers migrating from on-premises SQL Server can reuse existing licenses, including Software Assurance. - Support is provided through Microsoft’s License Mobility program. - AWS License Manager tracks license usage and compliance. ### Multi-Region Amazon Cognito - Cognito can replicate user and machine identity data to a standby Region in near real time. - Replicated data includes credentials, user pool settings, and federation configurations. - Users can continue using applications without re-authentication after a primary-Region disruption. - Available as an add-on for Essentials and Plus user pools across 16 Regions. ### OpenAI Models on Amazon Bedrock - GPT-5.5, GPT-5.4, and Codex are generally available for production use. - GPT-5.5 targets agentic coding, data analysis, and complex autonomous tasks. - Codex supports the Codex App, CLI, and integrations with VS Code, JetBrains, and Xcode. - AWS governance and security controls remain available, pricing follows OpenAI rates, and usage counts toward existing AWS commitments. ## Recent AWS Launches - **Amazon Bedrock observability:** CloudWatch metrics now cover inference counts, token usage, and client errors for OpenAI- and Anthropic-compatible APIs. - **Redesigned Bedrock console:** Adds model catalogs, side-by-side comparisons, project organization, and pre-filled code examples. - **AgentCore Identity secrets:** Credential providers can reference existing AWS Secrets Manager secret ARNs, supporting custom KMS keys, tagging, and rotation. - **Step Functions agentic reasoning:** Workflows can invoke AgentCore-powered agents sequentially or in parallel, include human approval, and trace decisions. - **Kubernetes 1.36 on EKS:** Adds User Namespaces GA, Mutating Admission Policies, in-place pod resource scaling, and resource health reporting. - **ECS Managed Instances accelerators:** Supports Trainium1, Trainium2, and Inferentia2 instances with automatic accelerator allocation. - **Amazon Quick VPC connectivity:** Enables private connections to MCP servers without exposing internal tools to the public internet. - **Cost and Usage Report 2.0:** Adds Athena and Redshift integrations with generated infrastructure templates, table definitions, and loading guidance. - **Amazon Location Service:** Routes API now supports transit and intermodal journeys across 13 Regions. AWS also directs readers to its What’s New page, Builder Center, and upcoming events for further announcements and community resources.

Read original

Amazon Rds Kubernetes Amazon Bedrock Edge Computing+3

awsFeb 16, 20263 min readCurated summary

AWS Weekly Roundup: Amazon EC2 M8azn instances, new open weights models in Amazon Bedrock, and more (February 16, 2026) | Amazon Web Services

AWS’s February 16, 2026 roundup highlights the launch of Amazon EC2 M8azn instances, which deliver substantial performance gains for compute-intensive workloads. It also covers expanded Amazon Bedrock model and networking support, improved observability in EKS Auto Mode, more efficient OpenSearch Serverless capacity management, and configurable RDS backup settings during snapshot restoration. The post concludes with upcoming AWS conferences, summits, and community events. ## Amazon EC2 M8azn Instances - Powered by fifth-generation AMD EPYC processors with a maximum frequency of 5 GHz. - Compared with M5zn instances, they provide: - Up to 2× compute performance - 4.3× higher memory bandwidth - 10× larger L3 cache - Up to 2× networking throughput - Up to 3× EBS throughput - Built on the AWS Nitro System with sixth-generation Nitro Cards. - Available in nine sizes, from 2 to 96 vCPUs and up to 384 GiB of memory, including two bare-metal options. - Designed for high-performance workloads such as financial analytics, high-frequency trading, CI/CD, gaming, simulations, and HPC. ## New Open-Weight Models in Amazon Bedrock - Bedrock now supports six fully managed models: - DeepSeek V3.2 - MiniMax M2.1 - GLM 4.7 - GLM 4.7 Flash - Kimi K2.5 - Qwen3 Coder Next - The models target reasoning, agentic intelligence, autonomous coding, and cost-efficient production deployments. - They use Project Mantle and support OpenAI-compatible APIs. - DeepSeek V3.2, MiniMax 2.1, and Qwen3 Coder Next are also available in Kiro. ## Amazon Bedrock PrivateLink Support - AWS PrivateLink now supports the `bedrock-mantle` endpoint in addition to `bedrock-runtime`. - Project Mantle provides serverless inference, quality-of-service controls, automated capacity management, and OpenAI API compatibility. - PrivateLink support for OpenAI-compatible endpoints is available in 14 AWS Regions. ## EKS Auto Mode Logging - EKS Auto Mode now supports CloudWatch Vended Logs for managed capabilities such as: - Compute autoscaling - Block storage - Load balancing - Pod networking - Logs can be delivered to CloudWatch Logs, Amazon S3, or Amazon Data Firehose. - The feature includes AWS authentication and authorization and is offered at a lower price than standard CloudWatch Logs. ## OpenSearch Serverless Collection Groups - Collection Groups allow multiple collections to share OpenSearch Compute Units while retaining separate KMS keys and access controls. - Shared capacity can reduce OCU costs. - Administrators can define both minimum and maximum OCU limits, ensuring baseline capacity for latency-sensitive applications. ## RDS Snapshot Restore Improvements - RDS now lets users view and configure backup retention periods and preferred backup windows before or during snapshot restoration. - Restored databases no longer need post-restore backup configuration changes. - The feature supports all major RDS engines, Aurora editions, commercial AWS Regions, and GovCloud at no additional cost. ## Upcoming AWS Events - AWS Summits in Paris, London, and Bengaluru during April 2026. - AWS AI and Data Conference in Ireland on March 12, focusing on Bedrock, SageMaker, QuickSight, agent deployment, data integration, and governance. - AWS Community Days in Ahmedabad, Slovakia, and Pune. Overall, the announcements emphasize faster specialized compute, broader managed AI model access, stronger private connectivity, and improved operational controls across AWS services.

Read original

Amazon Rds Kubernetes Generative AI Amazon Bedrock+4

awsFeb 9, 20263 min readCurated summary

AWS Weekly Roundup: Claude Opus 4.6 in Amazon Bedrock, AWS Builder ID Sign in with Apple, and more (February 9, 2026) | Amazon Web Services

The February 9, 2026 AWS roundup highlights updates across infrastructure, security, databases, and AI. Major announcements include new EC2 instances, cross-account DynamoDB replication, improved identity controls, CloudFront mutual TLS, Claude Opus 4.6 in Bedrock, and structured model outputs. AWS also announced AWS Community Day Romania for April 23–24, 2026. ## Compute, Networking, and Configuration - **New EC2 C8id, M8id, and R8id instances** - Powered by custom Intel Xeon 6 processors. - Deliver up to 43% higher performance and 3.3× more memory bandwidth than previous-generation instances. - **AWS Network Firewall price reductions** - Reduces hourly and data-processing costs for NAT Gateways service-chained with Network Firewall secondary endpoints. - Removes additional data-processing charges for Advanced Inspection and TLS inspection. - **Amazon ECS Network Load Balancer support** - Enables managed linear and canary deployments for applications using NLBs. - Supports TCP/UDP workloads, low-latency services, long-lived connections, and static IP requirements. - **Expanded AWS Config coverage** - Adds support for 30 resource types across services such as Amazon EKS, Amazon Q, and AWS IoT. - Improves resource discovery, auditing, assessment, and remediation. ## Databases and Operations - **Cross-account DynamoDB global table replication** - Allows multi-Region, multi-active tables to replicate across AWS accounts. - Improves resilience, account-level workload isolation, and independent security and governance controls. - **Improved Amazon RDS connection experience** - Generates connection snippets for Java, Python, Node.js, `psql`, and other tools. - Adjusts examples automatically for authentication settings, including IAM token-based authentication. - Adds CloudShell integration for connecting to databases directly from the RDS console. ## Identity and Security - **AWS Builder ID adds Sign in with Apple** - Apple users can access services such as AWS Builder Center, Training and Certification, re:Post, AWS Startups, and Kiro. - Complements the existing Google sign-in option. - **More identity-provider claim validation in AWS STS** - Supports selected claims from Google, GitHub, CircleCI, and OCI. - These claims can be used as condition keys in IAM trust policies and resource control policies for more precise federated-access controls and data perimeters. - **Account names in the AWS Management Console** - Displays the account name in the navigation bar, making it easier to distinguish between authorized AWS accounts. - **CloudFront origin mutual TLS** - Lets CloudFront authenticate to origins using certificates. - Helps restrict backend access to verified CloudFront distributions across AWS, on-premises, third-party cloud, and external CDN environments. ## AI and Amazon Bedrock - **Claude Opus 4.6 available in Amazon Bedrock** - Anthropic’s latest model targets complex coding, agentic tasks, enterprise workflows, and professional work requiring deep reasoning and reliability. - **Structured outputs in Amazon Bedrock** - Models can return responses matching developer-defined JSON schemas. - Reduces the need for prompt-based JSON enforcement and additional validation, making production integrations more predictable. ## Upcoming AWS Event - **AWS Community Day Romania — April 23–24, 2026** - Features more than 10 technical sessions from AWS Heroes, Solutions Architects, and industry experts. - Includes networking opportunities for developers, architects, entrepreneurs, and students. These updates emphasize stronger infrastructure performance, better multi-account governance, more secure authentication, and more reliable AI application development. Teams should evaluate the new services based on their networking, resiliency, identity, and structured-output requirements.

Read original

Amazon Rds Generative AI AWS Amazon Bedrock+4

awsDec 2, 2025Original article

New capabilities to optimize costs and improve scalability on Amazon RDS for SQL Server and Oracle (opens in new tab)

Amazon Web Services has introduced several key updates to Amazon RDS for SQL Server and Oracle designed to reduce operational overhead and licensing expenses. By integrating SQL Server Developer Edition and high-performance M7i/R7i instances with customizable CPU options, organizations can now scale their development and production environments more efficiently. These enhancements allow teams to mirror production features in testing environments and right-size resource allocation without the financial burden of traditional enterprise licensing. ### SQL Server Developer Edition for Non-Production Workloads * Amazon RDS now supports SQL Server Developer Edition, providing the full feature set of the Enterprise Edition at no licensing cost for development and testing environments. * The update allows for consistency across the database lifecycle, as developers can utilize RDS features such as automated backups, software updates, and encryption while testing Enterprise-level functionalities. * To deploy, users upload SQL Server binary files to Amazon S3; existing data can be migrated from Standard or Enterprise editions using native backup and restore operations. ### Performance and Licensing Optimization via M7i/R7i Instances * RDS for SQL Server now supports M7i and R7i instance types, which offer up to 55% lower costs compared to previous generation instances. * The billing structure for these instances provides improved transparency by separating Amazon RDS DB instance costs from software licensing fees. * The "Optimize CPU" capability allows users to customize the number of vCPUs on license-included instances, enabling them to reduce licensing costs while maintaining the high memory and storage performance of larger instance classes. ### Expanded Storage and Scalability for RDS * The updates include expanded storage capabilities for both Amazon RDS for Oracle and RDS for SQL Server to accommodate growing data requirements. * These enhancements are designed to support a wide range of workloads, providing flexibility for diverse compute and storage needs across development, testing, and production tiers. These updates represent a significant shift toward providing more granular control over database expenditures and performance. For organizations running heavy SQL Server or Oracle workloads, leveraging the Developer Edition for non-production tasks and migrating to M7i/R7i instances with optimized CPU settings can drastically reduce total cost of ownership while maintaining high scalability.

Amazon Rds Amazon S3 Cost Optimization Cloud Databases+3

awsDec 2, 2025Original article

Introducing Database Savings Plans for AWS Databases (opens in new tab)

AWS has expanded its flexible pricing model to include managed database services with the launch of Database Savings Plans, offering up to 35% cost reduction for consistent usage. By committing to a specific hourly spend over a one-year term, customers can maintain cost efficiency across multiple accounts, resource types, and AWS Regions. This initiative simplifies financial management for organizations running diverse data-driven and AI applications while providing the agility to modernize architectures without losing discounted rates. ### Flexibility and Modernization Support * The plan allows customers to switch between different database engines and deployment types, such as moving from provisioned instances to serverless options, without affecting their savings. * Usage is portable across AWS Regions, enabling global organizations to shift workloads as business needs evolve while retaining their commitment benefits. * The model supports ongoing cost optimization by automatically applying discounts to new instance types, sizes, or eligible database offerings as they become available. ### Service Coverage and Tiered Discounts * Database Savings Plans cover a wide array of services, including Amazon Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream, and AWS DMS. * Serverless deployments offer the most significant savings, providing up to 35% off standard on-demand rates. * Provisioned instances across supported services deliver discounts of up to 20%. * Specific workloads for Amazon DynamoDB and Amazon Keyspaces receive tailored rates, with up to 18% savings for on-demand throughput and up to 12% for provisioned capacity. ### Implementation and Cost Management * Customers can purchase and manage these plans through the AWS Billing and Cost Management Console or via the AWS CLI. * Discounts are applied automatically on an hourly basis to all eligible usage; any consumption exceeding the hourly commitment is billed at the standard on-demand rate. * Integrated cost management tools allow users to analyze their coverage and utilization, ensuring spend remains predictable even as application usage patterns fluctuate. For organizations with stable or growing database requirements, Database Savings Plans offer a low-risk path to reducing operational expenses. Customers should utilize the AWS Cost Explorer to analyze their historical usage and determine an appropriate hourly commitment level to maximize their return on investment over a one-year term.

Amazon Rds AWS Serverless Amazon Dynamodb+4

figmaMay 28, 20254 min readCurated summary

From Multi-Day Latency to Near Real-Time Insights: Figma’s Data Pipeline Upgrade | Figma Blog

Figma replaced a daily full-table export system that could take hours or days with an incremental synchronization pipeline designed for near real-time analytics. The new architecture combines database snapshots, change data capture (CDC), and Snowflake merge logic to transfer only recent changes. By building the system in-house, Figma gained greater flexibility, lower projected costs, and a design that can scale with continued growth. ## Why the Legacy Pipeline Failed - Since 2020, a daily cron job ran `SELECT * FROM <TABLE>`, exported results to S3, and loaded them into Snowflake. - As Figma’s tables and insert volume grew: - Daily syncs reached roughly six hours by 2023. - The largest tables took several days or longer. - Additional database replicas were required for exports. - Replica maintenance cost millions of dollars annually. - The delays limited access to timely company KPIs and analytical insights. ## Choosing Incremental Synchronization Figma evaluated three options: - Continue using the legacy process, which was increasingly expensive and too slow. - Add parallelism, which might improve throughput temporarily but would not scale sustainably. - Rebuild the synchronization system around incremental updates. Incremental synchronization transfers only new and changed records instead of repeatedly copying entire tables, reducing data movement, processing time, and infrastructure usage. ## Buy vs. Build Figma decided to build the pipeline internally because available proprietary tools did not meet its requirements. - **Flexibility:** Generic SQL tools did not take advantage of capabilities such as Amazon RDS for PostgreSQL snapshot exports. - **Cost:** Commercial solutions were projected to cost five to ten times more than an in-house implementation. - **Scale:** Building internally allowed Figma to optimize the system for its infrastructure and adapt it as the company grows. ## Pipeline Components The bespoke system combines several lower-level technologies: - **Snapshots:** Amazon RDS exports initial table copies to S3. - **Change data capture:** Kafka Connect streams database changes through Amazon MSK. - **Warehouse ingestion:** A Snowflake Connector loads CDC events into Snowflake. - **Incremental merging:** Custom Snowflake stored procedures and scheduled tasks merge changes into base tables. ## Architecture Principles The redesign was guided by four goals: - Reduce end-to-end synchronization latency. - Control costs as data volume increases. - Meet regulatory and compliance requirements. - Preserve data accuracy, completeness, consistency, and trustworthiness. The resulting architecture uses two workflows: a bootstrap workflow for onboarding tables and a validation workflow for checking data correctness. ## Bootstrap Workflow The automated onboarding process includes: - The CDC service begins capturing the new Postgres table and publishes events to a per-table Kafka topic. - Amazon RDS exports the latest database snapshot to S3. - Snowflake’s `COPY INTO <table>` loads the snapshot into a per-entity base table. - An MSK Connect Snowflake Sink Connector streams Kafka events into a separate CDC table, with offsets arranged so changes before the snapshot timestamp are retained. - A scheduled Snowflake task runs a custom `MERGE` procedure to combine the snapshot and CDC data. - Once the process catches up with current changes, Figma creates a lightweight user-facing view over the base table. ## Zero-Downtime Re-Bootstrapping - Bootstrap artifacts are versioned, while the final user-facing view remains stable. - New versions can be built in parallel without interrupting queries. - Promotion is completed through an atomic view update. - This supports schema evolution and other situations requiring a fresh bootstrap without downtime. ## Data Validation - Even well-designed pipelines can suffer corruption from partial failures, configuration errors, software bugs, or unexpected source-data anomalies. - Figma therefore added a validation workflow to verify correctness as data moves through snapshot exports, CDC capture, and incremental merging. Figma’s experience shows that incremental synchronization is a more sustainable alternative to repeated full-table exports. Combining managed infrastructure with custom orchestration can deliver lower latency, better cost control, and stronger operational flexibility than a one-size-fits-all commercial pipeline.

Read original

Amazon Rds PostgreSQL Apache Kafka Amazon S3+4

figmaApr 3, 20233 min readCurated summary

The growing pains of database architecture | Figma Blog

Figma outgrew its single Amazon RDS PostgreSQL database as traffic increased roughly threefold annually, pushing peak CPU utilization above 65% and making latency unpredictable. Initial fixes—larger hardware, read replicas, new databases, and PgBouncer—provided temporary relief but could not adequately reduce write load or handle replication-sensitive reads. Figma ultimately chose vertical partitioning, moving groups of related tables into separate databases as a lower-risk, incremental path to scalability. ## The Limits of a Single Database - Figma stored metadata such as permissions, file information, and comments in one large RDS instance. - Increasing users, new features, and preparation for a second product drove database traffic sharply upward. - Peak CPU utilization reached more than 65%, with latency becoming less predictable as the database approached its limits. - Full saturation would have made Figma unavailable, so the infrastructure team addressed the risk before it became an outage. ## Tactical Measures for More Headroom Figma introduced several short-term improvements: - Upgraded the database from an `r5.12xlarge` to an `r5.24xlarge` instance. - Added multiple read replicas to distribute read traffic. - Created separate databases for new use cases to prevent further growth of the original database. - Added PgBouncer to pool connections and reduce the impact of thousands of application connections. - These changes provided approximately another year of runway, but writes still consumed substantial resources. - Some reads could not be moved to replicas because the application was sensitive to replication lag. ## Evaluating Horizontal Scaling Figma considered horizontally sharding the database but found substantial technical and operational risks: - Many managed horizontally scalable databases were not natively compatible with PostgreSQL. - Migrating to NoSQL or Vitess would require complex double-read and double-write migration strategies. - NoSQL would also require significant application changes. - A managed distributed PostgreSQL system could make Figma an unusually large customer, exposing it to untested scaling limits. - Self-hosting would require new expertise, training, and considerable operational investment, diverting attention from the core scalability problem. ## Choosing Vertical Partitioning Instead of splitting individual tables across many database nodes, Figma chose vertical partitioning: - Groups of related tables would be moved to separate databases. - This approach immediately reduced load on the original database. - It preserved a future path toward horizontal sharding for particularly large or demanding table groups. - The strategy was considered more incremental and operationally manageable than replacing PostgreSQL or adopting a self-hosted distributed system. ## Selecting Tables to Move Figma evaluated candidate tables using two criteria: - **Impact:** Moving the tables should remove a meaningful portion of the database workload. - **Isolation:** The tables should have limited dependency on tables that remained in the original database. - To measure impact, the team analyzed average active sessions (AAS), which estimates the average number of active threads handling a query. - They gathered query activity from PostgreSQL’s `pg_stat_activity` view at 10-millisecond intervals to identify CPU waits associated with individual queries. Figma’s experience shows that database scaling does not always require an immediate move to distributed infrastructure. Carefully selected vertical partitioning can reduce pressure on a primary database while limiting migration risk and preserving more ambitious scaling options for the future.

Read original

Amazon Rds PostgreSQL Database Sharding Pgbouncer+3

figmaJan 28, 20203 min readCurated summary

Postmortem: Service disruption on January 21-22, 2020 | Figma Blog

Figma’s January 21–22, 2020 outages were caused by separate database failures that compounded one another. A long-running query triggered the first incident and created a vacuuming backlog; the next day, PostgreSQL 9 produced a severely mis-planned query after database statistics changed, while aggressive autovacuuming increased write and lock pressure. Upgrading to PostgreSQL 11 restored stability and addressed both the query-planning and autovacuum performance issues. ## Incident Timeline ### January 21: Long-Running Query - Automated alerts reported elevated error rates at 6:11 AM PST. - Engineers found an expensive, long-running database query driving CPU usage. - Canceling the query at 6:54 AM restored normal performance. - The terminated query left behind a backlog of data requiring vacuuming. ### January 22: Database Saturation - Increased write IOPS and lock contention appeared, despite database CPU being below normal. - Queued API requests eventually made Figma unavailable to some users. - Engineers canceled nonessential queries and increased allocated IOPS, providing only temporary relief. - Performance deteriorated again in the afternoon. - Restarting the database temporarily disabled a suspected background process. - Figma performed an emergency upgrade from PostgreSQL 9 to PostgreSQL 11. - The service returned online at 8:15 PM, with metrics back to normal. ## Aggressive Autovacuuming - The vacuuming backlog crossed the threshold for PostgreSQL’s more aggressive transaction-ID wraparound protection. - This mode generated substantial locking and write activity, particularly in the PostgreSQL version Figma was using. - Canceling autovacuum operations on large tables temporarily improved metrics, but the operations resumed. - Fully suppressing the aggressive behavior required changing `autovacuum_freeze_max_age` and rebooting the database. - Autovacuum was a significant contributor, but disabling it did not eliminate all performance problems. ## PostgreSQL Query Planner Failure - A complex query repeatedly appeared in lock-contention reports. - PostgreSQL estimated that the query would return more than 20 million rows, while the actual result contained only three. - The incorrect plan used full table scans instead of expected indexes. - It also wrote large amounts of data to temporary buffers, matching the observed increases in write IOPS and temporary-byte metrics. - The issue was likely caused by inaccurate statistics or a PostgreSQL planner defect or limitation following a routine statistics change. ## Upgrade and Preventive Measures - PostgreSQL 11 generated a substantially better plan for the problematic query. - Newer PostgreSQL versions improve autovacuum performance and query planning. - PostgreSQL 10+ also provides more advanced performance-analysis tools through Amazon RDS. - Figma had already tested the PostgreSQL 11 upgrade in staging and prepared a detailed production rollout plan, allowing the emergency upgrade to succeed safely. - The company planned to improve monitoring for expensive queries and impose stricter limits on query execution time. Figma concluded that upgrading PostgreSQL, improving query monitoring, and enforcing tighter runtime limits were necessary to prevent similar database-driven outages.

Read original

Amazon Rds PostgreSQL Database Monitoring Query Optimization+2