Simple Notification Service (SNS)
Kinesis + MQ
Databases & Analytics
Aurora
  • Aurora is a fully managed relational database engine that's compatible with MySQL and PostgreSQL.
  • With some workloads, Aurora can deliver up to five times the throughput of MySQL and up to three times the throughput of PostgreSQL.
  • The underlying storage grows automatically as needed.
    • An Aurora cluster volume can grow to a maximum size of 128 tebibytes (TiB).
  • Aurora also automates and standardizes database clustering and replication.

High Availability

  • Aurora automatically divides your database volume into 10GB segments spread across many disks.
    • Each 10GB chunk of your database volume is replicated six ways, across three Availability Zones.
    ​
  • It can handle the loss of up to two copies of data without affecting write availability.
  • It can handle the loss up to three copies without affecting read availability.
  • Amazon Aurora storage is also self-healing.
    • Data blocks and disks are continuously scanned for errors and repaired automatically.
    ​
  • You can create 1 to 15 replicas, in any of 3 AZs, and Amazon RDS will automatically include them in failover primary selection in the event of a database outage.

Global Database

  • An Aurora global database consists of one primary AWS Region where your data is maintained, and up to five read-only, secondary AWS Regions.
    • Aurora replicates data to the secondary AWS Regions with typical latency of under a second.
    ​
  • You issue write operations directly to the primary DB instance in the primary AWS Region.
    ​
  • An Aurora global database uses dedicated infrastructure to replicate your data, leaving database resources available entirely to serve application workloads.
  • The Aurora cluster in the primary AWS Region where your data is mastered performs both read and write operations.
  • The clusters in the secondary Regions enable low-latency reads.
  • You can scale up the secondary clusters independently by adding one of more DB instances (Aurora Replicas) to serve read-only workloads.

Aurora Endpoints

  • Aurora typically involves a cluster of DB instances instead of a single instance.
  • Each connection is handled by a specific DB instance.
  • When you connect to an Aurora cluster, the host name and port that you specify point to an intermediate handler called an endpoint.
  • Aurora uses the endpoint mechanism to abstract these connections.
  • An endpoint is represented as an Aurora-specific URL that contains a host address and a port.
  • Cluster endpoint
    • A cluster endpoint (or writer endpoint) for an Aurora DB cluster connects to the current primary DB instance for that DB cluster.
    • This is the only endpoint which can perform write operations such as DDL statements.
    • Because of this, the cluster endpoint is the one that you connect to when you first set up a cluster or when your cluster only contains a single DB instance.
    ​
  • Reader endpoint
    • A reader endpoint for an Aurora DB cluster provides load-balancing support for read-only connections to the DB cluster.
    • Use the reader endpoint for read operations, such as queries.
    • By processing those statements on the read-only Aurora Replicas, this endpoint reduces the overhead on the primary instance.
  • Custom endpoint
    • A custom endpoint for an Aurora cluster represents a set of DB instances that you choose.
    • An Aurora DB cluster has no custom endpoints until you create one.

Aurora Serverless

  • On-demand, autoscaling configuration for Aurora.
  • Unlike Aurora provisioned database clusters for which you manually manage capacity, an Aurora Serverless database cluster is a database cluster that scales compute capacity up and down based on your application's needs.
  • Provides a relatively simple, cost-effective option for infrequent, intermittent, or unpredictable workloads.
    • Cost-effective because it automatically starts up, scales compute capacity to match your application's usage, and shuts down when it's not in use.
  • Instead of provisioning and managing database servers, you specify Aurora capacity units (ACUs).
    • Each ACU is a combination of processing and memory capacity.

Aurora Multi-Master Clusters

  • In a multi-master cluster, all database instances have read/write capability.
  • Writer:
    • A database instance that can perform write operations.
    • With a single-master cluster, if the writer becomes unavailable, the failover mechanism promotes another DB instance to become the new writer.
    ​
  • Multi-master:
    • An architecture for Aurora clusters where each DB instance can perform both read and write operations.
    • Best suited for segmented workloads, such as for multitenant applications.
  • Single-master:
    • Default architecture for Aurora clusters.
    • A single DB instance (the primary instance) performs writes.
    • All other DB instances (the Aurora Replicas) handle read-only query traffic.
    • Appropriate for general-purpose applications.
    ​
  • Write conflict:
    • A situation that occurs when different DB instances attempt to modify the same data page at the same time.
Last modified 11mo ago