AWS prescriptive-guidance documentation change
Summary
Updated image paths, merged paragraphs about prefix-label strategy drawbacks, fixed a typo in calculation (removed backslash), and reordered image/caption placement.
Security assessment
While the existing text mentions preventing data leakage, these changes don't alter that security guidance. The modifications are structural (image paths, paragraph merging) and typo fixes. No new security content is added, and no vulnerabilities are addressed.
Diff
diff --git a/prescriptive-guidance/latest/multi-tenancy-amazon-neptune/pool-model-lpg.md b/prescriptive-guidance/latest/multi-tenancy-amazon-neptune/pool-model-lpg.md index 95b51340d..aab37b356 100644 --- a//prescriptive-guidance/latest/multi-tenancy-amazon-neptune/pool-model-lpg.md +++ b//prescriptive-guidance/latest/multi-tenancy-amazon-neptune/pool-model-lpg.md @@ -28 +28 @@ The following diagram shows this model. The two disconnected subgraphs have vari - + @@ -98 +98 @@ In the prefix-label strategy, you label each node with a combination of tenant i - + @@ -124,3 +124 @@ The prefix-label strategy assumes that all nodes are assigned to one or more ten -There are two primary drawbacks to the prefix label approach. First, it's difficult to run any queries that span across tenants. An example is a query that counts all nodes of a given label for reporting or monitoring. If this is your use case, consider combining this strategy with the multiple-label strategy. For more information about combining strategies, see the [Hybrid model](./hybrid-model.html) section. - -Second, the prefix-label strategy requires controls that enforce proper application of the appropriate prefix to every query to prevent data leakage. However, this strategy is the most efficient option for workloads that require low latency queries, and we highly recommend it. The Performance implications for LPG models section provides examples of why this is the most efficient strategy. +There are two primary drawbacks to the prefix label approach. First, it's difficult to run any queries that span across tenants. An example is a query that counts all nodes of a given label for reporting or monitoring. If this is your use case, consider combining this strategy with the multiple-label strategy. For more information about combining strategies, see the [Hybrid model](./hybrid-model.html) section. Second, the prefix-label strategy requires controls that enforce proper application of the appropriate prefix to every query to prevent data leakage. However, this strategy is the most efficient option for workloads that require low latency queries, and we highly recommend it. The Performance implications for LPG models section provides examples of why this is the most efficient strategy. @@ -132 +130 @@ The third option is to use a multiple-label strategy. For this approach, you add -You can now access the graph by using three different patterns: + @@ -134 +132 @@ You can now access the graph by using three different patterns: - +You can now access the graph by using three different patterns: @@ -216 +214 @@ Run a query that will retrieve the items for Tenant 3 by using the property stra - * Where `label = Item` has 12 million results (10 million from T1 \+ 1 million from T2 + 1 million from T3) + * Where `label = Item` has 12 million results (10 million from T1 + 1 million from T2 + 1 million from T3)