AWS Elastic Beanstalk Application Deployment and Environment Configuration – SAP-C02 Study Guide

Purpose of This Lesson

AWS Elastic Beanstalk is a platform-as-a-service deployment option for web applications. It provisions and manages the underlying AWS resources—such as Amazon EC2 instances, Auto Scaling, security groups, and load balancing—while allowing the engineering team to focus primarily on application code and configuration.

This lesson demonstrates creating an Elastic Beanstalk application and environment, selecting a managed platform, configuring networking and instance settings, and deploying a sample application.

Key Concepts

Elastic Beanstalk application versus environment

An Elastic Beanstalk application is a logical container for related deployments and environments. The application itself does not run the workload. An environment contains the deployed AWS resources and runs a specific version of the application.

An application can have multiple environments, such as:

• Development
• Test or staging
• Production
• Blue and green deployment environments

Each environment can have its own platform version, capacity, networking, scaling, and deployment configuration.

Web server and worker environments

Elastic Beanstalk supports two broad environment types:

• Web server environment: Receives HTTP or HTTPS requests and serves the application directly.
• Worker environment: Processes background tasks obtained from an Amazon SQS-backed queue.

A common architecture uses a web server environment to accept requests and place long-running work onto a queue. Worker instances consume those messages asynchronously. This avoids tying up web servers while they perform slow processing such as report generation, media processing, or batch operations.

Managed platforms

Elastic Beanstalk provides managed platforms for supported runtimes and web stacks, such as Node.js. The selected platform determines the operating system, runtime, web server, and deployment behavior used by the environment.

Elastic Beanstalk can provision the infrastructure, but application compatibility, dependency management, configuration, and deployment safety remain the responsibility of the application team.

Single-instance versus high-availability environments

A single-instance environment is useful for development, demonstrations, and low-cost workloads. It generally uses one EC2 instance and does not provide production-grade fault tolerance.

A load-balanced environment is intended for higher availability. It can use:

• An Elastic Load Balancing load balancer
• Multiple EC2 instances
• Auto Scaling
• Multiple Availability Zones

Selecting a high-availability preset does not eliminate the need to verify subnet design, capacity settings, health checks, security groups, and deployment policies.

IAM roles and instance profiles

Elastic Beanstalk uses different IAM identities for different purposes:

• Service role: Allows the Elastic Beanstalk service to perform actions in the AWS account, such as managing environment resources and reporting health.
• EC2 instance profile: Provides permissions to the EC2 instances launched for the environment.

The instance profile is especially important when application instances need to access AWS services, such as Amazon S3, Amazon DynamoDB, Amazon SQS, or Amazon CloudWatch. Follow least privilege; do not attach broad permissions merely because the wizard makes an instance profile available.

A key-pair selection is separate from the instance profile. The key pair enables administrative SSH access when the operating system and security groups permit it.

Networking configuration

During environment creation, you select a VPC and subnets. Important decisions include:

• Whether instances receive public IPv4 addresses
• Whether the environment is internet-facing or internal
• Which Availability Zones contain resources
• Whether private subnets require NAT gateways for outbound internet access
• Which security groups allow inbound application traffic
• Whether a database is created and, if so, where its subnets reside

Database subnet settings may appear in the configuration workflow even when no database is being provisioned. They are relevant only if a database is added to the environment.

Application versions and deployments

Elastic Beanstalk maintains application versions that can be deployed to environments. New versions should normally be packaged and deployed through a repeatable process, such as a CI/CD pipeline, rather than by modifying a running instance manually.

Common deployment policies include:

• All at once: Fastest and simplest, but causes downtime or reduced availability during deployment.
• Rolling: Replaces instances in batches, reducing deployment impact but temporarily reducing capacity.
• Rolling with additional batch: Adds temporary capacity so existing capacity is not reduced during a rolling deployment.
• Immutable: Launches a complete temporary replacement set before switching traffic, providing a safer rollback path at higher cost.
• Traffic splitting: Sends a controlled percentage of traffic to the new version for validation before completing the deployment.

The policies available depend on environment type and platform capabilities. A single-instance environment has fewer meaningful high-availability deployment choices than a load-balanced environment.

Health, monitoring, and managed updates

Elastic Beanstalk can provide enhanced health reporting and environment events. These features help identify failed deployments, unhealthy instances, application errors, and infrastructure issues.

Managed platform updates can periodically update the platform version during a configured maintenance window. This reduces manual maintenance but must be evaluated against application compatibility, change-control, and rollback requirements.

Logs can be requested from environment instances, and operational metrics can be viewed through Elastic Beanstalk and related AWS monitoring services.

Exam-Relevant Takeaways

• Elastic Beanstalk is a managed application platform, not a serverless runtime. It commonly provisions EC2, Auto Scaling, load balancing, security groups, and related resources.
• An Elastic Beanstalk application is a logical grouping; an environment is the deployable runtime.
• Use a web server environment for synchronous web requests and a worker environment for asynchronous SQS-based processing.
• A single-instance environment is appropriate for development or low-cost scenarios, not for multi-AZ production resiliency.
• A high-availability environment generally requires a load balancer and instances distributed across multiple Availability Zones.
• The Elastic Beanstalk service role and the EC2 instance profile are different IAM constructs with different responsibilities.
• Assign only the permissions the application and management processes require. Avoid treating an instance profile as an administrative role.
• Manual changes made directly to an EC2 instance are not durable. An instance replacement, scaling event, or redeployment can remove them.
• Store application artifacts and configuration in a source-controlled, repeatable deployment process.
• Public IP assignment is not automatically the correct design. Production instances can often be placed in private subnets behind a load balancer.
• Deployment strategy is a tradeoff among speed, availability, rollback safety, and cost.

Architecture Decision Guide

Requirement	Suitable Elastic Beanstalk design	Important considerations
Quick demonstration or development environment	Single-instance environment	Low cost, but no meaningful instance-level fault tolerance
Highly available public web application	Load-balanced environment across multiple AZs	Validate subnets, health checks, security groups, and scaling limits
Long-running background processing	Web server environment plus worker environment	Web tier submits messages; worker tier consumes SQS-backed work
Safe production release	Immutable or traffic-splitting deployment	Uses additional capacity and may increase deployment cost
Minimal deployment downtime with moderate risk tolerance	Rolling with additional batch	Requires temporary extra capacity
Simple and fastest release where downtime is acceptable	All-at-once deployment	Not appropriate for strict availability requirements
Application access to AWS APIs	Least-privilege EC2 instance profile	Do not embed long-term access keys in application code
Private application instances	Private subnets, load balancer as appropriate, NAT for outbound access	Ensure required package downloads and AWS endpoints remain reachable
Repeatable operations	Versioned application artifacts and CI/CD	Avoid modifying instances through SSH

Common Exam Traps

• Confusing an application with an environment: The application is the container; the environment runs the application version.
• Assuming Elastic Beanstalk is serverless: Beanstalk manages infrastructure but still commonly uses EC2 instances that incur charges.
• Choosing a single instance for high availability: One instance cannot tolerate instance failure or an Availability Zone failure.
• Confusing the service role with the instance profile: The service role is used by Elastic Beanstalk; the instance profile is assumed by environment EC2 instances.
• Assuming a public IP is required for every web server: A load balancer can be public while backend instances remain private.
• Using SSH as a deployment mechanism: Direct changes are not durable and conflict with immutable, repeatable deployment practices.
• Selecting all-at-once deployment for a zero-downtime requirement: Use an appropriate rolling, immutable, or traffic-shifting strategy instead.
• Treating worker environments as general-purpose queues: The worker pattern is based on asynchronous SQS-backed processing; it is not a replacement for every event-processing architecture.
• Granting excessive IAM permissions because a wizard requests a role: Inspect and reduce permissions to the required actions and resources.
• Assuming the creation wizard’s defaults are production-ready: Review subnet placement, public addressing, instance types, scaling, health checks, encryption, logging, and deployment policy.

Real-World Engineer Notes

• Use separate Elastic Beanstalk environments for staging and production. This makes validation and rollback safer than testing changes directly in production.
• Treat the environment configuration as code where practical. Elastic Beanstalk configuration files, saved configurations, and CI/CD automation can reduce console drift.
• Application settings may contain secrets. Prefer AWS Secrets Manager or AWS Systems Manager Parameter Store rather than storing credentials in source code or plain environment files.
• If an application requires a database, favor a separately managed Amazon RDS deployment when lifecycle independence, backup control, and operational separation matter. Avoid coupling a critical database too tightly to an easily recreated application environment.
• Verify the security-group relationships explicitly. A public load balancer should accept only required listener traffic, while application instances should accept traffic from the load balancer security group rather than from the entire internet.
• Enable centralized logs and meaningful health checks before production deployment. A green environment status alone does not prove that business transactions are working correctly.
• Platform updates should be tested in a nonproduction environment before enabling automated production updates.
• Worker environments need capacity and queue monitoring. A growing queue can indicate insufficient worker capacity, application errors, poison messages, or downstream throttling.
• Elastic Beanstalk is convenient, but it is not always the best fit for highly customized infrastructure, container orchestration, or complex multi-service deployment requirements.

Quick Reference Summary

• Elastic Beanstalk application: Logical container for related environments and versions.
• Environment: Running deployment and its AWS resources.
• Web server environment: Handles web requests.
• Worker environment: Processes asynchronous SQS-backed tasks.
• Service role: Permissions used by the Elastic Beanstalk service.
• Instance profile: Permissions granted to EC2 instances.
• Single instance: Low cost and simple; not highly available.
• Load balanced: Supports multiple instances and multi-AZ resilience.
• Application version: Packaged code artifact deployable to an environment.
• Direct SSH changes: Temporary and unsafe as a deployment process.
• Deployment policy: Determines how new versions replace or coexist with old versions.
• Managed platform updates: Automated platform maintenance that still requires compatibility and change-control planning.

Flashcards

1. Q: What is the difference between an Elastic Beanstalk application and an environment?

A: An application is a logical container; an environment is the running deployment and its underlying AWS resources.

1. Q: What is a web server environment used for?

A: Serving synchronous web or HTTP application requests.

1. Q: What is a worker environment used for?

A: Processing background tasks delivered through an SQS-backed queue.

1. Q: Which IAM identity does Elastic Beanstalk use to manage AWS resources?

A: Its service role.

1. Q: Which IAM identity supplies permissions to EC2 instances in the environment?

A: The EC2 instance profile.

1. Q: Why is a single-instance environment unsuitable for high availability?

A: It lacks instance redundancy and cannot tolerate failure of its only instance.

1. Q: What is the main disadvantage of an all-at-once deployment?

A: It can cause downtime or reduced availability while the application is replaced.

1. Q: Which deployment approach launches replacement capacity before switching versions?

A: Immutable deployment.

1. Q: Why should application changes not be made directly over SSH?

A: Instance replacement, scaling, or redeployment can discard those changes.

1. Q: Can Elastic Beanstalk instances be placed in private subnets?

A: Yes. A public load balancer can receive client traffic while instances remain private, with NAT or VPC endpoints used as required.

1. Q: What does managed platform updating automate?

A: Updating the Elastic Beanstalk platform version during a configured maintenance window.

1. Q: What is the purpose of a worker environment in a web architecture?

A: To move long-running or asynchronous processing away from the request-serving web tier.

Practice Questions

Question 1

A company has a web application that accepts image uploads. Image resizing can take several minutes, and the company wants web requests to return quickly. Which Elastic Beanstalk design is most appropriate?

A. Run all processing synchronously in a single web server environment
B. Use a web server environment that submits jobs to SQS and a worker environment that processes them
C. Deploy the application to a single EC2 instance and process images through SSH scripts
D. Use an immutable deployment policy for every image-processing request

Correct answer: B

The web tier should enqueue work and return quickly, while a worker environment consumes the queue and performs the long-running operation asynchronously.

Question 2

A production Elastic Beanstalk application must remain available if an EC2 instance fails or an Availability Zone becomes unavailable. Which configuration best addresses the requirement?

A. Single-instance environment with a larger EC2 instance
B. Single-instance environment with an Elastic IP address
C. Load-balanced environment with instances distributed across multiple Availability Zones
D. Worker environment with one instance and enhanced health reporting

Correct answer: C

Instance size and an Elastic IP do not provide instance redundancy. A load-balanced, multi-AZ environment provides multiple targets and supports replacement through Auto Scaling.

Question 3

An application running in Elastic Beanstalk must read objects from one S3 bucket. Which is the most appropriate way to grant access?

A. Store an IAM access key and secret key in the application source code
B. Attach a least-privilege policy to the EC2 instance profile
C. Make the S3 bucket public
D. Grant AdministratorAccess to the Elastic Beanstalk service role

Correct answer: B

The application instances should use an IAM instance profile with only the required S3 permissions. Long-term credentials and public bucket access create unnecessary security exposure.

Question 4

A company requires a deployment method that keeps the existing application version running while a complete replacement environment is prepared. It accepts additional temporary infrastructure cost in exchange for safer rollback. Which deployment policy should be selected?

A. All at once
B. Rolling
C. Immutable
D. Manual SSH deployment

Correct answer: C

Immutable deployment launches a separate replacement set, allowing the existing instances to remain available during provisioning and validation. It requires additional capacity during the deployment.

Question 5

An engineer manually edits configuration files on an EC2 instance managed by Elastic Beanstalk. The changes disappear after an Auto Scaling replacement. What is the best corrective action?

A. Disable Auto Scaling permanently
B. Use a larger instance type
C. Encode the configuration in the deployment process or Elastic Beanstalk configuration and redeploy
D. Allocate an Elastic IP to the instance

Correct answer: C

Elastic Beanstalk environments are managed and replaceable. Durable configuration should be versioned and applied through configuration files, environment settings, or an automated deployment pipeline—not changed manually on an instance.