Appendix A: AWS Infrastructure Resource Inventory
The following resources are provisioned by the Trellix IVX Private Cloud CDK deployment.
S3 Buckets
ivx-cloud-{aws_stage}-code-{aws_account_id}-{aws_region}: Stores the code for CDK deployment.ivx-cloud-{aws_stage}-code-artifacts-{aws_account_id}-{aws_region}: To store the cdk code artifacts.ivx-cloud-{aws_stage}-scan-artifacts-{aws_account_id}-{aws_region}: To store the scan artifacts.
Lambda Functions
ivx-cloud-{aws_stage}-notification-handler-{aws_account_id}-{aws_region}: Generates and delivers all informational, critical, and detection notifications.ivx-cloud-{aws_stage}-input-processor-{aws_account_id}-{aws_region}: Acts as the central entry point, processing submissions from S3, API, and ICAP integrations.ivx-cloud-{aws_stage}-authorizer-{aws_account_id}-{aws_region}: Provides authentication for API Gateway requests.ivx-cloud-{aws_stage}-user-config-updater-{aws_account_id}-{aws_region}: Updates and stores user configuration in the OpenSearch cluster.ivx-cloud-{aws_stage}-authentication-api-{aws_account_id}-{aws_region}: Handles the API authentication for the file submissions using the/filesAPI.ivx-cloud-{aws_stage}-output-processor-{aws_account_id}-{aws_region}: Processes analysis results from IVX BM and takes configured actions (e.g., quarantine, notify).ivx-cloud-{aws_stage}-ivx-farm-manager-{aws_account_id}-{aws_region}: Automates the scaling of the IVX Bare Metal farm based on workload.ivx-cloud-{aws_stage}-submission-result-{aws_account_id}-{aws_region}: Retrieves analysis results and reports for user queries.ivx-cloud-{aws_stage}-download-artifact-{aws_account_id}-{aws_region}: Enables downloading of scan artifacts via the/artifactsAPI endpoint.
SQS Queues
ivx-cloud-{aws_stage}-scan-job-{aws_account_id}-{aws_region}: Manages the queue of new analysis jobs submitted for processing.ivx-cloud-{aws_stage}-scan-message-{aws_account_id}-{aws_region}: Queues internal messages related to ongoing scan operations.ivx-cloud-{aws_stage}-scan-response-{aws_account_id}-{aws_region}: Receives completed analysis results from the IVX Bare Metal farm.ivx-cloud-{aws_stage}-asg-lifecycle-sqs-{aws_account_id}-{aws_region}: Receives Auto Scaling Group (ASG) lifecycle hook notifications for managing instance state changes.ivx-cloud-{aws_stage}-notification-handler-{aws_account_id}-{aws_region}: Queues all pending notifications for processing by the notification handler Lambda.
OpenSearch Cluster
ivx-cloud-{aws_stage}-{aws_region}: Provides data storage, search, and analytics capabilities for solution monitoring.API Gateway
ivx-cloud-{aws_stage}-api-gateway-{aws_account_id}-{aws_region}: Provides the external HTTP endpoints for submitting files and retrieving reports./reportsAPI endpoint: Used for retrieving analysis reports using a unique identifier.
The endpoints available are /files, /reports, /hashes, /artifacts.
EC2 and Autoscaling
ivx-cloud-{aws_stage}-launch-template-{aws_account_id}-{aws_region}: Defines the configuration (AMI, instance type) for launching new IVX Bare Metal EC2 instances.ivx-cloud-{aws_stage}-ivx-ami-asg-{aws_account_id}-{aws_region}: Manages the automatic scaling (launching and terminating) of EC2 instances based on the defined launch template and load.
IAM Roles
private-ivx-codepipeline-role-{aws_stage}-{aws_account_id}-{aws_region}: IAM role used by the AWS CodePipeline service for deployment.ivx-cloud-role-{aws_stage}-{aws_account_id}-{aws_region}: IAM role used by the AWS CodeBuild service for IVX Cloud deployment.
Web UI
private-portal-{aws_stage}.ivx-cloud.trellix.com: S3 bucket used to host the static website files for the Web UI portal.ivx-cloud-{aws_stage}-user-pool-{aws_account_id}-{aws_region}: Amazon Cognito User Pool for managing Web UI user authentication and access.
Appendix B: Troubleshooting
The solution incorporates automated remediation for critical issues such as unexpected traffic spikes, with a resilient architecture built on loosely coupled, serverless components.
System slowdown or unresponsiveness may occur and require manual intervention to restore normal function. The following scenarios detail how to recover from these potential disruptions.
Slow performance
In cases where overall system processing slows down, the system's autoscaling configurations typically initiate self-recovery. However, due to inherent scaling limitations, manual intervention may be necessary. In such cases, a two-step process can be implemented to address this issue.
Increase Maximum Instance Count: The system can scale more aggressively and recover faster by increasing the maximum number of allowable instances. This may require configuration changes or additional resources to handle the increased load.
Initiate Instance Refresh: This process maintains a robust and capable infrastructure by systematically replacing instances that are experiencing performance issues or hardware malfunctions.
Capacity Planning: Regularly reviewing and adjusting capacity plans based on historical usage patterns and anticipated future demand can help ensure the system has sufficient resources to handle peak loads.
Note
Even after executing these manual recovery procedures, the system will require some time to completely recover. This is due to the time needed for new instances to be provisioned, configurations to be applied, and data to be synchronized.
By understanding these potential scenarios and their corresponding recovery procedures, system administrators can effectively manage and maintain the system performance, ensuring its availability and responsiveness due to unexpected challenges.