Deploying to AWS
The AWS Beanstalk engine deploys application versions to a managed cloud environment.
Where to find it
Architect Panel → Integration & Connections:
- Deployments — environments and versions
Architect Panel → Integration & Connections:
- Database Hosts — where the data lives
What it gives you
- Autoscaling — capacity following load.
- Managed environments — live, test and others, each independent.
- Versioned deployments, so a specific version can be re-applied.
- Health checking, replacing instances that stop responding.
Point health checks at the right endpoint
The platform offers a liveness check that touches no database and a readiness check that does. The load balancer should use liveness.
If it checks the database, a brief database problem takes every instance out of service simultaneously — turning something recoverable into a total outage. Use readiness for monitoring instead.
Instances are disposable
They are replaced routinely. Anything written to an instance's own disk is lost, which matters for uploads, sessions and anything cached locally.
Sessions in particular need to be shared rather than held on the instance, or users are signed out whenever they reach a different one — which presents as random, intermittent sign-outs that are miserable to diagnose.
The database is separate
Deploying does not touch it, and scaling the application does not scale it. A database that is the constraint will not be helped by more application instances, and adding them can make it worse.
Watch the cost
Autoscaling responds to load, including load you did not intend — a runaway integration, a crawler, a badly configured poll. Set alarms on spend as well as on health.
Keep environments genuinely separate
Especially their credentials. A test environment holding live mail or payment credentials will eventually use them, and it will do so while somebody is testing something.
Deploy to test first
The whole point of having environments. A version that deployed cleanly to test is not guaranteed in live, but a version that failed in test certainly would have failed in live.
Worked example
An organisation runs live and test environments with sessions held in a shared store rather than on instances, the load balancer checking liveness and monitoring checking readiness. A database failover took forty seconds; monitoring alerted, no instances were replaced, and the site returned errors briefly instead of going down.
Recommendations
- Liveness for the load balancer, readiness for monitoring.
- Share sessions — instances are disposable.
- Separate environment credentials completely.
- Alarm on spend, not only on health.