AWS prescriptive-guidance documentation change
Summary
Updated documentation links, fixed typographical errors (e.g., apostrophe usage), reformatted comparison tables for readability, and adjusted product name references for consistency.
Security assessment
The changes primarily involve formatting improvements, grammatical corrections, and link updates. No security vulnerabilities, mitigations, or security feature enhancements are mentioned. References to high availability and transactional integrity remain unchanged in substance.
Diff
diff --git a/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/db-selection.md b/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/db-selection.md index 50f0053ff..0d1c78c2b 100644 --- a//prescriptive-guidance/latest/saas-multitenant-managed-postgresql/db-selection.md +++ b//prescriptive-guidance/latest/saas-multitenant-managed-postgresql/db-selection.md @@ -5 +5 @@ -[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Implementing managed PostgreSQL for multi-tenant SaaS applications on AWS](welcome.html) +[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Implementing managed PostgreSQL for multi-tenant SaaS applications on AWS](introduction.html) @@ -26 +26 @@ For many multi-tenant SaaS applications, selecting an operational database can b -The following table lists application data requirements and characteristics, and discusses them in the context of AWS database offerings: Aurora PostgreSQL-Compatible and Amazon RDS for PostgreSQL (relational), and Amazon DynamoDB (non-relational). You can reference this matrix when you’re trying to decide between relational and non-relational operational database offerings. +The following table lists application data requirements and characteristics, and discusses them in the context of AWS database offerings: Aurora PostgreSQL-Compatible and Amazon RDS for PostgreSQL (relational), and Amazon DynamoDB (non-relational). You can reference this matrix when you're trying to decide between relational and non-relational operational database offerings. @@ -28,5 +28,6 @@ The following table lists application data requirements and characteristics, and -**Databases** | **SaaS application data requirements and characteristics** ----|--- -**Data model** | **Access patterns** | **Latency requirements** | **Data and transactional integrity** | **Cross-Region availability and recovery** -**Relational** (Aurora PostgreSQL-Compatible and Amazon RDS for PostgreSQL) | Relational or highly normalized. | Doesn’t have to be thoroughly planned beforehand. | Preferably higher latency tolerance; can achieve lower latencies by default with Aurora and by implementing read replicas, caching, and similar features. | High data and transactional integrity maintained by default. | In Amazon RDS, you can create a read replica for cross-Region scaling and failover. [Aurora mostly automates this process](https://aws.amazon.com/blogs/database/aurora-postgresql-disaster-recovery-solutions-using-amazon-aurora-global-database/). For active-active configurations across multiple AWS Regions, you can use [write forwarding](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-write-forwarding.html) in conjunction with [Aurora global databases](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html). -**Non-relational** (Amazon DynamoDB) | Usually denormalized. These databases take advantage of patterns for modeling [many-to-many relationships](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-adjacency-graphs.html), [large items](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-use-s3-too.html), and [time series data](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-time-series.html). | All access patterns (queries) for data must be thoroughly understood before a data model is produced. | Very low latency with options such as Amazon DynamoDB Accelerator (DAX) able to improve performance even further. | Optional transactional integrity at the cost of performance. Data integrity concerns are shifted to the application. | Easy cross-Region recovery and active-active configuration with global tables. (ACID compliance is achievable only in a single AWS Region.) +The following table shows SaaS application data requirements and characteristics. + +Databases| Data model| Access patterns| Latency requirements| Data and transactional integrity| Cross-Region availability and recovery +---|---|---|---|---|--- +**Relational****(Aurora PostgreSQL-Compatible and Amazon RDS for PostgreSQL)**| Relational or highly normalized.| Doesn't have to be thoroughly planned beforehand.| Preferably higher latency tolerance; can achieve lower latencies by default with Aurora and by implementing read replicas, caching, and similar features.| High data and transactional integrity maintained by default.| In Amazon RDS, you can create a read replica for cross-Region scaling and failover. [Aurora mostly automates this process](https://aws.amazon.com/blogs/database/aurora-postgresql-disaster-recovery-solutions-using-amazon-aurora-global-database/). For active-active configurations across multiple AWS Regions, you can use [write forwarding](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-write-forwarding.html) in conjunction with [Aurora global databases](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html). +**Non-relational****(Amazon DynamoDB)**| Usually denormalized. These databases take advantage of patterns for modeling [many-to-many](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-adjacency-graphs.html) relationships, [large items](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-use-s3-too.html), and [time series data](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-time-series.html).| All access patterns (queries) for data must be thoroughly understood before a data model is produced.| Very low latency with options such as Amazon DynamoDB Accelerator (DAX) able to improve performance even further.| Optional transactional integrity at the cost of performance. Data integrity concerns are shifted to the application.| Easy cross-Region recovery and active-active configuration with global tables. (ACID compliance is achievable only in a single AWS Region.) @@ -36 +37 @@ Some multi-tenant SaaS applications might have unique data models or special cir -The remainder of this guide focuses on AWS relational database services that support PostgreSQL: Amazon RDS and Aurora PostgreSQL-Compatible. DynamoDB requires a different approach to optimize for SaaS applications, which is beyond the scope of this guide. For more information about DynamoDB, see the AWS blog post [Partitioning Pooled Multi-Tenant SaaS Data with Amazon DynamoDB](https://aws.amazon.com/blogs/apn/partitioning-pooled-multi-tenant-saas-data-with-amazon-dynamodb/). +The remainder of this guide focuses on AWS relational database services that support PostgreSQL: Amazon RDS and Amazon Aurora PostgreSQL-Compatible. DynamoDB requires a different approach to optimize for SaaS applications, which is beyond the scope of this guide. For more information about DynamoDB, see the AWS blog post [Partitioning Pooled Multi-Tenant SaaS Data with Amazon DynamoDB](https://aws.amazon.com/blogs/apn/partitioning-pooled-multi-tenant-saas-data-with-amazon-dynamodb/). @@ -42 +43 @@ In most cases, we recommend using Aurora PostgreSQL-Compatible over Amazon RDS f -**DBMS component** | **Amazon RDS for PostgreSQL** | **Aurora PostgreSQL-Compatible** +DBMS component| Amazon RDS for PostgreSQL| Aurora PostgreSQL-Compatible @@ -48 +49 @@ In most cases, we recommend using Aurora PostgreSQL-Compatible over Amazon RDS f -**High availability and disaster recovery** | Two Availability Zones with a standby instance, cross-Region failover to read replica or copied backups | Three Availability Zones by default, cross-Region failover with Aurora global databases, [write forwarding](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-write-forwarding.html) across AWS Regions for active-active configurations +**High availability and disaster recovery**| Two Availability Zones with a standby instance, cross-Region failover to read replica or copied backups| Three Availability Zones by default, cross-Region failover with Aurora global databases,[ write forwarding](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-write-forwarding.html) across AWS Regions for active-active configuration @@ -52 +53 @@ In most cases, we recommend using Aurora PostgreSQL-Compatible over Amazon RDS f -In all the categories described in the previous table, Aurora PostgreSQL-Compatible is usually the better option. However, Amazon RDS for PostgreSQL might still make sense for small to medium workloads, because it has a greater selection of instance classes that might provide a more cost-effective option at the expense of Aurora’s more robust feature set. +In all the categories described in the previous table, Aurora PostgreSQL-Compatible is usually the better option. However, Amazon RDS for PostgreSQL might still make sense for small to medium workloads, because it has a greater selection of instance classes that might provide a more cost-effective option at the expense of Aurora's more robust feature set.