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
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
Ensure AWS Control Tower automation is active and operational before starting.
Manual verification is required for ECS task roles, IAM user credentials, S3 bucket permissions, and event notifications.
All services should comply with corporate security policies regarding VPCs, subnets, and access controls.
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:
TCP
8000
Destination VPC range
TCP
9200
Private Elasticsearch Security Group
TCP
3306
Private RDS Security Group
All
All
Private EFS Security Group
Step 2: EFS Access Points
Create EFS Access Points for askEdgi Insight Service:
/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
Assign correct mount permissions to ECS tasks to ensure persistent storage access.
Step 3: S3 Bucket Creation
Create a new S3 bucket for storing Edgi-related data.

Configure CORS permissions:
[
{
"AllowedHeaders": ["*"],
"AllowedMethods": ["PUT"],
"AllowedOrigins": ["*"],
"ExposeHeaders": []
}
]
Step 4: IAM User Configuration
IAM User for AskEdgi Python
Create IAM user (example: edgi_user) with:
AmazonSQSFullAccess
AskEdgi_policy_Saas from: AWS SAAS ECS Policy JSON


Generate Access Key and Secret Key for CLI access.

Use credentials in Ovaledge Task Definition environment variables:
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:
BRIDGE_AWS_USER_ACCESS_KEY
<bridge IAM access key>
BRIDGE_AWS_USER_SECRET_KEY
<bridge IAM secret key>
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.

This IAM role is shared across all ECS Task Definitions to ensure consistent and secure access.
Automation scripts handle permission setup automatically, but verification is recommended.
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

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:
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

Step 8: ECS Task Definition – Data Service
Create an ECS Task Definition for the Edgi Data Service with the following configuration details.
CPU
0.5 vCPU
Memory
2 GB
Container Name
edgi-data-service
Port
8000
Storage
200 GB
CloudWatch Logs
Enabled
Environment Variables
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.

Step 9: ECS Task Definition – Insight Service
Create an ECS Task Definition for the Edgi Insight Service using the details below:
CPU
1 vCPU
Memory
2 GB
Container Name
oe_edgi_insights_service
Port
8000
Storage
200 GB
CloudWatch Logs
Enabled
Environment Variables
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

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.

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
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
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 ;Do not run delete queries unless confirmed by the development team.
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.
Ensure that the EFS mount has proper access controls to prevent unauthorized access to AWS credentials.
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

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
Copyright © 2025, OvalEdge LLC, Peachtree Corners, GA, USA.
Last updated
Was this helpful?

