Some minor revisions

docs/features/aws-iam/tutorials/aws-visibility.mdx

@@ -5,13 +5,13 @@ image: /img/quick-tutorials/aws-iam-eks/social.png
 ---
 
 
-Many production Kubernetes workloads rely on external cloud resources. In this tutorial, we will look at how Otterize provides visibility into the AWS resources called by your workloads.
+Many production Kubernetes workloads rely on cloud resources, like S3 Buckets, RDS databases, and Lambda functions. In this tutorial, we will look at how Otterize provides visibility into the AWS resources called by your workloads.
 
 In this tutorial, we will:
-* Set up an EKS cluster
-* Deploy two Lambda functions
-* Deploy a server pod that evaluates jokes from one Lambda and forwards a review to another Lambda.
-* Automatically detect the Lambda function calls in Otterize
+* Set up an EKS cluster.
+* Deploy two Lambda functions.
+* Deploy a server pod that evaluates jokes from one Lambda and forwards a review to another.
+* Automatically detect the Lambda function calls in Otterize.
 
 By the end, you'll know how to map Kubernetes workloads alongside their dependent AWS resources using Otterize.
 
@@ -20,7 +20,7 @@ By the end, you'll know how to map Kubernetes workloads alongside their dependen
 ### CLI tools
 We will need the following CLI tools to set up our cluster and deploy our scripts.
 
-1. [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). You will also need credentials within the target account to work with EKS clusters, IAM, Cloudformation, and Lambda functions
+1. [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). You will also need credentials within the target account with permissions to work with EKS clusters, IAM, Cloudformation, and Lambda functions
 2. [eksctl](https://eksctl.io/installation/)
 
 ### Create an EKS cluster
@@ -47,32 +47,33 @@ aws eks update-kubeconfig --name otterize-tutorial-aws-visibility --region 'us-w
 To provide visibility, we will need to install Otterize in our cluster, and we will want to enable AWS IAM roles for service accounts (IRSA) on our cluster. We can quickly enable this using a cloudformation template on the Otterize Cloud Integrations page.
 
 1. **Install Otterize**
-   If you don't have a connected Kubernetes cluster, create one via [Otterize Clusters](https://app.otterize.com/clusters) and follow the setup instructions. Skip if your cluster is already connected.
+If you don't have a connected Kubernetes cluster, create one via [Otterize Clusters](https://app.otterize.com/clusters) and follow the setup instructions. Skip if your cluster is already connected.
 
 2. **Integrate AWS with Otterize Cloud**
-   To begin the integration with AWS, visit the [Integrations page](https://app.otterize.com/integrations). Once there,  you will be asked for some information to help populate a cloudformation script we will use to integrate AWS access controls into our cluster.
+To begin the integration with AWS, visit the [Integrations page](https://app.otterize.com/integrations). Once there,  you will be asked for information to help populate a cloudformation script we will use to integrate AWS access controls into our cluster.
 
-   If you created the EKS cluster above, the cluster name is `otterize-tutorial-aws-visibility` and the region is `us-west-2`.
+If you created the EKS cluster above, the cluster name would be`otterize-tutorial-aws-visibility`, and the region would be `us-west-2`.
 
-   Once the information is provided, a *Launch Cloudformation* button will take you to the AWS Console to deploy the cloudformation script. This script will install IRSA within your EKS cluster and enable Otterize Cloud to manage intents.
+Once the information is provided, a *Launch Cloudformation* button will take you to the AWS Console to deploy the cloudformation script. This script will install IRSA within your EKS cluster and enable Otterize Cloud to manage intents.
 
-   After IRSA is enabled in your cluster, you need to redeploy Otterize with the AWS credential operator and AWS visibility enabled. In Otterize Cloud, click the *Next* button to see the updated Helm commands.  Before executing the revised configuration, you will need to set an additional flag at the end of the command:
+After IRSA is enabled in your cluster, you need to redeploy Otterize with the AWS credential operator and AWS visibility enabled. In Otterize Cloud, click the *Next* button to see the updated Helm commands.  Before executing the revised configuration, you will need to set an additional flag at the end of the command:
 
-   ```bash
-   --set networkMapper.aws.visibility.enabled=true
-   ```
+```bash
+--set networkMapper.aws.visibility.enabled=true
+```
 
 ## Tutorial
 
-Having configured our environment, we'll now deploy AWS resources, authorize pod access using client intents, and monitor access in Otterize Cloud.
+Having configured our environment, we'll deploy AWS resources, authorize pod access using ClientIntents, and monitor access in Otterize Cloud.
 
 ### Deploy two Lambda functions
 
 First, we will deploy two Lambda functions (`DadJokeLambdaFunction` and `FeedbackLambdaFunction`). These services will work alongside our server pod to generate a humor training dataset. This works by receiving a joke from the DadJokeLambdaFunction, the server pod reviewing the joke, and then sending the feedback to the FeedbackLambdaFunction.
 
 We can deploy the lambda functions and their required roles with the following command:
 ```bash
-aws cloudformation deploy --template-file cloudformation.yaml --stack-name OtterizeTutorialJokeTrainingStack --capabilities CAPABILITY_IAM --region 'us-west-2'
+curl http://localhost:3003/code-examples/aws-visibility/cloudformation.yaml -o template.yaml && \
+aws cloudformation deploy --template-file template.yaml --stack-name OtterizeTutorialJokeTrainingStack --capabilities CAPABILITY_IAM --region 'us-west-2'
 ```
 <details>
     <summary>Inspect CloudFormation YAML</summary>
@@ -108,10 +109,9 @@ kubectl apply -n otterize-tutorial-aws-visibility -f ${ABSOLUTE_URL}/code-exampl
 ```
 </details>
 
+Inspecting our deployment YAML, you will see we have added two labels to our pod. The first `network-mapper.otterize.com/aws-visibility` informs the network mapper to identify AWS API calls, and the `credentials-operator.otterize.com/create-aws-role` that drives the credentials operator to create a role specifically for this pod that will be used for our intents.
 
-Inspecting our deployment YAML, you will see we have added two labels to our pod. The first `network-mapper.otterize.com/aws-visibility` informs the network mapper to identify AWS API calls and the `credentials-operator.otterize.com/create-aws-role` that drives the credentials operator to create a role specifically for this pod that will be used for our intents.
-
-Once our pod is deployed, we can see in the logs that it cannot access the Lambda functions.
+Once our pod is deployed, we can inspect the logs and see that we cannot access the Lambda functions.
 
 ```bash
 kubectl logs -f -n otterize-tutorial-aws-visibility deploy/joketrainer
@@ -146,7 +146,7 @@ spec:
 
 ```
 
-We can now check the logs again to ensure that the pod is running:
+We can now recheck the logs to ensure that the pod is running:
 ```bash
 kubectl logs -f -n otterize-tutorial-aws-visibility deploy/joketrainer
 ```
@@ -163,9 +163,20 @@ Sending Feedback of Funny?: No
 ```
 
 ### Visualize Relationships
-The Otterize network mapper inspects pods with the `network-mapper.otterize.com/aws-visibility: true` label. For the labeled pods, the network mapper will identify AWS API calls made by that pod and determine which resources and actions are being used. This information is shown on the [Access Graph](https://app.otterize.com/access-graph).
+The Otterize network mapper inspects pods with the `network-mapper.otterize.com/aws-visibility: true` label. For the labeled pods, the network mapper will identify AWS API calls made by that pod and determine which resources and actions are being used. This information is shown on the [Access graph](https://app.otterize.com/access-graph).
+
+In the Access graph screenshot below, you’ll see 4 AWS resources associated with our server pod: DadJokeLambdaFunction, FeedbackLambdaFunction, the role assumed by our server pod, and our wildcard intent definition. This wildcard definition matches any Lambdas created by our cloudformation stack. These types of wildcard definitions can be helpful for AWS Resources with dynamic ARN names as you move across staging and production deployments. Still, they open up a security space that could be overly permissive for some environments. Otterize makes deploying with a wildcard definition easy and then applying more stringent scoping without disrupting any services.
+
+![Otterize Cloud AWS Visibility Example](/img/quick-tutorials/aws-iam-visibility/aws-iam-visibility.png)
 
 ## Clean Up
+
+To remove cloudformation yaml:
+```bash
+rm template.yaml
+```
+
+
 To remove the deployed example:
 ```bash
 kubectl delete namespace otterize-tutorial-aws-visibility
@@ -176,7 +187,7 @@ To remove the Lambda functions:
 aws cloudformation delete-stack --stack-name OtterizeTutorialJokeTrainingStack
 ```
 
-To remove the EKS cluster
+To remove the EKS cluster:
 ```bash
 eksctl delete cluster --name otterize-tutorial-aws-visibility --region us-west-2
-```
+```

static/code-examples/aws-visibility/cloudformation.yaml

@@ -34,7 +34,7 @@ Resources:
     Properties:
       Handler: 'index.handler'
       Role: !GetAtt DadJokeLambdaExecutionRole.Arn
-      Runtime: 'nodejs14.x'
+      Runtime: 'nodejs20.x'
       Code:
         ZipFile: |
           const https = require('https');
@@ -74,7 +74,7 @@ Resources:
     Properties:
       Handler: 'index.handler'
       Role: !GetAtt DadJokeLambdaExecutionRole.Arn
-      Runtime: 'nodejs14.x'
+      Runtime: 'nodejs20.x'
       Code:
         ZipFile: |
           exports.handler = async (event) => {