DEV Community: Soumya

ECS vs. ECS Anywhere & EKS vs. EKS Anywhere: Making the Right Choice for Your Workloads

Soumya — Sat, 25 Jan 2025 08:29:53 +0000

As organizations increasingly embrace containerization to modernize their applications ,Containerization & its orchestration is becoming the key prospective towards Application transformation journey from Legacy ,monolithic to Microservices & Cloud agnostic . In this blog we will try to scratch the surface of ECS Anywhere & EKS Anywhere . We will understand the following areas :-

What Are ECS and ECS Anywhere?
What Are EKS and EKS Anywhere?
Key Comparisons
Real-World Examples with Step by Step guide to install ECS & EKS Anywhere

What Are ECS and ECS Anywhere?

Amazon ECS (Elastic Container Service) is a fully managed container orchestration service that allows you to deploy, manage, and scale containerized applications on AWS infrastructure.

Amazon ECS Anywhere, on the other hand, extends ECS's capabilities to run containers on on-premises or other cloud environments. It provides the flexibility to run and manage containers in hybrid or multi-cloud environments using the same ECS control plane.

What Are EKS and EKS Anywhere?

Amazon EKS (Elastic Kubernetes Service) is a managed Kubernetes service on AWS, enabling developers to run Kubernetes workloads without the operational overhead of managing the control plane.

Amazon EKS Anywhere allows businesses to run Kubernetes clusters on-premises or in any environment, offering the same Kubernetes experience as Amazon EKS but tailored to hybrid cloud strategies.

1. Key Comparisons

Control Plane Management

- ECS and EKS handle control plane management for you in the AWS cloud.
- ECS Anywhere and EKS Anywhere bring this capability to on-prem or edge environments, giving you more control and flexibility.

Ease of Use

- ECS is simpler to set up and use, especially for teams that prefer AWS-native solutions.
- EKS provides the flexibility of Kubernetes, which might be more complex but is a better choice for organizations with Kubernetes expertise.

Hybrid Cloud Support

ECS Anywhere and EKS Anywhere are designed for hybrid and multi-cloud deployments, making them ideal for organizations that want to maintain some workloads on-premises or across multiple clouds.

Cost and Resource Optimization

ECS and ECS Anywhere are generally cost-effective, especially for simpler workloads. EKS and EKS Anywhere provide more flexibility but come with additional management overhead and cost.

Security & Governance

Both ECS & EKS Anywhere ensures isolation of data ,compliance of data & meet regulatory norms especially based on HIPAA ,GDPR guidelines which assist clients gain its market adoption & add more values & proximity towards end users .

Real-World Examples with Step by Step guide :-

Imagine a healthcare provider wants to run patient data applications on-premises to comply with data residency laws, but they also want centralized management through AWS.

1. Setting up ECS Anywhere

At least one server with Linux or Windows installed.
Sufficient CPU, memory, and storage.
ECS Anywhere uses the SSM agent to manage on-prem servers
docs.aws.amazon.com
Next to Register & De register any external instances with ECS Cluster
docs.aws.amazon.com
Create task definitions for your healthcare application (e.g., containerized patient record management).
Push your application containers to Amazon Elastic Container Registry (ECR) or another container registry.
Deploy the tasks to the on-premises server through the ECS cluster.
Monitor the health and performance of tasks directly in the AWS console.

2. Setting up EKS Anywhere

Imagine a manufacturing firm wants to deploy IoT-enabled applications at factory locations for real-time data processing. EKS Anywhere allows them to manage these Kubernetes clusters local .

Minimum: 2 CPUs, 8GB RAM, and 50GB storage per node.
Install virtualization software like VMware vSphere or bare-metal servers.
Set up a dedicated control plane server (e.g., a Linux laptop or server).
Run the EKS Anywhere CLI to create an "Control plane node" (used to manage other Kubernetes clusters).
Use a pre-configured configuration file to define cluster details like networking and node sizes.
Use kubectl commands to deploy IoT-enabled apps to the Kubernetes cluster.
These applications process data from manufacturing IoT devices locally.
Monitor the Cluster via CloudWatch agent installed on those On-premises servers .

1. Admin Machine | EKS Anywhere

Steps for setting up the Admin Machine

anywhere.eks.amazonaws.com

Key Takeaways

- ECS Anywhere is simpler for containerized workloads that don’t require Kubernetes complexity.
- EKS Anywhere is ideal if you already use Kubernetes or need advanced orchestration in hybrid environments.

Kubectl Top command:-Secrets behind scenes

Soumya — Sun, 20 Oct 2024 05:04:49 +0000

Metrics Server is typically installed as an add-on in Kubernetes clusters, including in Minikube & other K8's clusters. It is not installed by default in most Kubernetes clusters, but it can be easily added. It is an optional add-on that you install to provide real-time resource utilization data for nodes and pods.

It is a lightweight service designed to work with the Kubernetes Metrics API to provide metrics like CPU and memory usage for horizontal pod autoscaling (HPA), the kubectl top command, and more.

If the Metrics Server is not installed, commands like kubectl top or the Horizontal Pod Autoscaler won’t have the necessary data for CPU and memory metrics.

In a Minikube Cluster:

Minikube is a local Kubernetes cluster, and similar to full Kubernetes clusters, the Metrics Server is also not enabled by default.

You can enable it in Minikube using a specific add-on command.
Installing Metrics Server in Minikube:

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

This will install the Metrics Server into your cluster.

Verify Metrics Server Deployment

After installing, check if the Metrics Server is running properly:

kubectl get pods -n kube-system

You should see a metrics-server pod running. For example:

NAME                                 READY   STATUS    RESTARTS   AGE
metrics-server-86cbb8457f-zkhrn       1/1     Running   0          1m

Now just execute below commands to listed all pods , nodes in default , respective namespace .

kubectl top pods 
kubectl top nodes 
kubectl top pods -n <namespace>
kubectl top pods --all-namespaces

Now deep dive a little bit .
View Resource Usage for a Specific Pod:-

kubectl top pod <pod-name> -n <namespace>

View Container Resource Usage within a Pod

kubectl top pod <pod-name> -n <namespace> --containers

Sort by Resource Usage (CPU or Memory):-

kubectl top pods -n <namespace> --sort-by=cpu
kubectl top pods -n <namespace> --sort-by=memory

Now let's walkthrough a real world troubleshooting scenario on where post installing Metrics server its not able to execute kubectl top commands and getting error as Metrics API not available .

Workaround Step by Step :-
I assume that Metrics server adds-on already installed ,so not going through the steps as those has been already mentioned above.

Verify Metrics Server Deployment

kubectl get pods -n kube-system

You should see a metrics-server pod running. For example:

metrics-server-86cbb8457f-zkhrn       1/1     Running   0          1m

Check Logs for Errors

kubectl logs -n kube-system <metrics-server-pod-name>

Now comes the most important part :-
Ensure Proper Configuration
The Metrics Server requires proper API access and SSL certificates to function correctly. Some common configuration issues might involve:

TLS or certificate issues: If you're using self-signed certificates, ensure the certificates are set up correctly.

API Server flags: The Kubernetes API server must allow the Metrics Server to access metrics. Ensure the --kubelet-insecure-tls flag is set if you are in a development environment:

Wait for Metrics to Populate
After starting the Metrics Server, it may take a few minutes for it to collect and expose metrics from the nodes and pods. Try running kubectl top nodes again after a couple of minutes

kubectl top nodes

** Check Kubelet Configuration**

The Kubelet (running on each node) must expose its metrics to the Metrics Server. Ensure that the --authentication-token-webhook and --authorization-mode=Webhook flags are enabled on your Kubelet configuration, allowing it to authenticate API requests.

Edit the Metrics Server deployment:

kubectl edit deployment metrics-server -n kube-system

Add the --kubelet-insecure-tls flag under the args section in the container definition

spec:
  containers:
  - name: metrics-server
    image: k8s.gcr.io/metrics-server/metrics-server:v0.6.2
    args:
      - --cert-dir=/tmp
      - --secure-port=4443
      - --kubelet-preferred-address-types=InternalIP,Hostname,ExternalIP
      - --kubelet-insecure-tls

Save and exit. Kubernetes will automatically update and restart the Metrics Server pod.

** Restart Metrics Server**
After applying any of the above changes, you should restart the Metrics Server to ensure it picks up the new configuration:

kubectl rollout restart deployment metrics-server -n kube-system

Check Logs and Verify
After restarting, check the Metrics Server logs to ensure the issue is resolved:

kubectl logs -n kube-system <metrics-server-pod-name>

Now run the top command again .

kubectl top nodes
kubectl top pods

Conclusion:
The Metrics Server is an essential tool in Kubernetes, enabling real-time resource monitoring and driving features like the Horizontal Pod Autoscaler (HPA). While it focuses on lightweight and short-term metrics, it is a key component for ensuring efficient resource management and auto-scaling within a cluster.

Uncovering SAST ,DAST ,OWASP Dependency-Check in DevSecOps family (Part-2)

Soumya — Thu, 17 Oct 2024 14:44:11 +0000

In the first part I uncovered the fundamentals of DevSecOps principles and demonstrates with a Jenkins Pipeline . Following that blog I will explain all other DevSecOps tools commonly used in a Jenkins Pipeline in separate stages. Let's delve and try to under stand the SAST ,DAST & OWASP Dependency Check in a simple terms & from the Jenkins Pipeline prospective .

What is SAST?
SAST (Static Application Security Testing) is like a spell-checker for your code, but instead of checking for grammar, it searches for security vulnerabilities. SAST tools scan the source code (without executing it) to identify potential vulnerabilities early in the development cycle, such as SQL injections, cross-site scripting (XSS), or insecure configurations.

When is SAST used ?
SAST is typically used during the development phase and analyzes the code before it's run. It integrates into the CI pipeline, flagging vulnerabilities while developers are still writing and testing code.

What is DAST?
DAST (Dynamic Application Security Testing), on the other hand, is a "black-box" testing approach that simulates real-world attacks on your running application. It doesn’t look at the code itself but focuses on finding vulnerabilities in the application’s behavior during runtime. DAST tests an application in an operational state to uncover vulnerabilities like misconfigurations, authentication issues, or common web application attacks (e.g., SQLi, XSS).

When is DAST used ?

DAST is often used later in the CI/CD pipeline, after the application has been built and deployed to a testing environment. It ensures the application is secure under actual running conditions.

OWASP Dependency-Check: Finding Vulnerabilities in Dependencies
OWASP Dependency-Check focuses on third-party libraries and dependencies your project uses. Many vulnerabilities lie in outdated or insecure libraries, which can easily slip under the radar. Dependency-Check scans the dependencies for known vulnerabilities in the National Vulnerability Database (NVD) and alerts developers to update or fix vulnerable versions.

Why is this important ?

With modern applications depending on numerous open-source libraries, it’s vital to ensure these third-party components are secure. A vulnerable library can become the weakest link, compromising the security of the entire application.

Real-World Example of SAST, DAST, and OWASP Dependency-Check

Let’s imagine a real-world scenario where you’re building a web application using Python on the backend, React on the frontend, and a MySQL database. As part of the DevSecOps team, you want to ensure that your CI/CD pipeline not only tests functionality but also performs security checks.

1. SAST Example:
Before your developers push their code to the repository, a SAST tool such as SonarQube is integrated into the Jenkins pipeline. It scans the Python backend code for hardcoded credentials, insecure API calls, and SQL injection vulnerabilities.

How it works:
SonarQube scans the source code (before execution) and produces a report identifying any vulnerabilities in the logic.
Developers can view the report directly in Jenkins and fix the vulnerabilities before proceeding.

2. DAST Example:
After the code is built and deployed in a staging environment, a DAST tool like OWASP ZAP (Zed Attack Proxy) runs dynamic tests against the running application. It simulates common web-based attacks to identify potential vulnerabilities like cross-site scripting (XSS) and SQL injection.

How it works:
Jenkins triggers OWASP ZAP to scan the running application.
ZAP performs attacks (e.g., tries to inject SQL statements in input fields) and reports on vulnerabilities that exist in the running application.

OWASP Dependency-Check Example As part of your build process, OWASP Dependency-Check scans your application’s dependencies for known vulnerabilities. Let’s say you’re using an older version of requests library in Python that contains a security flaw. Dependency-Check flags it as vulnerable and suggests updating to a safer version.

How it works:
The tool analyzes the libraries listed in your project (like requirements.txt in Python or package.json in Node.js).
Jenkins runs a scan and provides a detailed report, listing which dependencies are vulnerable, along with their CVE identifiers.

Now let's walkthrough how those actually functions in a typical Jenkins Pipeline .

SAST with SonarQube Plugin: The SonarQube Scanner Plugin for Jenkins allows seamless integration of static code analysis into your pipeline. It runs SonarQube scans and presents the results in Jenkins. Usage: After a code push or pull request, Jenkins triggers a static code scan using SonarQube.

sonarScanner {
    scannerHome = tool 'SonarQubeScanner'
    options = ['-Dsonar.projectKey=my-project', '-Dsonar.sources=.']
}

Now let's understand the above code part with a real world example :-
Imagine you are part of a team developing an online shopping application, and you want to ensure the code quality is maintained throughout the development process. You decide to use SonarQube for static code analysis to detect bugs, vulnerabilities, and code smells.

Here’s how this snippet fits in:

Scenario:
You are working on a new feature in the shopping cart section of the app, and you want to ensure that the code you write adheres to best practices.
Before merging your feature branch into the main branch, you need to check for issues like security vulnerabilities or bad coding patterns using SonarQube.

What the code does?

sonarScanner block: Jenkins is running a pipeline to build and test your code. As part of this process, it runs the SonarQube scanner.
scannerHome = tool 'SonarQubeScanner': Jenkins uses the SonarQube scanner installed on the server to perform code analysis.
options = ['-Dsonar.projectKey=my-project', '-Dsonar.sources=.']:

-Dsonar.projectKey=my-project: This tells SonarQube which project the code belongs to, in this case, the shopping cart app (my-project).

-Dsonar.sources=.: This indicates that the source code to be analyzed is located in the current directory of the project.

DAST (Dynamic Application Security Testing) Command Example: :-

In Jenkins, you could integrate a DAST tool like OWASP ZAP to scan your running application for security vulnerabilities. Here's a simplified version of how you might configure it:

zap-cli scan --target http://my-web-app.com

Explanation:
zap-cli scan: This command runs a DAST scan using OWASP ZAP.
--target http://my-web-app.com: Specifies the target web application URL that will be dynamically tested for vulnerabilities like SQL injection or XSS (cross-site scripting).

***Real-world example:*
Imagine you’ve built an online payment platform, and you want to check if your live application is vulnerable to attacks. This command dynamically tests your app while it’s running, simulating real-world attacks to ensure the app is secure.

OWASP Dependency-Check Command Example:
This tool only scans the third party libraries such as Lodash , Spring integrated with my application during build, development phase .

dependency-check --project MyApp --scan /path/to/project

Explanation:
dependency-check: Runs the OWASP Dependency-Check tool.
--project MyApp: Specifies the name of your project, like "MyApp"
--scan /path/to/project: Points to the directory where your project’s code and dependencies are located.

Real-world example:
Let’s say you’re building a social media app and you’ve used several third-party libraries like Lodash or Spring. This command checks all the libraries in your app for known vulnerabilities. If any are found, you can update the affected libraries before deploying the app, preventing potential security risks.

Conclusion
In the DevSecOps family, tools like SAST, DAST, and OWASP Dependency-Check ensure that security is baked into the development process. Jenkins pipelines make it incredibly easy by installing proper plugins with no additional cost to integrate these tools, providing an automated, scalable, and visible solution for secure code delivery. By adding security as a step in your Jenkins CI/CD pipeline, you can catch vulnerabilities early, reduce risks, and deliver safer applications to your users.

***Now, with Jenkins as your trusted butler and SAST, DAST, and Dependency-Check as your loyal security team, your DevSecOps journey just got a whole lot smoother!*😉😎

DevSecOps Fundamentals: Security in the Jenkins Pipeline

Soumya — Sun, 06 Oct 2024 07:31:21 +0000

In today’s rapidly evolving software development landscape, speed is crucial. However, speed without security can lead to disaster. That's where DevSecOps comes in, combining the agile nature of DevOps with a security-first mindset. In this blog, I will introduce you to the core concepts of DevSecOps and show how you can integrate security checks directly into your CI/CD pipeline using Jenkins.

What is DevSecOps?

DevSecOps stands for Development, Security, and Operations. It’s an approach that emphasizes embedding security throughout the entire software development lifecycle, from planning and coding to deployment and operations.

Instead of treating security as an afterthought or a final stage, DevSecOps ensures that every phase of development has built-in security controls. The goal is to shift security , meaning it is introduced early in the development process rather than after code has been written.

Why DevSecOps?

In a typical DevOps setup, the emphasis is on speed and automation—building, testing, and deploying software faster. However, security often gets neglected or delayed until after deployment, making applications vulnerable to attacks. By adopting DevSecOps, you ensure that:

Security risks are identified early.
Vulnerabilities are fixed during development, not after the product is deployed.
Teams collaborate to deliver secure, reliable, and compliant software at a faster pace.

Jenkins and DevSecOps Integration

Now, let's explore how you can embed security into your Jenkins pipeline. Jenkins, a powerful automation server, is widely used for continuous integration and delivery (CI/CD). By integrating security tools into Jenkins pipelines, we can ensure that security checks are automatically performed on every build.

A Jenkins Pipeline Example for DevSecOps

In this section, I'll demonstrate a simple Jenkins pipeline that includes security checks at key stages. We'll use tools like:

SAST (Static Application Security Testing): Scanning the source code for vulnerabilities.
Dependency Check: Ensuring there are no known vulnerabilities in third-party libraries.
Container Image Scanning: Checking Docker images for vulnerabilities.

Jenkins and DevSecOps Integration

A Jenkins Pipeline Example for DevSecOps

In this section, I'll demonstrate a simple Jenkins pipeline that includes security checks at key stages. We'll use tools like:

SAST (Static Application Security Testing): Scanning the source code for vulnerabilities.
Dependency Check: Ensuring there are no known vulnerabilities in third-party libraries.
Container Image Scanning: Checking Docker images for vulnerabilities.

Here's an example of a Jenkinsfile that demonstrates these concepts:

pipeline {
    agent any

    stages {
        stage('Checkout Code') {
            steps {
                // Pull the latest code from GitHub or your source control
                git url: 'https://github.com/your-repository.git', branch: 'main'
            }
        }

        stage('Build') {
            steps {
                // Compile the application or build the Docker image
                sh 'mvn clean install' // or docker build
            }
        }

        stage('Static Code Analysis (SAST)') {
            steps {
                // Run SAST tool like SonarQube to check for vulnerabilities in the code
                script {
                    // Run SonarQube scan
                    sh 'sonar-scanner -Dsonar.projectKey=my_project -Dsonar.sources=./src -Dsonar.host.url=http://sonarqube:9000 -Dsonar.login=my_token'
                }
            }
        }

        stage('Dependency Check') {
            steps {
                // Run OWASP Dependency-Check to scan for vulnerabilities in third-party libraries
                script {
                    sh 'dependency-check --project MyProject --scan ./ --format HTML --out dependency-check-report.html'
                }
            }
        }

        stage('Container Security Scan') {
            steps {
                // Scan Docker image for vulnerabilities using a tool like Trivy or Anchore
                script {
                    sh 'trivy image myapp:latest'
                }
            }
        }

        stage('Unit Tests') {
            steps {
                // Run unit tests to ensure functionality
                sh 'mvn test'
            }
        }

        stage('Deploy to Staging') {
            steps {
                // Deploy the application to the staging environment
                sh 'kubectl apply -f k8s-deployment.yaml'
            }
        }

        stage('Security Gate') {
            steps {
                // If security checks fail, abort the pipeline
                script {
                    def hasVulnerabilities = readFile('dependency-check-report.html').contains('High')
                    if (hasVulnerabilities) {
                        error "Security vulnerabilities found. Aborting the pipeline!"
                    }
                }
            }
        }

        stage('Deploy to Production') {
            when {
                branch 'main'
            }
            steps {
                // Deploy to production if the branch is 'main' and security checks passed
                sh 'kubectl apply -f k8s-prod-deployment.yaml'
            }
        }
    }

    post {
        always {
            // Archive the security reports regardless of the pipeline result
            archiveArtifacts artifacts: 'dependency-check-report.html, sonar-report.html', allowEmptyArchive: true
        }

        success {
            echo 'Pipeline completed successfully!'
        }

        failure {
            echo 'Pipeline failed!'
        }
    }
}

Breaking Down the Jenkins file

Checkout Code: The pipeline starts by pulling the code from the version control system (GitHub, GitLab, etc.).
Build Stage: The code is compiled (or a Docker image is built). This is your regular build step.
Static Code Analysis (SAST): We run a tool like SonarQube to analyze the code for security flaws, such as SQL injection, cross-site scripting, or hardcoded credentials. This step helps you identify vulnerabilities in the source code.
Dependency Check: Here, OWASP Dependency-Check scans for known vulnerabilities in third-party libraries and dependencies used in the project. These libraries can introduce severe security risks if not properly maintained.
Container Security Scan: We scan the Docker container image using a tool like Trivy or Anchore to ensure that the images do not contain vulnerabilities, outdated packages, or misconfigurations.
Unit Tests: As a standard practice, unit tests are run to verify that the code works as expected and hasn't introduced any breaking changes.
Deploy to Staging: The application is deployed to a staging environment for further testing. It's important to do this after all the security checks have passed.
Security Gate: This is a critical step. If any vulnerabilities are found (e.g., high-severity issues in the Dependency Check report), the pipeline will abort, and the application will not be deployed to production.
Deploy to Production: Only if all stages pass successfully (including the security gate), the code will be deployed to production.
Post Actions: Finally, security reports and other artifacts (like test results) are archived so that you have a record of the security checks and can review them later.

Key Tools Used in the Pipeline:

SonarQube for SAST.
OWASP Dependency-Check for third-party dependency scanning.
Trivy or Anchore for container image scanning.

Why This Pipeline is Effective in DevSecOps:

Automation: Security checks are automated, ensuring no human error or missed vulnerabilities.
Early Detection: Potential security issues are identified early in the pipeline, saving time and resources.
Continuous Security: Every code change goes through the same rigorous security checks, ensuring ongoing security compliance.
Collaboration: Developers, security, and operations teams work together seamlessly, reducing friction between security and deployment.

Wrapping Up

With the growing need for faster and secure software delivery, DevSecOps ensures that security is not compromised in the race to deliver features. Integrating security tools directly into your Jenkins pipeline, as shown in this blog, can help teams proactively manage security risks while maintaining speed and agility.

Follow me for more DevSecOps tips and tricks.
Try integrating the pipeline in your projects, and let me know how it works for you in the comments!

Happy securing! 😊

Sculpting Cloud Excellence: A Dive into AWS Well-Architected Framework

Soumya — Sat, 09 Mar 2024 08:35:35 +0000

In the ever-evolving landscape of cloud computing, the AWS Well-Architected Framework stands as a beacon of best practices and strategic guidance. It empowers architects and developers to build secure, high-performing, resilient, and efficient infrastructure for their applications. But what exactly are the pillars that uphold this framework, and how do they translate into real-world success? Let’s explore & walk through with brief example for better understanding.

The Six Pillars of Excellence: -
The AWS Well-Architected Framework is built upon six foundational pillars, each addressing a key aspect of architecture in the cloud:

Operational Excellence: - This pillar focuses on the ability to run and monitor systems to deliver business value and to continually improve processes and procedures.

Use case: - A company uses infrastructure as code (IaC) to automate the deployment of their application, ensuring consistent and repeatable processes.

Security: - Prioritizing the protection of information and systems is crucial, with a focus on confidentiality, integrity, and availability of data.

Use case: - An online retailer ecommerce business implements multi-factor authentication (MFA) and encryption for data at rest and in transit to protect customer information.

Reliability: Ensuring a workload performs its intended function correctly and consistently over time by handling changes in demand and recovering from failures.

Use case: - A streaming service uses AWS Auto Scaling and Amazon Route 53 to handle high traffic loads during peak hours, ensuring uptime and performance.

Performance Efficiency: Using computing resources efficiently to meet system requirements and maintaining efficiency as demand changes and technologies evolve.

Use case:-A mobile gaming company uses Amazon Elastic Compute Cloud (EC2) Spot Instances to process gaming data, optimizing resource usage and reducing costs.

Cost Optimization: Avoiding unnecessary costs by understanding and controlling where money is being spent, selecting the most appropriate and right number of resource types, analyzing spend over time, and scaling to meet business needs without overspending.

Use case: - A media company utilizes AWS Cost Explorer, AWS Budgets to track and analyze their spending patterns, allowing them to adjust resource usage and save on costs.

Sustainability: Reducing the environmental impact of running cloud workloads by improving efficiency and using less resources.

Use case: - A software firm selects AWS regions based on the proximity to their user base, reducing latency and the carbon footprint associated with data transmission.