在AWS ECS部署Neo4j Casual Cluster的架构选型及网络问题咨询

Hey there! Let's break down your questions step by step based on my hands-on experience deploying Neo4j Casual Clusters on ECS.

Absolutely—this is a great call, especially since you're aiming to avoid ELB costs. Here's why:

• No extra load balancer overhead: Neo4j's built-in routing lets clients connect directly to cluster nodes (writing to the primary, reading from replicas) without a middleman ELB. This cuts down on both cost and potential latency.
• Dynamic topology awareness: The Neo4j driver automatically discovers the cluster's current state and routes requests appropriately, so you don't have to manage routing rules externally.
• ECS compatibility: Pair this with ECS Service Discovery (or AWS CloudMap) and you've got a scalable, self-managing cluster where nodes can find each other without hardcoded IPs.

The only caveat? You'll need to ensure your ECS setup supports service discovery and cross-node communication (which ties directly into your Docker network issue below).

Your observation about custom bridge networks is spot-on—default Docker bridge networks on ECS EC2 instances don't play nice with Neo4j's clustering requirements. Here's how I've solved this:

Use AWS VPC Network Mode (Recommended) #

Instead of relying on Docker's bridge networks, use ECS's awsvpc network mode. This assigns each Neo4j task its own elastic network interface (ENI) with a private IP, making cross-node communication straightforward.

• In your ECS task definition, set the network mode to awsvpc.
• Assign a security group that allows inbound traffic on Neo4j's required ports: 5000 (discovery), 6000 (transaction), 7000 (Raft), 7474 (HTTP), and 7687 (Bolt) from other tasks in the cluster.

Configure Neo4j Advertised Addresses Correctly #

The biggest mistake I see is misconfiguring *_advertised_address in neo4j.conf. These settings tell other cluster nodes how to reach your instance:

# Listen on all interfaces
dbms.default_listen_address=0.0.0.0
causal_clustering.discovery_listen_address=0.0.0.0:5000
causal_clustering.raft_listen_address=0.0.0.0:7000
causal_clustering.transaction_listen_address=0.0.0.0:6000

# Advertise your task's private IP or service discovery hostname
dbms.default_advertised_address=<your-task-private-ip-or-service-name>
causal_clustering.discovery_advertised_address=<your-task-private-ip-or-service-name>:5000
causal_clustering.raft_advertised_address=<your-task-private-ip-or-service-name>:7000
causal_clustering.transaction_advertised_address=<your-task-private-ip-or-service-name>:6000

If you're using ECS Service Discovery, use the service's domain name (e.g., neo4j-cluster.local) instead of private IPs—this lets nodes dynamically discover each other as tasks scale up/down.

Validate Network Connectivity #

Once your setup is in place, test connectivity from within a Neo4j container:

• Run telnet <other-node-private-ip> 5000 to check if the discovery port is reachable.
• Use neo4j-admin cluster status (if you have access to the container's CLI) to verify cluster health.

Bonus: Persistent Storage #

Don't forget to mount EBS volumes to your Neo4j containers—without persistent storage, your cluster will lose data if tasks restart. In your task definition, add a volume mount pointing to an EBS volume for the /data directory.

内容的提问来源于stack exchange，提问作者Alex Brufsky