AWS wellarchitected documentation change
Summary
Removed entire content of the file which previously discussed expenditure awareness for game environments, including cost attribution per player, feature, and environment, best practices for cost management, and references to serverless architectures.
Security assessment
The removed content focused solely on cost optimization strategies, attribution methods, and architectural recommendations without any mention of security vulnerabilities, incidents, or security-specific features. There is no evidence of security fixes, vulnerability disclosures, or security enhancements in the deleted material.
Diff
diff --git a/wellarchitected/latest/games-industry-lens/games-cost-expend-aware.md b/wellarchitected/latest/games-industry-lens/games-cost-expend-aware.md index e1f466edb..8b1378917 100644 --- a//wellarchitected/latest/games-industry-lens/games-cost-expend-aware.md +++ b//wellarchitected/latest/games-industry-lens/games-cost-expend-aware.md @@ -1 +0,0 @@ -[](/pdfs/wellarchitected/latest/games-industry-lens/games-industry-lens.pdf#games-cost-expend-aware "Open PDF") @@ -3,49 +1,0 @@ -[Documentation](/index.html)[AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/)[AWS Well-Architected Framework](games-industry-lens.html) - -# Expenditure awareness - -GAMECOST04 - How do you measure the cost of your game environments? ---- - -Understand the cost per player, game feature, and environment so that you can manage and forecast your spend as the number of players changes over time and features are added and improved. Consider the following best practices in order to manage your costs of your different game environments. - -**GAMECOST_BP07: Implement attribution of cost per player, game feature, and environment.** - -Cost attribution for game servers is usually easier to perform than game backend services because a game server is usually optimized to be able to host a specific number of concurrent players per instance which can be amortized across the cost of running the instance. For game backend services, it is recommended to de-couple the components of your game into distinct features that can be managed as separate logical or physical resources to make it easier to analyze costs. For example, although it may seem easier to implement a single monolithic application to host game backend services, this pattern makes it hard to derive the total cost per player and game feature over time as you add more features because the compute, networking, and storage costs of resources are shared across all of them. - -Consider adopting a serverless architecture for your game backend services with services such as Amazon API Gateway and Lambda or Fargate for compute, Amazon SQS and Amazon SNS for messaging, Amazon S3 for object storage, and Amazon DynamoDB for database storage. These services are just a few examples of products that offer pricing that is usage-based and primarily driven by request volume so that costs can be broken down more granularly. Individual resources such as Lambda functions, Fargate services, DynamoDB tables, and S3 buckets can all be associated with cost allocation tags so that you can attribute the costs of these services with game feature names that make it easier for you to understand the costs for each of your services. - -It is also recommended to separately manage each of your game development environments so that you can easily attribute costs for the different environments. Typically, game developers will manage separate environments for development, test, staging and production environments, as described in the operations pillar of this games industry lens. Each environment usually has different scalability, performance, and usage requirements and may be managed by separate teams. To control costs, organize these environments so that you can properly monitor and attribute the costs of each environment. - -For more information, refer to the following documentation: - - * [Building a serverless muli-player game that scales](https://aws.amazon.com/blogs/compute/building-a-serverless-multiplayer-game-that-scales/) - - * [Standalone Game Session Servers with a Websockets-based backend](https://docs.aws.amazon.com/gamelift/latest/developerguide/gamelift_quickstart_customservers_designbackend_arch_websockets.html) - - * [Standalone Game Session Servers with a Serverless backend](https://docs.aws.amazon.com/gamelift/latest/developerguide/gamelift_quickstart_customservers_designbackend_arch_serverless.html) - - - - - **Javascript is disabled or is unavailable in your browser.** - -To use the Amazon Web Services Documentation, Javascript must be enabled. Please refer to your browser's Help pages for instructions. - -[Document Conventions](/general/latest/gr/docconventions.html) - -Matching supply and demand - -Optimizing over time - -Did this page help you? - Yes - -Thanks for letting us know we're doing a good job! - -If you've got a moment, please tell us what we did right so we can do more of it. - -Did this page help you? - No - -Thanks for letting us know this page needs work. We're sorry we let you down. - -If you've got a moment, please tell us how we can make the documentation better.