tweaks

content/02-base/06-reference/01-getting-started-guide-foundation-team-members.md

@@ -57,7 +57,7 @@ When you make changes to AWS account names and AWS Organizations OU names outsid
 
 By following this guide, your foundation team has already established a foundation for security:
 
-* Leveraged AWS Control Tower to set up and govern a secure, compliant, multi-account AWS environment based on best practices established by working with thousands of enterprises.
+* Leveraged AWS Control Tower to set up and govern a compliant multi-account AWS environment based on best practices established by working with thousands of enterprises.
 * Established mandatory [Guardrails](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html) to provide ongoing governance for your overall AWS environment. Additional guardrails are available and should be reviewed by your security administrator and team.
 * Established [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) logging to capture all actions taken by users, roles and services across all of your AWS accounts.
 * Secured the root user of your AWS accounts with multi-factor authentication (MFA).

content/03-dev/07-reference/02-controlling-builder-team-access.md

@@ -111,7 +111,7 @@ The following scenarios are just a few examples of when a builder team would ass
 * Deploy containers to Amazon ECS and EKS container orchestration services.
 
 {{% notice tip %}}
-**Best practice to use IAM service roles vs "service accounts":** In all of these examples, it's a best practice to use customer managed IAM service roles and policies and the associated short-term credentials to permit the workload access to other cloud resources on which they depend. This approach is more manageable and secure than the complexity and risks associated with managing and using workload specific "service accounts" in the form of IAM users and long-term  AWS access keys.
+**Best practice to use IAM service roles vs "service accounts":** In all of these examples, it's a best practice to use customer managed IAM service roles and policies and the associated short-term credentials to permit the workload access to other cloud resources on which they depend. This approach is more manageable and can be more secure than the complexity and risks associated with managing and using workload specific "service accounts" in the form of IAM users and long-term  AWS access keys.
 {{% /notice %}}
 
 ## Sample Implementation

content/04-test-prod/01-review-test-prod-solution.md

@@ -104,7 +104,7 @@ If your initial workload requires access either to or from the internet, then we
 
 |Approach|Description|Advantages|Disadvantages|
 |--------|-----------|----------|-------------|
-|**Direct internet access from VPCs**|Deploy a set of public subnets and associated internet and potentially NAT gateways in each VPC. Ensure use of direct internet access is performed in a secure manner.|Easy setup<br><br>No dependencies on other teams<br><br>No on-premises dependencies|Might not meet your internet security requirements<br><br>Responsibility on team managing the workloads to help ensure secure internet access,|
+|**Direct internet access from VPCs**|Deploy a set of public subnets and associated internet and potentially NAT gateways in each VPC. Ensure use of direct internet access is performed in a secure manner.|Easy setup<br><br>No dependencies on other teams<br><br>No on-premises dependencies|Might not meet your internet security requirements<br><br>Responsibility on team managing the workloads to help secure internet access,|
 |**Temporarily route internet traffic to on-premises**|Use only private subnets in each VPC. Route all internet traffic over private connection to on-premises and reuse your existing enterprise internet security services.|Relatively straightforward to configure if you already plan on setting up private connectivity with your on-premises environment.|Stopgap solution<br><br>Increased latency.<br><br>Potentially insufficient bandwidth<br><br>Cost depending on the amount of data transferred out of AWS to your on-premises environment<br><br>Dependencies on other teams|
 |**Establish centrally managed internet egress/ingress security capabilities in AWS**|Use only private subnets in each VPC. Route all internet traffic through a new centralized internet security services in your AWS environment.<br><br>For example, [Securing VPC Egress Using IDS/IPS Leveraging Transit Gateway](https://aws.amazon.com/blogs/networking-and-content-delivery/securing-egress-using-ids-ips-leveraging-transit-gateway/) and [How to Integrate Third-Party Firewall Appliances into an AWS Environment](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-integrate-third-party-firewall-appliances-into-an-aws-environment/).|Performance<br><br>Scales for broader adoption of AWS|Significant undertaking<br><br>Dependencies on other teams|  
 

content/05-extend/01-hybrid-networking/04-set-up-site-to-site-vpn/_index.md

@@ -10,7 +10,7 @@ Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
 SPDX-License-Identifier: CC-BY-SA-4.0
 {{% /comment %}}
 
-This section provides detailed step-by-step instructions for using AWS Site-to-Site VPN and AWS Transit Gateway as a means to quickly and securely establish network connectivity between your on-premises and AWS environments. 
+This section provides detailed step-by-step instructions for using AWS Site-to-Site VPN and AWS Transit Gateway as a means to establish network connectivity between your on-premises and AWS environments. 
 
 By following these instructions, you will enable network connectivity between your on-premises environment and the centrally managed development VPC you established earlier in this guide.