AWS Elastic Beanstalk Custom Platforms And Auto Scaling

Elastic Beanstalk provides a managed layer around EC2, load balancing, deployments, health monitoring, and scaling. It suits teams that want application environments without maintaining every component of an Auto Scaling group, while still allowing control over instance configuration and deployment behaviour.

A custom platform is useful when the managed Java, .NET, Node.js, Python, PHP, Ruby, Go, or Docker platforms do not provide the operating system packages, runtime versions, agents, or kernel-level settings an application requires. The platform becomes a reusable AMI-based foundation rather than a one-off server build.

AWS has changed the support position for custom platforms over time, so check current Elastic Beanstalk and account-region availability before committing a new production design. In many cases, a Docker platform or a current managed platform is the safer long-term path. Existing custom platform estates should be reviewed for operating system and runtime support.

The examples below use Australian deployment considerations, including the Sydney region (ap-southeast-2), workloads serving Melbourne and Brisbane, and data residency requirements common in regulated Australian organisations. The same design principles apply to other AWS regions.

Choosing A Platform Strategy

Start by defining what the application genuinely needs from the host. If the requirement is simply a supported runtime and a few packages, use a managed Elastic Beanstalk platform with .ebextensions or platform hooks. This reduces patching work and keeps upgrades aligned with AWS release cycles.

A custom platform is justified when the build needs a particular Linux base, a security agent, a custom proxy, a specialised monitoring daemon, or a controlled systemd configuration. Treat the platform as code: keep the Packer template, shell scripts, package manifest, and validation tests in source control.

For Australian services, select ap-southeast-2 when the application must remain in Sydney or needs low latency to local databases and users. A Melbourne-facing business may still use Sydney for its primary environment, but should measure latency and plan a second region if its recovery objectives require geographic separation.

Building The Custom Platform Image

A typical custom platform pipeline uses Packer to launch a temporary EC2 instance, install the operating system updates and required packages, apply hardening, install the Elastic Beanstalk platform components, and create an AMI. The build should be repeatable and should never depend on an engineer manually changing a running instance.

The platform definition identifies the operating system, architecture, platform version, and builder configuration. Pin package repositories where appropriate, record the AMI ID and source commit, and publish the resulting artefacts through a controlled CI/CD pipeline. Use an instance profile with narrowly scoped permissions for image creation and logging.

Test the image before making it available to environments. Confirm that the EB engine can deploy the application, health reporting works, log collection succeeds, and a replacement instance can join the load-balanced environment. A failed platform build should stop promotion rather than create a partially functional AMI.

Creating The Elastic Beanstalk Environment

Create the application and environment with the EB CLI or AWS CLI, selecting the custom platform version where that capability remains available. Keep environment configuration in .ebextensions, saved configurations, or a deployment pipeline rather than relying on console-only settings.

A load-balanced environment is the normal choice for a web application:

option_settings:
  aws:elasticbeanstalk:environment:
    EnvironmentType: LoadBalanced
  aws:autoscaling:asg:
    MinSize: '2'
    MaxSize: '6'
  aws:autoscaling:launchconfiguration:
    InstanceType: t3.medium

Use at least two Availability Zones for production. Configure security groups so the instances accept application traffic only from the load balancer, and place the database, cache, and internal services in private subnets. If an application must consume a private service in another VPC, PrivateLink service access can avoid exposing that dependency through public networking.

Tuning Auto Scaling Behaviour

CPU utilisation is a reasonable starting metric, but it is rarely the best indicator for every workload. A queue consumer may need scaling based on queue depth, while an API may be constrained by request count, latency, or application worker saturation. Publish a custom CloudWatch metric when host CPU does not represent user demand.

Set a sensible minimum capacity for the service’s baseline traffic and enough maximum capacity for a controlled burst. Scale-out should react sooner than scale-in, with cooldown or warm-up periods long enough for instances to complete bootstrap and pass health checks. Sudden scaling activity can otherwise produce repeated launches and terminations.

For example, a CPU policy can be represented with Elastic Beanstalk options:

option_settings:
  aws:autoscaling:trigger:
    MeasureName: CPUUtilization
    Statistic: Average
    Unit: Percent
    Period: '60'
    BreachDuration: '5'
    UpperThreshold: '70'
    LowerThreshold: '30'

Validate the policy with a load test that reflects Australian peak periods, such as a retail campaign, an end-of-financial-year processing window, or a morning traffic surge across Sydney and Brisbane. Check that the load balancer health checks, target registration, application startup time, and downstream database capacity all behave as expected.

Managing Deployments And Shutdowns

Custom platform hooks should make deployments predictable. Use pre-deploy hooks for configuration validation and dependency checks, and post-deploy hooks for tasks that must run after the application is placed on the instance. Avoid destructive database changes in instance lifecycle hooks because Auto Scaling may execute them repeatedly.

Graceful shutdown matters when instances scale in or deployments replace hosts. Configure the application service to stop accepting new work, finish active requests, and release connections before termination. For systemd-managed services, review systemd stop controls when selecting KillMode, KillSignal, and timeout values.

Enable connection draining on the load balancer and make the application tolerant of interruption. Store sessions outside the instance, keep uploaded files in Amazon S3, and use a durable queue for work that must survive a host replacement. These patterns prevent Auto Scaling from becoming a source of lost state.

Operational Checks And Recommendations

Monitor environment health, deployment events, instance replacement, scaling activities, load balancer errors, and application logs in CloudWatch. Alarms should cover elevated 5xx responses, unhealthy hosts, queue growth, database saturation, and an Auto Scaling group approaching its maximum size.

Review platform versions regularly and rebuild the image when the operating system, agent, security tooling, or runtime requires an update. A custom AMI can provide consistency, but it also creates responsibility for patching and testing that AWS handles for managed platforms.

Deployment path	Best fit	Maintenance responsibility	Main trade-off
Managed Elastic Beanstalk platform	Standard supported runtimes	AWS manages the platform layer	Less host-level customisation
Custom platform	Special packages, agents, or OS controls	Team owns image lifecycle and testing	Maximum control with greater operational effort
Docker on Elastic Beanstalk	Portable application and dependency stack	Team owns image and container configuration	Easier packaging, but container operations still require discipline

• Keep the platform build and environment settings in version control.
• Use private subnets, least-privilege IAM roles, and security groups based on traffic flow.
• Set minimum, maximum, and scaling thresholds from measured load rather than guesswork.
• Test deployment rollback, instance replacement, and graceful shutdown before production.
• Reassess a legacy custom platform against a current managed or Docker-based alternative.