Amazon AWS EC2 gives you a virtual machine that you can ssh login to directly with a high amount of control. But it also means that you are responsible for most everything, because it isn't automatic or opinionated.
Some of the benefits of EC2 include:
- Full control. For a Linux server instance, you can ssh in directly and get root access, install Linux packages via apt/rpm/etc, pick your desired port, etc.
- If your workflow development process is to ssh in to the server, edit the source on the server with vim, and simply start the workflow code from the command line, this is as quick of a deployment as there is, and it works well during the development phase.
Some of the challenges of EC2 include:
- Full responsibility. With that full control, you are responsible for everything. This includes applying software updates, TLS, version control, production deployment, etc.
You'll need to start your workflow application. To do that from a shell on a Linux image, run the command: i.e.,
./mywf.py, etc. This may be adequate during development, but for production you may consider something more substantial, such as configuring it in
A full description of VPC is out of scope for this document, but it is critical to configure correctly so that your application has proper connectivity to the Internet, without exposing your internal components.
You can choose whatever port you want to run your server on, it doesn't have to be port 443. Whatever port you choose to listen on, configure the AWS Security Group to allow inbound traffic to that port.
To verify your workflow application is running, using a standard web browser hit the URL, which should look something like
https://ec2-54-123-45-67.compute-1.amazonws.com:3000/hellopath. Because the web browser is looking for an HTTP response instead of a websocket, it is normal for the web browser to display an error such as
You cannot access a WebSocket server directly with a browser. You need a WebSocket client. Seeing that error message is positive indication that your connectivity is good.
With Route 53, you can manage DNS records for your custom domain.
For TLS certificates, you can use the AWS Certificate Manager with a load balancer. Then is becomes easy to use the load balancer to run your server certificate, maybe even on port 443, so that your EC2 node can run in plaintext
ws but be reachable only via the load balancer: the load balancer handles the TLS.
Let's Encrypt is not an Amazon product, but here are some pointers if you choose to integrate a Let's Encrypt certificate with EC2.
- Be aware that Let's Encrypt has a policy against issuing certificates for hosts in the amazonaws.com DNS domain. So if you want to use Let's Encrypt, the FQDN for your EC2 instance will need to be in a custom DNS domain name. This can be done in AWS via a Route53 public hosted zone, or a domain hosted external to AWS to which you can add the IP address of your EC2 instance (or load balancer, if you are using one).
- The default configuration of the Let's Encrypt
certbottool needs inbound access to port 80 of your EC2 instance for ownership verification, which is not enabled by default, so you will need to add that in the EC2 Security Group.
- If you use the
--standaloneoption with the certbot tool, you don't need to have an existing web server on this EC2 instance.
- The Let's Encrypt CLI will store the key and certificate in
/etc/letsencrypt/live/HOSTNAME/, so verify that your workflow app or reverse proxy (if you use one) has read access to these files, which is not the default.
We aren't recommending any specific providers, but since AWS EC2 is common we'd like to share our lessons learned to help you get up and running quickly.
Updated 4 months ago