Skip to main content

AWS Deployment

Deployment Overview​

Account Folders and Permissions​

By default use the standard ec2-user account name when launching the VM. The Qarbine web content is within /var/www/qarbine and its owner and group are ec2user:ec2user. The Qarbine services code is under /home/ec2user/qarbine.service. The web application content is contained within /var/www/qarbine.

Basic Topology Example​

An initial Qarbine deployment has a primary Qarbine node which provides the web application support and core service interactions. This node has an internal database containing your Qarbine configuration information and the catalog components used to retrieve data, analyze it, and present it. You can configure Qarbine to access multiple data endpoints which can span technologies, cloud providers, and geo-locations. The basic deployment is depicted below.

  

All standard AWS Marketplace regions are supported. An AWS Foundation Technical Review (FTR) diagram for the Qarbine Professional edition is shown below.

  

Multi-Region Example​

Below is an FTR diagram showing accessing multiple databases across AWS regions. Access to Bedrock and other RESTful endpoint services varies by Qarbine edition.

  

Multi-Region and On-Premise Example​

Multi-node and multi-endpoint hosts can be deployed based on Qarbine edition. Multi-node and multi-endpoint hosts can be deployed based on Qarbine feature level. Please see the “Deployment Considerations” document within the Getting Started area. Below is an FTR with databases spread across regions and including an on-premise database of some sort.

In this example users have access to the Qarbine nodes but not directly to the databases. The nodes are allowed database interactions. The nodes within a distributed deployment must still have inter-accessibility for their configuration and internal database interactions.

The Qarbine node properties can vary to better support the databases they are interacting with. For example, the Qarbine administrator can configure an analysis to run on a specific node which is near the source data and deployed with optimal compute, storage, and network I/O.

  

​

Launching the AMI​

  1. Navigate to the EC2 page
  1. In the left hand sidebar, click on

  

  1. Select the starting AMI
  1. Click

  

  1. Enter a name
  1. Choose an appropriate key pair
  1. In the Network Settings area click Edit
  1. Choose or create a security group which has ports 22, 80, 443, and 4000 open enough for your interaction. You can adjust these permissions later on for your end users.
  1. If you are planning on using Let’s Encrypt for your SSL certificates then port 80 must be OPEN to the world for the challenge and response protocol to be successful! Once the certificate has been generated, you can adjust the port 80 permissions.
  1. Review the summary information
  1. Click

  

  1. Click on the link to navigate to the console
  1. Wait for the instance state to become

  

Elastic IP Creation and Association​

An Azure Static Public IP is equivalent to Elastic IP in AWS. SSL is used for browser and endpoint interactions. The host name must resolve to the desired public IP address.To avoid having your instance’s public IP address change after a reboot and break the DNS resolution, allocate an Elastic IP address as follows:

  1. In the AWS EC2 console click

  

  1. If you do not have an existing elastic IP to use allocate one now
  1. Select the desired elastic IP address
  1. Click

  

  

  1. In the Instance field, click and choose the intended instance
  1. Click

  

  1. In the summary area note the IP address

  

Other AWS Details​

Public Resources​

Qarbine utilizes integrated documentation within the front end application for rapid access to information. Periodically documents are amended and added. The documents are stored as view only Google Docs and a JSON file stored in a public S3 bucket includes metadata about these documents. At their discretion, the Qarbine administrator can pull this information into their deployment using the Administrator Tool. The metadata information is stored within the internal Qarbine database.

Identity and Access Management (IAM)​

The Qarbine application itself does utilize IAM for user management. Customers may choose to configure Qarbine access to their databases to use IAM features. It is the responsibility of the customer to properly configure IAM for this use case. The Qarbine administrator should test the Qarbine Data Service settings within the Qarbine Administrator Tool. Qarbine uses the AWS SDKs. The SDKs authenticate requests by using the access keys that you provide in the Data Service definition.

More information can be found at
https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html

DynamoDB related IAM information can be found at
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/security-iam.html

Encryption Keys​

Qarbine does not require any encryption keys.

Secrets Manager​

Qarbine does not require any stored secrets.

Billable Services​

The customer is responsible for Qarbine license fees, the associated compute/storage/network cost, and other AWS related fees. The standard Qarbine billable fees for the Professional edition are by the hour based.