Merge pull request #263 from aniadev-aws/usefullinks

Adding useful links page to add links to additional o11y resources

Author: mhausenblas

docs/en/guides/cost/kubecost.md

@@ -1,4 +1,4 @@
-# Cost visibility and resource right-sizing using Kubecost
+# Using Kubecost
 Kubecost provides customers with visibility into spend and resource efficiency in Kubernetes environments. At a high level, Amazon EKS cost monitoring is deployed with Kubecost, which includes Prometheus, an open-source monitoring system and time series database. Kubecost reads metrics from Prometheus then performs cost allocation calculations and writes the metrics back to Prometheus. Finally, the Kubecost front end reads metrics from Prometheus and shows them on the Kubecost user interface (UI). The architecture is illustrated by the following diagram:
 
 ![Architecture](../../images/kubecost-architecture.png)
@@ -16,8 +16,9 @@ A downside of the above two approach is that you may end up with unused capacity
 
 The most efficient way to track costs in multi-tenant Kubernetes clusters is to distribute incurred costs based on the amount of resources consumed by workloads. This pattern allows you to maximize the utilization of your EC2 instances because different workloads can share nodes, which allows you to increase the pod-density on your nodes. However, calculating costs by workload or namespaces is a challenging task. Understanding the cost-responsibility of a workload requires aggregating all the resources consumed or reserved during a time-frame, and evaluating the charges based on the cost of the resource and the duration of the usage. This is the exact challenge that Kubecost is dedicated to tackling.
 
-!!! tip
+:::tip
     Take a look at our [One Observability Workshop](https://catalog.workshops.aws/observability/en-US/aws-managed-oss/amp/ingest-kubecost-metrics) to get a hands-on experience on Kubecost.
+:::
 
 ## Recommendations
 ### Cost Allocation
@@ -49,7 +50,7 @@ So, idle costs can also be thought of as the cost of the space that the Kubernet
 
 ### Network Cost
 
-Kubecost uses best-effort to allocate network transfer costs to the workloads generating those costs. The accurate way of determining the network cost is by using the combination of  [AWS Cloud Integration](https://docs.kubecost.com/install-and-configure/install/cloud-integration/aws-cloud-integrations) and [Network costs daemonset](https://docs.kubecost.com/install-and-configure/advanced-configuration/network-costs-configuration). 
+Kubecost uses best-effort to allocate network transfer costs to the workloads generating those costs. The accurate way of determining the network cost is by using the combination of  [AWS Cloud Integration](https://www.ibm.com/docs/en/kubecost/self-hosted/3.x?topic=integration-aws-cloud-using-irsaeks-pod-identities) and [Network costs daemonset](https://docs.kubecost.com/install-and-configure/advanced-configuration/network-costs-configuration). 
 
 You would want to take into account your efficiency score and Idle cost to fine tune the workloads to ensure you utilize the cluster to its complete potential. This takes us to the next topic namely Cluster right-sizing.
 
@@ -99,7 +100,7 @@ eksctl create iamserviceaccount \
 --approve
 
 ```
-`CLUSTER_NAME` is the name of the Amazon EKS cluster where you want to install Kubecost and <REGION> is the region of the Amazon EKS cluster.
+`CLUSTER_NAME` is the name of the Amazon EKS cluster where you want to install Kubecost and "REGION" is the region of the Amazon EKS cluster.
 
 Once complete, you will have to upgrade the Kubecost helm chart as below :
 ```
@@ -113,7 +114,7 @@ oci://public.ecr.aws/kubecost/cost-analyzer --version <$VERSION> \
 ```
 ### Accessing Kubecost UI
 
-Kubecost provides a web dashboard that you can access either through kubectl port-forward, an ingress, or a load balancer. The enterprise version of Kubecost also supports restricting access to the dashboard using [SSO/SAML](https://docs.kubecost.com/install-and-configure/advanced-configuration/user-management-oidc) and providing varying level of access. For example, restricting team’s view to only the products they are responsible for.
+Kubecost provides a web dashboard that you can access either through kubectl port-forward, an ingress, or a load balancer. The enterprise version of Kubecost also supports restricting access to the dashboard using [SSO/SAML](https://www.ibm.com/docs/en/kubecost/self-hosted/3.x?topic=configuration-user-management-oidc) and providing varying level of access. For example, restricting team’s view to only the products they are responsible for.
 
 In AWS environment, consider using the [AWS Load Balancer Controller](https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html) to expose Kubecost and use [Amazon Cognito](https://aws.amazon.com/cognito/) for authentication, authorization, and user management. You can learn more on this [How to use Application Load Balancer and Amazon Cognito to authenticate users for your Kubernetes web apps](https://aws.amazon.com/blogs/containers/how-to-use-application-load-balancer-and-amazon-cognito-to-authenticate-users-for-your-kubernetes-web-apps/)
 

docs/en/guides/operational/gitops-with-amg/gitops-with-amg.md

@@ -25,13 +25,13 @@ The [grafana-operator](https://github.com/grafana-operator/grafana-operator#:~:t
 
 GitOps is a software development and operations methodology that uses Git as the source of truth for deployment configurations. It involves keeping the desired state of an application or infrastructure in a Git repository and using Git-based workflows to manage and deploy changes. GitOps is a way of managing application and infrastructure deployment so that the whole system is described declaratively in a Git repository. It is an operational model that offers you the ability to manage the state of multiple Kubernetes clusters leveraging the best practices of version control, immutable artifacts, and automation. 
 
-Flux is a GitOps tool that automates the deployment of applications on Kubernetes. It works by continuously monitoring the state of a Git repository and applying any changes to a cluster. Flux integrates with various Git providers such as GitHub, [GitLab](https://dzone.com/articles/auto-deploy-spring-boot-app-using-gitlab-cicd), and Bitbucket. When changes are made to the repository, Flux automatically detects them and updates the cluster accordingly.
+Flux is a GitOps tool that automates the deployment of applications on Kubernetes. It works by continuously monitoring the state of a Git repository and applying any changes to a cluster. Flux integrates with various Git providers such as GitHub, [GitLab](https://dzone.com/articles/auto-deploy-spring-boot-app-using-gitlab-cicd/), and Bitbucket. When changes are made to the repository, Flux automatically detects them and updates the cluster accordingly.
 
 ### Advantages of using Flux
 
 * **Automated deployments**: Flux automates the deployment process, reducing manual errors and freeing up developers to focus on other tasks.
 * **Git-based workflow**: Flux leverages Git as a source of truth, which makes it easier to track and revert changes.
-* **Declarative configuration**: Flux uses [Kubernetes](https://dzone.com/articles/kubernetes-full-stack-example-with-kong-ingress-co) manifests to define the desired state of a cluster, making it easier to manage and track changes.
+* **Declarative configuration**: Flux uses [Kubernetes](https://dzone.com/articles/kubernetes-full-stack-example-with-kong-ingress-co/) manifests to define the desired state of a cluster, making it easier to manage and track changes.
 
 ### Challenges in adopting Flux
 

docs/en/guides/serverless/aws-native/lambda-based-observability.md

@@ -179,15 +179,17 @@ One way to publish custom metrics to AWS CloudWatch is by calling CloudWatch met
 To achieve this, you can generate the logs using [EMF specification](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Specification.html), and send them to CloudWatch using `PutLogEvents` API. To simplify the process, there are **two client libraries that support the creation of metrics in the EMF** **format**.
 
 * Low level client libraries ([aws-embedded-metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Libraries.html))
-* Lambda Powertools [Metrics](https://docs.powertools.aws.dev/lambda/java/core/metrics/).
+* Lambda Powertools [Metrics](https://docs.aws.amazon.com/powertools/java/latest/core/metrics/).
 
 
 ### **Use [CloudWatch Lambda Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights.html) to monitor system-level metrics**
 
 CloudWatch Lambda insights provides you system-level metrics, including CPU time, memory usage, disk utilization, and network performance. Lambda Insights also collects, aggregates, and summarizes diagnostic information, such as **`cold starts`** and Lambda worker shutdowns. Lambda Insights leverages CloudWatch Lambda extension, which is packaged as a Lambda layer. Once enabled, it collects system-level metrics and emits a single performance log event to CloudWatch Logs for every invocation of that Lambda function in the embedded metrics format. 
 
-!!! note
+:::note
     CloudWatch Lambda Insights is not enabled by default and needs to be turned on per Lambda function. 
+:::
+
 You can enable it via AWS console or via  Infrastructure as Code (IaC). Here is an example of how to enable it using the AWS serverless application model (SAM). You add `LambdaInsightsExtension` extension Layer to your Lambda function, and also add managed IAM policy `CloudWatchLambdaInsightsExecutionRolePolicy`, which gives permissions to your Lambda function to create log stream and call `PutLogEvents` API to be able to write logs to it.
 
 ```
@@ -296,9 +298,9 @@ const AWS = AWSXRay.captureAWS(require('aws-sdk'));
 ...
 ```
 
-!!! note
+:::note
     To instrument individual clients wrap your AWS SDK client in a call to `AWSXRay.captureAWSClient`.  Do not use both `captureAWS` and `captureAWSClient` together. This will lead to duplicate traces.
-
+:::
 
 ## **Additional Resources**
 
@@ -314,10 +316,3 @@ const AWS = AWSXRay.captureAWS(require('aws-sdk'));
 In this observability best practice guide for AWS Lambda based serverless application, we highlighted critical aspects such as logging, metrics and tracing using Native AWS services such as Amazon CloudWatch and AWS X-Ray. We recommended using AWS Lambda Powertools library to easily add observability best practices to your application. By adopting these best practices, you can unlock valuable insights into your serverless application, enabling faster error detection and performance optimization.
 
 For further deep dive, we would highly recommend you to practice AWS Native Observability module of AWS [One Observability Workshop](https://catalog.workshops.aws/observability/en-US).
-
-
-
-
-
-
-

docs/en/tools/useful-links.md

@@ -0,0 +1,44 @@
+# Useful Links
+
+A curated collection of resources to help you learn and implement AWS observability best practices.
+
+## Learning Resources
+
+### AWS Cloud Operations Show
+
+Collection of live stream recordings where we dive deep into interesting AWS Cloud Operations features and use cases. This video series provides practical demonstrations and expert insights into cloud operations.
+
+[Watch on YouTube](https://www.youtube.com/playlist?list=PLehXSATXjcQHj8bPSf0uZuQBoxJ7a7ag7)
+
+### One Observability Workshop
+
+This hands-on workshop provides practical experience with the wide variety of tool sets AWS offers for monitoring and observability. The workshop is highly customizable - you can pick and choose any module based on your interests and availability.
+
+[Start the Workshop](https://catalog.workshops.aws/observability/)
+
+!!! tip
+    The One Observability Workshop is perfect for teams looking to get hands-on experience with AWS observability tools in a structured learning environment.
+
+## Demos and Examples
+
+### Application Signals Demo
+
+A complete demonstration application showcasing AWS Application Signals capabilities. This demo provides a working example (the Pet Clinic) which you can deploy and explore to understand how Application Signals works in practice.
+
+[View on GitHub](https://github.com/aws-observability/application-signals-demo)
+
+## Documentation
+
+### AWS Observability Best Practices Guide
+
+The home page of this Observability Best Practices guide. This comprehensive resource covers best practices, patterns, and recipes for implementing observability on AWS.
+
+[Visit the Guide](https://aws-observability.github.io/observability-best-practices/)
+
+### AWS Distro for OpenTelemetry (ADOT)
+
+Comprehensive guides on how to instrument your code with ADOT. Learn how to collect distributed traces and metrics from your applications using the AWS-supported distribution of OpenTelemetry.
+
+[Explore ADOT Documentation](https://aws-otel.github.io/)
+
+

docusaurus/docs/guides/cost/kubecost.md

@@ -50,7 +50,7 @@ So, idle costs can also be thought of as the cost of the space that the Kubernet
 
 ### Network Cost
 
-Kubecost uses best-effort to allocate network transfer costs to the workloads generating those costs. The accurate way of determining the network cost is by using the combination of  [AWS Cloud Integration](https://docs.kubecost.com/install-and-configure/install/cloud-integration/aws-cloud-integrations) and [Network costs daemonset](https://docs.kubecost.com/install-and-configure/advanced-configuration/network-costs-configuration). 
+Kubecost uses best-effort to allocate network transfer costs to the workloads generating those costs. The accurate way of determining the network cost is by using the combination of  [AWS Cloud Integration](https://www.ibm.com/docs/en/kubecost/self-hosted/3.x?topic=integration-aws-cloud-using-irsaeks-pod-identities) and [Network costs daemonset](https://docs.kubecost.com/install-and-configure/advanced-configuration/network-costs-configuration). 
 
 You would want to take into account your efficiency score and Idle cost to fine tune the workloads to ensure you utilize the cluster to its complete potential. This takes us to the next topic namely Cluster right-sizing.
 
@@ -114,7 +114,7 @@ oci://public.ecr.aws/kubecost/cost-analyzer --version <$VERSION> \
 ```
 ### Accessing Kubecost UI
 
-Kubecost provides a web dashboard that you can access either through kubectl port-forward, an ingress, or a load balancer. The enterprise version of Kubecost also supports restricting access to the dashboard using [SSO/SAML](https://docs.kubecost.com/install-and-configure/advanced-configuration/user-management-oidc) and providing varying level of access. For example, restricting team’s view to only the products they are responsible for.
+Kubecost provides a web dashboard that you can access either through kubectl port-forward, an ingress, or a load balancer. The enterprise version of Kubecost also supports restricting access to the dashboard using [SSO/SAML](https://www.ibm.com/docs/en/kubecost/self-hosted/3.x?topic=configuration-user-management-oidc) and providing varying level of access. For example, restricting team’s view to only the products they are responsible for.
 
 In AWS environment, consider using the [AWS Load Balancer Controller](https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html) to expose Kubecost and use [Amazon Cognito](https://aws.amazon.com/cognito/) for authentication, authorization, and user management. You can learn more on this [How to use Application Load Balancer and Amazon Cognito to authenticate users for your Kubernetes web apps](https://aws.amazon.com/blogs/containers/how-to-use-application-load-balancer-and-amazon-cognito-to-authenticate-users-for-your-kubernetes-web-apps/)
 

docusaurus/docs/guides/operational/gitops-with-amg/gitops-with-amg.md

@@ -25,13 +25,13 @@ The [grafana-operator](https://github.com/grafana-operator/grafana-operator#:~:t
 
 GitOps is a software development and operations methodology that uses Git as the source of truth for deployment configurations. It involves keeping the desired state of an application or infrastructure in a Git repository and using Git-based workflows to manage and deploy changes. GitOps is a way of managing application and infrastructure deployment so that the whole system is described declaratively in a Git repository. It is an operational model that offers you the ability to manage the state of multiple Kubernetes clusters leveraging the best practices of version control, immutable artifacts, and automation. 
 
-Flux is a GitOps tool that automates the deployment of applications on Kubernetes. It works by continuously monitoring the state of a Git repository and applying any changes to a cluster. Flux integrates with various Git providers such as GitHub, [GitLab](https://dzone.com/articles/auto-deploy-spring-boot-app-using-gitlab-cicd), and Bitbucket. When changes are made to the repository, Flux automatically detects them and updates the cluster accordingly.
+Flux is a GitOps tool that automates the deployment of applications on Kubernetes. It works by continuously monitoring the state of a Git repository and applying any changes to a cluster. Flux integrates with various Git providers such as GitHub, [GitLab](https://dzone.com/articles/auto-deploy-spring-boot-app-using-gitlab-cicd/), and Bitbucket. When changes are made to the repository, Flux automatically detects them and updates the cluster accordingly.
 
 ### Advantages of using Flux
 
 * **Automated deployments**: Flux automates the deployment process, reducing manual errors and freeing up developers to focus on other tasks.
 * **Git-based workflow**: Flux leverages Git as a source of truth, which makes it easier to track and revert changes.
-* **Declarative configuration**: Flux uses [Kubernetes](https://dzone.com/articles/kubernetes-full-stack-example-with-kong-ingress-co) manifests to define the desired state of a cluster, making it easier to manage and track changes.
+* **Declarative configuration**: Flux uses [Kubernetes](https://dzone.com/articles/kubernetes-full-stack-example-with-kong-ingress-co/) manifests to define the desired state of a cluster, making it easier to manage and track changes.
 
 ### Challenges in adopting Flux
 

docusaurus/docs/guides/serverless/aws-native/lambda-based-observability.md

@@ -179,7 +179,7 @@ One way to publish custom metrics to AWS CloudWatch is by calling CloudWatch met
 To achieve this, you can generate the logs using [EMF specification](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Specification.html), and send them to CloudWatch using `PutLogEvents` API. To simplify the process, there are **two client libraries that support the creation of metrics in the EMF** **format**.
 
 * Low level client libraries ([aws-embedded-metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Libraries.html))
-* Lambda Powertools [Metrics](https://docs.powertools.aws.dev/lambda/java/core/metrics/).
+* Lambda Powertools [Metrics](https://docs.aws.amazon.com/powertools/java/latest/core/metrics/).
 
 
 ### **Use [CloudWatch Lambda Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights.html) to monitor system-level metrics**