Modern enterprises often standardize identity management on Microsoft Entra ID (Azure AD) while operating workloads on AWS. A secure and scalable way to integrate both platforms is by using AWS Identity and Access Management (IAM) SAML federation, allowing Azure AD to act as the trusted Identity Provider (IdP).

This article walks through a complete, production-ready integration between AWS and Azure AD using AWS Identity and Access Management (IAM) SAML Identity Providers, IAM roles, and Azure AD provisioning, without using AWS IAM Identity Center.

Why This Approach?

This design enables centralized access control while following security best practices:

• Azure AD is the single source of identity
• AWS uses IAM roles, not IAM users
• No passwords stored in AWS
• Role-based access managed centrally
• Automatic role discovery and provisioning

This approach is ideal for enterprises that:

• Already use Azure AD as their corporate directory
• Need fine-grained access control in AWS
• Want to avoid IAM Identity Center
• Require auditability and least-privilege access

High-Level Architecture

The integration works as follows:

1. Azure AD (Microsoft Entra ID) authenticates the user
2. Azure AD sends a SAML assertion to AWS
3. AWS validates the assertion using a IAM SAML identity provider
4. The user assumes an IAM role with defined permissions
5. Azure AD provisioning syncs available AWS roles automatically

Step 1: Create the Enterprise Application in Azure AD

Start by creating an Azure AD Enterprise Application:

• Go to Microsoft Entra Admin Center
• Navigate to Enterprise Applications
• Create a new application named AWS Single-Account Access

This application represents AWS as a service provider in Azure AD.

Step 2: Configure SAML Single Sign-On

Enable SAML-based SSO for the application.

Key SAML Settings

• Identifier (Entity ID):
  Use a custom value such as:

aws-test-saml

• Reply URL (ACS):

https://signin.aws.amazon.com/saml

The Entity ID uniquely identifies Azure AD to AWS and must match later in AWS IAM.

Step 3: Download the Federation Metadata XML

From the SAML configuration section, download the Federation Metadata XML.

This file contains:

• Azure AD entity ID
• SAML endpoints
• Token signing certificate

AWS uses this file to establish trust with Azure AD.

Step 4: Create the IAM SAML identity provider in AWS

In the AWS console:

• Go to IAM → Identity providers
• Create a new provider of type SAML
• Upload the Federation Metadata XML
• Assign a provider same previous Entity ID name :

aws-test-saml

At this point, AWS trusts Azure AD as an external identity provider.

Step 5: Create Roles for SAML 2.0–based federation

IAM roles define what users can do in AWS.

To create a role:

• Choose SAML 2.0 federation as the trusted entity
• Select the previously created SAML provider
• Allow AWS Management Console access

Attach permissions such as:

• AdministratorAccess
• ReadOnlyAccess
• Custom least-privilege policies

Each role represents a permission set that Azure AD users can assume.

make sure to edit the trust IAM customer managed policy to make it as this

{
 "Version": "2012-10-17",
 "Statement": [
  {
   "Effect": "Allow",
   "Principal": {
    "Federated": "arn:aws:iam::1111111111:saml-provider/aws-test-saml"
   },
   "Action": "sts:AssumeRoleWithSAML",
   "Condition": {
    "StringEquals": {
     "SAML:aud": "https://signin.aws.amazon.com/saml"
    }
   }
  }
 ]
}

Step 6: Create an IAM User for Azure AD Provisioning

Azure AD provisioning requires AWS credentials to discover available roles.
This user is not used for login.

Create a IAM customer managed policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iam:ListRoles"
      ],
      "Resource": "*"
    }
  ]
}

Create the IAM User

• Username: AzureAdUser
• Access: Programmatic only
• No console access
• Attach the IAM customer managed policy above
• Generate Access Key and Secret Key

This user only allows Azure AD to list roles.

Step 7: Configure Azure AD Provisioning

Back in Azure AD:

• Open AWS Single-Account Access
• Go to Provisioning
• Select AWS Credentials as the authentication method
• Enter the Access Key and Secret Key
• Test the connection
• Enable provisioning

Azure AD will now automatically sync AWS roles.

click on Start provisioning and wait until the initial sync done

Step 8: Assign Users or Groups to AWS Roles

To grant access:

• Go to Users and groups in the Enterprise Application

• Add a user or group
• Select an App Role (mapped to an AWS IAM role)

• Assign

Within minutes, the user can access AWS with the assigned permissions.

User Login Experience

End users log in through Azure AD:

1. Open

https://myapps.microsoft.com

2. Select AWS Single-Account Access

3. AWS Console opens with the assigned role

No AWS credentials are required.

Security Best Practices

• Do not create IAM users for people
• Use groups instead of individual users
• Apply least-privilege IAM policies
• Rotate provisioning access keys regularly
• Use one SAML provider per Azure tenant
• Monitor access via AWS CloudTrail

Common Troubleshooting Tips

• If roles don’t appear, restart provisioning
• Ensure iam:ListRoles permission exists
• Verify SAML claims include Role and RoleSessionName
• Confirm trust IAM customer managed policy references the correct SAML provider

Conclusion

By integrating AWS with Azure AD using IAM SAML federation, organizations gain:

• Centralized identity management
• Strong security posture
• Scalable role-based access
• Clean separation of identity and permissions
• Reduced operational overhead

This approach aligns perfectly with enterprise IAM best practices and cloud governance frameworks.

References & Official Documentation

AWS

• https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html
• https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml.html
• https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-azuread.html

Microsoft

• https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-saml-single-sign-on
• https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/aws-provisioning-tutorial
• https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/assign-user-or-group-access

👋 If you find this helpful, please click the clap 👏 button below a few times to show your support for the author 👇

🚀Join FAUN.dev() & Get Similar Stories in your Inbox Each Week

Integrating AWS with Azure AD Using IAM SAML Federation (Without IAM Identity Center) was originally published in FAUN.dev() 🐾 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction:

When Your Infrastructure Starts Talking Back

Imagine asking your AWS infrastructure a question in plain English and getting an intelligent, contextual answer — not raw JSON or Amazon CloudWatch graphs, but actual insights. That’s what becomes possible when you combine the Model Context Protocol (MCP) with AWS.

I recently built CloudWhisper, an AI-powered chatbot that uses MCP to connect AI models like ChatGPT and Claude directly to AWS services. In this article, I’ll explain how MCP works with AWS, why it matters, and how to build your own MCP-powered AWS integration.

What is Model Context Protocol (MCP)?

MCP is a standardized protocol that lets AI models securely connect to external data sources and tools. Think of it as a translator between AI models and your infrastructure.

Without MCP, you’d need to:

• Manually format data for AI models
• Handle authentication and security yourself
• Build custom integrations for each service
• Manage complex API interactions

With MCP, you get:

• A standardized way for AI to access your data
• Built-in security and authentication
• Real-time data access without exposing credentials
• Contextual responses based on live infrastructure data

Why MCP Matters for AWS

AWS exposes many services and APIs. MCP provides a clean bridge so AI models can:

• Query Amazon Elastic Compute Cloud (Amazon EC2) instances
• Analyze Amazon Simple Storage Service (Amazon S3) bucket configurations
• Review Amazon CloudWatch alarms
• Provide recommendations based on real-time data
• Switch between multiple AWS accounts seamlessly

The key benefit: AI models get structured, real-time data instead of generic responses, enabling more accurate and actionable insights.

How CloudWhisper Uses MCP: The Architecture

CloudWhisper demonstrates a practical MCP implementation. Here’s how it works:

GitHub repo link: https://github.com/MohammadJomaa/cloudwhisper

The Three-Layer Architecture

1- AI Layer (MCP Client)

• ChatGPT or Claude receives user questions
• Formats requests using MCP protocol
• Sends requests to the MCP server

2- MCP Server Layer (The Bridge)

• Receives AI requests via JSON-RPC
• Translates requests into AWS API calls
• Fetches real-time data from AWS
• Returns structured data to the AI

3- AWS Layer (The Data Source)

• Returns infrastructure data
• Provides real-time metrics and statusThe Data Flow

The Data Flow

Building Your Own MCP Server for AWS

Let me walk you through building an MCP server for AWS, using CloudWhisper as a reference.

Step 1: Understanding the MCP Protocol

MCP uses JSON-RPC 2.0. The basic structure looks like this:

Request:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "list_instances",
    "arguments": {}
  }
}

Response:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "{\"success\": true, \"instances\": [...]}"
      }
    ]
  }
}

Step 2: Setting Up Your Project Structure

Here’s the structure I used for CloudWhisper:

cloudwhisper/
├── src/
│   ├── mcp_server/
│   │   └── multi_cloud_mcp_server.py    # MCP server implementation
│   ├── aws_integration/
│   │   └── aws_client.py                # AWS API wrapper
│   ├── chatbot/
│   │   └── multi_cloud_chatbot.py       # MCP client (AI integration)
│   └── config/
│       ├── cloud_accounts.yaml          # AWS account config
│       └── ai_integration_config.yaml   # AI API keys

Step 3: Creating the AWS Client

First, create a wrapper around AWS APIs. This abstracts AWS SDK for Python (boto3) and provides clean methods:

import boto3
from typing import Dict, Any

class AWSClient:
    def __init__(self, account_id: str = "default"):
        self.account_id = account_id
        self.session = boto3.Session(
            aws_access_key_id=os.getenv('AWS_ACCESS_KEY_ID'),
            aws_secret_access_key=os.getenv('AWS_SECRET_ACCESS_KEY'),
            region_name=os.getenv('AWS_DEFAULT_REGION', 'us-east-1')
        )
    
    def list_instances(self) -> Dict[str, Any]:
        """List EC2 instances with detailed information."""
        ec2 = self.session.client('ec2')
        response = ec2.describe_instances()
        
        instances = []
        for reservation in response['Reservations']:
            for instance in reservation['Instances']:
                instances.append({
                    'instance_id': instance.get('InstanceId'),
                    'status': instance.get('State', {}).get('Name'),
                    'instance_type': instance.get('InstanceType'),
                    'private_ip': instance.get('PrivateIpAddress'),
                    'public_ip': instance.get('PublicIpAddress'),
                    # ... more fields
                })
        
        return {
            "success": True,
            "instances": instances,
            "count": len(instances)
        }
    
    def list_storage_buckets(self) -> Dict[str, Any]:
        """List S3 buckets with size and configuration."""
        s3 = self.session.client('s3')
        # Implementation here
        pass
    
    def get_monitoring_alerts(self) -> Dict[str, Any]:
        """Get CloudWatch alarms."""
        cloudwatch = self.session.client('cloudwatch')
        # Implementation here
        pass

Step 4: Implementing the MCP Server

The MCP server handles JSON-RPC requests and translates them to AWS API calls:

import json
import sys
from aws_client import AWSClient

class CloudWhisperMCPServer:
    def __init__(self):
        self.aws_client = AWSClient()
    
    def run(self):
        """Main server loop - reads from stdin, writes to stdout."""
        while True:
            try:
                request_line = input()
                if not request_line:
                    continue
                
                request = json.loads(request_line)
                response = self._handle_request(request)
                
                print(json.dumps(response))
                sys.stdout.flush()
                
            except EOFError:
                break
            except Exception as e:
                error_response = {
                    "jsonrpc": "2.0",
                    "id": request.get("id", 1),
                    "error": {
                        "code": -32603,
                        "message": f"Internal error: {str(e)}"
                    }
                }
                print(json.dumps(error_response))
                sys.stdout.flush()
    
    def _handle_request(self, request: Dict[str, Any]) -> Dict[str, Any]:
        """Route requests to appropriate handlers."""
        method = request.get("method", "")
        params = request.get("params", {})
        request_id = request.get("id", 1)
        
        if method == "initialize":
            return self._handle_initialize(request_id)
        elif method == "tools/list":
            return self._handle_tools_list(request_id)
        elif method == "tools/call":
            return self._handle_tools_call(request_id, params)
        else:
            return {
                "jsonrpc": "2.0",
                "id": request_id,
                "error": {
                    "code": -32601,
                    "message": f"Method not found: {method}"
                }
            }
    
    def _handle_initialize(self, request_id: int) -> Dict[str, Any]:
        """Handle initialization request."""
        return {
            "jsonrpc": "2.0",
            "id": request_id,
            "result": {
                "protocolVersion": "2024-11-05",
                "capabilities": {
                    "tools": {}
                },
                "serverInfo": {
                    "name": "CloudWhisper MCP Server",
                    "version": "1.0.0"
                }
            }
        }
    
    def _handle_tools_list(self, request_id: int) -> Dict[str, Any]:
        """List available tools (AWS operations)."""
        tools = [
            {
                "name": "list_instances",
                "description": "List EC2 instances",
                "inputSchema": {
                    "type": "object",
                    "properties": {}
                }
            },
            {
                "name": "list_storage_buckets",
                "description": "List S3 buckets",
                "inputSchema": {
                    "type": "object",
                    "properties": {}
                }
            },
            {
                "name": "get_monitoring_alerts",
                "description": "Get CloudWatch alarms",
                "inputSchema": {
                    "type": "object",
                    "properties": {}
                }
            }
        ]
        
        return {
            "jsonrpc": "2.0",
            "id": request_id,
            "result": {
                "tools": tools
            }
        }
    
    def _handle_tools_call(self, request_id: int, params: Dict[str, Any]) -> Dict[str, Any]:
        """Execute tool calls (AWS API operations)."""
        tool_name = params.get("name", "")
        arguments = params.get("arguments", {})
        
        if tool_name == "list_instances":
            result = self.aws_client.list_instances()
            return {
                "jsonrpc": "2.0",
                "id": request_id,
                "result": {
                    "content": [
                        {
                            "type": "text",
                            "text": json.dumps(result)
                        }
                    ]
                }
            }
        # ... handle other tools
        
        return {
            "jsonrpc": "2.0",
            "id": request_id,
            "error": {
                "code": -32601,
                "message": f"Tool not found: {tool_name}"
            }
        }

Step 5: Connecting the AI Client

The AI client (ChatGPT or Claude) communicates with the MCP server via subprocess:

import subprocess
import json
import sys

class AWSChatbot:
    def __init__(self):
        self.server_process = None
        self.start_mcp_server()
    
    def start_mcp_server(self):
        """Start MCP server as subprocess."""
        server_path = "src/mcp_server/multi_cloud_mcp_server.py"
        self.server_process = subprocess.Popen(
            [sys.executable, server_path, "--subprocess"],
            stdin=subprocess.PIPE,
            stdout=subprocess.PIPE,
            text=True,
            bufsize=1
        )
    
    def call_tool(self, tool_name: str, arguments: Dict[str, Any] = None) -> str:
        """Call a tool on the MCP server."""
        request = {
            "jsonrpc": "2.0",
            "id": 1,
            "method": "tools/call",
            "params": {
                "name": tool_name,
                "arguments": arguments or {}
            }
        }
        
        # Send request
        self.server_process.stdin.write(json.dumps(request) + "\n")
        self.server_process.stdin.flush()
        
        # Read response
        response_line = self.server_process.stdout.readline()
        response = json.loads(response_line)
        
        if "result" in response:
            return response["result"]["content"][0]["text"]
        
        return None
    
    def ask_ai(self, question: str):
        """Get cloud data and ask AI about it."""
        # Get data from AWS via MCP
        instances_data = json.loads(self.call_tool("list_instances"))
        storage_data = json.loads(self.call_tool("list_storage_buckets"))
        alerts_data = json.loads(self.call_tool("get_monitoring_alerts"))
        
        # Prepare context for AI
        context = self._prepare_context(instances_data, storage_data, alerts_data)
        
        # Ask AI (ChatGPT or Claude)
        response = self.ai_client.chat.completions.create(
            model="gpt-4",
            messages=[
                {"role": "system", "content": "You are an AWS infrastructure expert."},
                {"role": "user", "content": f"{context}\n\nQuestion: {question}"}
            ]
        )
        
        return response.choices[0].message.content

Configuration and Setup

Prerequisites

Before you start, you’ll need:

1. Python 3.8+ installed
2. AWS Account with appropriate permissions
3. AI API Key (OpenAI or Anthropic)
4. AWS Credentials configured

Installation Steps

1- Clone and Install Dependencies

git clone https://github.com/MohammadJomaa/cloudwhisper.git
cd cloudwhisper
pip install -r requirements.txt

The key dependencies are:

• boto3 — AWS SDK for Python (boto3)
• openai or anthropic — AI model APIs
• flask — Web interface (optional)
• pyyaml — Configuration file parsing

2. Configure AWS Credentials

export AWS_ACCESS_KEY_ID="your-access-key"
export AWS_SECRET_ACCESS_KEY="your-secret-key"
export AWS_DEFAULT_REGION="us-east-1"

Option B: Configuration File

./setup_config.sh
# Then edit src/config/cloud_accounts.yaml

Option C: AWS Profile]

export AWS_PROFILE="your-profile-name"

3. Configure AI Integration

set your AI API key:

# For OpenAI
export OPENAI_API_KEY="sk-your-openai-key"

# For Anthropic
export ANTHROPIC_API_KEY="sk-ant-api03-your-anthropic-key"

Or use configuration files:

# src/config/ai_integration_config.yaml
ai_integration:
  chatgpt:
    enabled: true
    api_key: "sk-your-openai-key"
    model: "gpt-4"
  
  claude:
    enabled: true
    api_key: "sk-ant-api03-your-key"
    model: "claude-3-sonnet-20240229"

4. Verify Configuration

python3 validate_config.py

This checks:

• AWS credentials are valid
• AI API keys are set
• Configuration files are properly formatted
• All required permissions are available

5. Start the Application

Web Interface:

python3 chat_ui.py
# Open http://localhost:5001

Command Line:

python3 ai_chatbot.py

Real-World Usage Examples

Here are some practical examples of what you can do:

Example 1: Infrastructure Overview

Question: “Give me an overview of my AWS infrastructure”

What Happens:

1. MCP server calls list_instances(), list_storage_buckets(), get_monitoring_alerts()
2. AI receives structured data about all resources
3. AI generates a comprehensive summary

Response:

🖥️ AWS Infrastructure Overview

## 📊 Summary
• Total EC2 Instances: 5
  - Running: 3
  - Stopped: 2
• S3 Buckets: 8
  - Total Storage: 245.67 GB
  - Encrypted: 6/8
• CloudWatch Alarms: 12
  - Active: 8
  - In Alarm: 2

## 💰 Cost Insights
• Estimated Monthly Cost: $234.56
• Top Cost Driver: EC2 instances (65%)
• Recommendation: Consider Reserved Instances for production workloads

## 🔒 Security Status
• 2 S3 buckets without encryption
• 1 instance without monitoring enabled
• Recommendation: Enable encryption and monitoring for all resources

Example 2: Specific Resource Query

Question: “What are the IP addresses of my EC2 instances?”

What Happens:

1. MCP server calls list_instances()
2. Extracts network interface information
3. AI formats the response with IP addresses

Response:

🖥️ EC2 Instance IP Addresses

## Instance #1: web-server-prod
• Instance ID: `i-1234567890abcdef0`
• Private IP: 10.0.1.45
• Public IP: 54.123.45.67
• VPC: vpc-abc123
• Subnet: subnet-xyz789

## Instance #2: app-server-staging
• Instance ID: `i-0987654321fedcba0`
• Private IP: 10.0.2.12
• Public IP: None (no public IP assigned)
• VPC: vpc-def456
• Subnet: subnet-uvw456

## Instance #3: db-server-prod
• Instance ID: `i-1122334455aabbcc0`
• Private IP: 10.0.3.78
• Public IP: None (intentionally private)
• VPC: vpc-ghi789
• Subnet: subnet-rst123

Example 3: Cost Analysis

Question: “How can I reduce my AWS costs?”

What Happens:

1. MCP server gathers instance data, storage sizes, and usage patterns
2. AI analyzes the data for cost optimization opportunities
3. AI provides specific, actionable recommendations

Response:

💰 AWS Cost Optimization Analysis

## Current Spending Breakdown
• EC2 Instances: $156.78/month (67%)
• S3 Storage: $45.23/month (19%)
• Data Transfer: $23.45/month (10%)
• Other Services: $9.12/month (4%)

## 💡 Optimization Recommendations

### 1. EC2 Instance Optimization
• **Stopped Instances**: You have 2 stopped instances that are still incurring EBS costs
  - Action: Terminate `i-0987654321` and `i-1122334455` if not needed
  - Potential Savings: $23.45/month

• **Instance Right-Sizing**: `i-1234567890` is a t3.xlarge but only using 15% CPU
  - Action: Consider downgrading to t3.large
  - Potential Savings: $18.67/month

• **Reserved Instances**: For production instances, consider Reserved Instances
  - Action: Purchase 1-year Reserved Instance for `i-1234567890`
  - Potential Savings: $12.34/month (upfront payment required)

### 2. S3 Storage Optimization
• **Lifecycle Policies**: 3 buckets have old data that could be moved to Glacier
  - Action: Set up lifecycle policies for `logs-bucket`, `backups-bucket`, `archive-bucket`
  - Potential Savings: $8.90/month

• **Unused Buckets**: `test-bucket-old` has 0 objects but still exists
  - Action: Delete unused buckets
  - Potential Savings: $0.50/month (minimal, but good practice)

### 3. Data Transfer Optimization
• **CloudFront**: Consider using CloudFront for static content
  - Action: Set up CloudFront distribution for `static-assets-bucket`
  - Potential Savings: $5.67/month

## 📊 Total Potential Savings
• Monthly: $69.63 (30% reduction)
• Annual: $835.56

## ⚠️ Important Notes
• Review all recommendations before implementing
• Test changes in staging environment first
• Monitor costs after implementing changes
• Some optimizations require upfront investment (Reserved Instances)

Example 4: Security Analysis

Question: “What security issues do I have?”

What Happens:

1. MCP server checks encryption status, monitoring, and access patterns
2. AI analyzes security configurations
3. AI provides prioritized security recommendations

Response:

🔒 AWS Security Analysis

## 🚨 Critical Issues

### 1. Unencrypted S3 Buckets
• **Buckets**: `logs-bucket`, `temp-uploads`
• **Risk**: Data exposure if bucket is accidentally made public
• **Action**: Enable server-side encryption immediately
• **Priority**: HIGH

### 2. Missing CloudWatch Monitoring
• **Instance**: `i-1122334455` (db-server-prod)
• **Risk**: No visibility into performance or security events
• **Action**: Enable detailed monitoring
• **Priority**: HIGH

## ⚠️ Medium Priority Issues

### 3. Overly Permissive Amazon EC2 security group
• **Amazon EC2 security group**: `sg-web-server` allows SSH from 0.0.0.0/0
• **Risk**: Potential unauthorized access
• **Action**: Restrict SSH access to your IP or VPN
• **Priority**: MEDIUM

### 4. No MFA on Root Account
• **Risk**: Root account compromise could affect entire account
• **Action**: Enable MFA for root account
• **Priority**: MEDIUM

## ✅ Security Best Practices Checklist

### Implemented
✅ CloudTrail logging enabled
✅ S3 versioning enabled on production buckets
✅ AWS Identity and Access Management (IAM) roles
✅ Amazon Virtual Private Cloud (Amazon VPC) with private Amazon VPC subnet configured

### Recommended
1. Enable encryption on all S3 buckets
2. Enable Amazon CloudWatch monitoring on all instances
3. Review and restrict Amazon EC2 security group rules
4. AWS Identity and Access Management (IAM) users
5. Set up AWS Config for compliance monitoring
6. Implement AWS GuardDuty for threat detection
7. Regular security audits (quarterly recommended)

## 📋 Action Plan
1. **This Week**: Enable encryption on unencrypted buckets
2. **This Week**: Enable monitoring on db-server-prod
3. **This Month**: Review and update all Amazon EC2 security groups
4. **This Month**: Enable MFA for root account
5. **Ongoing**: Regular security reviews and audits

Conclusion: The Future of Infrastructure Management

MCP with AWS enables natural language interaction with your infrastructure. Instead of navigating consoles or writing scripts, you can ask questions and get intelligent answers.

The combination of:

• MCP for standardized AI-cloud communication
• AWS for comprehensive cloud services
• AI models for intelligent analysis

Creates a powerful tool for infrastructure management.

Whether you’re building your own MCP server or using CloudWhisper as a starting point, the key is understanding how these pieces fit together. Start simple with EC2 and S3, then expand to other services as needed.

The future of cloud management isn’t just about automation — it’s about making infrastructure accessible, understandable, and manageable through natural conversation. MCP is the bridge that makes this possible.

👋 If you find this helpful, please click the clap 👏 button below a few times to show your support for the author 👇

🚀Join FAUN Developer Community & Get Similar Stories in your Inbox Each Week

Bridging AI and AWS: A Deep Dive into Using Model Context Protocol (MCP) for Intelligent Cloud… was originally published in FAUN.dev() 🐾 on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Problem: Infrastructure Management is Too Complex

If you’ve ever managed AWS infrastructure, you know the struggle:

The AWS Console Dance

• Log in to AWS Console

• Navigate through countless menus

• Click through multiple pages to find one EC2 instance IP

• Repeat for every simple question

• Switch accounts? Start over.

The Script Fatigue

• Need to know S3 storage costs? Write a script.

• Want to check CloudWatch alarms? Another script.

• Different account? Modify the script.

• It’s exhausting.

The Context Switching Hell

• Console for viewing

• CLI for querying

• Third-party tools for analysis

• Mental model constantly shifting

I realized: We’re managing 2024 cloud infrastructure with 2014 tools.

The Vision: What If Infrastructure Could Talk?

Imagine asking your infrastructure questions like you’d ask a colleague:

“What are my EC2 instance IPs?”

“How much am I spending on S3?”

“Are there any security vulnerabilities?”

And getting instant, intelligent answers. Not raw JSON. Not CloudWatch graphs. Actual insights.

That’s the vision behind CloudWhisper.

What is CloudWhisper?

CloudWhisper is an AI-powered infrastructure chatbot that provides real-time insights about your AWS environment through natural language conversations.

But it’s more than just a chatbot. It’s a new paradigm for infrastructure management.

The Core Innovation: MCP Integration

CloudWhisper is built on the Model Context Protocol (MCP) — a standardized protocol that enables AI models to securely connect to external data sources.

Traditional Approach:

User → AWS Console → Manual Analysis → Decision

CloudWhisper Approach:

User → Natural Language Question → AI + Real-Time AWS Data → Intelligent Answer

The difference? Context and intelligence.

The Technology Stack: How CloudWhisper Works

Architecture Overview:

User asks: “What are my EC2 IPs?”

↓

CloudWhisper Web UI (Beautiful interface + Natural Language Processing)

↓

AI Integration (ChatGPT or Claude)

↓

MCP Server (Model Context Protocol — Translates AI → AWS API)

↓

AWS Services (Real-time data from EC2, S3, CloudWatch)

↓

Data Retrieved and Formatted

↓

AI Analyzes Data

↓

Intelligent Response Generated

↓

User Receives Insights

The MCP Magic

Model Context Protocol (MCP) is the secret sauce that makes CloudWhisper possible:

1. Secure Communication: AI models can’t directly access AWS — MCP acts as a secure intermediary

2. Real-Time Data: Every query fetches live data from your AWS account

3. Contextual Understanding: AI receives formatted, relevant data for accurate analysis

4. Controlled Access: You define what data AI can access

Technology Choices

Backend:

• Python 3.8+ for robust backend logic

• Flask for lightweight web framework

• Boto3 for official AWS SDK

• Structlog for structured logging

AI Integration:

• OpenAI GPT-4 for conversational intelligence

• Anthropic Claude as alternative AI provider

• MCP Protocol for secure AI-cloud communication

Frontend:

• Modern HTML/CSS/JS for responsive, beautiful interface

• Real-time updates for instant AI responses

• Loading animations for professional UX

Key Features: What Makes CloudWhisper Special

1. Natural Language Queries

Instead of navigating AWS Console or writing scripts, just ask:

Example Queries:

“What are the IP addresses of my EC2 instances?”

→ Gets all running instances with public/private IPs

“How much storage am I using in S3?”

→ Lists all buckets with sizes and costs

“Show me my CloudWatch alarms”

→ Displays all alarms with status and metrics

“Are there any security issues?”

→ AI-powered security analysis with recommendations

2. Real-Time AWS Data

Unlike static dashboards or scheduled reports, CloudWhisper queries your AWS infrastructure in real-time.

Every time you ask a question:

• Fresh API calls to AWS services

• Latest instance states

• Current resource usage

• Up-to-date alarm statuses

This means you’re always working with current data.

3. AI-Powered Intelligence

CloudWhisper doesn’t just return data — it analyzes and explains it.

Example:

You ask: “How can I reduce AWS costs?”

CloudWhisper responds:

Cost Optimization Analysis

Current Infrastructure

• Total EC2 Instances: 5 ($250/month)

• S3 Storage: 500GB ($12/month)

• Running but Unused: 2 instances

Recommendations

1. Stop 2 unused instances → Save $100/month

2. Move old S3 data to Glacier → Save $8/month

3. Use Reserved Instances → Save $50/month

Total Potential Savings: $158/month (63%)

4. Multi-Account Support

Managing multiple AWS accounts? CloudWhisper makes it easy:

• Quick switching between accounts

• Account-specific analysis

• Cross-account comparisons

• Centralized management

Perfect for:

• Development/Staging/Production environments

• Multi-client management

• Enterprise AWS setups

• Agency infrastructure management

5. Beautiful Interface

Web UI:

• Modern gradient design

• Real-time chat interface

• Responsive layout

• Loading animations

• Status indicators

• Quick action buttons

CLI:

• Terminal-based interface

• Fast responses

• Full feature parity

• Perfect for automation

Final Thoughts

Building CloudWhisper has been an incredible journey. From a simple idea — “what if I could just ask my infrastructure questions?” — to a fully-featured AI-powered chatbot using cutting-edge MCP technology.

But this is just the beginning.

The future of infrastructure management is conversational, intelligent, and real-time. CloudWhisper is a step toward that future.

🎁 I’m Open-Sourcing It!
Because the best tools are built by communities, not individuals.

🤝 Calling All Contributors:
Whether you’re a Python dev, AWS expert, AI enthusiast, or just curious — your contributions are welcome!

🔗 Check it out:
https://github.com/MohammadJomaa/cloudwhisper

If you find it useful, please ⭐ star the repo and share with your network!

Let’s make infrastructure management more conversational! 💬

👋 If you find this helpful, please click the clap 👏 button below a few times to show your support for the author 👇

🚀Join FAUN Developer Community & Get Similar Stories in your Inbox Each Week

CloudWhisper: Revolutionizing AWS Infrastructure Management with AI and MCP was originally published in FAUN.dev() 🐾 on Medium, where people are continuing the conversation by highlighting and responding to this story.

GitHub Repository

The complete implementation, including all CloudFormation templates, documentation, and deployment scripts, is available in the following GitHub repository:

[AWS_ORG_TAGGING Repository](https://github.com/MohammadJomaa/AWS_ORG_TAGGING)**

The repository contains:

• complete-tagging-strategy.yaml : Main CloudFormation template for core infrastructure
• virginia-region-components.yaml: Virginia region template for OU tag inheritance

Introduction

Managing resource tags across multiple AWS accounts can quickly become a nightmare. When you’re dealing with dozens or hundreds of accounts in an AWS Organization, manually ensuring consistent tagging becomes impossible. This is where automated tagging strategies come into play.

In this article, I’ll walk you through a real-world solution we implemented for automated resource tagging using AWS CloudFormation, Lambda functions, and Organization Config Rules. The approach we developed handles both existing resource tagging and ensures new resources inherit proper tags from their organizational units.

The Challenge

Most organizations struggle with:

• Inconsistent tagging across accounts
• Manual tag management overhead
• Compliance requirements for resource governance
• Difficulty tracking costs and resources without proper tags

Our solution addresses these pain points by creating an automated system that:

• Tags resources based on their account’s organizational tags
• Monitors compliance through AWS Config
• Propagates tags from organizational units to child accounts
• Works seamlessly across multiple regions

Architecture Overview

The solution consists of two main components deployed across different regions:

Core Infrastructure (Primary Region)

The main deployment includes Lambda functions that handle resource tagging and compliance evaluation. These functions work with AWS Config to monitor resource compliance and automatically apply missing tags.

OU Tag Inheritance (Virginia Region)

Since AWS Organizations events are only published in the us-east-1 region, we deploy a separate component there to handle organizational unit tag inheritance. This ensures that when OUs are tagged, those tags automatically propagate to child accounts and OUs.

Implementation Details

Before diving into the CloudFormation templates, you’ll need to ensure your AWS Organization is properly configured. This includes:

• Enabling AWS Organizations
• Setting up CloudFormation StackSets
• Configuring AWS Config in your target regions
• Having appropriate IAM permissions

The deployment requires several key pieces of information:

• Your management account ID
• Your organization ID (in the format o-xxxxxxxxxx)
• Target regions for deployment
• Specific configuration preferences

Repository Structure and Files

The [GitHub repository](https://github.com/MohammadJomaa/AWS_ORG_TAGGING) is organized as follows:

The [GitHub repository](https://github.com/MohammadJomaa/AWS_ORG_TAGGING) is organized as follows:

AWS_ORG_TAGGING/
├── complete-tagging-strategy.yaml      # Main CloudFormation template
├── virginia-region-components.yaml     # Virginia region template
├── readme.md                          # Deployment documentation
└── [Additional files as needed]

Key Files Explained

1. `complete-tagging-strategy.yaml` - This is the primary template that deploys:
   - Lambda functions for resource tagging and compliance evaluation
   - IAM roles with appropriate permissions
   - AWS Config Organization Config Rule
   - CloudFormation StackSet for cross-account role deployment
   - Custom resources for automated StackSet instance creation

2. `virginia-region-components.yaml` - This template deploys:
   - OU tag inheritance Lambda function
   - EventBridge rules for Organizations events
   - Necessary permissions for cross-region functionality

Core Tagging Logic

The heart of the solution lies in two Lambda functions:

OrgAccountTagger

This function identifies resources missing required tags and applies them automatically. It works by:

• Retrieving the account’s organizational tags
• Scanning resources in the account
• Comparing existing tags with required tags
• Applying missing tags using the appropriate AWS service APIs

ConfigOrgAccountTagEvaluator

This function evaluates resource compliance for AWS Config. It:

• Receives configuration change notifications
• Checks if resources have all required tag keys
• Reports compliance status back to Config
• Triggers the tagger function when non-compliant resources are found

Cross-Account Role Management

One of the trickier aspects of this solution is managing permissions across multiple accounts. We use CloudFormation StackSets to deploy a standardized role (`TagPropagatorRole`) in each member account. This role allows the management account’s Lambda functions to tag resources in member accounts.

The StackSet deployment is automated through a custom CloudFormation resource that:

• Creates the StackSet
• Automatically provisions instances in all member accounts
• Handles deployment failures gracefully
• Provides visibility into deployment status

Organizational Unit Tag Inheritance

The OU tag inheritance component is particularly useful for maintaining consistency. When you tag an organizational unit, the system automatically:

• Applies those tags to all direct child accounts
• Propagates tags to direct child OUs
• Handles account moves between OUs
• Manages new account creation

This is implemented through EventBridge rules that listen for Organizations API calls and trigger the appropriate Lambda function.

Deployment Process

Step 1: Main Template Deployment

The first step involves deploying the core infrastructure in your primary region. This template creates:

• IAM roles with appropriate permissions
• Lambda functions for tagging and evaluation
• AWS Config rules for compliance monitoring
• StackSet for cross-account role deployment

Required Parameters for Main Template

- `ManagementAccountId`: Your AWS Organizations management account ID (12-digit number)
- `OrganizationId`: Your AWS Organizations ID (format: o-xxxxxxxxxx)
- `ConfigRegion`: Region where AWS Config is enabled (e.g., me-central-1)
- `DeploymentRegions`: Comma-separated list of regions for StackSet deployment
- `EnforceValues`: Boolean flag for tag value enforcement (default: false)
- `TaggerFunctionName`: Name for the tagging Lambda function (default: OrgAccountTagger)
- `EvaluatorFunctionName`: Name for the evaluator Lambda function (default: ConfigOrgAccountTagEvaluator)
- `MemberRoleName`: Name for cross-account role (default: TagPropagatorRole)
- `FailureTolerancePercentage`: Percentage of accounts that can fail during deployment (default: 0)
- `MaxConcurrentPercentage`: Maximum percentage of accounts to process concurrently (default: 10)

The deployment command requires several parameters:

aws cloudformation deploy \
  --template-file complete-tagging-strategy.yaml \
  --stack-name AutomatedTaggingStrategy \
  --parameter-overrides \
    ManagementAccountId=YOUR_ACCOUNT_ID \
    OrganizationId=o-YOUR_ORG_ID \
    ConfigRegion=me-central-1 \
    DeploymentRegions=me-central-1 \
    EnforceValues=false \
    TaggerFunctionName=OrgAccountTagger \
    EvaluatorFunctionName=ConfigOrgAccountTagEvaluator \
    MemberRoleName=TagPropagatorRole \
    FailureTolerancePercentage=0 \
    MaxConcurrentPercentage=10 \
  --capabilities CAPABILITY_NAMED_IAM \
  --region me-central-1

Step 2: Virginia Region Components

The second deployment handles the OU tag inheritance components in us-east-1. This step is crucial because AWS Organizations events are only published in the us-east-1 region.

Required Parameters for Virginia Template:

- `LambdaTagPropagatorRoleArn`: ARN of the Lambda execution role from the main template output
- `StackName`: Name of the main CloudFormation stack (used for resource naming)

Important Notes

- This template must be deployed in us-east-1 region

- The `LambdaTagPropagatorRoleArn` parameter must be obtained from the main template’s output

- The template creates EventBridge rules that listen for Organizations API events

aws cloudformation deploy \
  --template-file virginia-region-components.yaml \
  --stack-name AutomatedTaggingStrategy-Virginia \
  --parameter-overrides \
    LambdaTagPropagatorRoleArn=arn:aws:iam::ACCOUNT:role/LambdaTagPropagatorRole \
    StackName=AutomatedTaggingStrategy \
  --capabilities CAPABILITY_NAMED_IAM \
  --region us-east-1

Security Best Practices

All IAM roles follow the principle of least privilege. Cross-account roles have minimal permissions, and Lambda execution roles are scoped to specific functions. The solution doesn’t require any public internet access and uses AWS internal networks for all communication.

Testing and Validation

After deployment, it’s crucial to test the solution thoroughly:

1. Manual Lambda Testing: Invoke the functions directly to verify they work correctly
2. Config Rule Validation: Check that the Organization Config Rule is evaluating resources properly
3. OU Tag Inheritance: Test tagging organizational units and verifying tag propagation
4. Cross-Account Functionality: Ensure the StackSet deployed roles correctly in member accounts

Common Pitfalls and Solutions

StackSet Deployment Issues

One common issue is StackSet instance creation failing due to empty account lists. This usually happens when the organization ID is incorrect or when there are no accounts in the specified organizational units. The solution includes logic to automatically detect the root OU and use it as the deployment target.

Cross-Region Permission Issues

Lambda functions in one region sometimes struggle to assume roles in another region. This is resolved by ensuring the role ARNs are correct and that the roles exist in the target regions.

Config Rule Evaluation Problems

Config rules might fail to evaluate resources if the Lambda function doesn’t have proper permissions or if the function code has bugs. The solution includes comprehensive error handling and logging to identify and resolve these issues.

Maintenance and Updates

Regular Monitoring

The solution requires ongoing monitoring:

• Check Config rule compliance regularly
• Review Lambda function logs for errors
• Monitor StackSet operation status
• Verify tag inheritance is working correctly

Updates and Changes

• Use CloudFormation change sets for template updates
• Test changes in a development environment first
• Update Lambda function code through the CloudFormation template
• Modify parameters through the CloudFormation console

Results and Benefits

Implementing this automated tagging strategy provides several key benefits:

• Consistency: All resources across the organization have consistent tagging
• Compliance: Automated monitoring ensures ongoing compliance with tagging policies
• Efficiency: Reduces manual overhead and human error
• Cost Management: Better resource tracking and cost allocation
• Governance: Improved visibility into resource usage and ownership

Conclusion

Automated resource tagging across AWS Organizations doesn’t have to be complex. With the right combination of CloudFormation, Lambda functions, and AWS Config, you can create a robust solution that handles both existing and new resources automatically.

The key to success is understanding your organization’s specific requirements and adapting the solution accordingly. Start with the core functionality and gradually add more sophisticated features like OU tag inheritance and cross-region deployment.

Remember that this is an ongoing process. Regular monitoring, testing, and updates are essential to maintaining an effective automated tagging strategy. The investment in setting up this system pays dividends in improved governance, compliance, and operational efficiency.

👋 If you find this helpful, please click the clap 👏 button below a few times to show your support for the author 👇

🚀Join FAUN Developer Community & Get Similar Stories in your Inbox Each Week

Implementing Automated Resource Tagging Across AWS Organizations was originally published in FAUN.dev() 🐾 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Elastic Block Store (EBS) is a storage, which provides block-level persistent volumes for the EC2 instances. By reducing the size of your EBS volume according to the minimum storage requirements for your application, one can save a lot in terms of money on storing costs. Here’s a step-by-step guide:

1. Take a new AMI snapshot from your existing EC2 instance.
2. Create a new EC2 instance based on the previous AMI snapshot.
3. Create a new EBS of your desired size, making sure that it is larger than the amount used in the original EBS.
4. Connect the newly created EBS to a new EC2 instance that you have just launched.
5. Newly logged into the fresh EC2, we prepare a new EBS with a suitable file system.
6. Paste all the data from the / directory to another EBS.
7. Setup and setup grup2 on a new EBS.
8. Shutdown the new EC2 instance.
9. Unmount both the EBS volumes (new and old) to detach it from the new EC2.
10. Connect the newly EBS to a new EC2 via /dev/sda1 as a bootable EBS.
11. Take your EC2 instance with the resized EBS and have alot of fun! ^_^

Solution implementation

1. Take a new AMI snapshot from your existing EC2 instance.
2. Create a new EC2 instance based on the previous AMI snapshot.=

3. Create a new EBS of your desired size, making sure that it is larger than the amount used in the original EBS.

4. Connect the newly created EBS to a new EC2 instance that you have just launched.

5. Newly logged into the fresh EC2, we prepare a new EBS with a suitable file system.

#Create new dir for /mnt/new-volume001
sudo mkdir /mnt/new-volume001
#list all of blocks
lsblk

fdisk /dev/nvme1n1
#for XFS
sudo mkfs -t xfs /dev/nvme1n1p1

#for Ext4
#sudo mkfs -t ext4 /dev/nvme1n1p1

6. Paste all the data from the / directory to another EBS.

sudo mount /dev/nvme1n1p1 /mnt/new-volume001

sudo rsync -axv / /mnt/new-volume001/

7. Setup and setup grup2 on a new EBS.

grub2-install --root-directory=/mnt/new-volume001/ --force /dev/nvme1n1

# might face error like that
# grub2-install: error: /usr/lib/grub/x86_64-efi/modinfo.sh doesn't exist. Please specify --target or --directory.
#you can add this to your command 
grub2-install --root-directory=/mnt/new-volume001/ --force /dev/nvme2n1 --target i386-pc

lsblk

# get the dev name of OS in old EBS
blkid /dev/<devname>

cat /etc/fstab

# Copy the UUID of old EBs

UUID=<UUID>
umount /mnt/new-volume001
#XFS
xfs_admin  -U <UUID> /dev/<devname>

#ext4

# sudo tune2fs -U $UUID  /dev/nvme1n1p1
# e2fsck -f /dev/nvme1n1p1
# sudo tune2fs -U $UUID   /dev/nvme1n1p1
# blkid
# e2label /dev/nvme1n1p1 root

8. Shutdown the new EC2 instance.

9. Unmount both the EBS volumes (new and old) to detach it from the new EC2.

10. Connect the newly EBS to a new EC2 via /dev/sda1 as a bootable EBS.

11. Take your EC2 instance with the resized EBS and have alot of fun! ^_^

👋 If you find this helpful, please click the clap 👏 button below a few times to show your support for the author 👇

🚀Join FAUN Developer Community & Get Similar Stories in your Inbox Each Week

Part 1 : Setup Microservice Extractor , ASP.Net sample app review, ASP.NET application Onboarding

Part 2: Launch visualization, AWS Microservice Extractor for .NET AI-Powered Recommendations, Microservice extraction, Application refactoring

Part 3: Testing, Deploy the new micro-services app on EKS & ECS (Under processing )

Agenda

1. Introduction

2. Launch visualization

3. AWS Microservice Extractor for .NET AI-Powered Recommendations

4. Microservice extraction

5. Application refactoring

6. Conclusion

1. Introduction

we are already discussed the following points in Part 1

1. Setup Microservice Extractor
2. ASP.Net sample app review
3. ASP.NET application Onboarding

Now in this Part 2 we are going to discuss the ASP.NET Class visualization, AI-Powered Recommendations, Microservice extraction and Application refactoring.

2. Launch visualization

If the onboarding status changes to Success, you can open up the visualization either by pointing your mouse at View dependency graph in top green banner or from Applications list selecting Launch Visualization.

Microservice Extractor isolates and identifies the logically grouped components to be extracted as independent services, which are visible in the tab Visualization (Nodes dependencies). A link between nodes indicates a connection between them.
Normally, nodes in the visualization are represented on Project level. Filters allow you to view certain project level or namespace level nodes. In addition, you may also double-click on specific nodes to navigate the namespace level or class level aggregations.

3. AWS Microservice Extractor for .NET AI-Powered Recommendations

What are AI-powered recommendations?

The new AI-powered recommendations system relies on an ML model that inspects the source code of your own project. When the analysis by Microservice Extractor is done, your classes are organized within this tool into prospective candidates for microservices creation.

This improved feature is especially useful for those customers that do not have the required skills to update their applications. This is typically the situation for many companies that have applications with a long ‘shelf’ life in the market, where the original developers are no longer accessible or at times developed by third parties and it becomes challenging to upgrade.

Choosing the right recommendation option

The Microservice Extractor provides three extraction options: manual classification, heuristic assessment, and AI-based recommendations. These are a few of the methods that you can use to grouping your classes for microservices hence enabling you as the developer to select an approach which is flexible and effective at least depending on how comfortable one should get with special building blocks without relying 100 percent on classical ones. Crucially, this first choice of extraction does not restrict your ability to select a different approach through the user interface later on as you contemplate the emerging needs for these new microservices.

If you have a well-developed domain understanding of some application planned for refactoring, the manual classification suits best with the purpose to build such microservice that will serve it. This requires a deep understanding of the application class structure, and even how these classes are related to each other.

If you are familiar with the application at a lower level, but if know enough about how to strip out what is needed then it should be apparent as well from the source code using heuristic analysis where your logical starting points would lie. In this case of analysis, the points selected are classified according to the group that features classes by their name. For instance, in an MVC application a class of controller may act as the starting point at which one would start to pull out an order-related microservice.

On the other hand, in case you have limited or no knowledge about applications that are being modernized, then an AI-powered recommendations engine is very priceless. These recommendations move from the heuristic analysis since they clearly distinguish the entrance and exit points for the services. The microservice extractor application uses AI recommendation algorithms to scan every source file in an application and produce recommendations that one can use as the actual list of the candidates.

to use AI- powered recommendations you can click on Generate automated groups as below:

4. Microservice extraction

In this example, you will extract Inventory as a standalone service.

• Right-click the Inventory node and select Add node to group.

• Select create new group. Set the Group name to InventoryGroup. then click Add

• Right-click on the inventory class then Go to group

• Click View group details.

On the right section, you can find the Group details

Note that the Nodes list refers to the InventoryGroup class. This class will be released as a standalone service and exposed as a REST API after release. Check the list of Dependencies. All dependencies in this list will be listed or referenced in the extracted standalone service.

• Choose Extract group from the Extract and Port menu to begin the extraction process.

• Set name for your standalone service “InventoryService1”

• After complete the extraction process you can check-out the extraction path as below:

Extraction path

• Once extraction is passed, you can open the Output path of the Modified application code & Extracted service

• Open Extracted service codes to identify any changes made

Extracted service codes

• You’ll discover that it created an ApiController called InventoryController. This controller is closely linked to the methods of the Inventory class exposing them as REST APIs.
• It also copied all the Entity Framework data model types and DBContext referenced by the extracted Inventory services under the Models folder.
• In addition it has relocated the Inventory class to the Services folder.

Please note that although our AWS Microservice Extractor, for.NET will make its efforts to ensure that the created service compiles there is no guarantee. You may still need to fix references or update NuGet packages in order to successfully compile the Web API project.

Change the port of Extracted service to be http://localhost:8081/ as below:

• After you finished this step click f5 to test the Extracted service

• Open Modified application code to identify any changes made on monolith app

Please take a look, at the HomeController.cs, ShoppingCartController.cs and StoreController.cs files, in the Controllers folder. The local Inventory class calls have been modified to make remote API calls using the EndpointAdapter.

• The AWS Microservice Extractor for .NET efficiently converts local class calls to remote API calls, but there may be times where manual adjustments or refactoring are necessary.
• Take a look at the EndpointAdapter folder, which was generated during the extraction process, where you’ll find the InventoryEndpointFactory class. This handy class allows for a seamless switch between making remote REST API calls or local Inventory class calls, depending on the setting of the RemoteRoutingToMicroservice flag in the local web.config file.

Modified application Code / web.config

In the line 11 please change the url and link it to the new extracted service [ http://localhost:8081 ] as below:

Modified application Code / web.config

5. Application refactoring

In the preceding sections, you were introduced to the capabilities of AWS Microservice Extractor for .NET and how it can aid in extracting microservices from your existing .NET monolithic applications. Although the subsequent section of this tutorial is not mandatory, it offers valuable insights as most of the tasks involved do not require the use of AWS Microservice Extractor. It is highly recommended to follow these steps if your objective is to successfully refactor the extracted service and integrate it with the remaining monolith through REST APIs.

Refactor the extracted service

• Go to Tools >> NuGet Package Manager >> Package Manager Console

To update the Microsoft.AspNet.WebApi.Client NuGet package, enter the following command in the Package Manager Console. This package will provide support for formatting and content negotiation for System.Net.Http.

Update-Package -reinstall Microsoft.AspNet.WebApi.Client

To optimize communication efficiency, it’s beneficial to transform the Entity Framework data entities from the Inventory class into simplified “plain old CLR objects” (POCOs), also referred to as Data Transfer Objects (DTOs), before transmitting them over the network.

• Create a new class by right-clicking on the GadgetsOnline project in the Visual Studio solution explorer and Name it DTO.cs (copy from step 2–1a from this link)
• Create a new class by right-clicking on the GadgetsOnline project in the Visual Studio solution explorer and Name it DTOHelper.cs (copy from step 2–1b from this link)
• Navigate to the directory “ Models/GadgetsOnlineEntities.cs” and disable the code highlighted in the following section. This particular code is responsible for seeding the data and is unnecessary for the extracted service.

• Open Controllers/InventoryController.cs and do the below code changes.

1. In line 39

//Remove
                //return Ok(myInstance.GetBestSellers(count));

//ADD 
                return Ok(DTOHelper.GetDTOProductList(myInstance.GetBestSellers(count)));

2. in line 99

//Remove
      // return Ok(myInstance.GetAllProductsInCategory(category));

//Add
      return Ok(DTOHelper.GetDTOProductList(myInstance.GetAllProductsInCategory(category)));

3. In line 130

//Remove
          //return Ok(myInstance.GetProductById(id));

//Add
          return Ok(DTOHelper.GetDTOProduct(myInstance.GetProductById(id)));

• To initiate the service in debug mode, simply press F5. Once activated, a browser window will automatically launch as below:

Launch the Extracted service

Refactor the modified application code.

• Go to Tools >> NuGet Package Manager >> Package Manager Console

To update the Microsoft.AspNet.WebApi.Client NuGet package, enter the following command in the Package Manager Console. This package will provide support for formatting and content negotiation for System.Net.Http.

Update-Package -reinstall Microsoft.AspNet.WebApi.Client

• Open Controllers/ShoppingCartController.cs and update line 15 as indicated below

// remove
    //Inventory inventory;

//Add
    IInventoryEndpoint inventory;

• Open Controllers/StoreController.cs and update line 14 as indicated below.

//Remove
   //Inventory inventory;

//Add
   IInventoryEndpoint inventory;
   // GET: Store

Simply hit the F5 button to activate the application’s debug mode. Keep in mind that it may take a few minutes for the web app to fully load, and you may see a message saying “This site can’t be reached” in the meantime. If that occurs, just give it some time to start up completely. Once the application is up and running, you’ll be directed to the same home page you started with. However, take note that the categories displayed on the left side and the list of top-selling products at the bottom are now being fetched from the Inventory Web API through REST API requests.

The ASP.NET Application after refactoring

6. Conclusion

To sum it up, implementing the AWS Microservices Extractor for .NET has splitted the monolithic application into two separate services that seamlessly communicate through REST APIs. This structural change not only amplifies scalability and adaptability, but also maintains a consistent end-user experience. Adopting microservices has been a game-changing move, enhancing efficiency and flexibility in the development and operation of the application.

Abstract

Accepting Amazon EKS or ECS as the ecosystem for running your app is very much beneficial since it has a lot of features that come along. In this series, we will convert ASP.NET application into a microservices architecture with AWS Microservice Extractor for .NET then try to run them in EKS & ECS.

This unique solution specifically for .NET apps lets us go from a monolithic towards the microservices arch, thus more scalability and also better fault isolation as well with cost efficiencies.

In general, throughout the series we will not only show how to extract but also fully test the code and functions of this newly organized microservice.

Part 1 : Setup Microservice Extractor , ASP.Net sample app review, ASP.NET application Onboarding

Part 2: Launch visualization, AWS Microservice Extractor for .NET AI-Powered Recommendations, Microservice extraction, Application refactoring

Part 3: Testing, Deploy the new micro-services app on EKS & ECS (Under processing )

Agenda

1. Introduction

2. Setup Microservice Extractor

3. ASP.Net sample app review

4. ASP.NET application Onboarding

1. Introduction

The AWS Microservice Extractor for .NET simplifies the process of decomposing applications into individual services. Use this tool to improve and modernize .NET applications as it analyzes source code and runtime metrics in order to produce a graphical representation of an application, its relationships. it gives a full view of applications and facilitates the work when dealing with code refactoring as well as extracting different projects & services from existing codebases. This allows teams to perform self-service for developing, constructing and operating these projects thereby improving agility time on hand as well usability scalability.

2. Setup Microservice Extractor

Check the Prerequisites to use AWS Microservice Extractor for .NET form this link : https://docs.aws.amazon.com/microservice-extractor/latest/userguide/microservice-extractor-prerequisites.html

AWS Microservice Extractor for .NET runs on the Microsoft Windows operating system. If you are running this tutorial on a development environment that you control (such as your laptop or a virtual machine), you will need to ensure that you have the following required prerequisites:

1. Visual Studio 2022 (Download VS 2022 Community Edition ) with the following features enabled.

• In the workloads section, select “ASP.NET and Web Development”.

• In the Individual components section, ensure the following are selected:

a. NET 4.7.1 Targeting Pack

b. SQL Server Express 2019 LocalDB

2. Download and Install Git from here .

3. In your AWS account choose to work with us-west-2 region and create new s3 bucket as below:

I have used other region but the tool does not work correctly so just choose us-west-2 region

4. In your AWS account create user then create Secret key & Access key (as an example MicroserviceUser)

Create the IAM policy as this link and link it with your user

5. Download the tool from this link: https://aws.amazon.com/microservice-extractor/

6. Install the tool and open it as below:

7. Click on settings and configure the tool as below :

3. ASP.Net sample app review

You can clone the sample asp.net MVC app by run the below command:

git clone -b extractor-lab https://github.com/aws-samples/dotnet-modernization-gadgetsonline.git

The repository can be found at https://github.com/aws-samples/dotnet-modernization-gadgetsonline

Open downloaded sample app in Visual studio by double-clicking the solution file, located at dotnet-modernization-gadgetsonline\GadgetsOnline\GadgetsOnline.sln

Then, check the structure of the project in Visual Studio. MVC Controllers are classes that receive requests from users and create an instance of a business service class. Each service class creates an instance of the GadgetsOnlineEntities DbContext and passes one or more data model objects (Product, Order, Category etc.) from calling controller.

This application represents a three-layer app, where controllers make requests to business services in order to complete such user deals and facilitate the interaction between the two layers. The latter service is dependent on database access layer calls for further processing of information. This is a typical structure usually seen in ASP.NET MVC frameworks.

In Visual Studio Press F5 to Launch the sample app in debug mode as below

The port (8080) in your case will be different and the home page casue i haved changed some html codes.

Before going to the code details you can check the high level digram as below:

And for more complicated relations between all classes you can check the diagram as below :

Review the Index() method in the Controllers\HomeController.cs file.

• It calls GetBestSellers(6) method to obtain top 6 selling products that will be shown on the home screen page.
  The GetBestSellers method provides data model object collection as a result List<Product>.

Examine the Services\Inventory.cs file in project folders, ! There are several methods that use a instance of the GadgetsOnlineEntities DbContext to fetch data models and filter based on one or more conditions.

4. ASP.NET application Onboarding

1. choose Applications in the left pane.

2. In the right pane, click Onboard application.

3. On the Application details page:

• For Name, enter “Any name”.
• In the Source Code part, click Choose file and find GadgetsOnline.sln in the file picker. click Open.

• For MSBuild path, you should select the version of MSBuild that is to be used in building your app.

Make sure that Visual Studio 2022 is selected (it will be the default option).

The rest of the settings in this section you can leave it as the default values.

• Runtime profiling data — optional is an option that allows for the inclusion of runtime usage measurements which can appear overly on the visualization chart. This is also optional and can be omitted for this experiment.
• Analyze .NET Core Portability This setting can be enabled after installing Porting Assistant for .NET on the same machine as AWS Microservice Extractor. This environment connects a source code analyzer and Porting Assistant to analyze the compatibility of updated.from .Net Framework into .NET core
• Click Onboard application to begin the analysis.
• The analysis will create a directed dependency graph indicating the relationships between various classes of the application.
• This process will take a few moments to finish. Once it has completed, the message “GadgetsOnline is ready for visualization” will be displayed as a banner. You can then proceed to the next step to visualize the dependency graph created by AWS Microservice Extractor for .NET.
• This analysis will generate a directed dependency graph that explains the dependences between different classes of the application.
• This procedure will take a few seconds to be completed. When it has been done, the message “< Your appname > is ready for visualization” will appear on a banner. You may then move on to the next step where you can see the dependency graph that has been generated by AWS Microservice Extractor for .NET.

To view [Part 2] Please check the link below:

https://medium.com/@jomaajob/convert-net-monolithic-app-to-microservices-using-aws-microservice-extractor-part-1-6422442572ed

👋 If you find this helpful, please click the clap 👏 button below a few times to show your support for the author 👇

🚀Join FAUN Developer Community & Get Similar Stories in your Inbox Each Week

Convert .NET Monolithic app to Microservices using AWS Microservice Extractor [Part 1] was originally published in FAUN.dev() 🐾 on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article, we will discuss how you can protect EKS (Objects configuration and Persistent Volume EBS) by Kasten10 from regional disasters. We will create two EKS clusters (us-east-1, us-east-2) and regularly backup the objects configurations of primary EKS to S3 and make an EBS snapshot for persistent volume, so that secondary EKS can import and restore the backup.

Contents:

1. Introduction:
2. Overview of AWS EKS:
3. Overview of Kasten10:
4. Environment preparation:
5. Kasten10 Installation:
6. Backup and restore Ghost application:
7. Conclusion

Prerequisites :

We assume that the reader has basic knowledge of kubernetes ,Helm, AWS.

1. Introduction:

Kubernetes backup refers to the process of creating a copy of the Kubernetes resources and data to protect against data loss and to ensure business continuity. Backing up Kubernetes resources, such as deployments, statefulsets, and services, is critical to ensure that your applications can be quickly restored in case of a catastrophic failure.

There are several Kubernetes backup tools available, including open-source solutions like Velero and commercial solutions from vendors like Kasten10 by Veeam. These tools provide an easy and efficient way to backup and restore Kubernetes resources and data.

Kubernetes backup can be performed at the cluster level, namespace level, or even at the resource level. This provides granular control over the backup process and enables you to create backups that meet specific business requirements.

When implementing Kubernetes backup, it is important to consider factors such as the frequency and scope of backups, recovery point objectives (RPOs), and recovery time objectives (RTOs). Testing backups regularly is also critical to ensure that they can be successfully restored in case of a failure.

To deploy Kasten10 on AWS, users can choose from a variety of deployment options, including Amazon EKS, self-managed Kubernetes clusters, and managed Kubernetes services such as Amazon Elastic Kubernetes Service (EKS) and Amazon EKS Anywhere. Regardless of the deployment option, Kasten10 provides a seamless experience for backup and recovery, with support for various storage providers, including Amazon S3, Amazon EBS, and Amazon EFS.

2. Overview of AWS EKS

AWS EKS (Elastic Kubernetes Service) is a fully managed service that allows you to easily run, scale, and manage Kubernetes clusters on AWS. Kubernetes is an open-source platform for container orchestration that is widely used for deploying and managing containerized applications.

With AWS EKS, you can quickly provision a Kubernetes cluster in a few simple steps, and the service takes care of the underlying infrastructure and management tasks, such as scaling, patching, and upgrading the cluster. This means you can focus on deploying and managing your applications, rather than worrying about the underlying infrastructure.

AWS EKS integrates with other AWS services, such as Amazon Elastic Container Registry (ECR) for storing and managing container images, and AWS Identity and Access Management (IAM) for managing access to your Kubernetes resources. Additionally, EKS provides a number of built-in integrations with other AWS services and third-party tools, such as AWS CloudFormation for infrastructure as code and Grafana for monitoring and observability.

3. Overview of Kasten10

The K10 data management platform, purpose-built for Kubernetes, provides enterprise operations teams an easy-to-use, scalable, and secure system for backup/restore, disaster recovery, and mobility of Kubernetes applications.

K10’s application-centric approach and deep integrations with relational and NoSQL databases, K10 provides a native Kubernetes API and includes features such as full spectrum consistency, database integrations, automatic application discovery, multi-cloud mobility, and a powerful web-based user interface.

Deploying this Quick Start for a new virtual private cloud (VPC) with default parameters builds the following K10 platform in the AWS Cloud. The diagram shows three Availability Zones, leveraging multiple AWS services.

More detailed K10 architecture diagram is shown below.

Kasten K10 provides application backup and mobility capabilities with the following tenets:

• Create scalable and resilient backups. Kasten K10 integrates with the Amazon S3 (and other target stores) so that your applications can be stored as a true backup in a fault-domain that is separated from primary storage and has the cost efficiencies to afford long term retention. The data efficiently transferred by K10 using techniques like dedup and change-block-tracking.
• Seamless Migration: The ability to move an application across clusters is an extremely powerful feature that enables a variety of use cases including Disaster Recovery (DR), Test/Dev with realistic data sets, and performance testing in isolated environments. In particular, the K10 platform is built to support application migration and mobility in a variety of different and overlapping contexts:

1. Cross-Namespace

2. Cross-Cluster

3. Cross-Account: (e.g., AWS accounts, Google Cloud projects)

4. Cross-Region: (e.g., US-East-1 to US-East-2)

5. Cross-Cloud: (e.g., Azure to AWS)

• Treat the application as the operational unit. This balances the needs of operations and development teams in cloud-native environments. Kasten’s data management solution works with an entire application and not just the infrastructure or storage layers. This allows your operations team to scale by ensuring business policy compliance at the application level instead of having to think about the hundreds of components that make up a modern app. At the same time, working with the application gives your developers power and control when needed without slowing them down.

4. Environment preparation :

Our target is to install kasten10 on two EKS as below:

All the instructions are in Linux if you are using Mac or Windows please check out the provided links with each step.

• AWS CLI version 2. See Installing, updating, and uninstalling the AWS CLI version 2.

curl “https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o “awscliv2.zip” unzip awscliv2.zip sudo ./aws/install

• Install eksctl on your desktop machine: See Installing or upgrading eksctl for another OS

curl — silent — location “https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz” | tar xz -C /tmp

sudo mv /tmp/eksctl /usr/local/bin

eksctl version

• Helm. See Installing Helm.

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh

• kubectl. See Installing kubectl.

4.2 Create two EKS Clusters as below :

Two EKS clusters in the same AWS account. See Creating an EKS Cluster. (This blog post was tested with EKS running Kubernetes version 1.24)

The two clusters will be referred to as the Primary{pk} and Recovery {rk}clusters.

Configure all the required environments as below:

REGION=us-east-1
REGION2=us-east-2
BUCKET={Name of AWS S3}
PRIMARY_EKS=pk
RECOVERY_EKS=rk
PRIMARY_CONTEXT=pkc
RECOVERY_CONTEXT=rkc
ACCOUNT=$(aws sts get-caller-identity --query Account --output text)

Create two EKS clusters in separate region { us-east-1 & us-east-2}

eksctl create cluster --name=$PRIMARY_EKS --nodes=3 --node-type=t3.medium --region $REGION
eksctl create cluster --name=$RECOVERY_EKS --nodes=3 --node-type=t3.medium --region $REGION2

#Add two contexts to your .kube file so you can deal with them easily
#For easier management of kubectl config, we add our clusters to kubeconfig with an alias:

aws eks --region $REGION update-kubeconfig --name $PRIMARY_EKS --alias $PRIMARY_CONTEXT
aws eks --region $REGION update-kubeconfig --name $RECOVERY_EKS --alias $RECOVERY_CONTEXT

kubectl config use-context $PRIMARY_CONTEXT
# In the Production env be careful and use this command kubectl config get-contexts to check what the current context

4.3 Configure OIDC

Each cluster must be configured with an EKS IAM OIDC Provider. See Create an IAM OIDC provider for your cluster. This is a requirement for IAM roles for service account which is used to grant the required AWS permissions to the Velero deployments.

kubectl config use-context $PRIMARY_CONTEXT
eksctl utils associate-iam-oidc-provider --cluster $PRIMARY_EKS --approve --region $REGION

kubectl config use-context $RECOVERY_EKS
eksctl utils associate-iam-oidc-provider --cluster $RECOVERY_EKS --approve --region $REGION2

kubectl config use-context $PRIMARY_CONTEXT

oidc_id_primary=$(aws eks describe-cluster --name $PRIMARY_EKS --region $REGION --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5)
oidc_id_recovery=$(aws eks describe-cluster --name $RECOVERY_EKS --region $REGION2 --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5)

echo oidc_id_recovery= $oidc_id_recovery
echo ACCOUNT= $ACCOUNT
echo oidc_id_primary  = $oidc_id_primary

4.4 Set up persistent storage in Amazon EKS useing EBS CSI driver:

• Download an example IAM policy with permissions that allow your worker nodes to create and modify Amazon EBS volumes:

curl -o example-iam-policy.json https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/v0.9.0/docs/example-iam-policy.json

• Create an IAM policy named Amazon_EBS_CSI_Driver:

aws iam create-policy --policy-name AmazonEKS_EBS_CSI_Driver_Policy --policy-document file://example-iam-policy.json

• View your cluster’s OIDC provider URL

aws eks describe-cluster --name $PRIMARY_EKS --region $REGION --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5
aws eks describe-cluster --name $RECOVERY_EKS --region $REGION2 --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5

• To deploy the Amazon EBS CSI driver, run one of the following commands:

# PRIMARY_Cluster
kubectl config use-context $PRIMARY_CONTEXT

kubectl apply -k "github.com/kubernetes-sigs/aws-ebs-csi-driver/deploy/kubernetes/overlays/stable/?ref=master"

eksctl create iamserviceaccount --name ebs-csi-controller-sa --namespace kube-system  --cluster $PRIMARY_EKS --region $REGION --role-name "AmazonEKS_EBS_CSI_DriverRole" \
    --attach-policy-arn arn:aws:iam::$ACCOUNT:policy/AmazonEKS_EBS_CSI_Driver_Policy --approve

kubectl delete pods -n kube-system -l=app=ebs-csi-controller

#make sure that the sa is Annotated with ARN role
kubectl describe serviceAccount ebs-csi-controller-sa -n kube-system

# RECOVERY_Cluster 

kubectl config use-context $RECOVERY_CONTEXT

kubectl apply -k "github.com/kubernetes-sigs/aws-ebs-csi-driver/deploy/kubernetes/overlays/stable/?ref=master"

eksctl create iamserviceaccount --name ebs-csi-controller-sa --namespace kube-system   --cluster $RECOVERY_EKS --region $REGION2 --role-name "AmazonEKS_EBS_CSI_DriverRole_recovery" \
--attach-policy-arn arn:aws:iam::$ACCOUNT:policy/AmazonEKS_EBS_CSI_Driver_Policy --approve

kubectl delete pods -n kube-system -l=app=ebs-csi-controller

# make sure that the sa is Annotated with ARN role
kubectl describe serviceAccount ebs-csi-controller-sa -n kube-system

eksctl will Annotate the ebs-csi-controller-sa Kubernetes service account with the Amazon Resource Name (ARN) of the IAM role that will created too by eksctl:

4.5 Prepare S3 to Save Kasten10’s backups :

aws s3 mb s3://$BUCKET --region $REGION

Although Amazon S3 stores your data across multiple geographically distant Availability Zones by default, compliance requirements might dictate that you store data at even greater distances. Cross-Region Replication allows you to replicate data between distant AWS Regions to satisfy these requirements.

4.6 Prepare IAM policy for Kasten10 deployment :

Kasten10 performs a number of API calls to resources in EC2 and S3 to perform snapshots and save the backup to the S3 bucket. The following IAM policy will grant Kasten10 the necessary permissions

cat > Kasten10.json <<EOF
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:CopySnapshot",
                "ec2:CreateSnapshot",
                "ec2:CreateTags",
                "ec2:CreateVolume",
                "ec2:DeleteTags",
                "ec2:DeleteVolume",
                "ec2:DescribeSnapshotAttribute",
                "ec2:ModifySnapshotAttribute",
                "ec2:DescribeAvailabilityZones",
                "ec2:DescribeRegions",
                "ec2:DescribeSnapshots",
                "ec2:DescribeTags",
                "ec2:DescribeVolumeAttribute",
                "ec2:DescribeVolumesModifications",
                "ec2:DescribeVolumeStatus",
                "ec2:DescribeVolumes"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "ec2:DeleteSnapshot",
            "Resource": "*",
            "Condition": {
                "StringLike": {
                    "ec2:ResourceTag/Name": "Kasten: Snapshot*"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:CreateBucket",
                "s3:PutObject",
                "s3:GetObject",
                "s3:PutBucketPolicy",
                "s3:ListBucket",
                "s3:DeleteObject",
                "s3:DeleteBucketPolicy",
                "s3:GetBucketLocation",
                "s3:GetBucketPolicy"
            ],
            "Resource": "*"
        }
    ]
}
EOF

# Create Katen10 IAM Policy
aws iam create-policy --policy-name KastenPolicy --policy-document file://Kasten10.json

5. Kasten10 Installation :

We should install Kasten10 on both EKS clusters, you can check out the diagram below for more details :

helm repo add kasten https://charts.kasten.io/

kubectl config use-context $PRIMARY_CONTEXT
helm install k10 kasten/k10 --namespace=kasten-io # --set serviceAccount.create=false

kubectl config use-context $RECOVERY_CONTEXT
helm install k10 kasten/k10 --namespace=kasten-io # --set serviceAccount.create=false

To establish a connection to it use the following `kubectl` command:

# RECOVERY_Cluster
kubectl config use-context $PRIMARY_CONTEXT

kubectl -namespace kasten-io port-forward service/gateway 8080:8000

# The Kasten dashboard will be available at: `http://127.0.0.1:8080/k10/#/`

# open new terminal and run thoses for RECOVERY_Cluster

kubectl config use-context $RECOVERY_CONTEXT
kubectl -namespace kasten-io port-forward service/gateway 8090:8000

# The Kasten dashboard will be available at: `http://127.0.0.1:8090/k10/#/`

Annotate the K10-k10 sa Kubernetes service account with the Amazon Resource Name (ARN) of the IAM role that will be created too by eksctl:

# PRIMARY_EKS

# Change the context 
kubectl config use-context $PRIMARY_CONTEXT

# delete the sa 
kubectl delete serviceAccount k10-k10  -n kasten-io

# Create iamserviceaccount and linked with new k10-k10 sa
eksctl create iamserviceaccount --name k10-k10 --namespace kasten-io  --cluster $PRIMARY_EKS --region $REGION --role-name "KastenRole" --attach-policy-arn arn:aws:iam::$ACCOUNT:policy/KastenPolicy --approve

    
kubectl describe serviceAccount k10-k10  -n kasten-io

# RECOVERY_EKS

# Change the context
kubectl config use-context $RECOVERY_CONTEXT

# delete the sa
kubectl delete serviceAccount k10-k10  -n kasten-io

# Create iamserviceaccount and linked with new k10-k10 sa
eksctl create iamserviceaccount --name k10-k10 --namespace kasten-io  --cluster $RECOVERY_EKS --region $REGION2 --role-name "KastenRecoverRole" --attach-policy-arn arn:aws:iam::$ACCOUNT:policy/KastenPolicy --approve

# make sure that sa is Annotated with ARN role
kubectl describe serviceAccount k10-k10 -n kasten-io

eksctl will Annotate the k10-k10 Kubernetes service account with the Amazon Resource Name (ARN) of the IAM role that will created too by eksctl:

6. Backup and restore Ghost application:

Ghost is an open-source publishing platform designed to create blogs, magazines, and news sites. It includes a simple markdown editor with preview, theming, and SEO built-in to simplify editing.

We will use the Bitnami Helm chart as it’s commonly deployed and well-tested. This chart depends on the Bitnami MariaDB chart that will serve as the persistent data store for the blog application. The MariaDB data will be stored in an EBS volume that will be snapshotted by Velero as part of performing the backup.

Now we switch to the Primary cluster’s context and install Ghost (ignore the notification ERROR: you did not provide an external host that appears when you install Ghost. This will be solved with the following commands):

helm repo add bitnami https://charts.bitnami.com/bitnami

kubectl config use-context $PRIMARY_CONTEXT
helm install ghost bitnami/ghost \
    --create-namespace \
    --namespace ghost

export APP_HOST=$(kubectl get svc --namespace ghost ghost --template "{{ range (index .status.loadBalancer.ingress 0) }}{{ . }}{{ end }}")
export GHOST_PASSWORD=$(kubectl get secret --namespace "ghost" ghost -o jsonpath="{.data.ghost-password}" | base64 -d)
export MYSQL_ROOT_PASSWORD=$(kubectl get secret --namespace "ghost" ghost-mysql -o jsonpath="{.data.mysql-root-password}" | base64 -d)
export MYSQL_PASSWORD=$(kubectl get secret --namespace "ghost" ghost-mysql -o jsonpath="{.data.mysql-password}" | base64 -d)

helm upgrade ghost bitnami/ghost \
  --namespace ghost \
  --set service.type=LoadBalancer,ghostHost=$APP_HOST,ghostPassword=$GHOST_PASSWORD,mysql.auth.rootPassword=$MYSQL_ROOT_PASSWORD,mysql.auth.password=$MYSQL_PASSWORD

We can check that the installation was successful by running this command:

kubectl get pod -A

In the Ghost Admin console, you can create an example blog post that will be included in the backup and restore process by signing in (using the Admin URL displayed above). As a result, the backup includes not only the application deployment configuration but also the posts in the blog database that is saved in PV — EBS.

6.1 Backup Ghost application

Open a new terminal and run those commands

kubectl config use-context $PRIMARY_CONTEXT

kubectl --namespace kasten-io port-forward service/gateway 8080:8000

Open this link http://127.0.0.1:8080/k10/#/ in your browser

Go to settings and choose locations, in this page you will configure your S3 Bucket that has already been created to save your EKS backup files.

echo $BUCKET

Now go to Dashboard → Applications → Ghost app → Create a Policy

and configure your policy to take a frequent snapshot as below:

Go to the polices section and chack-out your new one and try to run it once.

In this policy please Click on “Show more details” as below and save this token, because we need it to configure restore policy in the recovery EKS

After finishing this job Go to the S3 bucket and Snapshot section in the AWS console to follow up on the changes as below:

6.2 Restore Ghost application

Open a new terminal and run those commands

kubectl config use-context $RECOVERY_EKS

kubectl --namespace kasten-io port-forward service/gateway 8090:8000

Open this link http://127.0.0.1:8090/k10/#/ in your browser

Go to settings and choose locations, in this page you will configure your S3 Bucket that has already been created to restore your EKS backup files.

echo $BUCKET

Now go to Dashboard → Applications → Ghost app → Create a Policy

Now go to Dashboard → Applications → Ghost app → restore

choose one of PIT to restore your application and restore it

Note: you can configure the policy to restore after import

Summary :

In conclusion, Kasten10 is a powerful data management solution that simplifies backup, recovery, and mobility of Kubernetes applications. By deploying Kasten10 on AWS, users can take advantage of the scalability and flexibility of the cloud to protect their applications and data. With Kasten10’s comprehensive features, including backup scheduling, policy-based automation, and efficient data storage, users can ensure the availability and integrity of their Kubernetes workloads.

To deploy Kasten10 on AWS, users can choose from a variety of deployment options, including Amazon EKS, self-managed Kubernetes clusters, and managed Kubernetes services such as Amazon Elastic Kubernetes Service (EKS) and Amazon EKS Anywhere. Regardless of the deployment option, Kasten10 provides a seamless experience for backup and recovery, with support for various storage providers, including Amazon S3, Amazon EBS, and Amazon EFS.

Overall, implementing Kasten10 on AWS provides a robust solution for Kubernetes data management, with the flexibility and scalability of the cloud. Whether you’re managing a small-scale deployment or a large-scale enterprise cluster, Kasten10 and AWS have you covered.

👋 If you find this helpful, please click the clap 👏 button below a few times to show your support for the author 👇

🚀Join FAUN Developer Community & Get Similar Stories in your Inbox Each Week

Abstract :

The purpose of this document is to backup AWS EKS (Object configurations & persistent data — EBS) in the same region. In a Cross-Region scenario, we encountered this issue, and you can implement the Cross-Region solution using this branch by (Jesse Glick).

Prerequisites :

We assume that the reader has basic knowledge of kubernetes ,Helm, AWS.

Contents:

1. Introduction

2. Overview of Velero

3. Overview of AWS EKS

4. Implementing Velero on EKS

5. Cleaning up

6. Conclusion

1. Introduction :

Kubernetes backup refers to the process of creating a copy of the Kubernetes resources and data to protect against data loss and to ensure business continuity. Backing up Kubernetes resources, such as deployments, statefulsets, and services, is critical to ensure that your applications can be quickly restored in case of a catastrophic failure.

There are several Kubernetes backup tools available, including open-source solutions like Velero and commercial solutions from vendors like VMware and Trilio. These tools provide an easy and efficient way to backup and restore Kubernetes resources and data.

Kubernetes backup can be performed at the cluster level, namespace level, or even at the resource level. This provides granular control over the backup process and enables you to create backups that meet specific business requirements.

When implementing Kubernetes backup, it is important to consider factors such as the frequency and scope of backups, recovery point objectives (RPOs), and recovery time objectives (RTOs). Testing backups regularly is also critical to ensure that they can be successfully restored in case of a failure.

2. Overview of Velero:

Velero is an open-source tool that enables backup and disaster recovery of Kubernetes clusters and their persistent volumes. It can be used to back up your Kubernetes resources, including namespace, deployment, statefulset, cronjob, and others, as well as the persistent volumes associated with them.

Velero consists of two components:

• A Velero server pod that runs in your Amazon EKS cluster
• A command-line client (Velero CLI) that runs locally

2.1 How Velero Backup works:

When you run velero backup create test-backup:

1. The Velero client makes a call to the Kubernetes API server to create a Backup object.
2. The BackupController notices the new Backup object and performs validation.
3. The BackupController begins the backup process. It collects the data to back up by querying the API server for resources.
4. The BackupController makes a call to the object storage service – for example, AWS S3 – to upload the backup file.

By default, velero backup create makes disk snapshots of any persistent volumes. You can adjust the snapshots by specifying additional flags. Run velero backup create --help to see available flags. Snapshots can be disabled with the option --snapshot-volumes=false.

2.2 How Velero Restore works:

1. The Velero CLI makes a call to Kubernetes API server to create a restore CRD that will restore from an existing backup.
2. The restore controller:

2.1. Validates the restore CRD object.

2.2. Makes a call to Amazon S3 to retrieve backup files.

2.3. Initiates restore operation.

The restore operation allows you to restore all of the objects and persistent volumes from a previously created backup. You can also restore only a filtered subset of objects and persistent volumes.

By default, backup storage locations are created in read-write mode. However, during a restore, you can configure a backup storage location to be in read-only mode, which disables backup creation and deletion for the storage location. This is useful to ensure that no backups are inadvertently created or deleted during a restore scenario.

3. Overview of AWS EKS?

AWS EKS (Elastic Kubernetes Service) is a fully managed service that allows you to easily run, scale, and manage Kubernetes clusters on AWS. Kubernetes is an open-source platform for container orchestration that is widely used for deploying and managing containerized applications.

With AWS EKS, you can quickly provision a Kubernetes cluster in a few simple steps, and the service takes care of the underlying infrastructure and management tasks, such as scaling, patching, and upgrading the cluster. This means you can focus on deploying and managing your applications, rather than worrying about the underlying infrastructure.

AWS EKS integrates with other AWS services, such as Amazon Elastic Container Registry (ECR) for storing and managing container images, and AWS Identity and Access Management (IAM) for managing access to your Kubernetes resources. Additionally, EKS provides a number of built-in integrations with other AWS services and third-party tools, such as AWS CloudFormation for infrastructure as code and Grafana for monitoring and observability.

4. Implementing Velero on EKS

When it comes to using Velero on Amazon Web Services (AWS) Elastic Kubernetes Service (EKS), there are a few steps that need to be taken. Here’s a general outline of the process:

1. Install Velero: Velero can be installed on EKS using the Helm chart.
2. Configure Velero: After installing Velero, you’ll need to configure it to specify which resources you want to back up and where to store the backups. This can be done by creating a Velero custom resource definition (CRD)
3. Create a storage location: To store your backups, you’ll need to create a storage location. This can be done using an Amazon S3 bucket, which can be created using the AWS Management Console.
4. Backup your resources: Once Velero is configured, you can create a backup of your Kubernetes resources using the command velero backup create <backup-name>.
5. Restore your resources: If you need to restore your resources, you can do so using the command velero restore create <restore-name> --from-backup <backup-name>.

These are just the basic steps for using Velero on AWS EKS. There are many additional options and features available with Velero that can be customized to fit your specific needs.

4.1 Prerequisites

All the instructions are in Linux if you are using Mac or Windows please check out the provided links with each step.

• AWS CLI version 2. See Installing, updating, and uninstalling the AWS CLI version 2.

curl “https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o “awscliv2.zip” unzip awscliv2.zip sudo ./aws/install

• Install eksctl on your desktop machine: See Installing or upgrading eksctl for another OS

curl — silent — location “https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz” | tar xz -C /tmp

sudo mv /tmp/eksctl /usr/local/bin

eksctl version

• Helm. See Installing Helm.

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh

• kubectl. See Installing kubectl.

4.2 Create two EKS Clusters as below :

Two EKS clusters in the same AWS account. See Creating an EKS Cluster. (This blog post was tested with EKS running Kubernetes version 1.24.)

The two clusters will be referred to as the Primary and Recovery clusters.

Configure all the required environment as below:

BUCKET=<BUCKETNAME> 
REGION=<REGION>
PRIMARY_EKS=<PRIMARY CLUSTERNAME>
RECOVERY_EKS=<RECOVERY CLUSTERNAME>
REGION=<Your AWS region>

eksctl create cluster --name=$PRIMARY_EKS --nodes=3 --node-type=t3.small --region $REGION
eksctl create cluster --name=$RECOVERY_EKS --nodes=3 --node-type=t3.small --region $REGION

# Add two contexts to your .kube file so you can deal with them easily
#For easier management of kubectl config, we add our clusters to kubeconfig with an alias:

PRIMARY_CONTEXT=PRIMARY_velero
RECOVERY_CONTEXT=RECOVERY_velero
aws eks --region $REGION update-kubeconfig --name $PRIMARY_EKS --alias $PRIMARY_CONTEXT
aws eks --region $REGION update-kubeconfig --name $RECOVERY_EKS --alias $RECOVERY_CONTEXT

kubectl config use-context $PRIMARY_CONTEXT
# In the Production env be careful and use this command kubectl config get-contexts to check what the current context

• Each cluster must be configured with an EKS IAM OIDC Provider. See Create an IAM OIDC provider for your cluster. This is a requirement for IAM roles for service account which is used to grant the required AWS permissions to the Velero deployments.

kubectl config use-context $PRIMARY_CONTEXT
eksctl utils associate-iam-oidc-provider --cluster $PRIMARY_EKS --approve

kubectl config use-context $RECOVERY_EKS
eksctl utils associate-iam-oidc-provider --cluster $RECOVERY_EKS --approve

kubectl config use-context $PRIMARY_CONTEXT

4.3 Set up persistent storage in Amazon EKS useing EBS CSI driver:

• Download an example IAM policy with permissions that allow your worker nodes to create and modify Amazon EBS volumes:

curl -o example-iam-policy.json https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/v0.9.0/docs/example-iam-policy.json

• Create an IAM policy named Amazon_EBS_CSI_Driver:

aws iam create-policy --policy-name AmazonEKS_EBS_CSI_Driver_Policy --policy-document file://example-iam-policy.json

• View your cluster’s OIDC provider URL

oidc_id_primary=$(aws eks describe-cluster --name $PRIMARY_EKS --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5)
oidc_id_recovery=$(aws eks describe-cluster --name $RECOVERY_EKS --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5)
ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
echo $oidc_id_primary
echo $oidc_id_recovery
echo $ACCOUNT

• Create the following IAM trust policies file:

cat <<EOF > trust-policy-primary.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::$ACCOUNT:oidc-provider/oidc.eks.$REGION.amazonaws.com/id/$oidc_id_primary"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.$REGION.amazonaws.com/id/$oidc_id_primary:sub": "system:serviceaccount:kube-system:ebs-csi-controller-sa"
        }
      }
    }
  ]
}
EOF

cat <<EOF > trust-policy-recovery.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::$ACCOUNT:oidc-provider/oidc.eks.$REGION.amazonaws.com/id/$oidc_id_recovery"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.$REGION.amazonaws.com/id/$oidc_id_recovery:sub": "system:serviceaccount:kube-system:ebs-csi-controller-sa"
        }
      }
    }
  ]
}
EOF

• Create an IAM roles:

aws iam create-role \
  --role-name AmazonEKS_EBS_CSI_DriverRole \
  --assume-role-policy-document file://"trust-policy-primary.json"

aws iam create-role \
  --role-name AmazonEKS_EBS_CSI_DriverRole_Recovery \
  --assume-role-policy-document file://"trust-policy-recovery.json"

• Attach your new IAM policies to the roles:

aws iam attach-role-policy \
--policy-arn arn:aws:iam::$ACCOUNT:policy/AmazonEKS_EBS_CSI_Driver_Policy \
--role-name AmazonEKS_EBS_CSI_DriverRole

aws iam attach-role-policy \
--policy-arn arn:aws:iam::$ACCOUNT:policy/AmazonEKS_EBS_CSI_Driver_Policy \
--role-name AmazonEKS_EBS_CSI_DriverRole_Recovery

• To deploy the Amazon EBS CSI driver, run one of the following commands:

kubectl config use-context $PRIMARY_CONTEXT
kubectl apply -k "github.com/kubernetes-sigs/aws-ebs-csi-driver/deploy/kubernetes/overlays/stable/?ref=master"

kubectl config use-context $RECOVERY_CONTEXT
kubectl apply -k "github.com/kubernetes-sigs/aws-ebs-csi-driver/deploy/kubernetes/overlays/stable/?ref=master"

• Annotate the ebs-csi-controller-sa Kubernetes service account with the Amazon Resource Name (ARN) of the IAM role that you created earlier:

# PRIMARY_CONTEXT -- 
kubectl config use-context $PRIMARY_CONTEXT

kubectl annotate serviceaccount ebs-csi-controller-sa \
  -n kube-system \
  eks.amazonaws.com/role-arn=arn:aws:iam::$ACCOUNT:role/AmazonEKS_EBS_CSI_DriverRole

kubectl delete pods -n kube-system -l=app=ebs-csi-controller

# ---------------------------------------------------

# RECOVERY_CONTEXT -- 
kubectl config use-context $RECOVERY_CONTEXT

kubectl annotate serviceaccount ebs-csi-controller-sa \
  -n kube-system \
  eks.amazonaws.com/role-arn=arn:aws:iam::$ACCOUNT:role/AmazonEKS_EBS_CSI_DriverRole_Recovery

kubectl delete pods -n kube-system -l=app=ebs-csi-controller

# Return Back to PRIMARY_CONTEXT
kubectl config use-context $PRIMARY_CONTEXT

In this step, make sure that you annotate the service account ebs-csi-controller-sa correctly (optional )

kubectl edit serviceaccount ebs-csi-controller-sa -n kube-system

4.4 Prepare S3 to Save velero’s backups :

aws s3 mb s3://$BUCKET --region $REGION

Although Amazon S3 stores your data across multiple geographically distant Availability Zones by default, compliance requirements might dictate that you store data at even greater distances. Cross-Region Replication allows you to replicate data between distant AWS Regions to satisfy these requirements.

4.5 Prepare IAM policy for Velero deployment :

Velero performs a number of API calls to resources in EC2 and S3 to perform snapshots and save the backup to the S3 bucket. The following IAM policy will grant Velero the necessary permissions

cat > velero_policy.json <<EOF
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeVolumes",
                "ec2:DescribeSnapshots",
                "ec2:CreateTags",
                "ec2:CreateVolume",
                "ec2:CreateSnapshot",
                "ec2:DeleteSnapshot"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:DeleteObject",
                "s3:PutObject",
                "s3:AbortMultipartUpload",
                "s3:ListMultipartUploadParts"
            ],
            "Resource": [
                "arn:aws:s3:::${BUCKET}/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::${BUCKET}"
            ]
        }
    ]
}
EOF

aws iam create-policy \ 
    --policy-name VeleroAccessPolicy \
    --policy-document file://velero_policy.json

4.6 Create Service Accounts for Velero:

The best practice for providing AWS policies to applications running on EKS clusters is to use IAM Roles for Service Accounts. eksctl provides an easy way to create the required IAM role and scope the trust relationship to the velero-server Service Account.

eksctl create iamserviceaccount \
--cluster=$PRIMARY_EKS \
--name=velero-server \
--namespace=velero \
--role-name=eks-velero-backup \
--role-only \
--attach-policy-arn=arn:aws:iam::$ACCOUNT:policy/VeleroAccessPolicy \
--approve

eksctl create iamserviceaccount \
--cluster=$RECOVERY_EKS \
--name=velero-server \
--namespace=velero \
--role-name=eks-velero-recovery \
--role-only \
--attach-policy-arn=arn:aws:iam::$ACCOUNT:policy/VeleroAccessPolicy \
--approve

The --namespace=velero flag ensures that only an workloads running in the velero namespace will be able to access the IAM Policy (VeleroAccessPolicy)

4.7 Install Velero in both EKS Clusters

helm repo add vmware-tanzu https://vmware-tanzu.github.io/helm-charts

cat > values.yaml <<EOF
configuration:
  backupStorageLocation:
    bucket: $BUCKET
  provider: aws
  volumeSnapshotLocation:
    config:
      region: $REGION
credentials:
  useSecret: false
initContainers:
- name: velero-plugin-for-aws
  image: velero/velero-plugin-for-aws:v1.6.1
  volumeMounts:
  - mountPath: /target
    name: plugins
serviceAccount:
  server:
    annotations:
      eks.amazonaws.com/role-arn: "arn:aws:iam::${ACCOUNT}:role/eks-velero-backup"
EOF

cat > values_recovery.yaml <<EOF
configuration:
  backupStorageLocation:
    bucket: $BUCKET
  provider: aws
  volumeSnapshotLocation:
    config:
      region: $REGION
credentials:
  useSecret: false
initContainers:
- name: velero-plugin-for-aws
  image: velero/velero-plugin-for-aws:v1.6.1
  volumeMounts:
  - mountPath: /target
    name: plugins
serviceAccount:
  server:
    annotations:
      eks.amazonaws.com/role-arn: "arn:aws:iam::${ACCOUNT}:role/eks-velero-recovery"
EOF

We need to install the Velero server twice: once in the Primary cluster and again in the Recovery cluster.

We can check that we have these new contexts with the following command:

kubectl config get-contexts

• Change the context to your Primary cluster and install Velero:

kubectl config use-context $PRIMARY_CONTEXT
helm install velero vmware-tanzu/velero \
    --create-namespace \
    --namespace velero \
    -f values.yaml

We can check that the Velero server was successfully installed by running this command in each context:

kubectl get pods –n velero

• Now change the context to your Recovery cluster and proceed to install Velero:

kubectl config use-context $RECOVERY_CONTEXT
helm install velero vmware-tanzu/velero \
    --create-namespace \
    --namespace velero \
    -f values_recovery.yaml

4.7.1 Install the Velero CLI

Velero operates by submitting commands as CRDs. To take a backup of the cluster, you submit to the cluster a backup CRD. These can be difficult to create by hand, so the Velero team has created a CLI that makes it easy to perform backups and restores. We will be using the Velero CLI to create a backup of the Primary cluster and restore to the Recovery cluster.

Installation instructions vary depending on your operating system. Follow the instructions to install Velero here.

4.8 Backup and restore Ghost application

Ghost is an open-source publishing platform designed to create blogs, magazines, and news sites. It includes a simple markdown editor with preview, theming, and SEO built-in to simplify editing.

We will use the Bitnami Helm chart as it’s commonly deployed and well-tested. This chart depends on the Bitnami MariaDB chart that will serve as the persistent data store for the blog application. The MariaDB data will be stored in an EBS volume that will be snapshotted by Velero as part of performing the backup.

Now we switch to the Primary cluster’s context and install Ghost (ignore the notification ERROR: you did not provide an external host that appears when you install Ghost. This will be solved with the following commands):

helm repo add bitnami https://charts.bitnami.com/bitnami

kubectl config use-context $PRIMARY_CONTEXT
helm install ghost bitnami/ghost \
    --create-namespace \
    --namespace ghost

export APP_HOST=$(kubectl get svc --namespace ghost ghost --template "{{ range (index .status.loadBalancer.ingress 0) }}{{ . }}{{ end }}")
export GHOST_PASSWORD=$(kubectl get secret --namespace "ghost" ghost -o jsonpath="{.data.ghost-password}" | base64 -d)
export MYSQL_ROOT_PASSWORD=$(kubectl get secret --namespace "ghost" ghost-mysql -o jsonpath="{.data.mysql-root-password}" | base64 -d)
export MYSQL_PASSWORD=$(kubectl get secret --namespace "ghost" ghost-mysql -o jsonpath="{.data.mysql-password}" | base64 -d)

helm upgrade ghost bitnami/ghost \
  --namespace ghost \
  --set service.type=LoadBalancer,ghostHost=$APP_HOST,ghostPassword=$GHOST_PASSWORD,mysql.auth.rootPassword=$MYSQL_ROOT_PASSWORD,mysql.auth.password=$MYSQL_PASSWORD

We can check that the installation was successful by running this command:

kubectl get pod -A

In the Ghost Admin console, you can create an example blog post that will be included in the backup and restore process by signing in (using the Admin URL displayed above). As a result, the backup includes not only the application deployment configuration but also the posts in the blog database that is saved in PV — EBS.

4.9 Backup Primary Cluster

Create a backup of the Primary cluster. Be sure to switch your kubectl context back to the Primary cluster before running the command below.

We can see how a Velero backup CRD looks like by using the -o flag, which outputs the backup CRD YAML without actually submitting the backup creation to the Velero server.

kubectl config use-context $PRIMARY_CONTEXT

# Check out the outputs of configurations file
velero backup create ghost-backup -o yaml

velero backup create ghost-backup

The backup CRD shows that we are backing up all namespaces since the includedNamespaces array includes the star wildcard. By using selectors, we can choose individual components of the cluster, even though we are backing up the entire cluster. As a result, we are able to back up a single namespace, which may include a single application.

We can also see the backup files created by Velero in the Amazon S3 bucket we previously created:

aws s3 ls $BUCKET/backups/ghost-backup/

4.10 Validate the backup :

Let’s check the status of the backup and validate that backup has been completed successfully.

velero backup describe ghost-backup

Check out the field Phase: in the output. If the current Phase is InProgress, then wait a few seconds and try again until you see the Phase: Completed.

4.11 Restore the app into the Recovery cluster

# Switch your kubectl context to your Recovery cluster.
kubectl config use-context $RECOVERY_CONTEXT

velero restore create ghost-restore \
    --from-backup ghost-backup \
    --include-namespaces ghost

you can check the services in the ghost namespace as below:

kubectl -n ghost get svc ghost

• Validate that the restoring processes have been completed by visiting the URL under EXTERNAL-IP, and check if your previous post is existing.

You might need to change the DNS for your production environment and assign it to a new EKS cluster

4.12 Schedule a Backup

The schedule operation allows you to create a backup of your data at a specified time, defined by a Cron expression.

velero schedule create NAME --schedule="* * * * *" [flags]

• Cron schedules use the following format.

# ┌───────────── minute (0 - 59)
# │ ┌───────────── hour (0 - 23)
# │ │ ┌───────────── day of the month (1 - 31)
# │ │ │ ┌───────────── month (1 - 12)
# │ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday;
# │ │ │ │ │                                   7 is also Sunday on some systems)
# │ │ │ │ │
# │ │ │ │ │
# * * * * *

• For example, the command below creates a backup that runs every 30 minutes.

velero schedule create ghost-schedule --schedule="*/30 * * * *"

This command will create the backup, ghost-schedulewithin Velero, but the backup will not be taken until the next scheduled time, Every 30 minutes.

Backups created by a schedule are saved with the name <SCHEDULE NAME>-<TIMESTAMP>, where <TIMESTAMP> is formatted as YYYYMMDDhhmmss. For a full list of available configuration, flags use the Velero CLI help command.

For more details check Velero Backup Reference

5. Cleaning up

To avoid incurring future charges, delete the resources. If you used eksctl to create your clusters, you can use eksctl delete cluster <clustername> to delete the clusters.

# Delete PRIMARY_EKS Cluster
eksctl delete cluster $PRIMARY_EKS

# Delete RECOVERY_EKS Cluster
eksctl delete cluster $RECOVERY_EKS

# Delete S3  Bucket
aws s3 rb s3://$BUCKET --force

6. Conclusion

In conclusion, Velero is a powerful tool for managing backups and restores of Kubernetes applications, and it’s a great fit for running on EKS. With Velero, you can easily backup your Kubernetes resources, including your applications, volumes, and configuration data, to an S3 bucket, and restore them in case of a disaster or data loss. With Velero on EKS, you can also easily migrate your applications across clusters or regions, and ensure your data is securely stored and protected. Additionally, Velero provides advanced features like scheduling backups, specifying backup retention policies, and validating backups, making it a versatile tool for managing your Kubernetes workloads on EKS.

Overall, Velero on EKS is a great solution for anyone looking to simplify their backup and restore process for Kubernetes applications, while taking advantage of the scalability and flexibility of EKS. Whether you’re a developer, a DevOps engineer, or a cloud administrator, Velero can help you ensure your Kubernetes workloads are always available and protected, so you can focus on delivering value to your users.

👋 If you find this helpful, please click the clap 👏 button below a few times to show your support for the author 👇

🚀Join FAUN Developer Community & Get Similar Stories in your Inbox Each Week

How to Backup & Protect AWS EKS using Velero from vmware-tanzu was originally published in FAUN.dev() 🐾 on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article talks about the features and capabilities of AWS Migration-Hub Orchestrate, accompanied by examples that illustrate its technical aspects. We consider a scenario where we have an On-prem application comprising of two virtual machines (Linux and Windows). We will explore how these VMs can be seamlessly migrated to AWS as EC2 instances using Migration Hub’s Orchestrate functionality..

Prerequisites

We supposed that the reader has the basic knowledge of AWS, AWS Migrations strategics, AWS MGN, System administration (Linux, Windows )

The content :

1- Introduction

2- What is Migration-hub

3- What is Migration-hub orchestrator

4- Solution Architecture

5- Implementation

6- Conclusion

1. Introduction :

The existing solution for migrating On-prem workloads to AWS suffers from several issues.

1- Central Management Dashboard: Beginning with the lack of an integrated dashboard that can facilitate the managing and orchestrating this journey. Prepare MHO-Plugin ImageThis interface, however, does not serve any unified control and oversight.
2- Automated Standards: Another major issue is a lack of automated standards, which becomes acute at work with big and demanding customers who have lots of servers. It leads to the loss of time on repeated operations and also a greater chance of human errors, particularly in relation to the daily technical activities associated with migration.

Migration Hub addresses these challenges with an effective solution by offering further functionality to automate the On-prem workloads migration towards AWS. With the Migration Hub, you can bypass many such challenges and achieve a more seamless migration process.

2. What is Migration-hub?

With Migration Hub, you get a clear view of your application lineup, making planning and monitoring a breeze. It doesn’t matter which migration tool you’re using — you can visualize the status of each connection, server, or database for the applications in your portfolio.

Migration Hub gives you the flexibility to either jump right into migration and create groups as your servers move, or you can first identify servers and then group applications. The choice is yours! And no matter which approach you take, you can migrate each server in an application and keep an eye on the progress using any tool in AWS Migration Hub

• For those considering to migrate their applications through lift-and-shift on AWS, they should consider employing the Application Migration Service service. You should go to the AWS Application Migration Service with its documentation for a deeper understanding.
• In the database migration to AWS, in our case we have chosen a Database Migration Service also known as an AWS DMS. In case you need more details to make sure that your database move is successful, do no hesitate using the information about AWS Database Migration Service and find its documentation.

3. What is a Migration-hub Orchestrate?

Imagine how AWS Migration Hub Orchestrator is like your personal assistant, simplifying and automating the whole process of shifting your servers as well as enterprise apps on to Amazon Web Services. It serves as a single stop way station where you can hassle freely manage and track your migration path.

SAP NetWeaver-based applications, including such as the ones like S/4HANA may be shifted to AWS using Migration Hub Orchestrator very easily. It achieves this by re-hosting them with the custom applications supported on Amazon EC2. The best part? The available templates would include many that one can conveniently edit to match the unique demands of the migration.

Migration Hub Orchestrator automates the steps in your chosen workflow and displays the status of the migration.

4. Solution Architecture :

Step 1:

In this step, we will Install AWS Application Discovery to get some information about VMs (CPU, Memory, Disk, Network, IPs, etc). once you finish this step you will be able to see those servers on the Migration-Hub servers console.

Step 2:

From the Migration-Hub console tool tap, you can download a plugin image and boot it on an On-prem environment and configure the connectivity & credentials on (Linux/SSH-22),(Windows/WinRM-5986) VMs

Step 3:

In this step, you are ready to build the workflow that will automate the VMs migration and launch them on AWS

Step 4:

During the workflow, one crucial step involves installing an MGN agent on the virtual machines (VMs) to facilitate the replication of their data to the replication server on AWS. This step ensures seamless data transfer and is executed automatically without requiring any manual intervention. The installation process is initiated by sending commands from the plugin VM to the target VMs, streamlining the setup without necessitating any direct involvement on your part.

Step 5:

Once replication is done, the Migration-Hub workflow will ask you to start the lunch test instance and test it. If you are ready the workflow will ask you for starting in the Cutover process

Step 6:

If you are ready the workflow will ask you for starting the Cutover process, the MGN will start with cutover

Step 7:

The MGN at this step will launch the final instance in the target subnet and should be ready for production.

5. Implementation :

We have set up all the required resources on AWS in the testing environment. But it should be emphasized that you can carry out the following setup in both on-premises and also AWS as well. Therefore, we will start by installing the Migration-Hub Plugin.

5.1.1 Prepare MHO-Plugin Image

If you intend to install the plugin on-premises, you may treat this section as optional.

This workflow needs the vmimport role to be created as this link

Create a role with this required name “vmimport” and add the below policy and Trust relationships

After completing the workflow, you will be able to find the Amazon Machine Image listed. This AMI serves as a template from which you can create and launch new instances.

5.1.2 Prepare IAM user for MHO-Plugin

Then open IAM console → MHO plugin user → Security Credentials → Access keys → Create access key → other

Save the key as csv file becaue you need to use it in the next step

5.1.3 MHO-Plugin Configuration

You can access the plugin by SSH

You can use SSM because the SSM agent is already installed and the test env is on AWS.

ssh ec2-user@PluginIPAddress
#default password, plugin@123

To set up the Migration Hub Orchestrator plugin using plugin setup commands, initiate a bash shell session within the plugin Docker container with the provided command

docker exec -it mhub-orchestrator-plugin bash

After accessing the container run this command to configure AWS access for Plugin as below:

aws configure --profile <profile-name>
####
plugin setup --aws-configurations

You can check the plugin list in Migration-Hub → Orchestrate → Plugins:

For more details about MHO-plugin

5.2 Linux & Windows workloads Setup

In this POC we are going to create two workloads and install AWS Discovery Agent

Linux : amzn2-ami-kernel-5.10-hvm-2.0.20230515.0-x86_64-gp2

windows: Windows_Server-2016-English-Full-Base-2023.05.10

After preparing the env you should find something like that:

For Security group configurations you can check out the below table.

5.2.2 AWS Discovery Agent Installation ( Linux )

These agents do not only harvest the technical parameters and general performance information but also snatch up the needed in-process operations and active network connections. The Discovery Agent is a sort of your local detective that works right within the environment. It requires substantial authority(root rights) to be able to accomplish its any mission. After its installation and activation, this agent establishes a secure connection with the home region of your residence and introduces itself to The Application Discovery Service.

But before that, we should create an IAM user for this Agent and add the below policy:

• AWSApplicationDiscoveryAgentAccess

Open Migration-Hub → Discovery → tools

curl -o ./aws-discovery-agent.tar.gz https://s3-us-west-2.amazonaws.com/aws-discovery-agent.us-west-2/linux/latest/aws-discovery-agent.tar.gz
tar -xzf aws-discovery-agent.tar.gz
sudo bash install -r us-east-1 -k AKIAY45XASXO7VIBQYX5 -s0DDhsRb/Zfid4ZqaMI5/qgVFjICt9DgZIwA+SVaX

After the registration, the agent then begins collecting the data on behalf of the host or this VM where it is located. The agent pings the Application Discovery Service every 15 minutes for the configuration information.

After joining it, the agent goes into action; he gets all the information on behalf of his host or just a VM. It resembles an attentive assistant continuously keeping in touch with the Application Discovery Service for the configuration details every 15 minutes.for more details

5.2.2 AWS Discovery Agent Installation ( Windows )

powershell -command "& { iwr https://s3-us-west-2.amazonaws.com/aws-discovery-agent.us-west-2/windows/latest/AWSDiscoveryAgentInstaller.exe -OutFile AWSDiscoveryAgentInstaller.exe }" .\AWSDiscoveryAgentInstaller.exe REGION="us-east-1" KEY_ID="AKIAY45XASXO7VIBQYX5" KEY_SECRET="-s0DDhsRb/Zfid4ZqaMI5/qgVFjICt9DgZIwA+SVaX" /q

For more details.

After installing AWS Discovery Agent you will be able to see both machines in the AWS Migration-Hub console

5.3 Providing MHO-Plugin with Workloads credentials

Linux :

For the Linux workload, you should run some commands to prepare it to work with MHO-Plgin for more details check out this link

We need to configure SSH user on MHO-Linux-workload as below:

vi /etc/ssh/sshd_config
# Then set  PasswordAuthentication as below 
# PasswordAuthentication yes

# Restart SSHd service 
sudo systemctl restart sshd
# set password for ec2-user and a save it to use in next step
sudo passwd ec2-user

At this point, you can supply the MHO-Plugin with Linux credentials. This can be done by logging into the MHO-Plugin machine and executing the following command:

# Login MHO-Plugin
docker exec -it mhub-orchestrator-plugin bash
plugin setup --remote-server-configurations

Copy the public key form MHO-Plugin to MHO-Linux-Workload as below:

Windows

To prepare your Windows workload to work with the MHO-Plugin, some specific commands need to be executed. For more detailed instructions, please refer to the link provided

#1 Download the setup 
Invoke-WebRequest -Uri "https://medium.com/r/?url=https%3A%2F%2Fapplication-data-collector-release.s3.us-west-2.amazonaws.com%2Fscripts%2FWinRMSetup.ps1"
#2 Download the New-SelfSignedCertificateEx.ps1
Invoke-WebRequest -Uri "https://medium.com/r/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fazure-libraries-for-net%2Fblob%2Fmaster%2FSamples%2FAsset%2FNew-SelfSignedCertificateEx.ps1"

.\WinRMSetup.ps1

Remember to ensure that port 5986 is open on the MHO-Windows-workload, and that the MHO-plugin can access it.

You’re now able to configure the MHO-plugin using the Windows credentials as depicted below:

# Login MHO-Plugin
docker exec -it mhub-orchestrator-plugin bash
plugin setup --remote-server-configurations

6. Build Migration-hub Workflow to Rehost applications on Amazon EC2

Let’s check what we have done until now :

1. We prepared MHO plugin and all requirements.
2. We prepared our test environment as required.

If you look at the diagram, you will notice a section that refers to MGN features such as the replication server, the target subnet, the staging subnet, and so on. These elements are configured in the next section.

Before going to build workflow let’s do some actions that are required

1- Grouping the servers to applications

Open to Migration-hub console → Applications, create App1 and add our servers to this App1 as below:

2- Prepare MGN service settings

AWS Application Migration Service (MGN) is a highly automated lift-and-shift (rehost) solution that simplifies, expedites, and reduces the cost of migrating applications to AWS

For more details follow this guide.

Ensure that the necessary service roles have been created by clicking on the Reinitialize service permissions button on the Application Migration Service Console Replication settings page.

3- Provide credentials to install the AWS Replication Agent on your remote server.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "mgn:StartCutover",
                "mgn:StartTest"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:PassedToService": "ec2.amazonaws.com"
                }
            }
        }
    ]
}

With the environment now prepared, we are ready to migrate our App1 (consisting of both Linux & Windows VMs) to AWS as detailed below:

• Open Migration-Hub consol → Rehost Applications on Amazon Ec2

Once the workflow is created, it needs to be executed. Following this, you’ll be able to review the subsequent steps as depicted below:

if you need to change the Migrated instance type, VPC & subnets, etc for the launched instances this can be achieved by modifying the launch settings for each source server, as illustrated below:

Upon finishing the replication process, you’ll encounter a few manual steps requiring user intervention, similar to the one illustrated here. “ Marking the instance ‘Ready for test’ “ :

Once you’ve completed all the steps, you’ll observe that your on-premises workloads have been successfully migrated to AWS, as illustrated below.

Conclusion

In conclusion, AWS Migration Hub overcoming the limitations and challenges faced during the migration of On-prem workloads to AWS.

By providing a central management dashboard, it enables efficient control and orchestration of the migration journey. Moreover, the inclusion of automated standards reduces time wastage and minimizes the risk of human errors, especially in complex migration tasks.

Ultimately, we thoroughly examined the capabilities and features of AWS Migration Hub orchestration, using real workload scenarios to illuminate every technical aspect. Our case study was a theoretical on-premises application, made up of two Virtual Machines — a Linux and a Windows VM. This application is set to be migrated to AWS, where it transformed into EC2 instances with the orchestration of the Migration Hub.

👋 If you find this helpful, please click the clap 👏 button below a few times to show your support for the author 👇

🚀Join FAUN Developer Community & Get Similar Stories in your Inbox Each Week

How to migrate Linux & Windows On-prem workloads to AWS using Migration-Hub Orchestrate was originally published in FAUN.dev() 🐾 on Medium, where people are continuing the conversation by highlighting and responding to this story.