This template creates a complete Userify Enterprise cluster in the region, VPC, and subnets of your choice. This is designed for new installs only, since it generates the cryptokey and does not give you an opportunity to provide your own. (Please contact the support team for help with existing installs.)
The following resources are generated in the region of your choice:
- Launch Configuration (customize instance type) running Userify Enterprise
- Elasticache Cluster (customize size)
- S3 Bucket for primary data storage
- Autoscaling Group (customize scaling constraints, add your own policies)
- ELB (lowest cost per transaction in this use case)
- Security Groups and IAM policies/roles
- Generated cryptokey for pre-encryption (before Redis/S3 storage) from passphrase
- Standard Linux AMI based on Ubuntu 16.04 LTS (customizable)
Userify Deployment Support
This is one of the most powerful ways to deploy Userify, but we recommend that you reach out to our support team (it's free!) at email@example.com for architectural tips and 'gotchas'.
During initial testing, it's recommended to just run a single instance in the auto-scaling group to make changes to configuration much faster and easier. You can do this, or even change the instance type, by adjusting the autoscaling group and launch configuration settings. (Switching instance type requires creating a new launch configuration based on the old one. If you need help, please reach out.)
AD/LDAP users are not compatible with previously-created non-AD/LDAP users and cannot share usernames or emails.
So: if you are planning to integrate with Active Directory or LDAP, you should do it immediately before clicking 'Sign up' and creating your first user account.
You can quickly configure for Active Directory/LDAP by clicking "Server
Configuration" and logging in with the cluster admin user account that you
created with this CloudFormation template. (Note: that admin username must be
lowercased during creation:
yourcompany_admin. Unlike regular
Userify accounts, you cannot create an administrator account with
uppercase characters such as
After making the change, you must reboot individual cluster nodes to force them to reload the changed cluster configuration:
The easiest way to do this is to double the size of the auto-scaling group, wait approximately ten minutes, and then halve it. This will cause the oldest nodes (the old configuration) to be terminated. (Instances will also check for updated cluster configuration every hour if you'd rather wait.)
If you are just testing, other important parts of configuration (such as setting up SMTP or SSL/TLS) can be delayed until later, except that instances installed pointing at the previous hostname (i.e., the ELB's long CNAME hostname) will not automatically update themselves.
In order to get you up and running quickly, the cluster instances pre-generate self-signed certificates and are pre-set at one. More than one will cause you to have to accept multiple self-signed certificates within the first few seconds.
IMPORTANT: Before going into production, the ELB should be modified to accept a TLS/HTTPS listener using a TLS certificate from Amazon Certificate Manager (ACM), IAM, or just pasted in, which will replace the current TCP listener on port 443. You should direct the traffic for the HTTPS listener to HTTP on port 8120. This will allow the ELB to pass through X-Forwarded-For HTTP headers and prevent double-counting of your nodes. (Otherwise, you'll see the external address of the instances that you are using as the ELB incoming instance IP's!) More information: https://docs.aws.amazon.com/elasticloadbalancing/...
Other caveats and notes
Please do not attempt to use this template with a pre-existing CFT or manual cluster build, although we intend to make future releases of this template backwards-compatible (so you can update an existing cluster). The reason why is that this template causes a new cryptokey to be generated. However, you could use this template to generate a new build, and then replace the AMI's in the launch configuration with your own customized version. (This is how we're going to switch to managing Userify Cloud.)
This beta release does not include Cloudwatch/ELB autoscaling policies to prevent unwanted scaling events, until we can gather more information in different region about timings and ELB health checks. (Those policies are very conservative right now.) You can certainly add some; if you are running t2 instances, you should run CPU no higher than 40% before scaling, while other instance types can scale at 80% or 90%, although user experience will suffer.
You can certainly add another launch configuration/ASG and ELB, based on the current LC and ELBs that the template provides for you, and provide two different autoscaling groups: one for your users for the best user experience (we use t2.nano or t2.micro for these, as the traffic is very bursty), and one for the servers themselves (we use m3.medium for these for the most inexpensive and consistent single-processor performance.) Userify has built-in support for managing clusters separately like this in the dashboard section. For example, if you visit configure.userify.com and dashboard.userify.com, you'll see our two clusters (at disparate clouds) - one is designed for cost controls with a heavy load, and the other is designed for the best user experience. If you front-end your server cluster with an ALB, you can also isolate the API paths to only the /api/userify/configure path for the server nodes for extra security (however, an ALB may increase transactional costs.)
Deleting the stack is a matter of simply clicking "delete" (but your data in the S3 bucket is kept around for the future, so empty it if it's no longer needed.)
For testing or playing around, the cluster includes a free ten server license, and you can customize the ELB as desired with ACM certificates from Amazon for free.
Get started now: Launch Stack