Forem: Evans Kiprotich

Ditching the Access Key: Implementing IAM Roles Anywhere for Secure Edge and On-Prem Workloads

Evans Kiprotich — Sun, 18 Jan 2026 08:10:29 +0000

In the early days of AWS, if you had a server in your local data center that needed to upload logs to S3, you likely did the unthinkable: you created an IAM User, generated an access_key_id and secret_access_key, and hardcoded them into a config file.

By 2026, this practice is not just outdated. It is a major compliance liability. Long-lived credentials are "static" targets for attackers. As AWS Community Builders, we should advocate for Zero Trust architectures. Enter IAM Roles Anywhere.

This service allows your non-AWS workloads (servers, containers, or IoT devices) to use X.509 digital certificates to obtain temporary, short-lived AWS credentials. No more static keys. No more manual rotation.

The Architecture of Trust

The workflow relies on a Public Key Infrastructure (PKI) chain:

Trust Anchor: You tell AWS which Certificate Authority (CA) to trust.
Profile: You define which IAM Roles can be assumed and for how long.
Role: An IAM Role with a trust policy that allows the rolesanywhere.amazonaws.com service principal to assume it.

Step 1: Infrastructure as Code (CloudFormation)

We'll start by defining the AWS-side resources. In this example, we assume you have a CA certificate (PEM format) from your internal PKI or a tool like OpenSSL.

AWSTemplateFormatVersion: '2010-09-09'
Description: Deploy IAM Roles Anywhere for On-Premise Workloads

Parameters:
  CACertificateBody:
    Type: String
    Description: The PEM-encoded Public Key of your Certificate Authority.

Resources:
  EdgeTrustAnchor:
    Type: AWS::RolesAnywhere::TrustAnchor
    Properties:
      Name: OnPremDataCenterAnchor
      Enabled: true
      Source:
        SourceData:
          X509CertificateData: !Ref CACertificateBody
        SourceType: CERTIFICATE_BUNDLE

  EdgeWorkloadRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: EdgeBackupRole
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: rolesanywhere.amazonaws.com
            Action:
              - sts:AssumeRole
              - sts:TagSession
              - sts:SetSourceIdentity
            Condition:
              StringEquals:
                "aws:PrincipalTag/x509Subject/OU": "DataCenter-Northeast"
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonS3FullAccess # Scoped to your needs

  EdgeProfile:
    Type: AWS::RolesAnywhere::Profile
    Properties:
      Name: EdgeServerProfile
      DurationSeconds: 3600 # 1-hour temporary credentials
      Enabled: true
      RoleArns:
        - !GetAtt EdgeWorkloadRole.Arn

Step 2: Preparing the Edge Server

On your on-premise server, you need two things:

A Client Certificate and Private Key signed by the CA you uploaded to the Trust Anchor.
The AWS Signing Helper tool (provided by AWS).

The Credential Process Logic
To make this seamless for the AWS CLI or SDKs, we use the credential_process feature in the AWS config file. This allows the CLI to call the signing helper automatically whenever credentials expire.

Update your ~/.aws/config on the edge server:

[profile edge-workload]
credential_process = /usr/local/bin/aws_signing_helper credential-process \
    --certificate /etc/pki/edge/server.crt \
    --private-key /etc/pki/edge/server.key \
    --trust-anchor-arn arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/your-anchor-id \
    --profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/your-profile-id \
    --role-arn arn:aws:iam::123456789012:role/EdgeBackupRole

Step 3: Python Implementation (Boto3)

Once the config is set up, your application code doesn't even need to know IAM Roles Anywhere exists. It simply uses the profile.

import boto3
from botocore.exceptions import ClientError

def upload_to_s3(file_name, bucket):
    session = boto3.Session(profile_name='edge-workload')
    s3 = session.client('s3')

    try:
        s3.upload_file(file_name, bucket, file_name)
        print(f"Successfully uploaded {file_name} using temporary credentials!")
    except ClientError as e:
        print(f"Upload failed: {e}")

if __name__ == "__main__":
    upload_to_s3('daily_backup.tar.gz', 'my-secure-onprem-backups')

Why This Matters

Zero Static Secrets: If your edge server is stolen, there are no AWS keys to harvest from the disk.
Instant Revocation: Revoke the certificate at your CA, and access is blocked immediately without touching AWS IAM.
Auditability: Every session creation is logged in CloudTrail with the unique certificate serial number.

Conclusion

Transitioning to IAM Roles Anywhere is a hallmark of a mature AWS architecture. It bridges the gap between on-premise stability and cloud security.

Beyond Chatbots: Building Autonomous Multi-Agent Workflows with Amazon Bedrock and Step Functions

Evans Kiprotich — Sun, 18 Jan 2026 08:01:11 +0000

I've witnessed the development of AI this year, especially on AWS. Simple prompt engineering and Retrieval Augmented Generation (RAG) have given way to autonomous agents. These programs are capable of reasoning, planning, and carrying out tasks, turning abstract objectives into tangible actions.

Instead of using monolithic models, generative AI can solve complex problems by coordinating a number of specialized agents. Using AWS Step Functions for orchestration and Amazon Bedrock Agents for task execution, this article will walk you through creating such a workflow.

The Transition to Agentic AI: Why It's Important Now

Conventional applications of generative AI frequently include:

A prompt is user input.
RAG (Optional): Knowledge base context.
LLM Call: Producing an answer.

This is useful for responding to enquiries, but what if the user wants to take action? "Summarize the last quarter's sales data, identify the top 3 underperforming products, and create a draft email to their respective product managers suggesting a review" is an example of what might happen.

This necessitates:

Information retrieval: Getting sales information.
Analysis: Finding underachievers.
Writing emails is the action.

This multi-step, action-oriented process is difficult for a single LLM call to handle. Bedrock Agents excel in this situation. An agent can be given a high-level objective, evaluate it, decide on a course of action, and then employ predefined "tools" (APIs) to accomplish that objective.

However, what happens if you require the cooperation of several agents? What if their tasks require human approval, conditional logic, error handling, and a particular sequence? This is the point at which AWS Step Functions become essential.

Overview of Architecture: Managing Independent Workflows

An "Order Processing" workflow will be used in our example scenario:

A fresh order arrives.
An "Order Validation Agent" uses an API to compare order details to the product catalogue.
A "Shipping Agent" communicates with a shipping provider API if it is legitimate.
An alert is sent by a "Notification Agent" if any problems occur (validation failed, shipping error, etc.).

Parts:

Order Ingestion: New order requests are sent to an API Gateway endpoint or an Amazon SQS queue.
Step Functions on AWS The central orchestrator is the State Machine. It manages conditional logic, parallel execution, retries, and flow definition.
Bedrock Agents on Amazon:
- Order Validation Agent: Verifies product IDs, stock, and prices by interacting with a Product Catalogue API (such as a Lambda function).
- Shipping Agent: Creates shipments by interacting with an API from an external shipping provider.
- Notification Agent: A more straightforward agent that can log to DynamoDB based on event details or send alerts via SNS.
AWS Lambda: Provides the "tools" (APIs) for Bedrock Agents, serving as a safe bridge between the agent and internal data stores or external services.
Amazon CloudWatch: For tracking and recording every step of the process.

Methodical Execution

Let's dissect the implementation using Python/Boto3 for agent definitions and interactions and CloudFormation for infrastructure.

Describe the AWS Lambda Functions Agent Tools. Every Bedrock Agent must have access to "tools"—API functions that it can use to carry out tasks. These will be implemented as AWS Lambda functions.

a) Lambda Product Catalogue (for Order Validation Agent) Checking a product catalogue is simulated by this Lambda.

# product_catalog_lambda.py
import json

def lambda_handler(event, context):
    print(f"Received event: {json.dumps(event)}")
    action_group = event['actionGroup']
    api_path = event['apiPath']
    http_method = event['httpMethod']
    parameters = event['parameters']

    response_body = {}

    if api_path == '/products/{productId}':
        product_id = next(p['value'] for p in parameters if p['name'] == 'productId')
        if product_id == 'PROD123':
            response_body = {
                "productName": "AWS Widget Pro",
                "price": 99.99,
                "inStock": True
            }
        elif product_id == 'PROD456':
             response_body = {
                "productName": "Cloud Gadget",
                "price": 49.99,
                "inStock": False 
            }
        else:
            response_body = {
                "message": "Product not found"
            }
    else:
        response_body = {
            "message": f"Unknown API path: {api_path}"
        }

    return {
        'body': json.dumps(response_body),
        'statusCode': 200,
        'applicationContentType': 'application/json'
    }

b) Shipping Provider Lambda (for Shipping Agent) This Lambda simulates interacting with an external shipping API.

import json
import random

def lambda_handler(event, context):
    print(f"Received event: {json.dumps(event)}")
    action_group = event['actionGroup']
    api_path = event['apiPath']
    http_method = event['httpMethod']
    parameters = event['parameters']
    request_body = json.loads(event['requestBody']['content']['application/json']['properties']['requestBody'])

    response_body = {}

    if api_path == '/shipments':
        # Extract details from request_body, e.g., request_body['orderId'], request_body['items']
        order_id = request_body.get('orderId', 'UNKNOWN')
        # Simulate an external API call
        if random.random() < 0.1: # 10% chance of failure
            response_body = {
                "message": f"Failed to create shipment for Order {order_id}",
                "status": "FAILED",
                "errorCode": "EXTERNAL_API_ERROR"
            }
            status_code = 500
        else:
            tracking_number = f"TRACK-{order_id}-{random.randint(1000, 9999)}"
            response_body = {
                "message": f"Shipment created successfully for Order {order_id}",
                "trackingNumber": tracking_number,
                "status": "CREATED"
            }
            status_code = 200
    else:
        response_body = {
            "message": f"Unknown API path: {api_path}"
        }
        status_code = 404

    return {
        'body': json.dumps(response_body),
        'statusCode': status_code,
        'applicationContentType': 'application/json'
    }

Create the Bedrock Agents Each agent requires:

An Agent Role with permissions to invoke the LLM and the Lambda tools.
An Agent Definition specifying the foundation model, a description, and the action groups (tools).
Action Groups: Link to the Lambda functions and their OpenAPI schemas.

a) CloudFormation for Agent Roles and Lambda Permissions

AWSTemplateFormatVersion: '2010-09-09'
Description: AWS Bedrock Agents and supporting Lambda functions

Resources:
  ProductCatalogLambda:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: ProductCatalogLambda
      Handler: product_catalog_lambda.lambda_handler
      Runtime: python3.9
      Code:
        ZipFile: |
          import json
          def lambda_handler(event, context):
              print(f"Received event: {json.dumps(event)}")
              action_group = event['actionGroup']
              api_path = event['apiPath']
              http_method = event['httpMethod']
              parameters = event['parameters']
              response_body = {}
              if api_path == '/products/{productId}':
                  product_id = next(p['value'] for p in parameters if p['name'] == 'productId')
                  if product_id == 'PROD123':
                      response_body = {
                          "productName": "AWS Widget Pro",
                          "price": 99.99,
                          "inStock": True
                      }
                  elif product_id == 'PROD456':
                      response_body = {
                          "productName": "Cloud Gadget",
                          "price": 49.99,
                          "inStock": False
                      }
                  else:
                      response_body = {
                          "message": "Product not found"
                      }
              else:
                  response_body = {
                      "message": f"Unknown API path: {api_path}"
                  }
              return {
                  'body': json.dumps(response_body),
                  'statusCode': 200,
                  'applicationContentType': 'application/json'
              }
      Role: !GetAtt LambdaExecutionRole.Arn
      Timeout: 30

  ShippingProviderLambda:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: ShippingProviderLambda
      Handler: shipping_provider_lambda.lambda_handler
      Runtime: python3.9
      Code:
        ZipFile: |
          import json
          import random
          def lambda_handler(event, context):
              print(f"Received event: {json.dumps(event)}")
              action_group = event['actionGroup']
              api_path = event['apiPath']
              http_method = event['httpMethod']
              parameters = event['parameters']
              request_body = json.loads(event['requestBody']['content']['application/json']['properties']['requestBody'])
              response_body = {}
              if api_path == '/shipments':
                  order_id = request_body.get('orderId', 'UNKNOWN')
                  if random.random() < 0.1:
                      response_body = {
                          "message": f"Failed to create shipment for Order {order_id}",
                          "status": "FAILED",
                          "errorCode": "EXTERNAL_API_ERROR"
                      }
                      status_code = 500
                  else:
                      tracking_number = f"TRACK-{order_id}-{random.randint(1000, 9999)}"
                      response_body = {
                          "message": f"Shipment created successfully for Order {order_id}",
                          "trackingNumber": tracking_number,
                          "status": "CREATED"
                      }
                      status_code = 200
              else:
                  response_body = {
                      "message": f"Unknown API path: {api_path}"
                  }
                  status_code = 404
              return {
                  'body': json.dumps(response_body),
                  'statusCode': status_code,
                  'applicationContentType': 'application/json'
              }
      Role: !GetAtt LambdaExecutionRole.Arn
      Timeout: 30

  LambdaExecutionRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: lambda.amazonaws.com
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

  BedrockAgentServiceRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: bedrock.amazonaws.com
            Action: sts:AssumeRole
      Policies:
        - PolicyName: BedrockAgentPermissions
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action:
                  - bedrock:InvokeModel # Allow agents to use Bedrock LLMs
                Resource:
                  - !Sub "arn:aws:bedrock:${AWS::Region}::foundation-model/anthropic.claude-v2" # or your preferred model
              - Effect: Allow
                Action:
                  - lambda:InvokeFunction # Allow agents to call their tool Lambdas
                Resource:
                  - !GetAtt ProductCatalogLambda.Arn
                  - !GetAtt ShippingProviderLambda.Arn
              - Effect: Allow
                Action:
                  - sns:Publish
                  - dynamodb:PutItem
                Resource: "*"

b) Agent Creation (Boto3/CLI) Since Bedrock Agents are often managed programmatically due to their complexity (OpenAPI schemas, etc.), we'll use Boto3.

First, define the OpenAPI schemas for our Lambda functions:

product_catalog_openapi.yaml

openapi: 3.0.0
info:
  title: ProductCatalogAPI
  version: 1.0.0
paths:
  /products/{productId}:
    get:
      summary: Get product details
      description: Retrieves details for a specific product ID.
      operationId: getProductDetails
      parameters:
        - name: productId
          in: path
          required: true
          schema:
            type: string
          description: The ID of the product to retrieve.
      responses:
        '200':
          description: Product details
          content:
            application/json:
              schema:
                type: object
                properties:
                  productName:
                    type: string
                  price:
                    type: number
                  inStock:
                    type: boolean
        '404':
          description: Product not found

shipping_provider_openapi.yaml

openapi: 3.0.0
info:
  title: ShippingProviderAPI
  version: 1.0.0
paths:
  /shipments:
    post:
      summary: Create a new shipment
      description: Creates a new shipment with the specified order details.
      operationId: createShipment
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              properties:
                orderId:
                  type: string
                  description: The ID of the order to ship.
                items:
                  type: array
                  items:
                    type: object
                    properties:
                      productId:
                        type: string
                      quantity:
                        type: integer
                      price:
                        type: number
              required:
                - orderId
                - items
      responses:
        '200':
          description: Shipment created successfully
          content:
            application/json:
              schema:
                type: object
                properties:
                  message:
                    type: string
                  trackingNumber:
                    type: string
                  status:
                    type: string
        '500':
          description: Failed to create shipment

Now, create the agents using Boto3 (Python):

import boto3
import json

bedrock_agent_client = boto3.client('bedrock-agent')
bedrock_agent_runtime_client = boto3.client('bedrock-agent-runtime')

agent_role_arn = "arn:aws:iam::<YOUR_ACCOUNT_ID>:role/BedrockAgentServiceRole" # From CloudFormation Output
product_catalog_lambda_arn = "arn:aws:lambda:<REGION>:<YOUR_ACCOUNT_ID>:function:ProductCatalogLambda"
shipping_provider_lambda_arn = "arn:aws:lambda:<REGION>:<YOUR_ACCOUNT_ID>:function:ShippingProviderLambda"

with open('product_catalog_openapi.yaml', 'r') as f:
    product_catalog_schema = f.read()

def create_order_validation_agent():
    try:
        response = bedrock_agent_client.create_agent(
            agentName='OrderValidationAgent',
            agentResourceRoleArn=agent_role_arn,
            description='Agent for validating product orders against a product catalog.',
            foundationModel='anthropic.claude-v2', # Or your preferred model
            idleSessionTTLInSeconds=1800,
            instruction="You are an order validation assistant. Your goal is to verify product details using the provided product catalog tool. If a product is not found or out of stock, report it as an error."
        )
        agent_id = response['agent']['agentId']
        print(f"Created OrderValidationAgent with ID: {agent_id}")

        response = bedrock_agent_client.create_agent_action_group(
            agentId=agent_id,
            agentVersion='DRAFT', # Always create on DRAFT
            actionGroupName='ProductCatalogActionGroup',
            description='Provides operations to check product details.',
            actionGroupExecutor={'lambda': product_catalog_lambda_arn},
            apiSchema={'payload': product_catalog_schema}
        )
        print(f"Created action group for ProductCatalogLambda: {response['agentActionGroup']['actionGroupId']}")

        response = bedrock_agent_client.prepare_agent(agentId=agent_id)
        print(f"Prepared OrderValidationAgent: {response['agent']['agentStatus']}")
        return agent_id
    except Exception as e:
        print(f"Error creating Order Validation Agent: {e}")
        return None

with open('shipping_provider_openapi.yaml', 'r') as f:
    shipping_provider_schema = f.read()

def create_shipping_agent():
    try:
        response = bedrock_agent_client.create_agent(
            agentName='ShippingAgent',
            agentResourceRoleArn=agent_role_arn,
            description='Agent for creating shipments using an external shipping provider API.',
            foundationModel='anthropic.claude-v2',
            idleSessionTTLInSeconds=1800,
            instruction="You are a shipping assistant. Your goal is to create shipments for orders using the shipping provider tool. If the shipment creation fails, report the error."
        )
        agent_id = response['agent']['agentId']
        print(f"Created ShippingAgent with ID: {agent_id}")

        response = bedrock_agent_client.create_agent_action_group(
            agentId=agent_id,
            agentVersion='DRAFT',
            actionGroupName='ShippingProviderActionGroup',
            description='Provides operations to create shipments.',
            actionGroupExecutor={'lambda': shipping_provider_lambda_arn},
            apiSchema={'payload': shipping_provider_schema}
        )
        print(f"Created action group for ShippingProviderLambda: {response['agentActionGroup']['actionGroupId']}")

        response = bedrock_agent_client.prepare_agent(agentId=agent_id)
        print(f"Prepared ShippingAgent: {response['agent']['agentStatus']}")
        return agent_id
    except Exception as e:
        print(f"Error creating Shipping Agent: {e}")
        return None

if __name__ == "__main__":
    validation_agent_id = create_order_validation_agent()
    shipping_agent_id = create_shipping_agent()

    print(f"\nOrder Validation Agent ID: {validation_agent_id}")
    print(f"Shipping Agent ID: {shipping_agent_id}")

Orchestrate with AWS Step Functions Now, the magic of orchestration. Step Functions allows us to define the entire workflow visually and programmatically using Amazon States Language (ASL).

AWSTemplateFormatVersion: '2010-09-09'
Description: AWS Step Functions State Machine for Autonomous Order Processing

Parameters:
  OrderValidationAgentId:
    Type: String
    Description: The ID of the Bedrock Order Validation Agent.
  ShippingAgentId:
    Type: String
    Description: The ID of the Bedrock Shipping Agent.

Resources:
  AutonomousOrderProcessingStateMachine:
    Type: AWS::StepFunctions::StateMachine
    Properties:
      StateMachineName: AutonomousOrderProcessingWorkflow
      DefinitionString: !Sub |
        {
          "Comment": "Autonomous Order Processing Workflow using Bedrock Agents",
          "StartAt": "InitializeOrder",
          "States": {
            "InitializeOrder": {
              "Type": "Pass",
              "Result": {
                "orderId.$": "$.orderId",
                "items.$": "$.items",
                "validationResult": null,
                "shippingResult": null
              },
              "Next": "InvokeOrderValidationAgent"
            },
            "InvokeOrderValidationAgent": {
              "Type": "Task",
              "Resource": "arn:aws:states:::bedrock:invokeAgent", 
              "Parameters": {
                "AgentId": "${OrderValidationAgentId}",
                "AgentAliasId": "TSTALIAS", # Use TSTALIAS for the DRAFT version
                "InputText.$": "States.Format('Validate the following order details: Order ID {}. Items: {}.', $.orderId, States.JsonToString($.items))",
                "SessionState": {
                  "sessionAttributes": {
                    "orderId.$": "$.orderId"
                  }
                },
                "EnableTrace": true
              },
              "ResultPath": "$.validationResult",
              "Catch": [
                {
                  "ErrorEquals": ["States.TaskFailed", "Bedrock.InvokeAgent.Failed"],
                  "Next": "OrderValidationFailed"
                }
              ],
              "Next": "CheckValidationStatus"
            },
            "CheckValidationStatus": {
              "Type": "Choice",
              "Choices": [
                {
                  "Variable": "$.validationResult.output.text",
                  "StringContains": "Validation successful",
                  "Next": "InvokeShippingAgent"
                },
                {
                  "Variable": "$.validationResult.output.text",
                  "StringContains": "Product not found",
                  "Next": "OrderValidationFailed"
                },
                {
                  "Variable": "$.validationResult.output.text",
                  "StringContains": "out of stock",
                  "Next": "OrderValidationFailed"
                }
              ],
              "Default": "OrderValidationFailed" # Catch-all for unexpected validation results
            },
            "OrderValidationFailed": {
              "Type": "Task",
              "Resource": "arn:aws:states:::sns:publish", # Example Notification Action
              "Parameters": {
                "TopicArn": "arn:aws:sns:${AWS::Region}:${AWS::AccountId}:OrderAlertsTopic", 
                "Message": !Sub "Order ${$.orderId} failed validation. Reason: ${$.validationResult.output.text}"
              },
              "End": true
            },
            "InvokeShippingAgent": {
              "Type": "Task",
              "Resource": "arn:aws:states:::bedrock:invokeAgent",
              "Parameters": {
                "AgentId": "${ShippingAgentId}",
                "AgentAliasId": "TSTALIAS",
                "InputText.$": "States.Format('Create a shipment for order {} with the following items: {}.', $.orderId, States.JsonToString($.items))",
                "SessionState": {
                  "sessionAttributes": {
                    "orderId.$": "$.orderId",
                    "items.$": "$.items"
                  }
                },
                "EnableTrace": true
              },
              "ResultPath": "$.shippingResult",
              "Catch": [
                {
                  "ErrorEquals": ["States.TaskFailed", "Bedrock.InvokeAgent.Failed"],
                  "Next": "ShippingFailed"
                }
              ],
              "Next": "CheckShippingStatus"
            },
            "CheckShippingStatus": {
              "Type": "Choice",
              "Choices": [
                {
                  "Variable": "$.shippingResult.output.text",
                  "StringContains": "Shipment created successfully",
                  "Next": "CompleteOrder"
                }
              ],
              "Default": "ShippingFailed"
            },
            "ShippingFailed": {
              "Type": "Task",
              "Resource": "arn:aws:states:::sns:publish",
              "Parameters": {
                "TopicArn": "arn:aws:sns:${AWS::Region}:${AWS::AccountId}:OrderAlertsTopic",
                "Message": !Sub "Order ${$.orderId} failed shipping. Reason: ${$.shippingResult.output.text}"
              },
              "End": true
            },
            "CompleteOrder": {
              "Type": "Succeed"
            }
          }
        }
      RoleArn: !GetAtt StepFunctionsExecutionRole.Arn

  StepFunctionsExecutionRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: states.${AWS::Region}.amazonaws.com
            Action: sts:AssumeRole
      Policies:
        - PolicyName: StepFunctionsPermissions
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action:
                  - bedrock:InvokeAgent
                Resource:
                  - !Sub "arn:aws:bedrock:${AWS::Region}:${AWS::AccountId}:agent/${OrderValidationAgentId}"
                  - !Sub "arn:aws:bedrock:${AWS::Region}:${AWS::AccountId}:agent/${ShippingAgentId}"
                  - !Sub "arn:aws:bedrock:${AWS::Region}:${AWS::AccountId}:agent-alias/${OrderValidationAgentId}/*" # Allow invoking specific agent aliases
                  - !Sub "arn:aws:bedrock:${AWS::Region}:${AWS::AccountId}:agent-alias/${ShippingAgentId}/*"
              - Effect: Allow # For SNS notifications
                Action:
                  - sns:Publish
                Resource: "arn:aws:sns:${AWS::Region}:${AWS::AccountId}:OrderAlertsTopic" # Ensure this topic exists or create it

Kicking off the Workflow You can start a Step Functions execution via the AWS CLI or SDK:

aws stepfunctions start-execution \
    --state-machine-arn "arn:aws:states:<REGION>:<YOUR_ACCOUNT_ID>:stateMachine:AutonomousOrderProcessingWorkflow" \
    --input '{
        "orderId": "ORD789",
        "items": [
            {"productId": "PROD123", "quantity": 1, "price": 99.99},
            {"productId": "PROD456", "quantity": 2, "price": 49.99}
        ]
    }'

Benefits of this Approach

Modularity: Each agent is a specialist, reducing the cognitive load on a single LLM and allowing for easier updates and maintenance.
Observability: Step Functions provides a visual workflow, detailed execution history, and CloudWatch Logs integration, making it easy to debug complex AI processes.
Reliability: Built-in retry mechanisms, error handling, and parallel execution capabilities of Step Functions ensure resilience.
Scalability: Both Bedrock Agents and Step Functions are fully managed, scaling automatically to meet demand.
Security: IAM roles control permissions granularly, ensuring agents only access the resources they need.
Cost-Effectiveness: You only pay for the state transitions in Step Functions and the Bedrock agent inv ocations.

Considerations for Production

Version Control: Manage Bedrock agent versions carefully. Step Functions should typically invoke a specific, published agent version, not DRAFT for production.
Input Validation: Implement robust input validation at the Step Functions entry point and within your Lambda tools.
Human-in-the-Loop: For critical workflows, consider adding a human approval step in Step Functions, perhaps by sending a task to an Amazon SQS queue that a human operator monitors.
Prompt Engineering: The instruction given to your Bedrock agents is crucial for their performance. Experiment with clear, concise instructions and few-shot examples if necessary.
Tool Design: Design your Lambda tools to be idempotent and handle various edge cases, as the LLM might call them with unexpected inputs.

Conclusion

As we push the boundaries of Generative AI, the ability to build and orchestrate autonomous agents becomes a cornerstone of truly intelligent applications. By combining the reasoning and task execution capabilities of Amazon Bedrock Agents with the robust workflow management of AWS Step Functions, you can construct complex, multi-step processes that move far beyond simple conversational AI.

This architecture empowers developers to build sophisticated, resilient, and scalable AI solutions that can perform real-world actions, marking a significant leap forward in the journey of cloud-native AI. Dive in, experiment, and unleash the full potential of agentic AI on AWS!

🚀 Deploying a Sample Web Application on AWS Using CloudFormation and EC2 💻🌐

Evans Kiprotich — Fri, 08 Mar 2024 09:41:13 +0000

Introduction

If you're an AWS Cloud Engineer, and you're looking to automate infrastructure deployment on AWS using IAC principles, you've come to the right place. In this guide, I'll walk you through the steps to deploy a sample application stack using AWS CloudFormation and AWS CLI. The goal is to automate the deployment of a multi-tier application stack and configure it to run smoothly on AWS. By following the steps in this guide, you'll be able to demonstrate your knowledge of AWS services and tools and how you can leverage them to streamline the deployment of complex applications on AWS. Let's get started!

AWS CLI

Developers and system administrators can connect with AWS services and manage resources via the command line using the robust and flexible AWS CLI (Command Line Interface). The AWS CLI can be modified to match certain use cases and workflows because it is made to be highly flexible. It is also simple to combine with other tools and services thanks to the variety of output formats it offers, including JSON, YAML, and text.

The AWS CLI can be installed following the guide in this AWS documentation. Once installed, you can set up access keys to use as credentials. In this scenario, I am going to use AWS CloudShell to run the AWS CLI commands from the browser.

CLoudFormation Template

The CloudFormation template to set up the VPC, subnets, security groups and EC2 instances is shown below. The code can be saved as IACTest.yaml and uploaded to AWS CloudShell. For the key name, The 3tier specified is an already existing key pair.

---
AWSTemplateFormatVersion: "2010-09-09"
Resources:
  VPC:
    Type: "AWS::EC2::VPC"
    Properties:
      CidrBlock: "10.0.0.0/16"
      EnableDnsHostnames: true
      Tags:
        - Key: "Name"
          Value: "LabVPC"
  PublicSubnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      AvailabilityZone: "us-east-1a"
      CidrBlock: "10.0.0.0/24"
      MapPublicIpOnLaunch: true
      VpcId: !Ref VPC
      Tags:
        - Key: "Name"
          Value: "MyPublicSubnet"
  PrivateSubnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      AvailabilityZone: "us-east-1b"
      CidrBlock: "10.0.1.0/24"
      MapPublicIpOnLaunch: false
      VpcId: !Ref VPC
      Tags:
        - Key: "Name"
          Value: "MyPrivateSubnet"
  SecurityGroup:
    Type: "AWS::EC2::SecurityGroup"
    Properties:
      GroupDescription: "Allow inbound traffic to the EC2 instances"
      VpcId: !Ref VPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          CidrIp: 0.0.0.0/0
  Instance:
    Type: "AWS::EC2::Instance"
    Properties:
      InstanceType: t2.micro
      ImageId: ami-0c94855ba95c71c99
      KeyName: "3tier"
      NetworkInterfaces:
        - DeviceIndex: "0"
          SubnetId: !Ref PublicSubnet
          GroupSet:
            - !Ref SecurityGroup

You can then run the command aws cloudformation create-stack --stack-name my-stack --template-body file://IACTest.yaml --region us-east-1 to deploy the CloudFormation stack.

We can configure the EC2 instances to run a sample web application by adding user data section to the template and then updating the template. This modifies the Instance section of the template to look like this:

  Instance:
    Type: "AWS::EC2::Instance"
    Properties:
      InstanceType: t2.micro
      ImageId: ami-0c94855ba95c71c99
      KeyName: "3tier"
      NetworkInterfaces:
        - DeviceIndex: "0"
          SubnetId: !Ref PublicSubnet
          GroupSet:
            - !Ref SecurityGroup
      UserData:
        Fn::Base64: !Sub |
          #!/bin/bash
          yum update -y
          yum install -y httpd
          systemctl start httpd
          systemctl enable httpd
          echo "<html><head><title>EC2 Instance Metadata</title></head><body><h1>EC2 Instance ID:</h1>" >> /var/www/html/index.html
          curl http://169.254.169.254/latest/meta-data/instance-id >> /var/www/html/index.html
          echo "</body></html>" >> /var/www/html/index.html

We can the update the CloudFormation stack by running the following command: aws cloudformation update-stack --stack-name my-stack --template-body file://IACTest.yaml --region us-east-1.

🌐💻 Building a Multi-AZ Three-Tier Architecture on AWS: A Comprehensive Guide

Evans Kiprotich — Fri, 21 Apr 2023 08:37:06 +0000

Introduction

As a budding cloud engineer, I was recently given the task of creating a three-tier architecture for a web application that previously had a straightforward one-tier architecture. A fault-tolerant, scalable design that could accommodate increasing traffic and demand was the aim. I successfully designed and implemented a three-tier architecture on AWS using multiple availability zones for high availability and fault tolerance after some research and testing. Anyone who wishes to carry out a similar task can use this blog post as a guide.

LongPostAlert!

Architectural Diagram

The first step is to create a three-tier architecture. There are several tools available for this purpose. This AWS webpage provides a summary of several websites that can be used, and I suggest draw.io. A sample architectural plan created is shown below.

Deployment

The resources needed can be divided into various sections which will be discussed below.

VPC

The VPC can be created as shown in the following figure.

Next is to edit VPC settings to enable DNS resolution and hostnames.

Subnets

The architecture requires six subnets, with three in each availability zone. Two subnets are private while only one is public in each availability zone.

For the public subnets, their settings can be edited to enable auto-assign public IPv4 settings.

Security Groups

Next is to create the security groups.

The first is the web-elb-sg which allows HTTP access from all sources.

The web-sg is created next which allows HTTP access from web-elb-sg.

The app-elb-sg is created next which allows HTTP access from web-sg.

The app-sg is next which allows HTTP access from app-elb-sg.

Finally, db-sg is created which allows MySQL access from app-sg.

Internet Gateway

Since this is a new VPC, an internet gateway has to be created and attached to the VPC as shown below.

Route Tables

When a VPC is created, a default route table is created. Any subnets that have no explicit route table associations will be associated with the default route table.

A web-RT route table can then be created with a route with 0.0.0.0/0 destination with the internet gateway as the target.

The public subnets can then be associated with this route table.

Launch Templates

Web Tier Launch Template A launch template is then created to be used in the web tier. This is associated with the web-sg security group, with auto-assign public IP enabled.

Some user data can be included to enable Apache web server to run in the instances after creation.

App Tier Launch Template A launch template is then created to be used in the app tier. This is associated with the app-sg security group.

Target Groups

Web Tier Target Group A target group is then created to be used for the web tier.

No instances are registered at the moment, but they will be registered automatically once they will be launched by the Auto Scaling Group.

App Tier Target Group. This is a similar process to the web tier target group.

Application Load Balancers

Web Tier This is set up with the internet-facing scheme. Under mappings, the two public subnets in the two AZs are selected. This is associated with the web-elb-sg security group.

A HTTP:80 listener is then associated with the WebTierTargetGroup.

App Tier This is set up with the internal scheme. Under mappings, the two app private subnets in the two AZs are selected. This is then associated with the app-elb-sg security group.

A HTTP:80 listener is associated with the AppTierTargetGroup.

Auto Scaling Groups

Web Tier The WebTierASG is created and associated with the WebTierLaunchTemplate.

The two web public subnets are selected to be used by the ASG.

This is then associated with the WebTierELB, with ELB health checks enabled.

The group size is selected as shown, with a target tracking scaling policy using the Average CPU utilization metric.

App Tier The AppTierASG is created and associated with the AppTierLaunchTemplate.

The two app private subnets are selected to be used by the ASG.

This is then associated with the AppTierELB.

The group size is selected as shown, with a target tracking scaling policy using the Average CPU utilization metric.

Web Tier Test

After the auto scaling groups are set, it kicks in and creates the instances. Two instances are created initially in each tier since the desired capacity is set to two.

Upon visiting the ELB endpoint, it can be seen that we get responses from both instances as shown below.

However, since the minimum capacity is set to one, once the target tracking policy kicks in and the web servers are idle, the capacity is reduced to one in each tier.

DB Subnet Group

The DB subnet group is created specifying the two availability zones and the two DB subnets created earlier on.

RDS Database Creation

This is created using RDS using the Aurora(MySQL Compatible) engine. Multi-AZ deployment is enabled. The subnet group created in the previous section is selected, specifying the db-sg as the security group to be used.

This creates two DB instances, one in each AZ. One is set as the writer instance in us-east-1b and the other as the reader instance in us-east-1a.

In order to test failover to see what happens if the writer fails, we can see that the writer instance switches to us-east-1a.

CloudFront Distribution

A CloudFront distribution is created with with the web tier ELB as the origin domain using the HTTP protocol. A custom header is added so that requests coming through the distribution will include it. This will be essential to distinguish traffic that come via the distribution and those that go directly to the ELB.

WAF Web ACL

A WAF web ACL is used to block any traffic to the ELB that do not contain the custom header, implying that only traffic that go through CloudFront will be allowed to the ELB.

The CustomHeaderACL is created and associated with the WebTierELB.

A rule is added to block any request that do not contain the custom header specified in the previous step.

The default action is left as Allow to permit any request that does not match the set rule.

CloudFront Test

Traffic that is sent via the CloudFront endpoint is allowed as shown below.

Traffic sent using the ALB endpoint is now denied.

Outro

Think of deleting unused AWS resources like eating your vegetables - it may not be fun, but it's necessary for a healthy and cost-efficient cloud environment 🥦💰💪

Experimenting with these resources can be a fantastic experience, giving you the thrill when you get the desired outcome and even more fun when you have to troubleshoot and figure out why something went wrong.