some typo cleanup (#10)

jlbutler · web-flow · commit b4f93e9c55ca · 2026-02-25T13:19:41.000-06:00
* typo fixups

* fix up some aws-isms

* fix some grammar/spacing nits
diff --git a/docs/announcements.adoc b/docs/announcements.adoc
@@ -3,7 +3,7 @@
 = Announcements
 :info_doctype: chapter
 
-This topic covers past annoucements of new Eksctl features.
+This topic covers past announcements of new Eksctl features.
 
 == Managed Nodegroups Default
 
diff --git a/docs/clusters/access-entries.adoc b/docs/clusters/access-entries.adoc
@@ -6,11 +6,11 @@ You can use eksctl to manage EKS Access Entries. Use access entries to grant Kub
 
 This topic covers how to use eksctl to manage access entries. For general information about access entries, see link:eks/latest/userguide/access-entries.html["Grant IAM users access to Kubernetes with EKS access entries",type="documentation"].
 
-You can attach Kubernetes access policies defined by AWS, or assocoiate an IAM Identity with a Kubernetes group. 
+You can attach Kubernetes access policies defined by AWS, or associate an IAM Identity with a Kubernetes group. 
 
 For more information about the available pre-defined policies, see link:eks/latest/userguide/access-policies.html#access-policy-permissions["Associate access policies with access entries",type="documentation"].
 
-If you need to define customer Kubernetes policies, associate the IAM Identity with a Kubernetes group, and grant permissions to that group. 
+If you need to define custom Kubernetes policies, associate the IAM Identity with a Kubernetes group, and grant permissions to that group. 
 
 == Cluster authentication mode
 
@@ -101,7 +101,7 @@ The integration with access entries for these resources will be achieved behind
 
 Each access entry has a type. For authorizing self-managed nodegroups, `eksctl` will create a unique access entry for each nodegroup with the principal ARN set to the node role ARN and type set to either `EC2_LINUX` or `EC2_WINDOWS` depending on nodegroup amiFamily.
 
-When creating your own access entries, you can also specify `EC2_LINUX` (for an IAM role used with Linux or Bottlerocket self-managed nodes), `EC2_WINDOWS` (for an IAM roles used with Windows self-managed nodes), `FARGATE_LINUX` (for an IAM roles used with AWS Fargate (Fargate)), or `STANDARD` as a type. If you don't specify a type, the default type is set to `STANDARD`.
+When creating your own access entries, you can also specify `EC2_LINUX` (for an IAM role used with Linux or Bottlerocket self-managed nodes), `EC2_WINDOWS` (for IAM roles used with Windows self-managed nodes), `FARGATE_LINUX` (for IAM roles used with AWS Fargate (Fargate)), or `STANDARD` as a type. If you don't specify a type, the default type is set to `STANDARD`.
 
 [NOTE]
 ====
@@ -128,7 +128,7 @@ For an example config file for creating access entries, see https://github.com/e
 
 == Get access entry
 
-The user can retieve all access entries associated with a certain cluster by running one of the following:
+The user can retrieve all access entries associated with a certain cluster by running one of the following:
 
 [,shell]
 ----
diff --git a/docs/clusters/creating-and-managing-clusters.adoc b/docs/clusters/creating-and-managing-clusters.adoc
@@ -95,7 +95,7 @@ nodeGroups:
         imageBuilder: true
 ----
 
-The cluster name or nodegroup name must contain only alphanumeric characters (case-sensitive) and hyphens. It must start with an alphabetic character and can't exceed 128 characters, or you will receive a validation error. For more information, see link:AWSCloudFormation/latest/UserGuide/cfn-using-console-create-stack-parameters.html["Create a stack from the CloudFormation console",type="documentation"] in the AWS CLoudFormation user guide. 
+The cluster name or nodegroup name must contain only alphanumeric characters (case-sensitive) and hyphens. It must start with an alphabetic character and can't exceed 128 characters, or you will receive a validation error. For more information, see link:AWSCloudFormation/latest/UserGuide/cfn-using-console-create-stack-parameters.html["Create a stack from the CloudFormation console",type="documentation"] in the AWS CloudFormation user guide. 
 
 == Update kubeconfig for new cluster
 
diff --git a/docs/clusters/customizing-the-kubelet.adoc b/docs/clusters/customizing-the-kubelet.adoc
@@ -45,7 +45,7 @@ nodeGroups:
 
 In this example, given instances of type `m5a.xlarge` which have 4 vCPUs and 16GiB of memory, the `Allocatable` amount
 of CPUs would be 3.4 and 15.4 GiB of memory. It is important to know that the values specified in the config file for
-the the fields in `kubeletExtraconfig` will completely overwrite the default values specified by eksctl.
+the fields in `kubeletExtraConfig` will completely overwrite the default values specified by eksctl.
 However, omitting one or more `kubeReserved` parameters will cause the missing parameters to be defaulted to sane
 values based on the aws instance type being used.
 
diff --git a/docs/clusters/eksctl-karpenter.adoc b/docs/clusters/eksctl-karpenter.adoc
@@ -106,7 +106,7 @@ spec:
     - alias: al2023@latest # Amazon Linux 2023
 ----
 
-Note that you must specify one of `role` or `instanceProfile` for lauch nodes. If you choose to use `instanceProfile`
+Note that you must specify one of `role` or `instanceProfile` for launch nodes. If you choose to use `instanceProfile`
 the name of the profile created by `eksctl` follows the pattern: `eksctl-KarpenterNodeInstanceProfile-<cluster-name>`.
 
 ## Automatic Security Group Tagging
diff --git a/docs/clusters/fargate.adoc b/docs/clusters/fargate.adoc
@@ -189,7 +189,7 @@ pod to match a selector entry. A pod only needs to match one selector
 entry to run on the profile. Any pod that matches all the conditions in
 a selector field would be scheduled to be run on Fargate. Any pods not
 matching either the whitelisted Namespaces but where the user manually
-set the scheduler: fargate-scheduler filed would be stuck in a Pending
+set the scheduler: fargate-scheduler field would be stuck in a Pending
 state, as they were not authorized to run on Fargate.
 
 Profiles must meet the following requirements:
@@ -237,7 +237,7 @@ cluster, it’s also possible to create a Fargate profile with the
 NOTE: This operation is only supported on clusters that run on the
 EKS platform version `eks.5` or higher.
 
-NOTE: If the existing was created with a version of `eksctl` prior to 0.11.0, you will  need to run `eksctl upgrade
+NOTE: If the existing cluster was created with a version of `eksctl` prior to 0.11.0, you will need to run `eksctl upgrade
 cluster` before creating the Fargate profile.
 
 [source,console]
diff --git a/docs/clusters/unowned-clusters.adoc b/docs/clusters/unowned-clusters.adoc
@@ -99,4 +99,4 @@ vpc:
 ...
 ----
 
-Fore more information on VPC configuration options, see xref:networking[Networking].
+For more information on VPC configuration options, see xref:networking[Networking].
diff --git a/docs/deployment/deployment.adoc b/docs/deployment/deployment.adoc
@@ -17,7 +17,7 @@ For the most accurate information about EKS deployment options, see link:eks/lat
 ** AWS Outposts is a family of fully managed solutions delivering AWS infrastructure and services to virtually any on-premises or edge location for a truly consistent hybrid experience. 
 ** AWS Outposts support in eksctl lets you create local clusters with the entire Kubernetes cluster, including the EKS control plane and worker nodes, running locally on AWS Outposts. 
 * <<hybrid-nodes>>
-** Run on-premises and edge applications on customer-managed infrastructure with the same AWS EKS clusters, features, and tools you use in the AWS Cloud.
+** Run on-premises and edge applications on customer-managed infrastructure with the same Amazon EKS clusters, features, and tools you use in AWS.
 
 include::eksctl-anywhere.adoc[leveloffset=+1]
 
diff --git a/docs/iam/iam-identity-mappings.adoc b/docs/iam/iam-identity-mappings.adoc
@@ -2,7 +2,7 @@
 [#iam-identity-mappings]
 = Manage IAM users and roles
 
-NOTE: AWS suggests migraitng to <<pod-identity-associations>> from the `aws-auth` ConfigMap. 
+NOTE: AWS suggests migrating to <<pod-identity-associations>> from the `aws-auth` ConfigMap. 
 
 EKS clusters use IAM users and roles to control access to the cluster. The rules are implemented in a config map
 
diff --git a/docs/iam/iam-policies.adoc b/docs/iam/iam-policies.adoc
@@ -2,7 +2,7 @@
 [#iam-policies]
 = IAM policies
 
-You can attach Instance Roles to node groups. Workloads running on the node will receive IAM permissions from the node. For mroe information, see link:AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html[IAM roles for Amazon EC2,type="documentation"].
+You can attach Instance Roles to node groups. Workloads running on the node will receive IAM permissions from the node. For more information, see link:AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html[IAM roles for Amazon EC2,type="documentation"].
 
 This page lists the pre-defined IAM policy templates available in eksctl. These templates simplify the process of granting your EKS nodes the appropriate AWS service permissions without having to manually create custom IAM policies.
 
diff --git a/docs/iam/iam.adoc b/docs/iam/iam.adoc
@@ -25,7 +25,7 @@ This chapter includes information about working with AWS IAM.
 ** Attach custom instance roles or inline policies to node groups for additional permissions.
 ** Attach specific AWS managed policies by ARN to node groups, ensuring required policies like AmazonEKSWorkerNodePolicy and AmazonEKS_CNI_Policy are included.
 * <<minimum-iam-policies>>
-** Manage AWS EC2 resources, including load balancers, auto-scaling groups, and CloudWatch monitoring
+** Manage Amazon EC2 resources, including load balancers, auto-scaling groups, and CloudWatch monitoring
 ** Create and manage AWS CloudFormation stacks
 ** Manage Amazon Elastic Kubernetes Service (EKS) clusters, node groups, and related resources like IAM roles and policies
 
diff --git a/docs/iam/pod-identity-associations.adoc b/docs/iam/pod-identity-associations.adoc
@@ -4,7 +4,7 @@
 
 include::../attributes.txt[]
 
-AWS EKS has introduced a new enhanced mechanism called Pod Identity Association for cluster administrators to configure Kubernetes applications to receive IAM permissions required to connect with AWS services outside of the cluster. Pod Identity Association leverages IRSA, however, it makes it configurable directly through the EKS API, eliminating the need for using IAM API altogether.
+Amazon EKS has introduced a new enhanced mechanism called Pod Identity Association for cluster administrators to configure Kubernetes applications to receive IAM permissions required to connect with AWS services outside of the cluster. Pod Identity Association leverages IRSA, however, it makes it configurable directly through the EKS API, eliminating the need for using IAM API altogether.
 
 As a result, IAM roles no longer need to reference an xref:iam-how-works[OIDC provider] and hence won't be tied to a single cluster anymore. This means, IAM roles can now be used across multiple EKS clusters without the need to update the role trust policy each time a new cluster is created. This in turn, eliminates the need for role duplication and simplifies the process of automating IRSA altogether.
 
diff --git a/docs/networking/vpc-configuration.adoc b/docs/networking/vpc-configuration.adoc
@@ -22,11 +22,11 @@ In `us-east-1` eksctl only creates 2 public and 2 private subnets by default.
 == Change VPC CIDR
 
 If you need to set up peering with another VPC, or simply need a larger or smaller range of IPs, you can use `--vpc-cidr` flag to
-change it. Please refer to link:vpc/latest/userguide/VPC_Subnets.html#VPC_Sizing["the AWS docs",type="documentation"] for guides on choosing CIDR blocks which are permitted for use in an AWS VPC.
+change it. Please refer to link:vpc/latest/userguide/VPC_Subnets.html#VPC_Sizing["the AWS docs",type="documentation"] for guides on choosing CIDR blocks which are permitted for use in a VPC.
 
-If you are creating an IPv6 cluster you can configure `VPC.IPv6Cidr` in the cluser config file. This setting is only in the config file, not in a CLI flag.
+If you are creating an IPv6 cluster you can configure `VPC.IPv6Cidr` in the cluster config file. This setting is only in the config file, not in a CLI flag.
 
-If you own an IPv6 IP address block, you can also bring your own IPv6 pool. See link:AWSEC2/latest/UserGuide/ec2-byoip.html["Bring your own IP addresses (BYOIP) to Amazon EC2",type="documentation"] on how to import your own pool. Then use the `VPC.IPv6Cidr` in the cluser config file to configure Eksctl.
+If you own an IPv6 IP address block, you can also bring your own IPv6 pool. See link:AWSEC2/latest/UserGuide/ec2-byoip.html["Bring your own IP addresses (BYOIP) to Amazon EC2",type="documentation"] on how to import your own pool. Then use the `VPC.IPv6Cidr` in the cluster config file to configure Eksctl.
 
 == Use an existing VPC: shared with kops
 
diff --git a/docs/nodegroups/hybrid-nodes.adoc b/docs/nodegroups/hybrid-nodes.adoc
@@ -7,7 +7,7 @@
 
 == Introduction
 
-AWS EKS introduces Hybrid Nodes, a new feature that enables you to run on-premises and edge applications on customer-managed infrastructure with the same AWS EKS clusters, features, and tools you use in the AWS Cloud. AWS EKS Hybird Nodes brings an AWS-managed Kubernetes experience to on-premises environments for customers to simplify and standardize how you run applications across on-premises, edge and cloud environments. Read more at link:eks/latest/userguide/hybrid-nodes-overview.html["EKS Hybrid Nodes",type="documentation"].
+Amazon EKS introduces Hybrid Nodes, a new feature that enables you to run on-premises and edge applications on customer-managed infrastructure with the same Amazon EKS clusters, features, and tools you use in AWS. Amazon EKS Hybrid Nodes brings an AWS-managed Kubernetes experience to on-premises environments for customers to simplify and standardize how you run applications across on-premises, edge and cloud environments. Read more at link:eks/latest/userguide/hybrid-nodes-overview.html["EKS Hybrid Nodes",type="documentation"].
 
 To facilitate support for this feature, eksctl introduces a new top-level field called `remoteNetworkConfig`. Any Hybrid Nodes related configuration shall be set up via this field, as part of the config file; there are no CLI flags counterparts. Additionally, at launch, any remote network config can only be set up during cluster creation and cannot be updated afterwards. This means, you won't be able to update existing clusters to use Hybrid Nodes.
 
@@ -16,7 +16,7 @@ The `remoteNetworkConfig` section of the config file allows you to setup the two
 [#hybrid-networking]
 == Networking
 
-EKS Hybrid Nodes is ﬂexible to your preferred method of connecting your on-premises network(s) to an AWS VPC. There are several link:whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html["documented options",type="documentation"] available, including AWS Site-to-Site VPN and AWS Direct Connect, and you can choose the method that best fits your use case. In most of the methods you might choose, your VPC will be attached to either a virtual private gateway (VGW) or a transit gateway (TGW). If you rely on eksctl to create a VPC for you, eksctl will also configure, *within the scope of your VPC*, any networking related pre-requisites in order to facilitate communication between your EKS control plane and the remote nodes i.e.
+EKS Hybrid Nodes is flexible to your preferred method of connecting your on-premises network(s) to a VPC. There are several link:whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html["documented options",type="documentation"] available, including AWS Site-to-Site VPN and AWS Direct Connect, and you can choose the method that best fits your use case. In most of the methods you might choose, your VPC will be attached to either a virtual private gateway (VGW) or a transit gateway (TGW). If you rely on eksctl to create a VPC for you, eksctl will also configure, *within the scope of your VPC*, any networking related pre-requisites in order to facilitate communication between your EKS control plane and the remote nodes i.e.
 
 * ingress/egress SG rules
 * routes in the private subnets' route tables
@@ -45,7 +45,7 @@ eksctl does not setup any networking infrastructure outside your AWS VPC (i.e. a
 == Credentials
 
 EKS Hybrid Nodes use the AWS IAM Authenticator and temporary IAM credentials provisioned by either *AWS SSM* or *AWS IAM Roles Anywhere*
-to authenticate with the EKS cluster. Similar to the self-managed nodegroups, if not otherwise provided, eksctl will create for you a Hybrid Nodes IAM Role to be assumed by the remote nodes. Additioanlly, when using IAM Roles Anywhere as your credentials provider, eksctl will setup a profile, and trust anchor based on a given certificate authority bundle (`iam.caBundleCert`) e.g.
+to authenticate with the EKS cluster. Similar to the self-managed nodegroups, if not otherwise provided, eksctl will create for you a Hybrid Nodes IAM Role to be assumed by the remote nodes. Additionally, when using IAM Roles Anywhere as your credentials provider, eksctl will setup a profile, and trust anchor based on a given certificate authority bundle (`iam.caBundleCert`) e.g.
 
 [,yaml]
 ----
@@ -101,7 +101,7 @@ Container Networking Interface (CNI): The AWS VPC CNI can't be used with hybrid
 
 [NOTE]
 ====
-If you install VPC CNI in your cluster for your self-managed or EKS-managed nodegroups, you have to use `v1.19.0-eksbuild.1` or later, as this includes an udpate to the add-on's daemonset to exclude it from being installed on Hybrid Nodes.
+If you install VPC CNI in your cluster for your self-managed or EKS-managed nodegroups, you have to use `v1.19.0-eksbuild.1` or later, as this includes an update to the add-on's daemonset to exclude it from being installed on Hybrid Nodes.
 ====
 == Further references
 
diff --git a/docs/nodegroups/nodegroup-managed.adoc b/docs/nodegroups/nodegroup-managed.adoc
@@ -72,7 +72,7 @@ managedNodeGroups:
 Another example of a config file for creating a managed nodegroup can be found https://github.com/eksctl-io/eksctl/blob/main/examples/15-managed-nodes.yaml[here].
 
 It's possible to have a cluster with both managed and unmanaged nodegroups. Unmanaged nodegroups do not show up in
-the AWS EKS console but `eksctl get nodegroup` will list both types of nodegroups.
+the Amazon EKS console but `eksctl get nodegroup` will list both types of nodegroups.
 
 [,yaml]
 ----
@@ -244,9 +244,9 @@ managedNodeGroups:
       version: "2" #optional (uses the default version of the launch template if unspecified)
 ----
 
-* create a new version of the custom AMI (using AWS EKS console).
+* create a new version of the custom AMI (using Amazon EKS console).
 
-* create a new launch template version with the new AMI ID (using AWS EKS console).
+* create a new launch template version with the new AMI ID (using Amazon EKS console).
 
 * upgrade the nodes to the new version of the launch template. e.g.
 +
diff --git a/docs/nodegroups/nodegroups.adoc b/docs/nodegroups/nodegroups.adoc
@@ -19,8 +19,8 @@ This chapter includes information about how you create and configure Nodegroups
 ** Provision and manage EC2 instances (nodes) for Amazon EKS Kubernetes clusters
 ** Easily apply bug fixes, security patches, and update nodes to the latest Kubernetes versions
 * <<hybrid-nodes>>
-** Enable running on-premises and edge applications on customer-managed infrastructure with the same AWS EKS clusters, features, and tools used in the AWS Cloud
-** Configure networking to connect on-premises networks to an AWS VPC, using options like AWS Site-to-Site VPN or AWS Direct Connect
+** Enable running on-premises and edge applications on customer-managed infrastructure with the same Amazon EKS clusters, features, and tools used in AWS
+** Configure networking to connect on-premises networks to a VPC, using options like AWS Site-to-Site VPN or AWS Direct Connect
 ** Set up credentials for remote nodes to authenticate with the EKS cluster, using either AWS Systems Manager (SSM) or AWS IAM Roles Anywhere
 * <<nodegroup-node-repair-config>>
 ** Enabling Node Repair for EKS Managed Nodegroups to automatically monitor and replace or reboot unhealthy worker nodes
diff --git a/docs/security/kms-encryption.adoc b/docs/security/kms-encryption.adoc
