Introduction

Yes, you can run Elastic Beanstalk without an Elastic Load Balancer by choosing a single-instance environment. In that mode, Elastic Beanstalk manages one EC2 instance directly instead of placing a load balancer in front of multiple instances.

That setup is useful for development, test, low-traffic internal tools, and other cost-sensitive workloads. The tradeoff is that you lose high availability, horizontal scaling, and the normal load-balancer health-check path used in production-style environments.

Single-Instance Environment

Elastic Beanstalk supports two broad web-environment shapes:

• Load-balanced, scalable
• Single-instance

A single-instance environment does not create a load balancer. Elastic Beanstalk still uses an Auto Scaling group, but the minimum, maximum, and desired capacity are all effectively pinned to one instance.

If you create the environment with the EB CLI, the intent is explicit:

eb create my-env --single

You can also set the environment type in configuration.

option_settings:
  aws:elasticbeanstalk:environment:
    EnvironmentType: SingleInstance

That tells Beanstalk to provision one EC2 instance without a dedicated Elastic Load Balancing resource.

What You Gain and What You Lose

The main benefit is simplicity. There are fewer moving pieces, lower cost, and less network infrastructure to reason about. For demos, QA environments, or internal admin tools, that can be a rational choice.

The downsides are substantial:

• One instance is a single point of failure.
• Traffic spikes cannot be distributed across multiple instances.
• Rolling updates and restarts can create visible downtime.
• You do not get the usual ALB-level request routing and health-check behavior.

That is why single-instance Beanstalk environments are generally better for development, testing, or staging than for production.

Operational Differences

Without a load balancer, the environment CNAME points effectively at the single running instance path rather than routing through an ALB. Health reporting also behaves differently because Elastic Beanstalk relies on EC2-level checks for single-instance environments rather than load-balancer health checks.

This matters when you are troubleshooting deployment issues. A load-balanced environment can isolate unhealthy instances behind the load balancer, while a single-instance environment simply becomes unavailable if that one host is unstable or being replaced.

If your application depends on sticky sessions, TLS termination behavior, path-based routing, or multi-process listener configuration through an ALB, removing the load balancer changes the architecture materially.

When This Is a Good Fit

Single-instance Beanstalk is reasonable when:

• You are developing or validating a prototype.
• Downtime during deployment is acceptable.
• Traffic is low and predictable.
• Cost matters more than availability.
• You want Beanstalk conveniences without a full production footprint.

It is much less attractive when uptime, redundancy, or autoscaling matter. In those cases, load-balanced Beanstalk is the safer default.

Deployment Example

A simple workflow might look like this:

eb init
neb create demo-single --single
neb deploy

If you later outgrow that setup, you can switch the environment type in Elastic Beanstalk configuration rather than rebuilding the entire application package from scratch. That migration path is one reason Beanstalk can work well for teams that start small and scale later.

Common Pitfalls

A common mistake is assuming “no load balancer” means “production is fine if traffic is small.” Even light production traffic can still suffer from downtime during restarts, instance replacement, or configuration changes.

Another issue is forgetting that some tutorials assume ALB-backed features. If you copy listener, rule, or load-balancer health-check configuration into a single-instance environment, it will not apply the way you expect.

Developers also sometimes overlook security-group design. With no load balancer mediating inbound traffic, the instance-facing security posture matters even more.

Finally, be careful with deployment expectations. In a single-instance environment, application updates can make the site unavailable while the one host is being updated or recycled.

Summary

• Elastic Beanstalk can run without an Elastic Load Balancer in single-instance mode.
• Use --single or EnvironmentType: SingleInstance to request that setup.
• The architecture is cheaper and simpler but gives up redundancy and scaling.
• Health reporting and deployment behavior differ from load-balanced environments.
• Single-instance mode is usually best for development, staging, or low-risk workloads.