ECS Variant-1: New Customers

This article outlines the end-to-end process for enabling AskEdgi components for newly onboarded SaaS customers on ECS-Variant-1. The implementation leverages AWS Control Tower automation for creating and managing core AWS resources, incorporating manual verification steps to ensure correct configuration and functionality.

AskEdgi components rely on a combination of AWS services such as ECS, RDS, EFS, S3, SQS, IAM, and Secrets Manager. These components are configured to interact seamlessly, enabling secure and scalable operations for the SaaS environment. This document provides a structured, step-by-step guide for setting up network security, IAM roles, ECS tasks, S3 buckets, SQS queues, event notifications, Bridge server and client setup, and feature validation for AskEdgi.

Purpose of the document

The purpose of this document is to provide a detailed, professional, and structured process for implementing AskEdgi components on ECS-Variant-1 for new SaaS customers. It ensures all AWS resources, ECS tasks, S3 buckets, SQS queues, IAM configurations, and application services are configured correctly. It also provides verification steps to validate operational readiness and integration of AskEdgi within the Ovaledge environment.

Prerequisites

Component
Requirement
Notes / Important

ECS

ECS cluster and service access

Required for deploying Edgi Data and Insight services

SQS

Access to create and manage queues

Needed for data sync between services

IAM

Permissions to create roles, users, and attach policies

Ensure IAM policies include required permissions for ECS, SQS, and S3

RDS

Database instance

Used for storing Edgi data and metadata

EFS

File system access

Required for persistent storage for the Insight service

Secrets Manager

Create and manage secrets

Used to store database credentials and other sensitive keys

EC2

EC2 instances for ECS tasks

Ensure instance type and network configurations are compatible

Implementation Steps

Step 1: Network Security

  • Create two private subnets for the Edgi Insight Service.

  • Create a Security Group for the Edgi ECS service with the following rules:

Protocol
Port
Source/Destination

TCP

8000

Destination VPC range

TCP

9200

Private Elasticsearch Security Group

TCP

3306

Private RDS Security Group

All

All

Private EFS Security Group

  • Ensure that ports 8000, 9200, and 3306 are allowed only from specified sources.

  • Security Group configuration ensures proper communication between Edgi ECS, RDS, EFS, and Elasticsearch.

Step 2: EFS Access Points

  • Create EFS Access Points for askEdgi Insight Service:

Access Point Path
Notes

/oe_edgi_insights_dev_logs

Stores Insight service logs

/oe_edgi_insights_dev_documents

Stores uploaded documents

/oe_edgi_insights_dev_store

Stores processed data

Step 3: S3 Bucket Creation

  • Create a new S3 bucket for storing Edgi-related data.

  • Configure CORS permissions:

[
  {
    "AllowedHeaders": ["*"],
    "AllowedMethods": ["PUT"],
    "AllowedOrigins": ["*"],
    "ExposeHeaders": []
  }
]
  • The bucket will store all data uploaded via Edgi Data Service and processed by the Insight Service.

  • Ensure correct permissions to allow S3 to send events to SQS.

Step 4: IAM User Configuration

IAM User for AskEdgi Python

Environment Variable
Value

EDGI_AWS_ACCESS_ID

<access key>

EDGI_AWS_SECRET_KEY

<secret key>

IAM User for Bridge Server and Client

  • Create another IAM user with S3 PutObject permissions only.

  • Use credentials in Ovaledge Task Definition environment variables:

Environment Variable
Value

BRIDGE_AWS_USER_ACCESS_KEY

<bridge IAM access key>

BRIDGE_AWS_USER_SECRET_KEY

<bridge IAM secret key>

  • Bridge user credentials are required for secure S3 uploads.

  • Validate IAM policies before ECS task deployment.

Step 5: ECS Task Role Configuration

  • Create IAM Role with ECS task execution permissions.

  • Attach the custom policy: AskEdgi ECS Policy JSON.

  • Modify the Trust Relationship for ECS.

Step 6: AWS SQS Configuration

Amazon SQS (Simple Queue Service) is a fully managed message queuing service provided by AWS. It allows decoupling of application components so that they can communicate and scale independently.

  • Create SQS queue: data_sync_queue using naming convention <prefix>_data_sync_queue (example: askedgi_data_sync_queue).

Configure Access Policy – Send Message Permissions

  • Go to Advanced settings and note the Resource ARN.

  • Modify the JSON below to include the AWS Account ID, Region, IAM Role Name, and S3 Bucket ARN.

Access Policy – add Send Message Permissions:

  • Modify the below JSON according to the account ID and S3 ARN

  • AWS: SourceArn: The S3 bucket ARN created at Step 3.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "__owner_statement_1",
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::${AWS_ACCOUNT_ID}:root"},
      "Action": "SQS:*",
      "Resource": "arn:aws:sqs:{AWS_REGION}:${AWS_ACCOUNT_ID}:{PREFIX}_data_sync_queue"
    },
    {
      "Sid": "__receiver_statement",
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::${AWS_ACCOUNT_ID}:role/{IAM_ROLE_NAME}"},
      "Action": ["SQS:ChangeMessageVisibility","SQS:DeleteMessage","SQS:ReceiveMessage"],
      "Resource": "arn:aws:sqs:{AWS_REGION}:${AWS_ACCOUNT_ID}:{PREFIX}_data_sync_queue"
    },
    {
      "Sid": "__s3_sender_statement",
      "Effect": "Allow",
      "Principal": {"Service": "s3.amazonaws.com"},
      "Action": "SQS:SendMessage",
      "Resource": "arn:aws:sqs:{AWS_REGION}:${AWS_ACCOUNT_ID}:{PREFIX}_data_sync_queue",
      "Condition": {"ArnLike": {"aws:SourceArn": "arn:aws:s3:::${BUCKET_NAME}"}}
    }
  ]
}

Access Policy – Receive Message Permissions:

  • Principal: IAM role ARN

  • Resource: edgi_galaxy_data_sync_queue ARN

  • Ensure aws: SourceArn points to the correct S3 bucket.

  • Verify SQS ARN for both send and receive permissions.

Step 7: S3 Event Notifications

Amazon S3 Event Notifications allow automatic triggering of actions when certain events happen in an S3 bucket - like when an object is uploaded, deleted, or restored.

To enable automated processing of uploaded files, configure S3 Event Notifications to trigger the SQS queue:

  • Navigate to the S3 bucket > Properties > Event Notifications > Click Create Event Notification.

  • Create Notification for CSV Files

    • Name: csv_event_to_sqs (customizable)

    • File Suffix: .csv

    • Event Type: All object creation events

    • Destination: SQS

    • SQS ARN: {PREFIX}_data_sync_queue

  • Create Additional Notifications Repeat the above steps for the following file types, ensuring each notification points to the same SQS queue:

Notification Name
File Suffix
Event Type
Destination

avro_event

.avro

All object creation events

data_sync_queue

json_event

.json

All object creation events

data_sync_queue

parquet_event

.parquet

All object creation events

data_sync_queue

xlsx_event

.xlsx

All object creation events

data_sync_queue

  • These notifications enable real-time processing of files uploaded to the S3 bucket.

  • Verify that the correct SQS queue ARN is used for each notification.

Step 8: ECS Task Definition – Data Service

Create an ECS Task Definition for the Edgi Data Service with the following configuration details.

Configuration
Value

CPU

0.5 vCPU

Memory

2 GB

Container Name

edgi-data-service

Port

8000

Storage

200 GB

CloudWatch Logs

Enabled

Environment Variables

Key
Value

AWS_REGION

<Region>

AWS_SCTNAME

<Database secret name>

BUCKET_NAME

<Bucket Name>

CREDENTIAL_TYPE

container

DEPLOYMENT_TYPE

ecs

ENV

production

  • Enable CloudWatch Logs for the container to capture logs.

  • Under Storage configuration, allocate a maximum of 200 GB.

CloudWatch logging is essential for monitoring Data Service activity.

Step 9: ECS Task Definition – Insight Service

  • Create an ECS Task Definition for the Edgi Insight Service using the details below:

Configuration
Value

CPU

1 vCPU

Memory

2 GB

Container Name

oe_edgi_insights_service

Port

8000

Storage

200 GB

CloudWatch Logs

Enabled

Environment Variables

Key
Value

AI_FUNCTION_QUEUE_NAME

ai_functions_queue

AWS_REGION

<region>

AWS_SCTNAME

<db_secretname>

BUCKET_NAME

<S3 bucket name>

CLUSTER_NAME

<ecs cluster name>

CREDENTIAL_TYPE

container

DATA_SYNC_QUEUE_NAME

data_sync_queue

DEPLOYMENT_TYPE

ecs

DNS_NAME_SPACE_ID

<ecs namespace ID>

DOCS_FOLDER

/app/documents

EDGI_WORKSPACE_DISCOVERY

dynamic

EDGI_WORKSPACE_HOST

edgi-data-service

EDGI_WORKSPACE_NAME_SPACE

<ecs namespace name>

ENV

prod

LOG_PATH

/app/logs

SECURITY_GROUPS

<Edgi insight>

SQS_QUEUE_PREFIX

<sqs_prefix_name>

STORE_FOLDER

/app/store

SUBNETS

sub1, sub2

TASK_DEFINITION

<Edgi data task definition latest ARN>

  • Elastic File System Configuration

    • Add three EFS mounts for the Insight service.

  • Enable CloudWatch Logs for the container to capture logs

  • Under Storage configuration, allocate a maximum of 200 GB

  • Add three EFS mounts for persistent storage.

  • CloudWatch logging must be enabled for troubleshooting.

Step 10: ECS Service Creation – Insight Service

  • Deploy ECS Service using the Insight Task Definition.

  • Network Security

  • Enable Service Discovery during service creation.

Once the service is deployed:

  • Go to Configuration and Networking > Service Discovery.

  • Note down the Service Discovery Endpoint, which will be used in Ovaledge configuration.

Service Discovery endpoint is required in Ovaledge task definitions.

Step 11: Update Ovaledge Task Definition and Job

To enable the AskEdgi feature in the Ovaledge environment, update the UI and Job ECS Task Definitions by adding the following environment variables.

Environment Variables for UI and Job Tasks

Key
Value

BRIDGE_AWS_USER_ACCESS_KEY

<Bridge user access key>

BRIDGE_AWS_USER_SECRET_KEY

<Bridge user secret key>

EDGI_AI_FUNCTION_QUEUE

ai_functions_queue

EDGI_AWS_ACCESS_ID

<edgi user access key>

EDGI_AWS_SECRET_KEY

<edgi user secret key>

EDGI_AWS_REGION

<region>

EDGI_BUCKET_NAME

<s3 bucket name>

EDGI_CLIENT_PREFIX

<sqs prefix name>

EDGI_CONSUMER_CREDENTIAL_TYPE

static

EDGI_ENABLE

true

EDGI_INSIGHT_SERVICE_HOST

<insight service endpoint>

EDGI_WORKSPACE_DISCOVERY

dynamic

EDGI_WORKSPACE_HOST

<edgi data task definition family name>

EDGI_WORKSPACE_NAMESPACE

<ECS cluster namespace>

Optional OAUTH2 Configuration

Key

OAUTH2_BASE_URL

<provided by dev team>

OAUTH2_CLIENTID

<provided by dev team>

OAUTH2_CLIENT_REGISTRATION

auth0

OAUTH2_ROLE_ATTRIBUTE

https:///roles

OAUTH2_SECRET

<provided by dev team>

OVALEDGE_SECURITY_TYPE

oauth2

Both the UI and Job task definitions must be updated, and then new ECS services must be deployed using the latest task definition revisions.

Step 12: AskEdgi Feature Checks

  • Once the application is up and running.

  • Log in with the admin user.

  • Verify Workspace creation with a valid project ID.

  • Navigate to Application > Settings > AI.

  • Under AI Config, select OpenAI.

  • Enter the API Key provided by the development team.

  • Save the configuration to enable AI functionality within AskEdgi.

  • By default, AskEdgi Edition provides Data Analytics functionality (upload and catalog data).

  • If configured for Metadata Analytics, only data cataloging will be available.

  • After saving, log out and log in again.

  • Go to the AskEdgi module and wait for the workspace to initialize.

  • Then, try uploading a file from the application.

  • Navigate to Application > Settings > AI.

  • Ensure that all Marketplace details are correctly populated in the settings.

  • Save the configuration if any updates are made.

If Workspace is not created:

  • Check Insight Service logs.

  • Validate IAM Role permissions.

  • Verify user entry in the database:

select * from edgi_data_service_stack edss ;
delete * from edgi_data_service_stack edss;
delete from edgi_data_service_uptime_history ;

Remove User Entry from Service Discovery

  • Navigate to AWS Cloud Map > Service Discovery Resource.

  • Locate and delete the user entry associated with the application.

  • Log back into the application to verify that the changes have taken effect.

  • Check if the files have been uploaded or not.

Step 13: NiFi Bridge Server

AWS Access Key Secret Key for Bridge Server and Client

  • These credentials have S3 PutObject permissions, allowing secure uploads to the S3 bucket (created in Step 4B).

  • During Ovaledge application installation, AWS Credentials (Access Key & Secret Key) are securely stored in /mnt/tmp and also provided as environment variables in the run.sh file.

  • During Bridge Client installation, the credentials, along with S3 bucket details (name and region), are packaged into the Bridge Client certificate ZIP file. This enables the Bridge Client to authenticate with S3 seamlessly.

ECS Task Definition and Credential Management

During installation, these values are passed into the ECS Task Definition.

  • Credentials are temporarily stored in a file during installation.

  • After installation, the credentials file remains in the EFS mount directory at /mnt/tmp.

S3 Bucket Configuration

  • During Bridge Server installation, the nifi.properties file is updated with the following S3 details:

    • S3 Bucket Name

    • AWS Region

  • These values are also passed as environment variables in the Bridge Server Docker run.sh file and defined in the ECS Task Definition. The run.sh script handles these updates.

  • After installation, the script ensures that the nifi.properties file contains the correct S3 bucket name and region.

Bridge Server UI Changes

  • To configure S3 access through the UI, update the following parameters under S3PutObject > View Configuration:

    • S3 Bucket Name

    • AWS Region

    • AWS Access Key and Secret Key

  • Always verify that the credentials used have S3 PutObject permissions.

  • Changes made via the UI should match the configuration in nifi.properties to prevent synchronization issues.

Bridge Client Installation

  • During Bridge Client installation, the S3 bucket name and region are retrieved from the Bridge Server’s nifi.properties file.

  • The script generate_bridge_client.sh is responsible for applying these changes.

The Bridge Client’s nifi.properties file is updated with the same S3 configuration.

Key Change Summary:

  • Before: Bridge Client certificate ZIP contained only certificates.

  • After: Bridge Client certificate ZIP now includes:

    • AWS Credentials (Access Key & Secret Key)

    • S3 Bucket Name

    • AWS Region

This ensures the Bridge Client can directly connect to S3 using the provided credentials and configuration.

Bridge Client UI Changes

To configure S3 access through the UI, update the following parameters under S3PutObject > View Configuration:

  • S3 Bucket Name

  • AWS Region

  • AWS Access Key and Secret Key

  • Ensure that the Bridge Client certificate ZIP file is stored securely.

  • Do not share AWS credentials externally; they are sensitive and allow direct access to S3.

  • Always confirm that the S3 bucket exists and the region is correct before starting the Bridge Client.


Copyright © 2025, OvalEdge LLC, Peachtree Corners, GA, USA.

Last updated

Was this helpful?