3 node deployment resides in a single AZ

This impacts HA/FT.

Looks like the issue is present down at the network layer and presumably flows up from there.

amazon-cloud-formation-neo4j/marketplace/neo4j.template.yaml

Lines 152 to 155 in a2f118a

    
           AvailabilityZone: !Join 
        
             - '' 
        
             - - !Ref 'AWS::Region' 
        
               - 'a'

This was by design in order to keep the number of lines of code to a minimum. We can re-architect across 3 AZs if required, but this will mean additional:

Subnets
Route table entries and associations

In order to be "Well Architected" the deployment needs to span AZs. We did that automatically deploying into the default network that comes with subnets in each AZ for the region it resides in. By not specifying an AZ, the ASG automatically spanned the available ones.

I can't remember how this all works in a non default network. It does seem like we need to explore that.

AWS does provide this which might be useful for insight. I've found it to be rather over engineered in the past. https://github.com/aws-quickstart/quickstart-aws-vpc

It might be good for us to review this material a bit. We became compliant on this for our Quick Start deployment (and the subsequent Marketplace template based on it). That allowed us to achieve a well architected status for the IaaS deployment. That in turn got Neo4j an approved IaaS FTR which led to Advanced Tier status with AWS.

https://aws.amazon.com/architecture/well-architected/

#46

@benofben added changes to make this work across two AZ's , did not go with three since there might be a region with only two AZ's. Please have a look and close the issue if this looks good

Is there a way we can span 3 if 3 available, two if not?

@benofben i can try but it will make it more complex and extra code since this will need some conditions and length function to check the number of AZ's ...and as far as i can remember we wanted to keep the template as simple as possible.

@benofben Let me know if you are ok with giving up on the simplicity of the template and i can work on it

I'm a little afraid we're seeing a snowball impact of moving away from the default VPC. That's led to making our own VPC. That leads to subnet stuff. CFT doesn't provide good constructs to manage that, so we now have this increasingly complex code that customers will have difficulty customizing.

I'm not sure the best path here.

i think the current code suffice's our need of deploying Neo4j in a multi AZ ...i don't think we need to deploy it in exactly 3 multi AZ since deploying in a minimum of 2 satisfy the multi AZ condition.
To be discussed more with @edrandall-dev

This is fixed.