One Click APEX AWS Deployment

Standing up a production ready, cloud native APEX environment is hard, especially on AWS. Using a managed service is a solution to this problem however these can make developing more niche and bespoke applications that require granular control over the webserver complex. Client restrictions also need to be considered, if an organization is heavily invested in the AWS ecosystem they may require you to use Amazon’s cloud. At RADAPEX, we have experienced these problems with our own production infrastructure so we decided to invest resources in developing an AWS environment with infrastructure as code tooling. We successfully achieved our end goal which was a one click, fully managed deployment into any region and AWS account powered by CDK, Amazon’s infrastructure as code framework (IaC).

A production ready environment takes around 30 minutes to stand up, 90% of which is just waiting for the Oracle database to patch itself! Our stack includes an NGINX reverse proxy, a Tomcat server running ORDS and an RDS database running Oracle 19c. It also provides the deployer with full control over the NGINX and Tomcat configuration files, something that is not possible with the managed service available on OCI. The webserver components are run on an ECS cluster with Fargate, meaning this stack leverages AWS’s powerful ‘serverless compute’ offerings. Our database is hosted using RDS, which is very affordable, one of our development RDS instances costs ~60 USD a month to run (excluding liscensing). We also take advantage of Amazon’s VPC technology, having a private subnet for our RDS and Tomcat and a public subnet for our exposed NGINX frontend. This provides an additional layer of security as it makes Tomcat (which contains the database credentials) and the database itself completely inaccessible from the internet.

If the database is inaccessible to public internet connections, you may be wondering how developers connect to it. In order to tunnel into the private subnet of the VPC, an EC2 jump box is required, this allows developers to forward remote ports from the private subnet onto their local development machine. In order to do this, the jump box must be running AWS Systems Manager (SSM), then you can start an SSH connection to it via the AWS CLI and simply forward the ports via the established connection. This provides secure database access to developers as they can simply connect to it from localhost. It is worth noting that for development only setups you could place NGINX in the private subnet and use this port forwarding approach to allow developers to connect to the frontend on their local development machines. This would provide a very secure development environment that has no egress to the internet and is guaranteed to only be accessible by developers. It is worth noting that with this setup, developers require an AWS account. Our setup involves an IAM role that our developers can assume. This role follows the principle of least privilege and has the bare minimum privileges required to establish the tunnel. This role is created by our CDK stack.

After the infrastructure has initialised itself, numerous commands, functions and procedures are required to be run on the database before applications can be deployed to the stack. As RDS is a managed service, they are extremely restrictive on direct machine access and certain administrative utilities. AWS have created a lot of wrappers for such functionality, most of these can be found in the ORDS with APEX installation guide written by AWS here. To assist with this ‘post deployment’ procedure, we created a custom shell script that runs on our Tomcat ECS container during the installation of ORDS. This script makes the setup entirely automated and unlocks the APEX_PUBLIC_USER, creates an INTERNAL user and configures our APEX workspaces.

APEX static files can be problematic to manage, serve and keep up to date. Our CDK stack uses an S3 bucket to manage all of the static files. This provides us with the full capability of AWS S3 which includes backups, file encryption and file versioning. These static files are then proxied via NGINX which takes the publicly inaccessible files and makes them publicly available via the /i/ directory on our domain, this approach is very simple and means that any changes to the S3 bucket are instantly reflected on the webserver, making any static file updates require zero downtime.

IaC has proved a powerful technology that we are now able to leverage in order to create a standard playbook that can be deployed for various different clients. It allows us to focus on developing your bespoke solutions instead of dealing with complex infrastructure problems. APEX and AWS is an extremely powerful combination that we are excited to be taking full advantage of.