Great question—this is a super common point of confusion when you’re getting started with Amazon Aurora, so let’s break it down in plain terms!

First, let’s align with what you noticed during setup: when you create your first Aurora environment, you’re actually spinning up two core components at once: a Database Cluster and an initial Database Instance (the writer node). If you later create a totally separate Aurora setup, you’ll need unique names for both the new cluster and new instance—neither can reuse names from your first setup. Now, here’s what each component does, and how they differ:

Database Cluster: The Central Shared Hub #

Think of the cluster as the "backbone" of your Aurora setup. It’s the top-level container that manages all the shared resources every instance in the setup uses:

• Shared Replicated Storage: All instances in the cluster attach to the same underlying storage volume, which Aurora automatically replicates across multiple Availability Zones (AZs) for high availability and durability. Any write made by the writer instance is instantly available to all reader instances via this shared storage.
• Endpoints: The cluster provides three key endpoints to simplify access:
  • A cluster endpoint that always points to the current writer instance (so your app doesn’t have to track which node is handling writes)
  • A reader endpoint that load-balances read traffic across all reader instances
  • Individual instance endpoints if you need to target a specific node directly
• Cluster-Wide Settings: Things like engine version, backup retention policies, encryption configuration, and network access rules are all managed at the cluster level.

Cluster names are unique across your AWS account and region—you can’t create two clusters with the same name, since it’s the primary identifier for that entire set of Aurora resources.

Database Instance: The Compute Workhorse #

An instance is the actual compute server (with CPU, memory, and network capacity) that runs the Aurora database engine. Each instance belongs to exactly one cluster, and there are two types:

• Writer Instance: Handles all write operations (INSERT, UPDATE, DELETE) and manages replicating those changes to the shared storage. Only one writer can exist per cluster at a time (if it fails, Aurora automatically promotes a reader instance to take its place).
• Reader Instances: Handle read-only queries (SELECT) to offload traffic from the writer. You can add multiple reader instances to scale out your read capacity, and they also act as failover targets for the writer.

Each instance has its own unique name (across your account/region)—you can’t have two instances (even in different clusters) with the same name. When you create your first setup, you’re naming this initial writer instance; if you add more instances to the same cluster later, you’ll name those too (they just need to be unique within your account/region).

A Quick Note on Database Names #

As you mentioned, specifying a Database name during setup is optional. If you do provide one, Aurora automatically creates that database within the cluster’s instances. If you skip it, you’ll need to connect to the instance later and run SQL commands like CREATE DATABASE my_custom_db; to create your databases manually.

Key Difference Recap #

To wrap it up:

• Cluster = Shared Storage + Management: It’s the centralized layer that holds your data and controls how instances access it.
• Instance = Compute Power: It’s the server that runs queries, with roles split between writing and reading.
• Relationship: One cluster can have multiple instances, but each instance belongs to exactly one cluster.
• Naming: Both cluster and instance names must be unique across your AWS account/region—no duplicates allowed, even across separate setups.

内容的提问来源于stack exchange，提问作者Vinícius Queiroz