ZFlow on AWS

Use Cases for ZFlow on AWS

ZFlow is most commonly deployed by organizations within their AWS Private Cloud environment (AWS account). The most common use cases for ZFlow include the following.

Supply Chain Collaboration Portal

ZFlow is used to set up a supply chain collaboration portal to enable business process collaboration with manufacturers, suppliers, logistics partners, and contract manufacturers. 

Hosted on AWS, the portal supports collaborative workflows related to Product Engineering, Component Engineering, Strategic Sourcing, Cost Management, Forecast Collaboration, PO Collaboration, and Supplier Development. The portal ensures secure, scalable, flexible, and always-on collaboration across organizational boundaries to improve coordination with Supply Chain partners.

Master Data Management for Supply Chain Excellence

ZFlow, when deployed as a Master Data Management solution within the customer’s AWS account, helps manufacturing organizations establish an effective and high-performance single source of truth and governance for Supply Chain Master data. It uses AI/ML-powered deduplication, approval workflows, and data quality monitoring to ensure high-quality master data. The system integrates with SAP, Oracle, and legacy platforms and leverages Amazon RDS and EFS/S3 for persistence. Customers achieve 98 %+ data quality and 90 %+ reduction in cycle times for various master data processes.

New Production Introduction and Product Lifecycle Management

ZFlow’s New Product Introduction and Product Lifecycle Management capabilities help accelerate new product introduction by providing a centralized, cloud-native platform for orchestrating NPI and PLM processes, managing Product Data, engineering changes, quality gates, and supplier onboarding. Customers use it to reduce NPI cycle time by 30–50%, support and sustain product lifecycle, and coordinate effectively with component manufacturers, contract manufacturers, and other supply chain partners.

 

Deployment

ZFlow is deployed within the customer’s AWS account using an automated CloudFormation template. It provisions a secure VPC with two public subnets and an internet gateway for internet access. Key AWS resources include:

  • Elastic Beanstalk for Tomcat environment hosting a Tomcat-based web application, fronted by an Application Load Balancer
  • Amazon EFS, encrypted at rest, is used for shared file storage across application instances
  • Optional Amazon S3 for storing documents
  • IAM roles and policies follow the principle of least privilege

Customers are responsible for provisioning the stack, managing data, and maintaining runtime configurations. Our team provides versioned deployment templates, released war files, update guidance, and support documentation for secure and reliable operations.

Deployment Options

Our solution is deployed in the customer’s AWS account using a pre-built CloudFormation template that automates setup of the entire infrastructure stack, including networking, IAM, Elastic Beanstalk environment, and supporting services like EFS and S3.

For customers who prefer Terraform, we provide equivalent scripts upon request.

All deployment artifacts, including templates and step-by-step documentation, are available via our documentation portal.

The solution supports deployment to any AWS region that offers the required services (e.g., Lambda, Beanstalk for Tomcat, EFS, EC2, AWS RDS for MySQL). Customers are responsible for deploying and managing the environment, with support provided by our team for configuration and updates.

 

Deployment Time

Estimated deployment time: 30 minutes to 1 hour depending on the region and AWS service availability.

Supported Regions

The solution supports deployment in all AWS regions where the required services—Elastic Beanstalk, EC2, EFS, Lambda, RDS for MySQL, and optionally S3—are available. The full list of supported regions is configurable via the Region parameter in the deployment template, allowing customers to deploy based on their preferred location and regional service availability.

 

Prerequisites and Requirements

The following components are required for successful deployment:

IAM permissions to create and manage:

  • Elastic Beanstalk environments
  • EC2 instances and associated VPC components (subnets, route tables, IGWs)
  • EFS volumes
  • Lambda functions and CloudWatch Logs
  • IAM roles and policies

An AWS region with the necessary services enabled.

 

Required Skills

Users deploying and managing the solution should have familiarity with:

  • AWS CloudFormation and the AWS Management Console
  • Elastic Beanstalk deployment and monitoring
  • IAM policies and role management
  • Basic usage of Lambda and S3

Environment Configuration

  • An active AWS account with appropriate permissions
  • A VPC with at least two public subnets in separate Availability Zones
  • DNS support is enabled within the VPC

 

Architecture Diagram

 

 

Security

Deployment does not require root account credentials. All operations are performed using scoped IAM roles. IAM roles follow least-privilege principles, scoped to only the actions needed (e.g., access to S3, EFS, Lambda, logs).

Public Resources

The solution is designed to expose only necessary public-facing components. In cases where the application is accessed by external suppliers, the Elastic Beanstalk environment is configured with a public-facing Application Load Balancer. This allows controlled, secure access to the application while ensuring that backend EC2 instances and other AWS resources remain private.

No other resources, such as EFS or RDS, are exposed publicly. S3 buckets (if used) are configured as private by default, and customers are advised to apply restrictive bucket policies and avoid public access unless explicitly required.

Security groups and IAM roles are scoped to ensure that only the load balancer is exposed to the internet, minimizing the public surface area and supporting secure supplier access scenarios.

IAM Role Descriptions

  • LambdaExecutionRole: S3 and CloudWatch access
  • ElasticBeanstalkServiceRole: for Elastic Beanstalk
  • ElasticBeanstalkEC2Role: EC2 access to S3, EFS

Key Usage

Amazon EFS is encrypted using AWS-managed keys (Encrypted: true in the template).

Secrets Management

The current version does not use secrets. If introduced, secrets will be stored securely using AWS Secrets Manager.

Sensitive Data Storage

Application data is stored in RDS for MySQL, and files are in EFS. It is possible 

Data Encryption

Amazon EFS encryption is enabled via CloudFormation template using Encrypted: true.

Network Configuration

The CloudFormation stack configures:

  • Public subnets, route tables, and Internet Gateway (IGW)
  • Security groups for EC2, EFS, and Load Balancer access
  • VPC and subnet associations for managed services

Costs

This solution may incur charges from:

  • Elastic Beanstalk / EC2 (compute resources)
  • Amazon EFS (storage and throughput)
  • RDS for MySQL (Relational Database)
  • Lambda (execution time)
  • Amazon S3 (optional)
  • Other services (IAM, VPC, CloudWatch) typically fall under the free tier or low usage tiers

The solution infrastructure does not require any third-party licensing. However, the deployed application (ZFlow) follows a Bring Your Own License (BYOL) model. Customers must ensure they have a valid license for ZFlow prior to deployment. No license enforcement is embedded within the CloudFormation stack itself.

Sizing

Resource Sizing Guidance

Default EC2 instance type: m5.large, adjustable per workload

EFS: Uses bursting throughput mode by default

Customers may adjust instance size, EFS throughput mode, and DB instance types based on performance needs

 

Deployment Assets

Deployment Instructions

Deployment is initiated using AWS Console or aws cloudformation deploy. Key parameters include:

  • GitHubZipFileURL
  • VpcCidrBlock
  • Region, and other stack variables

Testing & Troubleshooting

  • Verify the Elastic Beanstalk environment is green
  • Check Lambda function logs in CloudWatch
  • Confirm EFS is mounted on EC2 instances via the startup script logs

Health Check

Monitoring Guidance

The solution provides multiple monitoring mechanisms:

  • Use the Elastic Beanstalk health dashboard to monitor environment health and instance status.
  • Review CloudWatch Logs for application-level and Lambda execution insights.
  • Monitor Amazon EFS performance and throughput via CloudWatch metrics.
  • A custom health check URL is available within the application and can be configured in the Elastic Beanstalk environment. This allows Beanstalk to initiate instance replacement or failover if the application becomes unresponsive.

Backup & Recovery

Backup Guidance

Amazon EFS backups are enabled using BackupPolicy: ENABLED

Customers may also configure AWS Backup for full backup lifecycle management

 

Routine Maintenance

The solution uses Elastic Beanstalk managed platform updates to apply operating system and runtime patches.

Application-level upgrades are provided using a dedicated Application Upgrade Utility, facilitating smooth version transitions while preserving configuration and data integrity. Customers are responsible for initiating upgrade workflows as per their internal change management processes.

License Management

This is not applicable, as the solution follows a Bring Your Own License (BYOL) model. Customers are responsible for obtaining and managing their valid ZFlow application license.

 

Service Limits

The solution relies on standard AWS platform services such as Elastic Beanstalk, EC2, EFS, Lambda, and optionally RDS and S3. As such, deployment and scaling behavior may be affected by AWS service limits (quotas) in the customer’s account.

 

Emergency Maintenance

The solution supports fault detection, isolation, and recovery through integrated AWS services and deployment best practices. The following mechanisms are in place to handle common failure scenarios:

1. Fault Detection

  • Elastic Beanstalk health checks monitor the status of EC2 instances and application responsiveness.
  • CloudWatch Logs and CloudWatch Alarms capture failures in Lambda execution, EFS access, and application logs.
  • Application-level custom health check URL can trigger instance replacement when the app becomes unresponsive.

2. Common Fault Scenarios & Recovery Steps

  • Beanstalk Deployment Fails
    → Review Beanstalk event logs. Roll back to a known stable environment version or redeploy with corrected parameters.
  • EC2 Instance Unhealthy
    → Beanstalk automatically replaces failing instances. Check instance logs for startup issues (e.g., EFS mount failure, WAR deployment errors).
  • EFS Mount Failure
    → Verify security group rules, VPC mount targets, and user data scripts on EC2 instances.
  • CloudFormation Stack Failure
    → Inspect the Events tab for specific resource failure messages. Correct the configuration and relaunch the stack.

3. Customer Recovery Actions

  • Redeploy the application WAR to Elastic Beanstalk if corrupted or misconfigured.
  • Re-run the CloudFormation template to provision a fresh environment using previously validated parameters.
  • Restore EFS data from AWS Backup, if enabled.
  • The backed up application configuration and database backup files can be used  to redeploy the application in another Beanstalk for Tomcat or a EC2-based Tomcat environment

4. Operational Best Practices

  • Maintain application version control using Beanstalk environment versions.
  • Use CloudWatch alarms and notification alerts for early fault detection.
  • Use internal runbooks for environment rollback and data restoration.

 

Recovery Steps

In the event of a critical failure or unrecoverable state, the following recovery actions are recommended to restore service availability:

  1. Redeploy Application WAR File
    • Upload a clean or updated version of the WAR file through the Elastic Beanstalk console or CLI.
    • This is recommended when the application becomes unresponsive due to configuration or deployment errors.
  2. Re-run CloudFormation Stack
    • If infrastructure provisioning fails or becomes misaligned, re-launch the CloudFormation stack using the original or updated parameters.
    • Ensure existing resources (e.g., EFS, RDS) are reused or handled to avoid data loss.
  3. Restore EFS from Backup
    • If critical application data stored in EFS is corrupted or lost, use AWS Backup to restore from the latest recovery point.
    • Ensure the restored file system is remounted to the EC2 instances and accessible to the application.

Based on the nature of the issue, each of these actions can be executed independently, but together, they provide a reliable fallback plan to restore operational continuity.

 

Support

Customers can access ZFlow support through the following channels:

  • ZFlow Support Portal: Submit support requests and access product documentation.
  • Live Support: Telephone or chat support is available for certain non-technical inquiries, at Cambrian Lab’s discretion.
  • Email Support: Direct email support is provided for licensed customers.

Support is available during Cambrian Lab’s standard business hours, Monday to Friday, 8:00 AM to 8:00 PM EST. Emergency support requests can be routed via the support phone line outside these hours.

 

Support Tiers

Standard support is included as part of the ZFlow subscription purchased by customers. It includes:

  • Access to the support forum for submitting requests
  • Email-based support
  • Assistance from the Customer Success Team
  • Access to product documentation and training resources

This support model ensures customers receive timely assistance and self-service tools to maximize solution value without requiring separate tiered support packages.

 

SLAs

ZFlow categorizes support requests based on severity levels, each with defined response times:

  • Level 1 (Critical): Production instance down or major malfunction. Response within 4 hours.
  • Level 2 (High): Critical loss of functionality affecting many users. Response within 12 hours.
  • Level 3 (Medium): Moderate loss of functionality with available workaround. Response within 24 hours.
  • Level 4 (Low): Minor issues, feature requests, or general inquiries. Response within 2 business days.

Cambrian Lab will use commercially reasonable efforts to resolve issues, including providing corrections, patches, or workarounds. Resolution times are estimates and not guaranteed.