AWS prescriptive-guidance documentation change
Summary
Updated image paths, fixed typographical quotes, added content about SAP system compatibility, and made minor editorial changes
Security assessment
Changes primarily involve image path updates, typographical corrections (straight vs. curly quotes), and adding a general compatibility consideration. The added bullet point regarding SAP system compatibility focuses on functional requirements rather than security controls. No specific security vulnerabilities, access controls, or encryption mechanisms are mentioned. The environment separation recommendation ('Do not put non-production environments in production VPCs') was already present and only received typographical fixes.
Diff
diff --git a/prescriptive-guidance/latest/sap-greenfield-implementations/design.md b/prescriptive-guidance/latest/sap-greenfield-implementations/design.md index 1a5847e3c..4cb6d11d1 100644 --- a//prescriptive-guidance/latest/sap-greenfield-implementations/design.md +++ b//prescriptive-guidance/latest/sap-greenfield-implementations/design.md @@ -5 +5 @@ -[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Best practices for SAP on AWS greenfield implementations](welcome.html) +[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Best practices for SAP on AWS greenfield implementations](introduction.html) @@ -21 +20,0 @@ Considerations: - @@ -23 +22,5 @@ Considerations: - * A typical greenfield SAP implementation spans a year or more. It includes times when the infrastructure team doesn’t actively build infrastructure components, so it’s important to consider the activities and deliverables during that time. Examples of activities to map include HA setup and testing, DR setup and testing, performance testing, and building automation scripts. + + + + + * A typical greenfield SAP implementation spans a year or more. It includes times when the infrastructure team doesn't actively build infrastructure components, so it's important to consider the activities and deliverables during that time. Examples of activities to map include HA setup and testing, DR setup and testing, performance testing, and building automation scripts. @@ -29 +32 @@ Here is an example of a typical high-level SAP landscape diagram. The boxes repr - + @@ -44 +47 @@ Considerations: - * A key consideration is boundary systems that integrate with SAP. If you’re hosting boundary or satellite applications on AWS, it’s best to host SAP in the same primary Region, to prevent any unnecessary discussions about latency. Even if you confirm that latency is not an issue, it will be difficult to explain why boundary applications are built in a different Region than your SAP applications to your stakeholders. + * A key consideration is boundary systems that integrate with SAP. If you're hosting boundary or satellite applications on AWS, it's best to host SAP in the same primary Region, to prevent any unnecessary discussions about latency. Even if you confirm that latency is not an issue, it will be difficult to explain why boundary applications are built in a different Region than your SAP applications to your stakeholders. @@ -47,0 +51,2 @@ Considerations: + * Make sure that the solutions and optimizations work with SAP systems. Service teams typically build services that aren't always SAP-specific for large enterprise systems. + @@ -53 +58 @@ Considerations: -Thoroughly vet and document naming conventions for the host, SAP environment, virtual private cloud (VPC), and AWS accounts. Be sure to follow existing standards or conventions. In a greenfield implementation, you will probably have to define your naming conventions from scratch. Be consistent. For example, if you call the VPC _Pre-Prod_ , the SAP environment _UAT_ , and the AWS account _TST_ , it will be challenging to associate these three names from a support perspective. Be sure to gain consensus and assign names in which every character has a meaning, but leave room for flexibility. For example, do not hardcode the Region name into the server name, in case you have to switch to another Region in the future. Avoid using the naming convention you’re using for your on-premises servers. Instead, recommend a flexible cloud naming convention if your organization doesn’t already have one. +Thoroughly vet and document naming conventions for the host, SAP environment, virtual private cloud (VPC), and AWS accounts. Be sure to follow existing standards or conventions. In a greenfield implementation, you will probably have to define your naming conventions from scratch. Be consistent. For example, if you call the VPC _Pre-Prod_ , the SAP environment _UAT_ , and the AWS account _TST_ , it will be challenging to associate these three names from a support perspective. Be sure to gain consensus and assign names in which every character has a meaning, but leave room for flexibility. For example, do not hardcode the Region name into the server name, in case you have to switch to another Region in the future. Avoid using the naming convention you're using for your on-premises servers. Instead, recommend a flexible cloud naming convention if your organization doesn't already have one. @@ -59 +64 @@ Considerations: - * Do not put non-production environments in production VPCs. If that’s a requirement, make sure that there’s a valid reason before you agree. + * Do not put non-production environments in production VPCs. If that's a requirement, make sure that there's a valid reason before you agree.