India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Amazon RDS, Aurora & DynamoDB Managed Database Services
Amazon RDS and Amazon Aurora are AWS's managed relational database services that handle provisioning, patching, backups and Multi-AZ failover, while Amazon DynamoDB is a serverless key-value and document database. NTSPL migrates Indian firms off self-managed Oracle and SQL Server onto Aurora PostgreSQL or RDS using AWS DMS and Schema Conversion, and models DynamoDB tables for high-concurrency transactional workloads.
AWS services in scope
The Problem Amazon Aurora (PostgreSQL-Compatible and MySQL-Compatible) and Amazon RDS (PostgreSQL, MySQL, MariaDB, Oracle, SQL Server, Db2) Solve
The database is usually the reason a migration stalls. Applications move to EC2 in weeks, but a 3 TB Oracle schema with 1,400 PL/SQL packages, an Enterprise Edition licence renewal due in eight months and a recovery time objective nobody has tested keeps the core system on a two-node RAC in the data centre. Elsewhere, teams put high-write workloads such as inventory counters on a relational engine and spend weekends tuning lock contention. The engineering problem is choosing the right engine per access pattern and moving data with near-zero downtime.
NTSPL sizes from real wait events and AWR or Query Store data, not from current hardware. We run DMS Schema Conversion or AWS SCT to score code conversion effort, decide between Aurora, RDS and DynamoDB per workload, and use AWS DMS full load plus change data capture so cutover is a short, rehearsed switch. Failover is tested before go-live, and RDS Proxy, Performance Insights and parameter groups are part of the build, not a later phase.
When to Move Databases to Amazon RDS, Aurora or DynamoDB (and When Not To)
Signals that point to managed databases on AWS
- Your Oracle or SQL Server Enterprise Edition renewal is due within 12 months and less than 20% of features in use are Enterprise-only.
- A failover test of your current database has never been run, or took longer than 15 minutes.
- Database administrators spend more than a day a month on patching, backups and storage expansion.
- Read traffic on the primary exceeds 70% of queries and reporting jobs slow down the transactional system.
- Row-lock waits or deadlocks spike when concurrent users update the same inventory, counters or balances.
- Storage on the database server crosses 80% and the SAN upgrade needs downtime.
When a different approach is better
- Large analytical queries scanning terabytes for dashboards belong in Amazon Redshift or Amazon Athena on S3, not on an Aurora or RDS writer.
- Workloads with unpredictable ad hoc queries, many-table joins and evolving relationships should stay relational on Aurora rather than be forced into DynamoDB.
- Full-text and relevance search across catalogues or documents is better served by Amazon OpenSearch Service than by LIKE queries on RDS.
AWS Database Building Blocks: Aurora Clusters, RDS Engines, DynamoDB Tables, RDS Proxy and DMS
| Service | Role in the architecture | Choose it when |
|---|---|---|
| Amazon Aurora (PostgreSQL-Compatible and MySQL-Compatible) | Runs PostgreSQL- or MySQL-compatible engines on a distributed storage layer that keeps six copies of data across three Availability Zones, with up to 15 low-lag read replicas and fast failover. | A business-critical OLTP database needs sub-minute failover, read scaling and storage that grows automatically without re-provisioning. |
| Amazon RDS (PostgreSQL, MySQL, MariaDB, Oracle, SQL Server, Db2) | Manages a single-primary database engine on EC2-class instances with automated backups, point-in-time restore and Multi-AZ standby replicas. | You need a specific commercial engine such as SQL Server or Oracle with licence-included or BYOL options, or a standard open-source engine without Aurora's pricing model. |
| Amazon DynamoDB | Provides a fully managed key-value and document database with single-digit millisecond reads and writes at any scale, ACID transactions, conditional writes, streams and global tables. | Access patterns are known and keyed, such as inventory by property and date or sessions by user, and request volume is highly variable. |
| Amazon ElastiCache (Valkey, Redis OSS, Memcached) | Caches hot reads and holds ephemeral data such as rate-limit counters and search results in memory in front of the primary database. | The same queries are repeated thousands of times a minute, or read replicas are being added only to absorb repetitive reads. |
| AWS Database Migration Service (DMS) and DMS Schema Conversion | Copies data from source databases with full load and ongoing change data capture, and converts schemas and code objects between engines, with AWS SCT available for complex conversions. | Moving a live database to AWS or between engines with a cutover window of minutes rather than hours. |
| Amazon RDS Proxy | Pools and multiplexes application connections to RDS and Aurora, and shortens failover impact by holding client connections while the writer changes. | Applications open many short-lived connections, such as Lambda functions or PHP and Java pools that exhaust max_connections. |
Multi-AZ Aurora cluster with RDS Proxy, cache tier and DMS migration path
Multi-AZ Aurora cluster with RDS Proxy, cache tier and DMS migration path
Application servers connect through RDS Proxy to the Aurora cluster writer endpoint for transactions and to the reader endpoint for queries, with ElastiCache absorbing repeated reads and DynamoDB serving keyed high-concurrency data. During migration, AWS DMS reads change data capture from the on-premises source over Direct Connect or VPN and applies it to Aurora until cutover, after which backups, snapshots and an Aurora Global Database or cross-Region snapshot copy protect the data in Hyderabad.
Select any component
Multi-AZ Aurora cluster with RDS Proxy, cache tier and DMS migration path: click any of its 10 components to see its role and the design choice NTSPL makes for it, or trace the 5-step primary path.
Database Engineering Decisions: Engine Choice, Code Conversion, Failover Design and DynamoDB Keys
Aurora vs RDS vs DynamoDB per workload
Aurora is our default for business-critical PostgreSQL or MySQL OLTP because storage replication, sub-minute failover and fast replicas come built in. RDS fits commercial engines, small databases where Aurora's minimum footprint is overkill, and teams needing a specific engine version or extension Aurora does not offer. DynamoDB is chosen only when every access pattern can be written down as a key lookup or range query before build; if the team cannot list them, it stays relational.
Oracle and SQL Server code conversion
We run DMS Schema Conversion or AWS SCT first and read its assessment by object type. Tables, indexes and simple procedures convert largely automatically; autonomous transactions, DBMS_ packages, hierarchical CONNECT BY queries and CLR objects need manual work. When conversion effort for a SQL Server application is too high, Babelfish for Aurora PostgreSQL or RDS for SQL Server are the fallbacks. Effort estimates come from object counts, not guesses.
Failover and high availability design
For Aurora we place at least one reader in a different Availability Zone from the writer at the same instance class, so failover does not land on an undersized node. For RDS we choose Multi-AZ instance deployment or, for MySQL and PostgreSQL, Multi-AZ DB clusters with two readable standbys. Applications must reconnect on DNS change; RDS Proxy or AWS JDBC Driver failover support cuts reconnection time. Every design is proven with a forced failover before go-live.
DynamoDB key and capacity design
Partition keys must spread writes; a key such as date alone creates hot partitions on busy days. We combine entity and identifier, for example PROPERTY#id with sort key DATE#yyyy-mm-dd#ROOMTYPE, and add GSIs only for listed queries. On-demand capacity suits new or spiky tables; provisioned capacity with auto scaling and reserved capacity suits steady tables. Conditional expressions and TransactWriteItems enforce business rules without locks.
Cutover strategy with DMS CDC
We separate full load from cutover: DMS loads the bulk over days, then CDC keeps the target within seconds of the source. Validation tasks compare data, sequences are reset, and triggers and foreign keys are enabled after load. Cutover is a rehearsed sequence of stopping writes, waiting for CDC lag to reach zero, switching connection strings and opening traffic, typically completed within a 30-60 minute window.
How NTSPL Migrates a Production Database to Aurora or RDS with DMS
Workload capture and licence audit
Collect AWR, Statspack or Query Store data, peak IOPS and connection counts, and map Enterprise Edition features actually used against the licence contract.
Schema conversion assessment
Run DMS Schema Conversion or AWS SCT against the source, convert automatically where possible and log every object needing manual rewrite.
Target cluster build
Provision the Aurora or RDS cluster, parameter groups, RDS Proxy, Secrets Manager rotation and Performance Insights through infrastructure code.
DMS full load and CDC
Load data through DMS with validation enabled, then keep CDC running while application teams test against the target.
Failover and performance rehearsal
Force a writer failover under load, replay top queries and compare plan and latency with the source before booking cutover.
Cutover and reverse replication
Switch traffic in a short freeze and, where risk is high, run reverse CDC back to the source for a defined rollback window.
What you receive
Securing Managed Databases: Secrets Rotation, IAM Authentication, KMS and Network Isolation
Managed databases hold the most regulated data in the estate, so the threats that matter are leaked credentials, over-broad network paths and unencrypted snapshots shared by mistake. NTSPL keeps clusters in private subnets with security groups that accept only the application and proxy groups, rotates credentials through Secrets Manager, encrypts clusters and snapshots with customer managed KMS keys, and enables audit logging aligned to RBI and IRDAI expectations where the client is regulated.
- Secrets Manager managed rotation for master and application credentials, removing passwords from code
- IAM database authentication for administrators so access is tied to identities and logged in CloudTrail
- Encryption at rest with customer managed KMS keys, which also encrypts automated backups, replicas and snapshots
- Database activity streams or engine audit logs (pgaudit, SQL Server audit) exported to CloudWatch Logs for review
- DynamoDB fine-grained access with IAM condition keys on partition key values for multi-tenant tables
RDS and Aurora Pricing Levers: Instance Classes, I/O-Optimized Storage, Licensing and Reserved Instances
RDS and Aurora bill on instance hours, storage GB-month, backup storage beyond the free allowance and, for Aurora Standard, I/O requests; Aurora I/O-Optimized removes I/O charges for a higher instance and storage rate. Commercial engines add licence cost through licence-included pricing or BYOL. DynamoDB bills on read and write request units or provisioned capacity, plus storage. Right engine, right class and right licence model matter more than tuning.
- Reserved Instances for RDS and Aurora instances that run around the clock
- Aurora I/O-Optimized when I/O exceeds about a quarter of Aurora spend
- Graviton-based database instance classes such as r7g and r8g for supported engines
- Moving from Oracle or SQL Server Enterprise to Aurora PostgreSQL or Standard Edition to remove licence cost
- DynamoDB provisioned capacity with reserved capacity for steady tables, on-demand for spiky ones
Amazon Aurora vs RDS for PostgreSQL vs DynamoDB: which database should I choose?
Use three criteria. Data model: if queries join many tables, change over time or need SQL reporting, choose a relational engine; if every query is a known key lookup at very high concurrency, choose DynamoDB. Availability and scale: Aurora gives faster failover, up to 15 replicas and auto-growing storage, so pick it for business-critical OLTP; RDS for PostgreSQL is cheaper and simpler for smaller or less critical databases and supports some extensions and versions Aurora may not. Cost shape: RDS is usually lower for small, steady databases; Aurora becomes competitive at scale, especially with I/O-Optimized for I/O-heavy workloads; DynamoDB on-demand is cheapest when traffic is spiky and unpredictable. Many estates run all three side by side.
Key facts about managed databases on AWS
Managed Databases on AWS in Practice
3 managed databases scenarios from Financial services (NBFC, retail and MSME lending), Travel and hospitality technology, Pharmaceutical distribution: the starting position, the services chosen, the architecture, the rollout and the measured outcome.
NBFC moves loan-origination Oracle database to Aurora PostgreSQL and drops EE licences
Hotel booking engine ends overbooking with DynamoDB conditional writes on room inventory
Pharma distributor runs SQL Server ERP on RDS Multi-AZ and cuts DB recovery to minutes
Specialty chemicals group links 6 plants and HQ to AWS with dual-path hybrid network
Mobile gaming studio handles 6x tournament match-making spikes on EKS with Spot nodes
Cold-chain operator cuts temperature-excursion response from hours to 4 minutes
State grievance portal handles 8x deadline-day traffic and tracks every case end-to-end
Managed Databases on AWS: Frequently Asked Questions
How is Amazon Aurora priced compared with RDS?
Both charge per instance hour and per GB of storage. Aurora Standard also charges per million I/O requests, while Aurora I/O-Optimized has no I/O charge but higher instance and storage rates. RDS charges for provisioned storage and, on io1 or io2, provisioned IOPS. We compare a month of real CloudWatch metrics across options before recommending one.
Can we migrate our Oracle database without long downtime?
Yes. AWS DMS performs a full load while the source stays live, then replicates ongoing changes through change data capture, so the target stays seconds behind. Cutover is a short, rehearsed freeze to drain changes and switch connections, usually 30-60 minutes. Schema and PL/SQL conversion is the longer effort and is done and tested before data moves.
Do we still need DBAs after moving to RDS or Aurora?
Yes, but their work changes. AWS handles hardware, OS and engine patching, backups and failover mechanics. Your DBAs or NTSPL's managed service still own schema design, query tuning, index strategy, capacity planning and access reviews. Performance Insights makes that tuning faster because top SQL and wait events are visible without extra tooling.
Can our RBI-regulated NBFC host its loan database on AWS in India?
Yes, regulated entities can use cloud services provided they meet RBI's directions on IT outsourcing and IT governance, including due diligence, data access for the regulator and audit rights. Hosting Aurora or RDS in Asia Pacific (Mumbai) with backups in Asia Pacific (Hyderabad) keeps data in India. NTSPL maps controls to these requirements, but your compliance team owns the final assessment.
When should we not use DynamoDB?
Avoid DynamoDB when you cannot list your access patterns up front, when users need ad hoc reporting across many attributes, or when relationships between entities change often. Those needs suit Aurora or RDS. DynamoDB shines for keyed lookups, counters and session or inventory data with unpredictable spikes.
How long does Aurora failover take?
Aurora typically completes failover to a replica in well under a minute, often around 30 seconds, because replicas share the same storage volume and do not need to replay data. Application reconnection adds time unless you use RDS Proxy or failover-aware drivers. We measure end-to-end recovery in a forced failover test before go-live.