AWS Security ChangesHomeSearch

AWS solutions documentation change

Service: solutions · 2025-02-27 · Documentation low

File: solutions/latest/prebid-server-deployment-on-aws/aws-well-architected-design-considerations.md

Summary

Changed punctuation from en dash (–) to hyphen (-) throughout the document for consistency

Security assessment

The changes are purely stylistic, modifying punctuation marks without altering any security-related content or introducing new security information.

Diff

diff --git a/solutions/latest/prebid-server-deployment-on-aws/aws-well-architected-design-considerations.md
index 1dda22d8a..4db54b193 100644
--- a/solutions/latest/prebid-server-deployment-on-aws/aws-well-architected-design-considerations.md
+++ b/solutions/latest/prebid-server-deployment-on-aws/aws-well-architected-design-considerations.md
@@ -17 +17 @@ This section describes how we architected this solution using the principles and
-**Perform operations as code** – This solution’s infrastructure is entirely specified using CDK v2.0 in Python 3.x and deployed as a CloudFormation template. Application logging and metric workflows are automated with [Amazon EventBridge](https://aws.amazon.com/eventbridge/) and Lambda. 
+**Perform operations as code** \- This solution’s infrastructure is entirely specified using CDK v2.0 in Python 3.x and deployed as a CloudFormation template. Application logging and metric workflows are automated with [Amazon EventBridge](https://aws.amazon.com/eventbridge/) and Lambda.
@@ -19 +19 @@ This section describes how we architected this solution using the principles and
-**Make frequent, small, reversible changes** – This solution is designed to be customized by the end user, if desired. The solution can be forked from the [GitHub repository](https://github.com/aws-solutions/aws-solution-for-prebid-server) into a customer's account, customized, rebuilt, hosted in a customer’s Amazon S3 buckets, and deployed via CloudFormation. This process can be repeated iteratively to test changes to the default solution. 
+**Make frequent, small, reversible changes** \- This solution is designed to be customized by the end user, if desired. The solution can be forked from the [GitHub repository](https://github.com/aws-solutions/aws-solution-for-prebid-server) into a customer’s account, customized, rebuilt, hosted in a customer’s Amazon S3 buckets, and deployed via CloudFormation. This process can be repeated iteratively to test changes to the default solution.
@@ -27 +27 @@ This section describes how we architected this solution using the principles and
-**Implement a strong identity foundation** – All interactions among resources created by the solution are secured using [AWS Identity and Access Management](https://aws.amazon.com/iam/) (IAM) roles, policies, and signature V4 request signing. All credentials used to interact among resources are temporary, and typically have a lifetime of less than one hour. 
+**Implement a strong identity foundation** \- All interactions among resources created by the solution are secured using [AWS Identity and Access Management](https://aws.amazon.com/iam/) (IAM) roles, policies, and signature V4 request signing. All credentials used to interact among resources are temporary, and typically have a lifetime of less than one hour.
@@ -29 +29 @@ This section describes how we architected this solution using the principles and
-**Maintain traceability** – Runtime logging by Lambda functions installed by the solution is sent to [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) and preserved with the default retention settings. 
+**Maintain traceability** \- Runtime logging by Lambda functions installed by the solution is sent to [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) and preserved with the default retention settings.
@@ -31 +31 @@ This section describes how we architected this solution using the principles and
-**Apply security at all layers** – Interactions among resources require permissions defined in the related resource’s IAM role. AWS WAF protects public application endpoints from common web exploits. Security groups restrict inbound and outbound traffic at the resource level within the customers Amazon VPC. 
+**Apply security at all layers** \- Interactions among resources require permissions defined in the related resource’s IAM role. AWS WAF protects public application endpoints from common web exploits. Security groups restrict inbound and outbound traffic at the resource level within the customers Amazon VPC.
@@ -33 +33 @@ This section describes how we architected this solution using the principles and
-**Protect data in transit and at rest** **–** All data is encrypted in transit via TLS-protected API requests. All persistent resources are configured for encryption at rest. Application-level data is encrypted with [AWS Key Management Service](https://aws.amazon.com/kms/) using customer managed keys. 
+**Protect data in transit and at rest** \- All data is encrypted in transit via TLS-protected API requests. All persistent resources are configured for encryption at rest. Application-level data is encrypted with [AWS Key Management Service](https://aws.amazon.com/kms/) using customer managed keys.
@@ -39 +39 @@ This section describes how we architected this solution using the principles and
-**Automatically recover from failure** – The solution uses [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) metrics and alarms are used to monitor the operation of the solution with the ability to notify users or other systems when thresholds are breached. 
+**Automatically recover from failure** \- The solution uses [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) metrics and alarms are used to monitor the operation of the solution with the ability to notify users or other systems when thresholds are breached.
@@ -49 +49 @@ This section describes how we architected this solution using the principles and
-**Go global in minutes** – The CloudFormation template can be used to create a stack in any compatible Region, with the ability to deploy multiple stacks in the same Region for testing and production. 
+**Go global in minutes** \- The CloudFormation template can be used to create a stack in any compatible Region, with the ability to deploy multiple stacks in the same Region for testing and production.
@@ -51 +51 @@ This section describes how we architected this solution using the principles and
-**Use serverless architectures** – Amazon ECS uses [AWS Fargate](https://aws.amazon.com/fargate/) serverless deployment to manage container resources at cloud scale without the operational burden of managing physical servers. 
+**Use serverless architectures** \- Amazon ECS uses [AWS Fargate](https://aws.amazon.com/fargate/) serverless deployment to manage container resources at cloud scale without the operational burden of managing physical servers.
@@ -53 +53 @@ This section describes how we architected this solution using the principles and
-**Consider mechanical sympathy** – Application metrics data is transformed, partitioned, and stored in Amazon S3 and [AWS Glue](https://docs.aws.amazon.com/glue/) in accordance with common data access patterns to improve query performance. 
+**Consider mechanical sympathy** \- Application metrics data is transformed, partitioned, and stored in Amazon S3 and [AWS Glue](https://docs.aws.amazon.com/glue/) in accordance with common data access patterns to improve query performance.
@@ -59 +59 @@ This section describes how we architected this solution using the principles and
-**Analyze and attribute expenditure** – This solution is configured with [Service Catalog AppRegistry](https://docs.aws.amazon.com/servicecatalog/latest/arguide/intro-app-registry.html), which supports accumulating cost data for each instance of the stack. Over time, you can see the impact of each stack deployment on your monthly account charges. 
+**Analyze and attribute expenditure** \- This solution is configured with [Service Catalog AppRegistry](https://docs.aws.amazon.com/servicecatalog/latest/arguide/intro-app-registry.html), which supports accumulating cost data for each instance of the stack. Over time, you can see the impact of each stack deployment on your monthly account charges.
@@ -61 +61 @@ This section describes how we architected this solution using the principles and
-**Adopt a consumption model** – Serverless computing is used to only pay for consumed compute resources on Amazon ECS. 
+**Adopt a consumption model** \- Serverless computing is used to only pay for consumed compute resources on Amazon ECS.
@@ -67 +67 @@ This section describes how we architected this solution using the principles and
-**Maximize utilization** – Managed services allow for optimal resource provisioning to ensure high utilization while minimizing idle resources to maximize the energy efficiency of the underlying hardware. 
+**Maximize utilization** \- Managed services allow for optimal resource provisioning to ensure high utilization while minimizing idle resources to maximize the energy efficiency of the underlying hardware.
@@ -69 +69 @@ This section describes how we architected this solution using the principles and
-**Use managed services** – This solution uses managed services such as Fargate and Lambda, which share resources across a broad customer base and reduces the amount of infrastructure needed to support cloud workloads. 
+**Use managed services** \- This solution uses managed services such as Fargate and Lambda, which share resources across a broad customer base and reduces the amount of infrastructure needed to support cloud workloads.