Aurora DB, Hands-on: twtech Use Cases.

 

twtech-insights

Amazon Aurora is a fully managed relational database engine offered by AWS, designed for high performance and availability at global scale. It is compatible with MySQL and PostgreSQL, making it easy to migrate existing applications.

 Key Features of Amazon Aurora

1. High Performance & Scalability:
• Up to 5x performance over MySQL and 3x over PostgreSQL.
• Supports autoscaling read replicas (up to 15).
• Aurora Serverless provides auto-scaling based on demand.
2. High Availability & Durability:
• Data is replicated across 3 Availability Zones (AZs).
• Fault-tolerant and self-healing storage.
• Automated backups, snapshots, and point-in-time recovery.
3. Compatibility:
• Drop-in replacement for MySQL and PostgreSQL.
• Enables easy migration using AWS Database Migration Service (DMS).
4. Security:
• Data encrypted at rest and in transit using AWS Key Management Service (KMS).
• Integration with IAM, VPC, and CloudTrail.
5. Global Database:
• Supports multi-region replication with sub-second latency.
6. Monitoring & Management:
• Integrated with Amazon CloudWatch, AWS CloudTrail, and Performance Insights.

 Aurora Cluster Architecture

An Aurora cluster includes:

• One primary instance (read/write).
• Zero or more replicas (read-only).
• Shared distributed storage volume automatically replicated across 3 AZs.

There are two deployment modes:

1. Aurora Provisioned – Traditional setup with fixed capacity.
2. Aurora Serverless v2 – Auto-scaling version for variable workloads.

Benefits of Amazon Aurora

• Cost-effective compared to commercial DBs like Oracle.
• Reduced operational overhead with automated management.
• High throughput, low latency, ideal for enterprise applications.
• Seamless scalability (compute and storage scale independently).
• Strong disaster recovery with regional and global failover options.

 Limitations of Amazon Aurora

• Proprietary to AWS – Vendor lock-in.
• Limited customization compared to self-managed databases.
• Higher cost than RDS for small workloads.
• Feature parity gaps between MySQL and PostgreSQL compatibility modes.

twtech Common Use Cases

1. Enterprise Applications:
• ERP, CRM, and financial systems requiring strong consistency and performance.
2. Web and Mobile Backends:
• High traffic applications needing auto-scaling (Serverless Aurora).
3. SaaS Applications:
• Multi-tenant applications with scalability and global reach.
4. Analytics and Reporting:
• With read replicas for heavy read workloads.
5. Disaster Recovery Solutions:

                *  Global databases with cross-region replication.

Writer Endpoint Vs. Reader Endpoint in the Aurora DB Cluster:

In an Amazon Aurora DB cluster, the concepts of writer endpoint and reader endpoint are essential for managing how your application connects to the database for read and write operations.

 Writer Endpoint vs Reader Endpoint

Feature	Writer Endpoint	Reader Endpoint
Purpose	Handles read and write operations	Handles read-only operations
Points To	The primary instance in the Aurora cluster	A load-balanced group of Aurora Replicas
Connection Type	Read/write (DML & DDL)	Read-only (SELECT queries)
Failover Behavior	Automatically redirects to the new writer during failover	Automatically updates to reflect current healthy replicas
Endpoint Example	twtechdb-cluster.cluster-xyz.us-east-2.rds.amazonaws.com	twtechdb-cluster.cluster-ro-xyz.us-east-2.rds.amazonaws.com
Use Case	App logic that writes to the DB: INSERT, UPDATE, DELETE	Reporting, analytics, or distributed read scaling

 How They Work in Practice

• Writer Endpoint:
• Connects your application to the primary instance.
• Should be used for any database operation that modifies data.
• During a failover, Aurora promotes a replica to become the new writer, and the writer endpoint automatically updates to point to it.
• Reader Endpoint:
• Load balances across all available Aurora Replicas.
• Useful for scaling read traffic without overloading the primary instance.
• Can improve performance by splitting read/write operations in twtech application logic.

Best Practice

• Use the writer endpoint for:
• Transactions
• Writes and updates
• DDL statements (e.g., ALTER, CREATE)
• Use the reader endpoint for:
• Reporting/BI tools
• Analytics dashboards
• Read-heavy API endpoints

Project: Hands-on

How twtech creates and use AWS Aurora database.

Search the aws service: aurora and rds

Create a database: Aurora

Choose a database creation method: Standard create

Select the engine option (type): Aurora (MySQL Compactible)

Select a version: twtech keeps the default version as proposed by

Select a template: to meet twtech use case: 

Settings

DB cluster identifier: twtech-aurora-db

Enter a name for your DB cluster. The name must be unique across all DB clusters owned by your AWS account in the current AWS Region.:

Name: twtech-aurora-db-cluster

Add master username:twtechpat

For credential management, select: self managed

Enter a strong master password: twtechsuperadminpassword@9876543210

 And

Confirm the strong master password: twtechsuperadminpassword@9876543210

Select storage configuration:

Choose the storage configuration for the Aurora DB cluster that best fits your application’s price predictability and price performance needs.

Configuration options

Database instance, storage, and I/O charges vary depending on the configuration. 

Select: Aurora Standard (for cost optimization.)

Instance configuration: twtech selects the class of instance prefered

The DB instance configuration options below are limited to those supported by the engine that you selected above.

DB instance class  (Burstable classes, includes t classes): db.t3.medium

Configure Availability & durability

Multi-AZ deploymen

Connectivity

Select the vpc and subnets: 

Configure whether to have public access for: Yes (to use UI)

VPC security group (firewall)

Choose one or more VPC security groups to allow access to your database. Make sure that the security group rules allow the appropriate incoming traffic.

Create a new Security group to allow access to the aurora database via UI: twtech-aurora-db-SG

After creating the database, remember to go to the security group and add an inbound rule that allows traffic to custom port 3306 from IPv4 anywhere.

Configure Monitoring

Configure the original name to be used to access the database in the public: twtechauroradb

Backup

twtech Backup retention period:  1day

The number of days (1-35) for which automatic backups are kept.

It is okay to have database Encryption: twtech can use the default aws encryption key

Configure maintenance to enable:

Automatic version upgrades, no preferred period for maintenance and enable deletion protection for any attempts to accidentally delete the aurora-db: twtech-aurora-db

Review the estimated monthly cost and create the database:

From:

How aurora-db connects: with 2 endpoints created (reader-endpoint and writer-endpoint)

Eventaully, the aurora-db-cluster is fully created: twtech-arurora-db-cluster

(1 master instance and 2 other instances)

In order to access the database on UI, twtech needs to edit the securitiy group: twtech-aurora-db-SG

From:

To: save changes

With the twtech-aurora-db-cluster created, more Actions can be made like:

How twtech creates auto scaling policy for aurora database:

Add Auto Scaling policy:

Policy details

Policy name : twtechReadReplicaScaling

A name for the policy used to identify it in the console, CLI, API, notifications, and events.

Cluster capacity details

Configure the minimum and maximum number of Aurora Replicas you want Aurora Auto Scaling to maintain.

How twtech adds the aurora database to other regions: from us-east-2(Ohio) to us-east-1(N-Virginia)

Instance size needs to be changed from t2.mirco to handle large regional databases:  c7a.xlarge

How techech deletes unwanted aws aurora-databases:

When instance is permanently deleted, we delete the other instances and eventually the master instance.

Remember to modify database settings that prevents deletion : untenable deletion protection:

From:

To:

Modify the changes immediately: to effect immediate changes

Select the instances attached to the master instance and delelte:  first

Eventually, delete the master instance uncheck:  create final snapshot

From:

Acknowledge  to permanently delete the databa