Neptune DXP on AWS apps

User devices accessing the web application. In the case of your employees, they could be a mixture of users with corporate devices or on a "Bring Your Own Device" basis (BYOD).

A single region virtual private network (VPC) created to host DPX application servers across a minimum of 2 (or more) availability zones.

Neptune DXP is the public portion of the network accessible to external users.

Neptune DXP’s private database and cache is inaccessible to the public and is only visible to the Neptune DXP application server.

Web Access Firewall acting as the first line of defence against common attacks originating for malicious internet users.

Route 53 is used as the DNS service to route public-facing user-friendly internet links to the load balancer in front of the Neptune DXP application serve requests such as https://www.<app_name>.<company>.com but also to route to a failover website should the Neptune DXP application server experience downtime.

Neptune DXP has the ability to host digital assets using its Media Library function. This could be used to store user content in addition to assets necessary to render the application. However, large volumes of data residing in block or database storage managed by the compute instances hosting the Neptune DXP application server may interfere and potentially overwhelm its primary purpose, which is to serve the web application to its users, manage their authentication and to execute server scripts implementing business logic.

Content Delivery Network (CDN) service to cache content from the S3 static content storage as well as static or dynamic web pages served by the Neptune DXP application servers through its global network enabling users to view content with low latency across the globe. To enhance security, content distributed by the CDN should be encrypted using an SSL/TLS certificate issued by AWS’ Certificate Manager attached to the CloudFront distribution. As requests served by CloudFront don’t reach the VPC the usage cost for EC2 instances is lowered.

In the event there’s an issue with the infrastructure rendering the Neptune DXP application server temporarily unavailable a static website can present, at minimum, a holding page or enough content to service the Neptune DXP application users whilst the Neptune DXP web application is being recovered. This provides partial continuity of service and helps mitigate any reputational damage or potential loss of revenue that may accompany such outages. To achieve this, the AWS Route 53 DNS service must be configured to implement its Failover feature evaluating the health of the load balancer and the health of the application running on the EC2 instances hosting the Neptune DXP application server. When a failure is detected it should route incoming Neptune DXP application users to as a static S3 website configured for anonymous public access.

Acting as the main point of entry for all internet traffic into the virtual private network. Most browsers nowadays, as a precaution either prevent access to unsecured (HTTP) websites or notify their users that the target website is potentially unsecured or malicious. This may raise concerns with the Neptune DXP application’s users and is likely to hamper its adoption rate and fall foul of data privacy rules, such as GDRP for EU residents. It is therefore recommended that all public traffic accepted into the network is treated as sensitive and configured to the HTTPS protocol to ensure data is encrypted whilst in flight.

Application Load Balancer is a critical AWS service that continuously evaluates the healthiness of the compute units hosting the Neptune DXP application server and route all incoming internet traffic accordingly. The Load Balancer can be used as the termination point for incoming HTTPS traffic allowing you to select the use of HTTP or HTTPS for access to the Neptune DXP application server. Both approaches are supported by Neptune DXP, but you must judge whether the loss of performance when configuring Neptune DXP to accept HTTPS-only traffic is better than then the loss of security if the preference is given when accepting HTTP only traffic.

You can use your existing arrangements to issue (or re-use existing) SSL/TLS certificates or take advantage of the free AWS Certificate Manager service. Certificates are used encrypt your assets in your static content storage securing your CDN distributions as well as terminating internet traffic in the Load Balancer using the HTTPS protocol.

The Neptune DXP application server is the most important workload in this stack. As it will be highly available new instances will be “spun-up” and “terminated” based on demand and ad-hoc failures. It is good practice to wrap your Neptune DXP configuration inside an Amazon Machine Instance (AMI) to avoid having to perform configuration steps as new instances come to life.

Used as a primary defence mechanism evaluating incoming traffic into your Neptune DXP App server and ancillary AWS resources residing within the VPC network. Care should be taken to configure access to/from the Neptune DXP App server and Neptune DXP’s private database to only reference their respective security groups wrapped around them.

To adapt to changes in traffic demand it is recommended that the Neptune DXP App Servers are placed in an auto-scaling group. This will eliminate the need to manually intervene to add or remove EC2 instances hosting Neptune DXP in response to traffic increase or reduction. Appropriate metrics should be used as a threshold to regulate the provisioning and de-provisioning of EC2 instances (for example, a 70% CPU utilisation with enough wait time in case demand subsides). This can reduce operational costs by not having to operate “always-on” instances and improve reaction times as demand changes.

The use of own database installations is discouraged as they require you to be responsible for their operation and come at a cost in the form of database engineers and processes to achieve and maintain highly available and reliable operations (for example, replication, patches, backups,…​). Network Address Translation (NAT) gateways will also be required, at an additional cost, to prevent inbound internet connections to the database but also to enable outbound traffic to implement software updates and backups to external services. It is recommended to avoid these overheads by adopting an AWS managed service and specifically, the use of an AWS RDS managed database service for structured data, such as PostgreSQL.

If the Neptune DXP Application is expected to serve an increasing number of users or host additional Neptune DXP Apps so will the demand for data. Caching at the edge of your infrastructure using a CDN should reduce the need to access the database. For those requests that must be resolved by the Neptune DXP web application the implementation of an internal cache, using the AWS ElastiCache service, is recommended. More specifically, a master/replica arrangement across availability zones, in front of the Neptune DXP Database (RDS) instance should increase performance lowering latency and avoid incurring costs by limiting access to the database.

As there are multiple ephemeral Neptune DXP app servers being managed by this stack, along with multiple ancillary AWS services, it is always important to be aware of their operational state. The use of a centralised service to aggregate all logs, traces and metrics will enable the meaningful observability of the stack and the creation of higher-order actionable alerts relating to the Neptune DXP app’s user experience facilitating user-centric responses. For example, issuing alerts when commonly used features of the Neptune DXP web application (for example, search) start displaying increased latency or when web pages important to the user experience (for example, a stock or location check) start to degrade with an increased number of failures.