6.70 How to create an AURORA database

In this lab we create an Amazon Aurora database from the AWS console. Open RDS, click Create database and pick Standard create for full visibility. Engine: Amazon Aurora, with MySQL compatibility. Choose a version — for example MySQL 5.6.10a — and the deployment scope: regional (cluster in one region) or global for cross-region. We keep regional for this lab.

Cluster configuration

  • Capacity type: provisioned with one writer and one or more readers (vs serverless).
  • Template: production (or DR), and a cluster identifier.
  • Credentials: master user and password (e.g. 8-character mixed-case).
  • Instance class: memory-optimized (db.r5.large+) for production, or a burstable db.t3.small for the cheapest learning instance.
  • Multi-AZ: create one writer in primary AZ and one reader in another AZ; failover is automatic.
  • Network: default VPC, default security group, public access only for testing.
  • Database name: e.g. my_aurora_db.
  • Encryption: enabled with the default KMS key.
  • Backtrack: optional; lets you rewind the cluster in time without restoring a snapshot.

Creation takes several minutes. Once done, the console shows two endpoints: a writer endpoint pointing to the primary instance for writes, and a reader endpoint that load-balances queries across read replicas. You can add a read replica with auto scaling: in Actions > Add reader auto-scaling, define minimum and maximum number of replicas (e.g. 1 to 15), and a scale-out condition such as average CPU above 60%.

To clean up, terminate any extra reader instance first, then go to the cluster and disable deletion protection. After applying the change, choose Delete cluster. RDS asks if you want a final snapshot — skip it for the lab, acknowledge the data loss, type the confirmation phrase, and submit. The Aurora cluster and its instances are deleted within a few minutes. You now know how to create, scale, and terminate an Aurora cluster end-to-end.

Summary

This lesson walks through creating an AWS Aurora database from the RDS console, covering both provisioned and serverless deployment options. It details selecting the database engine (MySQL or PostgreSQL compatibility), instance type sizing, multi-AZ replication strategy for high availability, and essential configuration options like backup retention, encryption, and monitoring settings. The tutorial demonstrates best practices such as keeping databases private within a VPC and configuring automatic failover across availability zones.

Key points

  • Aurora offers two creation methods: standard (full control) and simplified path (pre-configured); choose between MySQL and PostgreSQL engine compatibility
  • Two deployment options exist: provisioned (specify instance type and replicas) and serverless (automatic scaling based on demand)
  • High availability setup includes a primary region with master instance and secondary read replicas across multiple availability zones for automatic failover
  • Instance class selection ranges from memory-optimized to cost-effective small instances (e.g., db.t2.small); storage can be auto-scaling
  • Critical configuration includes VPC assignment, security groups, backup retention policies, encryption with KMS keys, and Enhanced Monitoring for performance insights
  • Multi-AZ deployment ensures if primary region fails, a secondary replica automatically promotes to master across other availability zones

FAQ

What is the difference between provisioned and serverless Aurora deployments?

Provisioned requires you to specify instance type, size, and number of replicas—better for predictable workloads. Serverless automatically scales resources based on demand without manual specification—better for variable workloads where you don't want to manage capacity.

How does Aurora ensure data availability if a region fails?

Aurora uses multi-AZ architecture with a primary master instance and secondary read replicas across different availability zones. If the primary fails, a secondary replica is automatically promoted to master, and a new replica is created in another zone—ensuring zero downtime.

What are best practices for security and access to Aurora databases?

Databases should remain private within your VPC and not be publicly accessible. Use security groups to restrict access only from necessary services, enable encryption at rest with KMS keys, and configure automated backups with appropriate retention policies. Enable Enhanced Monitoring to track performance.