DEV Community: Raghu Reddy

AWS Security Hub in Action: Expert Strategies for Threat Detection and Compliance

Raghu Reddy — Tue, 30 Sep 2025 13:14:57 +0000

Beyond Static Secrets: Automating Kubernetes Secret Management with AWS Secrets Manager and External Secrets Operator

Raghu Reddy — Thu, 04 Sep 2025 06:08:20 +0000

Amazon VPC now supports idempotency for route table and network ACL creation

Raghu Reddy — Mon, 29 Jan 2024 14:30:50 +0000

Amazon VPC now supports idempotent creation of route tables and network ACLs, allowing you to safely retry creation without additional side effects. Idempotent creation of route tables and network ACLs is intended for customers that use network orchestration systems or automation scripts that create route tables and network ACLs as part of a workflow.

By adding a client token, you can now ensure that only one route table is created as part of the CreateRouteTable API request, or only one network ACL is created as part of the CreateNetworkAcl API request. With an idempotent request, once a resource is successfully created, any subsequent retries using the same client token will not create any additional resources. You can now build retry mechanisms into your creation workflow and avoid duplicate entries in an event of timeouts or server issues.

This feature is available in all AWS commercial and the AWS GovCloud (US) Regions. To get started with making idempotent API calls for CreateRouteTable and CreateNetworkACL you can visit the documentation page and API reference page.

Hashicorp support for this feature - https://lnkd.in/gPakJwGW

Securing Digital Frontiers: An In-Depth Analysis of AWS WAF

Raghu Reddy — Wed, 03 Jan 2024 05:38:03 +0000

What is AWS WAF

AWS WAF is a web application firewall that lets you monitor the HTTP(S) requests that are forwarded to your protected web application resources and Protect your web applications from common exploits. AWS WAF helps you protect against common web exploits and bots that can affect availability, compromise security, or consume excessive resources.

How AWS WAF Works

You use AWS WAF to control how your protected resources respond to HTTP(S) web requests. You do this by defining a web access control list (ACL) and then associating it with one or more web application resources that you want to protect. The associated resources forward incoming requests to AWS WAF for inspection by the web ACL.

In your web ACL, you create rules to define traffic patterns to look for in requests and to specify the actions to take on matching requests. The action choices include the following:

Allow the requests to go to the protected resource for processing and response.
Block the requests.
Count the requests.
Run CAPTCHA or challenge checks against requests to verify human users and standard browser use.

AWS WAF Components

The following are the central components of AWS WAF:

Web ACLs – You use a web access control list (ACL) to protect a set of AWS resources. You create a web ACL and define its protection strategy by adding rules. Rules define criteria for inspecting web requests and they specify the action to take on requests that match their criteria. You also set a default action for the web ACL that indicates whether to block or allow through any requests that the rules haven't already blocked or allowed. For more information about web ACLs, see Web access control lists (web ACLs).

A web ACL is an AWS WAF resource.

Rules – Each rule contains a statement that defines the inspection criteria, and an action to take if a web request meets the criteria. When a web request meets the criteria, that's a match. You can configure rules to block matching requests, allow them through, count them, or run bot controls against them that use CAPTCHA puzzles or silent client browser challenges. For more information about rules, see AWS WAF rules.

A rule is not an AWS WAF resource. It only exists in the context of a web ACL or rule group.

Rule groups – You can define rules directly inside a web ACL or in reusable rule groups. AWS Managed Rules and AWS Marketplace sellers provide managed rule groups for your use. You can also define your own rule groups. For more information about rule groups, see Rule groups. A rule group is an AWS WAF resource.

Implementing AWS WAF

Create a WEB ACL

Open WAF service and click on "Create WEB ACL"

Start filling the details and select the Amazon Cloud front distributions and then select the AWS Resources option. I have already created cloud front for the demo.

Select the Cloud front from the list and click on Add.

Click on Next, we will add Rules later.

Click on Next, Will also configure rule priority later.

We don't want metrics, will select disable option and proceed with next

The final page is for review, at the end of the page select "Create WEB ACL".

Add IP with in IP Sets to block IPs

Select IP Set section

Provide IP Set name and the IP addresses in CIDR format per line

This will create a rule set kind of database which we will use to either allow or block traffic.

Create Rule Group

Select Rule groups and click on "Create Rule Group".

In the following page we need to name the Rule group and click on next.

Click on Add rule

In the following section(below image) we will be adding the actual rule to either allow, block, count, CAPTHA or challenge.

We are basically creating
regular rule to
match the statement and
if the IP originates
from any of the IP from the BlacklistedIps IP Set
then take Action to block.
Click on Add rule to proceed

We will select the rule and click on Next keeping default values.

Since we have only one rule we will simply select the rule and click on Next. If you have multiple rule you can set/manage the rule priority here.

Review the steps and click on create rule group.

So far we have created IP Set - kind of database
Created Ruleset - what to do and when to do
and now it is time to attach this rule to the WAF

Attach rule to WAF

Select the WAF from the dashboard.

Click on rule section.

We will add the rule group that we have already created. Select "Add my own rules and rule groups"

We have different rule types, You can play around the rule type as per your requirements. For the demo we will go with Rule group, since we already have created one.
Select the Rule group and click on Add rule.

Time to test

Go the Web URL or the Cloudfront distrubution domain name to access the site.

You will get 403: Error and showing request is blocked.

Use Cases

Web Application Protection: AWS WAF helps protect web applications from common web exploits, such as SQL injection, cross-site scripting (XSS), and distributed denial-of-service (DDoS) attacks.
Bot Management: AWS WAF can be used to detect and block malicious bots, preventing them from causing harm or consuming excessive resources.
Content Filtering: AWS WAF allows you to control the content that users can access on your web applications by filtering out unwanted or malicious content.
Rate Limiting: AWS WAF enables you to set rate-based rules to limit the number of requests from specific IP addresses or user agents, protecting against brute force attacks or excessive traffic.
Compliance and Regulatory Requirements: AWS WAF helps meet compliance requirements by providing protection against known vulnerabilities and attacks, ensuring the security of sensitive data.
API Protection: AWS WAF can be used to protect APIs from unauthorized access, API abuse, and injection attacks.
Geo-blocking: AWS WAF allows you to block or allow traffic based on the geographic location of the requester, helping to prevent attacks from specific regions.
Content Security Policy (CSP) Enforcement: AWS WAF can enforce CSP headers to control how content is loaded and executed in web applications, preventing cross-site scripting (XSS) attacks.

References
https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html
https://docs.aws.amazon.com/waf/latest/developerguide/web-acl.html
https://docs.aws.amazon.com/waf/latest/developerguide/waf-rules.html
https://docs.aws.amazon.com/waf/latest/developerguide/waf-rules.html
https://crishantha.medium.com/aws-web-application-firewall-waf-ef3d46049a66

Elevate Your AWS Security: An in-Depth look at AWS Inspector

Raghu Reddy — Tue, 02 Jan 2024 11:01:12 +0000

What is Amazon Inspector

Amazon Inspector is a vulnerability management service that continuously scans your AWS workloads for software vulnerabilities and unintended network exposure. Amazon Inspector automatically discovers and scans running Amazon EC2 instances, container images in Amazon Elastic Container Registry (Amazon ECR), and AWS Lambda functions for known software vulnerabilities and unintended network exposure.

Features of Amazon Inspector

Centrally manage multiple Amazon Inspector accounts
Continuously scan your environment for vulnerabilities and network exposure
Assess vulnerabilities accurately with the Amazon Inspector Risk score
Identify high-impact findings with the Amazon Inspector dashboard
Manage your findings using customizable views
Monitor and process findings with other services and systems

Getting started with Amazon Inspector

Following steps is for activating Amazon Inspector scans for a standalone account or as an Amazon Inspector delegated administrator with AWS Organizations in a multi-account environment.

Open the Amazon Inspector console at https://console.aws.amazon.com/inspector/v2/home.
Choose Get Started.
Choose Activate Amazon Inspector.

> Amazon Inspector is a Regional service. Any of the configuration procedures that you complete must be repeated in each Region that you want to monitor with Amazon Inspector
> When you activate Amazon Inspector in a standalone account, all scan types are activated by default.

Once you activated, you see below dashboard

Managing findings in Amazon Inspector

Viewing findings

Findings can be grouped by the following parameters:

By vulnerability – Lists the most critical vulnerabilities detected in your environment. Choose a vulnerability title from this view to open a details pane with additional information.
By account – Lists your accounts, Amazon Inspector scan coverage percent for each account, and the total number of Critical and High severity findings for each account. This grouping is only available to delegated administrators.
By instance – Lists the most vulnerable Amazon EC2 instances in your environment.
By container image – Lists the most vulnerable Amazon ECR container images in your environment.
By container repository – Shows the repositories with the most vulnerabilities.
By Lambda function – Shows the Lambda functions with the most vulnerabilities.
All findings – Shows a complete list of findings for your environment. This is the default view when you navigate to the Findings page. In this view you can filter by active, suppressed, and closed findings.

Filtering findings

A finding filter allows you to view only the findings that match the criteria you specify. Findings that do not match the filter criteria are excluded from your view. You can create finding filters using the Amazon Inspector console.

Suppression rules

You can use suppression rules to automatically exclude Amazon Inspector findings that match specified criteria. For example, you can create a rule to suppress all findings with a low vulnerability score. This helps focus your view on only the findings that are the most critical to you.
Suppression rules don't have any impact on the finding itself and don't prevent Amazon Inspector from generating a finding. Suppression rules are only used to filter your list of findings.
If Amazon Inspector generates a new finding that matches a suppression rule, the service automatically sets the status of the finding to Suppressed. The findings that match suppression rule criteria don't appear by default.

Exporting findings reports

In addition to sending findings to Amazon EventBridge and AWS Security Hub, you can optionally export findings to an Amazon Simple Storage Service (Amazon S3) bucket as a findings report. A findings report is a CSV or JSON file that contains the details of findings that you choose to include in the report

Amazon Inspector deep inspection for Amazon EC2 Linux instances

With deep inspection Amazon Inspector can detect package vulnerabilities for application programming language packages in your Linux-based Amazon EC2 instances. Amazon Inspector scans default paths for programming language package libraries. You can also configure custom paths in addition to the default ones. For more information, see Custom paths for Amazon Inspector Deep inspection.

Amazon Inspector performs deep inspection scans using data collected from an Amazon Inspector SSM plugin.
Amazon Inspector collects updated application inventory from instances for deep inspection every 6 hours.

ℹ️
Deep inspection is not supported for Windows or Mac instances

Custom paths for Amazon Inspector Deep inspection

You can configure custom paths for Amazon Inspector to search when it performs Deep inspection of your Linux Amazon EC2 instances. When you add a custom path Amazon Inspector scans for packages in that directory and all sub-directories within it.

Amazon Inspector scans all custom paths in addition to the following default paths that are scanned for all accounts:

/usr/lib
/usr/lib64
/usr/local/lib
/usr/local/lib64

Set a custom path in the console
Sign in as the Amazon Inspector delegated administrator and follow the steps following to add custom paths for your organization.

Open the Amazon Inspector console at https://console.aws.amazon.com/inspector/v2/home.
Using the AWS Region selector in the upper-right corner of the page, select the Region where you want to activate Lambda standard scanning.
From the side navigation panel, under General settings, select EC2 scanning settings.
Under Custom paths for your own account , select Edit to add paths for your individual account. If you're the delegated administrator, you can choose Edit in the Custom paths for your organization pane to add custom paths for all accounts within the organization.
Enter your custom paths in the text boxes.
Choose Save to save your custom paths. Amazon Inspector will include these paths in its next Deep inspection.

Deactivate Amazon Inspector

ℹ️
Before you deactivate Amazon Inspector, we recommend that you export your findings. For more information, see Exporting findings reports from Amazon Inspector.

To deactivate Amazon Inspector

Open the Amazon Inspector console at https://console.aws.amazon.com/inspector/v2/home.
By using the AWS Region selector in the upper-right corner of the page, choose the Region in which you want to deactivate Amazon Inspector.
In the navigation pane, choose General settings.
Choose Deactivate Inspector.
When prompted for confirmation, enter deactivate in the text box, and then choose Deactivate Inspector.
(Recommended) Repeat these steps in each Region for which you want to deactivate Amazon Inspector.

Reference:
https://docs.aws.amazon.com/inspector/latest/user/what-is-inspector.html
https://docs.aws.amazon.com/inspector/latest/user/findings-understanding.html
https://docs.aws.amazon.com/inspector/latest/user/deactivating-best-practices.html

Cultivating Trust and Efficiency: Empowering Applications with Amazon EKS Pod Identity for Secure Access to AWS Services

Raghu Reddy — Fri, 29 Dec 2023 08:58:09 +0000

Introduction to Amazon EKS Pod Identity

Amazon EKS Pod Identity is a service designed to simplify AWS Identity and Access Management (IAM) permissions for applications deployed on Amazon Elastic Kubernetes Service (EKS) clusters. As a fully managed Kubernetes service, Amazon EKS streamlines the deployment, management, and scaling of containerized applications on AWS. user guide

High level Amazon EKS Pod Identity architecture

The Challenge: IAM Permissions in Kubernetes

In a standard Kubernetes environment, pod applications frequently interact with various AWS services like Amazon S3, AWS RSD, and others. Previously , the only way to achieve this was to hardcode IAM credentials in the cluster, or to use the worker node's IAM role—both being highly dangerous and discouraged practice.
Managing AWS IAM permissions for these applications can be complex.
Amazon EKS Pod Identity addresses this challenge by providing a way to associate AWS IAM roles directly with Kubernetes service accounts. This association allows applications running in Amazon EKS pods to assume AWS IAM roles seamlessly without requiring developers to manage AWS credentials directly within the application code or configuration.

How EKS Pod Identity Agent works with a Pod

    env:
    - name: AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE
      value: "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token"
    - name: AWS_CONTAINER_CREDENTIALS_FULL_URI
      value: "http://169.254.170.23/v1/credentials"
    volumeMounts:
    - mountPath: "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/"
      name: eks-pod-identity-token
  volumes:
  - name: eks-pod-identity-token
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          audience: pods.eks.amazonaws.com
          expirationSeconds: 86400 # 24 hours
          path: eks-pod-identity-token

When Amazon EKS starts a new pod that uses a service account with an EKS Pod Identity association, the cluster adds the following above content(code block) to the Pod manifest
Kubernetes selects which node to run the pod on. Then, the Amazon EKS Pod Identity Agent on the node uses the AssumeRoleForPodIdentity action to retrieve temporary credentials from the EKS Auth API.
The EKS Pod Identity Agent makes these credentials available for the AWS SDKs that you run inside your containers.
You use the SDK in your application without specifying a credential provider to use the default credential chain. Or, you specify the container credential provider. For more information about the default locations used, see the Credential provider chain in the AWS SDKs and Tools Reference Guide.
The SDK uses the environment variables to connect to the EKS Pod Identity Agent and retrieve the credentials.

Note

If your workloads currently use credentials that are earlier in the chain of credentials, those credentials will continue to be used even if you configure an EKS Pod Identity association for the same workload.

Benefits of Using EKS Pod Identity

Simplified AWS credential management: EKS Pod Identity eliminates the need to manage AWS credentials within your application code or container environment variables, streamlining the credential management process.
Enhanced security: By leveraging AWS Identity and Access Management (IAM) roles, EKS Pod Identity provides fine-grained access control, reducing the risk of unauthorized access and enhancing the overall security of your applications.
Seamless integration with AWS services: EKS Pod Identity allows your applications running on EKS to seamlessly authenticate and authorize access to various AWS services using IAM roles, eliminating the need for managing access keys or storing sensitive credentials within your application code.
Simplified deployment and management: EKS Pod Identity is designed to work seamlessly with EKS clusters, making it easy to deploy and configure. This simplifies the deployment and management process, reducing the operational overhead associated with managing AWS credentials.

Overall, EKS Pod Identity provides a convenient and secure way to manage AWS credentials, enhance security, seamlessly integrate with AWS services, and simplify the deployment and management of your applications on EKS clusters.

Real-World Use Cases of EKS Pod Identity

Serverless Data Processing: EKS Pod Identity can be used in conjunction with AWS Lambda to enable serverless data processing pipelines. By assigning IAM roles to Lambda functions, you can securely access and process data stored in AWS services like Amazon S3 or DynamoDB within your EKS cluster.
Microservices Architecture: In a microservices architecture, EKS Pod Identity can provide secure and granular access to AWS services for each microservice. Each microservice can have its own IAM role associated with its pods, allowing it to access specific AWS resources independently.
Machine Learning Workloads: EKS Pod Identity is valuable in machine learning scenarios. It allows training jobs running on EKS to securely access datasets stored in Amazon S3 or retrieve model artifacts from AWS services like Amazon SageMaker.
Data Analytics and Business Intelligence: EKS Pod Identity can enable data analytics and business intelligence applications to securely access and process data stored in AWS services. Applications can retrieve and analyze data from sources like Amazon Redshift, Amazon Athena, or Amazon QuickSight within the EKS cluster.
Cloud-Native CI/CD Pipelines: EKS Pod Identity can be integrated into cloud-native CI/CD pipelines to ensure secure and authorized access to AWS services during the build, test, and deployment processes. IAM roles associated with pods can be used to authenticate and authorize interaction with resources like AWS CodeCommit, AWS CodeBuild, or AWS CodeDeploy.

Overview of setting up EKS Pod Identities

Turn on EKS Pod Identities by completing the following procedures:

Setting up the Amazon EKS Pod Identity Agent – You only complete this procedure once for each cluster.
Configuring a Kubernetes service account to assume an IAM role with EKS Pod Identity – Complete this procedure for each unique set of permissions that you want an application to have.
Configuring Pods to use a Kubernetes service account – Complete this procedure for each Pod that needs access to AWS services.
Using a supported AWS SDK – Confirm that the workload uses an AWS SDK of a supported version and that the workload uses the default credential chain.

EKS Pod Identity Restrictions

EKS Pod Identities are available on the following:

Amazon EKS cluster versions listed below
Worker nodes in the cluster that are Linux Amazon EC2 instances.

Kubernetes version	Platform version
1.28	eks.4
1.27	eks.8
1.26	eks.9
1.25	eks.10
1.24	eks.13

EKS Pod Identities aren't available on the following:

China Regions.
AWS GovCloud (US).
AWS Outposts.
Amazon EKS Anywhere.
Kubernetes clusters that you create and run on Amazon EC2. The EKS Pod Identity components are only available on Amazon EKS.

You can't use EKS Pod Identities with:

Pods that run anywhere except Linux Amazon EC2 instances. Linux and Windows pods that run on AWS Fargate (Fargate) aren't supported. Pods that run on Windows Amazon EC2 instances aren't supported.
Amazon EKS add-ons that need IAM credentials. The EKS add-ons can only use IAM roles for service accounts instead. The list of EKS add-ons that use IAM credentials include:
- Amazon VPC CNI plugin for Kubernetes
- AWS Load Balancer Controller
- The CSI storage drivers: EBS CSI, EFS CSI, Amazon FSx for Lustre CSI driver, Amazon FSx for NetApp ONTAP CSI driver, Amazon FSx for OpenZFS CSI driver, Amazon File Cache CSI driver

Note

If these controllers, drivers, and plugins are installed as self-managed add-ons instead of EKS add-ons, they support EKS Pod Identities as long as they are updated to use the latest AWS SDKs.

References
https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-eks-pod-identity/
https://aws.amazon.com/blogs/aws/amazon-eks-pod-identity-simplifies-iam-permissions-for-applications-on-amazon-eks-clusters/
https://aws.amazon.com/blogs/containers/amazon-eks-pod-identity-a-new-way-for-applications-on-eks-to-obtain-iam-credentials/

Demystifying HELM: A Beginner's Guide to Kubernetes Package Management

Raghu Reddy — Tue, 14 Nov 2023 10:25:00 +0000

What is Helm?

Kubernetes(k8s) is an open-source platform that automates the deployment, scaling, and management of containerized applications. However, managing complex applications within Kubernetes can be challenging. This is where Helm comes in. Helm is a powerful package manager for Kubernetes, providing a streamlined way to define, install, and upgrade even the most intricate Kubernetes applications through the use of charts.

Helm is a graduated project in the CNCF and is maintained by the Helm community.

How to Install Helm

Installing Helm is a straightforward process. You can download the binary for your specific operating system from the official Helm GitHub repository. Once downloaded, follow the platform-specific installation instructions provided in the documentation.
https://helm.sh/docs/intro/install/

Why Use Helm?

Helm significantly eases the deployment process on Kubernetes by allowing you to define, install, and upgrade even the most complex Kubernetes applications. It promotes consistency and repeatability in the deployment process, making it an invaluable tool for managing Kubernetes clusters.

Pre-requisites

Before you begin using Helm, ensure that you have a running Kubernetes cluster. Additionally, you should have basic knowledge of Kubernetes concepts, such as pods, deployments, and services, to effectively utilize Helm for managing your applications.

Key Components

Charts

Charts are Helm packages that contain pre-configured Kubernetes resources necessary to run a specific application.

Releases

Releases are instances of a chart running in a Kubernetes cluster. Each release has a unique release name that is used to identify the deployed resources.

Repositories

Helm repositories store and distribute charts. They can be public or private, allowing users to share and discover Kubernetes applications easily.

Pre-requisite (We need kubernetes cluster)

Create AWS EKS Cluster - In Progress
Create Azure Kubernetes Cluster - In Progress

Creating a Sample Nginx Helm Chart and Testing It

We will try deploying nginx on k8s cluster.

To create a sample Nginx Helm chart, you can use the Helm CLI. First, use the helm create command to generate the basic directory structure for the chart.

$ > helm create nginx-demo

Creating nginx-demo

You can check the content of the folder that got created.

We will try to inspect the structure and it's content inside.

The first two files you see—Chart.yaml and values.yaml—define what the chart is and what values will be in it at deployment

We have values.yaml, in that all the values for nginx deployment can be configured. Declared variables to be passed into your templates at run time.
For example, we have below reference values.yaml file.

After making the necessary changes, use the helm install command to deploy the Nginx chart to your Kubernetes cluster.
Syntax and Example
helm install <release name> ./nginx-demo

$ > helm install nginx-dev-rel ./nginx-demo
NAME: nginx-dev-rel
LAST DEPLOYED: Tue Nov  14 15:35:09 2023
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
1. Get the application URL by running these commands:
  http://chart-example.local/

This command lists all of the releases for a specified namespace
helm list

 $ >  helm list
NAME        NAMESPACE   REVISION    UPDATED                                 STATUS      CHART               APP VERSION
nginx-dev   default     1           2023-11-14 15:35:09.214273 +0530 IST    deployed    nginx-demo-0.1.0    1.16.0

To display the status of the named release,
Syntax and Example
helm status <release name>

$ > helm status nginx-dev-rel
NAME: nginx-dev-rel
LAST DEPLOYED: Tue Nov  14 15:35:09 2023
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
1. Get the application URL by running these commands:
  http://chart-example.local/

Accessing Application

$ > export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=nginx-chart,app.kubernetes.io/instance=nginx-demo" -o jsonpath="{.items[0].metadata.name}")
$ > kubectl port-forward $POD_NAME 8080:80
Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80

Visit http://127.0.0.1:8080 to use your application

Happy Helming. You have deployed Nginx using HELM

Best Practices

Version your Helm charts to ensure consistency and traceability.
Use values files to manage configuration and make your Helm charts configurable.
Test your Helm charts thoroughly in a staging environment before deploying them to production.

Reference Links

Amazon CloudWatch Container Insights launches enhanced observability for Amazon EKS

Raghu Reddy — Tue, 07 Nov 2023 07:05:38 +0000

Amazon CloudWatch Container Insights now delivers enhanced observability for Amazon Elastic Kubernetes Service (EKS) with out-of-the-box detailed health and performance metrics, including container level EKS performance metrics, Kube-state metrics and EKS control plane metrics for faster problem isolation and troubleshooting.

You can get started with Container Insights by installing the CloudWatch observability add-on in your clusters after they are created using the add-ons tab in your cluster info view. Container Insights now delivers overall container health and performance visibility via a landing page where you can navigate to the performance dashboards view for detailed analysis by navigating to View performance dashboards link on the top right.

Setting up Container Insights on Amazon EKS and Kubernetes

Container Insights is supported on Amazon EKS versions 1.23 and later. The quick start method of installation is supported only on versions 1.24 and later.

The overall process for setting up Container Insights on Amazon EKS or Kubernetes is as follows:

Verify that you have the necessary prerequisites.
Set up the Amazon CloudWatch Observability EKS add-on, the CloudWatch agent, or AWS Distro for OpenTelemetry on your cluster to send metrics to CloudWatch.

Note
To use Container Insights with enhanced observability for Amazon EKS, you must use the Amazon CloudWatch Observability EKS add-on or the CloudWatch agent. For more information about this version of Container Insights, see Container Insights with enhanced observability for Amazon EKS.
To use Container Insights with Fargate, you must use AWS Distro for OpenTelemetry.

Set up Fluent Bit or Fluentd to send logs to CloudWatch Logs. (This is enabled by default if you install the Amazon CloudWatch Observability EKS add-on.)

You can perform these steps at once as part of the quick start setup if you are using the CloudWatch agent, or do them separately.

(Optional) Set up Amazon EKS control plane logging.
(Optional) Set up the CloudWatch agent as a StatsD endpoint on the cluster to send StatsD metrics to CloudWatch.
(Optional) Enable App Mesh Envoy Access Logs.

Viewing Container Insights metrics

After you have Container Insights set up and it is collecting metrics, you can view those metrics in the CloudWatch console.

For Container Insights metrics to appear on your dashboard, you must complete the Container Insights setup. For more information, see Setting up Container Insights.

This procedure explains how to view the metrics that Container Insights automatically generates from the collected log data. The rest of this section explains how to further dive into your data and use CloudWatch Logs Insights to see more metrics at more levels of granularity.

To view Container Insights metrics

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
In the navigation pane, choose Insights, Container Insights.
In the drop-down box under Container Insights, choose Performance monitoring.
Use the drop-down boxes near the top to select the type of resource to view, as well as the specific resource.

Container Insights is available in all public AWS Regions, including the AWS GovCloud (US) Regions, China (Beijing, operated by Sinnet), and China (Ningxia, operated by NWCD). Container Insights with enhanced observability for EKS comes with a new observation-based pricing – see pricing page for details. For further information, visit the Container Insights documentation.

Reference -
https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-cloudwatch-container-insights-enhanced-observability-eks/
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-view-metrics.html

EKS now allows modification of cluster subnets and security groups

Raghu Reddy — Wed, 25 Oct 2023 17:23:38 +0000

The recent update from Amazon Elastic Kubernetes Service (EKS) on October 24, 2023, announced a new feature that allows customers to modify the subnets and security groups associated with their existing EKS clusters. This enhancement aims to provide greater flexibility for cluster administrators to synchronize changes made to Amazon Virtual Private Cloud (VPC) resources, simplifying cluster management.

The problem that this update addresses is the challenge of adapting EKS clusters to changes in the underlying VPC resources, such as modifications or expansions in the VPC subnets. Previously, when changes were made to VPC resources, it necessitated the creation of new EKS clusters, which could be time-consuming and complex, especially for production environments.

The solution introduced by Amazon EKS is the capability for customers to update the subnets and security groups associated with their existing EKS clusters directly. This means that when changes occur in the VPC resources, such as modifications to the subnets due to VPC expansion, customers can now conveniently update their EKS clusters without the need to create new ones.

With this new functionality, cluster administrators can easily ensure that their EKS clusters remain synchronized with any changes made to the underlying VPC resources, thus streamlining the management process. This feature is immediately available for use on all existing EKS clusters across all AWS Regions where EKS is accessible. Customers interested in utilizing this feature can refer to the EKS documentation for detailed instructions on getting started.

Reference:

Web Shell - Browser-based Shell - AWS CloudShell

Raghu Reddy — Tue, 24 Oct 2023 04:27:27 +0000

AWS CloudShell

AWS CloudShell is a browser-based shell that gives you command-line access to your AWS resources in the selected AWS region. AWS CloudShell comes pre-installed with popular tools for resource management and creation. You have the same credentials as you used to log in to the console.

You can run AWS CLI commands using your preferred shell, such as Bash, PowerShell, or Z shell. And you can do this without downloading or installing command line tools.

Getting started

First, you sign in to the AWS Management Console and select an AWS Region. You then launch CloudShell

Or in the Search box, type “CloudShell”, and then choose CloudShell.

When you launch AWS CloudShell, a compute environment that's based on Amazon Linux 2 is created. Within this environment, you can access an extensive range of pre-installed development tools, 1 GB of Storage free per AWS region(storage persists after the session ends), options for uploading and downloading files, and file storage that persists between sessions.

Some packages and their list below

You can also switch your CloudShell session to a full screen by clicking Open in new browser tab.

Once you ready with the cloud shell, you can start playing around the shell.

Supported browsers for AWS CloudShell

The following table lists the supported browsers for AWS CloudShell.

Browser	Version
Google Chrome	Latest three major versions
Mozilla Firefox	Latest three major versions
Microsoft Edge	Latest three major versions
Apple Safari for macOS	Latest two major versions

Service quotas and restrictions

With AWS CloudShell, you have persistent storage of 1 GB for each AWS Region at no cos
There are monthly usage quotas for AWS CloudShell for each AWS Region in your AWS account
The command size cannot exceed 65412 characters
You can run up to 10 shells at the same time in each AWS Region for your account
No Inbound traffic, only outbound traffic is allowed. You can access the public internet.

CloudShell will migrate from Amazon Linux 2 to Amazon Linux 2023 starting December 4, 2023. For more information, see the User Guide
CloudShell-AL2023-Migration

Reference:
AWS Cloud Shell

Embarking on my AWS Journey: Exploring AWS global-infrastructure

Raghu Reddy — Mon, 23 Oct 2023 11:35:23 +0000

Dear Readers,

I am thrilled to embark on this exciting journey to contribute back to the community. As someone passionate about technology and innovation, I am eager to delve deeper into the world of cloud computing and share my learnings and experiences with you all. In this first blog post, I aim to introduce to AWS regions, Availability zones, Local zone and Edge networks along with building blocks of Amazon Web Services.

Let's begin the journey.

Understanding AWS

Amazon Web Services (AWS) is a comprehensive and widely adopted cloud computing platform offered by Amazon. It provides numerous services that enable organizations to build and deploy sophisticated applications with increased flexibility, scalability, and reliability. From computing power to storage solutions, databases to content delivery, AWS offers a vast array of services tailored to meet the diverse needs of businesses and developers worldwide.

AWS Regions

AWS has the concept of a Region, which is a physical location around the world where data centers are clustered. We call each group of logical data centers an Availability Zone. Each AWS Region consists of a minimum of three, isolated, and physically separate AZs within a geographic area.

Availability Zones (AZs)

An Availability Zone (AZ) is one or more discrete data centers with redundant power, networking, and connectivity in an AWS Region. All AZs in an AWS Region are interconnected with high-bandwidth, low-latency networking, over fully redundant, dedicated metro fiber providing high-throughput, low-latency networking between AZs. All traffic between AZs is encrypted.

AWS Local Zones

AWS Local Zones place compute, storage, database, and other select AWS services closer to end-users. With AWS Local Zones, you can easily run highly-demanding applications that require single-digit millisecond latencies to your end-users such as media & entertainment content creation, real-time gaming, reservoir simulations, electronic design automation, and machine learning.

Edge Networks

AWS Edge Locations are endpoints for AWS which are used for caching content and accelerating access to AWS services. They are part of the Amazon CloudFront content delivery network (CDN) and are located in most major cities around the world. AWS edge networking services securely transmit your user-facing data and with improved latency worldwide.

As of October 2023,

There are total 32 Launched Regions each with multiple Availability Zones (AZs).
102 Availability Zones
35 Local Zones& 29 Wavelength Zones for ultralow latency applications
550+ Points of Presence and 13 Regional Edge Caches
245 Countries and Territories Served
115 Direct Connect Locations

You can keep updated yourself by referring below links:

AWS global Infrastructure
AWS Local Zone
AWS Edge Network
AWS Documentation