AWS has introduced Cluster Mode for Elastic Beanstalk, bringing multiple applications onto shared managed infrastructure. For a website owner considering more than one application instance, there is a practical question to answer first: will a visitor keep the same working session when another instance serves the next request?
1. Map one complete visitor journey
Choose a representative journey in a test environment: sign in, add a synthetic item to a cart, upload a harmless file and retrieve the result. For every step, record where the application keeps the state and how another instance would access it.
Ask the maintainer to distinguish sessions, persistent files, cache and database records. This is an inventory exercise before it is an architecture change. Include scheduled jobs too: determine whether starting a second application copy would also start a second copy of the job.
The AWS announcement describes a particular platform. This guide proposes an application acceptance test; it does not assume that selecting a deployment option solves every state-management requirement for your code.
2. Exercise both instances with the same browser
Prepare two test instances running the same release and compatible configuration. Use fictitious accounts, a payment sandbox and an isolated email destination. Make instance identity visible in authorized logs so you can establish which copy handled each step.
Have the person managing the test load balancer route successive requests from the same browser to different instances. Preserve the hostname and cookies. Testing unrelated hostnames can introduce cookie differences that obscure the state-sharing question you intended to investigate.
Capture these outcomes explicitly:
- Authentication survives the switch between instances.
- Cart contents remain consistent.
- The uploaded file is accessible from the other instance.
- The business operation appears only once.
Keep timestamps and identifiers for synthetic operations. If a result is intermittent, investigate it even if refreshing the page makes the symptom disappear. A successful retry does not explain the original failure.
3. Rehearse an instance replacement
In the test environment, remove one instance from traffic using the intended operating procedure. Repeat the journey and observe in-flight requests, deferred work and already recorded results. A healthy home page alone cannot validate this scenario.
Correct the local dependencies revealed by the exercise, then rerun the same checks. Assign ownership of scheduled work and document how duplicate execution is prevented when multiple copies are running. Ensure that the test itself has not sent real email or created real orders.
Keep the results and the return procedure with the deployment record. You now have evidence about session continuity and data access, which is more useful for this decision than the mere availability of a cluster setting.
Sources: AWS News Blog.