AWS – Compute – Elastic Beanstalk

1. AWS Elastic Beanstalk

1. AWS Elastic Beanstalk: The “Managed” Powerhouse

Elastic Beanstalk is a Platform as a Service (PaaS) that automates the “heavy lifting” of infrastructure. It is the perfect balance between the simplicity of Heroku and the power of AWS.

1. The Workflow: You upload your code (ZIP, WAR, or Docker image) $\rightarrow$ EB provisions the environment (EC2, ALB, S3, CloudWatch) $\rightarrow$ Your app is live.
2. Key Platforms: Docker (Single/Multi-container via ECS), Node.js, Python, Java, .NET, Go, Ruby, and PHP.

Elastic Beanstalk gives speed, automation, and convenience, while keeping full control over AWS resources. and works with most popular languages and also supports single or multi-container Docker setups.

You bring the code; AWS handles the infrastructure.

1. Application can be: –
   • Docker Containers, Single and Multi-container using ECS.
   • NodeJS, Java, Dotnet, PHP, Ruby, Python and Go. etc.
   • On servers such as Apache, Nginx, Passenger and IIS.
2. Key Benefits: –
   • Fast deployment – upload ZIP/JAR/Docker image → app goes live.
   • Auto Scaling – scale up/down automatically based on load
   • Built-in load balancing and monitoring and health checks.
   • Full control – SSH into instances, change ASG/ALB settings.
   • Easy rollbacks
   • Cost-effective – EB is free, you pay only for EC2, ALB, etc.

DevSecOps Perspective: “Security by Design”

1. Identity & Access (IAM)
   • Least Privilege: Never use a default “FullAccess” role. Create a custom Instance Profile that only allows the EC2 instances to access the specific S3 buckets or DynamoDB tables they need.
   • Service Roles: Ensure the Elastic Beanstalk service role is restricted to managing only the resources in your specific environment.
2. Secrets Management
   • Don’t Hardcode: Use AWS Secrets Manager or Systems Manager (SSM) Parameter Store.
   • Automation: Use .ebextensions to fetch secrets during the deployment phase and set them as environment variables, ensuring your GitHub/Bitbucket repo never contains sensitive keys.
3. Shifting Security Left (CI/CD)
   • Vulnerability Scanning: Before the code reaches EB, integrate tools like Snyk or Trivy in your GitHub Actions or AWS CodeBuild. If a high-severity vulnerability is found in a library, the build should fail immediately.
   • Image Scanning: If using Docker, use Amazon ECR to scan images for vulnerabilities before Elastic Beanstalk pulls them.
4. Infrastructure Hardening
   • VPC Placement: Deploy your EC2 instances in private subnets and keep only the Load Balancer (ALB) in the public subnet.
   • Managed Updates: Enable Managed Platform Updates so AWS automatically patches your OS and runtime (Java/Python/Node) during maintenance windows.

Real-World Chalanges

While EB simplifies things, it introduces specific challenges that DevOps engineers face daily:

2. Architecture – How Elastic Beanstalk Works

Imagine you are building a Restaurant.

• The Building (EC2): This is where the cooking happens.
• The Security Guard (ALB): He stands at the gate, checks the customers, and directs them to the right table.
• The Extra Tables (Auto Scaling): If more customers come, the manager automatically adds more tables; if they leave, he removes them to save money.
• The Store Room (S3): Where all the recipes and old bills are kept.
• The External Accountant (RDS): He keeps the financial records safe in a separate, secure office so that even if the restaurant has a fire, the data is safe.

In EB, AWS gives you the whole setup automatically, but you must decide how high the security walls should be.

When you deploy, EB doesn’t just “create” resources; it orchestrates a complex ecosystem. Here is how to harden each piece:

2.1. The Compute Layer (EC2 & ASG)

• EB launches EC2 instances inside an Auto Scaling Group.
• DevSecOps Hardening: Private Subnets: Never put EC2 instances in a public subnet. Keep them in a Private Subnet and let the Load Balancer (in the public subnet) talk to them.
  • IMDSv2: Always enforce Instance Metadata Service Version 2. This prevents “SSRF” attacks where hackers try to steal your IAM role credentials.
  • Gold Images: Periodically use “Custom AMIs” that are pre-patched and scanned for vulnerabilities.

2.2. The Traffic Layer – Application Load Balancer

• Distributes traffic to healthy instances.
• DevSecOps Hardening:
  • WAF Integration: Attach an AWS WAF (Web Application Firewall) to your ALB to block SQL Injection and Cross-Site Scripting (XSS).
  • HTTPS Only: Use ACM (AWS Certificate Manager) to enforce SSL. Redirect all HTTP traffic (Port 80) to HTTPS (Port 443) automatically.

2.3. The Storage Layer – S3

• Stores your application versions and logs.
• Encryption at Rest: Ensure the S3 bucket created by EB has AES-256 encryption enabled.
• Public Access Block: Strictly enable “Block Public Access.” Your code should never be public.

2.4. The Data Layer – RDS

• Best Practice: Keep RDS outside of the EB Environment. If you delete your EB environment, the database is deleted too! Keeping it separate allows you to manage database security, patches, and backups independently of the application code.

DevSecOps Integration: “Security as Code”

To be a true DevSecOps professional, you don’t use the AWS Console for security settings. You use .ebextensions:

• Compliance: Use .config files inside the .ebextensions/ folder to automatically install security agents (like CloudWatch agent or antivirus) as soon as a new server starts.
• Automated Patching: Enable Managed Platform Updates. This ensures AWS automatically applies security patches to the OS (Linux/Windows) without you lifting a finger.

Architectural Challenges & Solutions

3. Elastic Beanstalk Environment Tiers

Think of your application like a Pizza Shop:

1. Web Tier (The Front Counter): This is where the customers come to order. The staff here must be fast and polite. If a customer asks for a “Monthly Financial Report” (a heavy task), the front counter staff doesn’t start doing math; they just write the request on a slip (SQS message) and move to the next customer.
   • Web Server Tier – Websites, REST APIs, Backend apps
   • Internet facing Load balancer
   • Default domain: – myapp.region.elasticbeanstalk.com
2. Worker Tier (The Kitchen): This is in the back. They don’t talk to customers. They just look at the slips, cook the pizza (process the task), and put it in the box.
   • Worker Tier – Backend jobs, Queue processing, Report generation, Email sending etc.
   • No load balancer, uses Amazon SQS to receive jobs,, cron jobs,

By separating them, even if the kitchen is super busy, the front counter can still take new orders!

1. Web Server Tier – The “Public” Face

1. Primary Job: Handles HTTP/HTTPS requests.
2. DevSecOps Tip (Network Isolation): Even though it is “public,” you should place these instances in a Private Subnet and only let the Load Balancer stay in the Public Subnet. This prevents hackers from directly attacking your servers via SSH or other ports.
3. WAF: Always attach AWS WAF to the Load Balancer of the Web Tier to block common web attacks like SQL injection.

2. Worker Tier – The “Private” Workhorse

1. Primary Job: Pulls tasks from an Amazon SQS queue and processes them.
2. Logic: A small program called the SQS Daemon runs on your EC2. it “reads” the queue and “POSTs” the data to your local app (usually at http://localhost/).
3. DevSecOps Tip (Queue Encryption): Always enable Server-Side Encryption (SSE) on your SQS queue using AWS KMS. This ensures that even if someone sees the data in the queue, it remains encrypted.
4. IAM Isolation: The Worker Tier needs an IAM role with sqs:ReceiveMessage and sqs:DeleteMessage. The Web Tier only needs sqs:SendMessage. Never give both tiers full SQS access.

DevSecOps: “Resilience & Monitoring”

1. Dead Letter Queues (DLQ): If a worker fails to process a message 3 times (maybe the code crashed?), SQS should move it to a DLQ. This is a DevSecOps “Detective” control it alerts you that something is wrong with your code logic without stopping the whole system.
2. Visibility Timeout: Ensure the SQS Visibility Timeout is longer than the time your code takes to process a task. If your code takes 2 minutes but the timeout is 30 seconds, another worker will pick up the same task, leading to “Double Processing” (a big security/logic risk).

Real-World Challenges

4. Deployment Strategies

How Elastic Beanstalk updates your application to a new version. and supports safe and flexible deployment methods; Immutable and Blue/Green are best for production.

1. All At Once
   • Deploys new version to all instances immediately
   • Fast but downtime occurs
   • Not recommended for Production
2. Rolling
   • Updates a few instances at a time
   • No downtime, but reduced capacity during update
   • Risk: mixed versions temporarily
3. Rolling With Additional Batch
   • Creates temporary extra instances
   • Maintains full capacity
   • More cost, no downtime
4. Immutable Deployment
   • Creates a brand-new Auto Scaling Group
   • Switches traffic after new version becomes healthy
   • Safest method, no downtime
   • Higher cost temporarily
5. Blue/Green Deployment (Not a built-in feature, but widely used)
   • Create a new environment (Green)
   • Test it
   • Swap CNAME between Blue (old) and Green (new)
   • Zero downtime, instant rollback
6. Traffic Splitting
   • Sends a small percentage of traffic to the new version
   • Used for Canary testing

DevSecOps Perspective

1. Blast Radius Reduction: DevSecOps is about minimizing the “Blast Radius” (how many users are affected if a bug goes live). Traffic Splitting and Blue/Green are the best here because you only expose a small group (Canary) to the new code.
2. Automated Rollbacks: In your .ebextensions, you should configure CloudWatch Alarms. If the “5xx Error Rate” increases by 1% during an Immutable deployment, EB should automatically abort and rollback before you even wake up!
3. Drift Detection: Immutable deployments are great for security because they kill old instances. If a hacker had gained access to an old server (Persistence), that server is destroyed and replaced with a “Clean” one during the deployment.

Real-World Challenges

5. Configuration as Code – .ebextensions

Imagine you are ordering a Customized Pizza.

• Standard EB: Is like a “Cheese Pizza” (Basic setup).
• .ebextensions: Is your Instruction Note to the chef. It says: “Add extra olives, bake it for exactly 10 minutes, use thin crust, and deliver it in a thermal bag.”

Whenever a new server (EC2) is born in your environment, EB reads these .config files and automatically installs your software, sets your security rules, and configures your “kitchen” exactly how you like it. No manual work needed!

.ebextensions/ lets you customize servers and environment settings using YAML or JSON.

5.1. Infrastructure Hardening – Security

You can use these files to ensure every EC2 instance is secure from the second it starts:

1. Security Agent Installation: Automatically install tools like Amazon Inspector or CloudWatch Agent for deep security monitoring.
2. Patching: Run yum update -y during the instance bootstrap phase to ensure the latest security patches are applied.
3. Disabling Weak Protocols: Configure the Load Balancer via code to disable old, insecure SSL versions (like TLS 1.0).

5.2. Compliance and Governance

1. Log Rotation: Create files in /etc/logrotate.d/ via .ebextensions to ensure logs don’t fill up the disk and are moved to S3 for auditing.
2. File Integrity: Use the files: section to create custom configuration files that restrict permissions (e.g., mode: "000400" for read-only sensitive configs).

5.3. Example

Here is how a “Guru” would write a config file to handle both app settings and security:

# .ebextensions/01_secure_config.config
packages:
  yum:
    amazon-cloudwatch-agent: [] # Install monitoring agent
    openssl: []                # Ensure latest OpenSSL

files:
  "/etc/config/my_app_security.txt":
    mode: "000400"  # Read-only for root
    owner: root
    group: root
    content: |
      SECURE_MODE=true
      AUDIT_LEVEL=high

option_settings:
  aws:elbv2:listener:443:
    Protocol: HTTPS
    SSLCertificateArns: "arn:aws:acm:region:account:certificate/id"
  aws:elasticbeanstalk:application:environment:
    DB_CONNECTION_TIMEOUT: "30"

Real-World Challenges

6. Monitoring & Health

Elastic Beanstalk includes strong monitoring features.

Enhanced health gives deep visibility into your app’s performance and helps troubleshoot quickly.

Basic Health: –

1. Green (OK)
2. Yellow (Degraded)
3. Red (Unhealthy)
4. Grey (Unknown)

Enhanced Health: –

Provides metrics from an agent running inside EC2: –

1. CPU, memory, disk
2. HTTP errors
3. Latency
4. Application logs

Health states include: –

1. OK
2. Warning
3. Degraded
4. Severe
5. Info
6. Pending
7. Suspended

Other Features: –

1. CloudWatch Logs integration
2. X-Ray support for tracing requests
3. Direct log download from console or CLI

6.1. Basic vs. Enhanced Health

1. Basic Health: Only looks at the Load Balancer level. If the server is responding, it’s “Green.”
2. Enhanced Health: It uses a Health Daemon inside each EC2 instance. It captures:
   • Application Metrics: Response times (latency) and 4xx/5xx error rates.
   • System Metrics: CPU, Memory, and Disk utilization.
   • OS-Level Health: If a specific process (like Nginx or Python) crashes, Enhanced Health catches it even if the EC2 instance is still “running.”

6.2. AWS X-Ray: Finding the “Ghost in the Machine”

• Trace Everything: X-Ray provides a “Service Map” of your application. In a DevSecOps world, this helps identify bottlenecks and security anomalies. For example, if your app suddenly starts making 1,000 requests to an external IP, X-Ray will show this visually.
• Troubleshooting: It helps you find exactly which database query or API call is making your app slow.

6.3. Centralized Logging – The Audit Trail

• CloudWatch Logs: Always enable Streaming of logs to CloudWatch.
• DevSecOps Benefit: Logs are your “Black Box.” If a hacker tries to breach your app, their attempts are recorded in the logs. By moving logs to CloudWatch, they are safe even if the hacker deletes the EC2 instance.

Real-World Challenges

7. Lifecycle Management

Elastic Beanstalk helps maintain clean environments.

automatically manages old versions, allows cloning, and lets you rebuild environments anytime.

1. Lifecycle Policy: Auto-delete old versions from S3
2. Clone Environment: Make a full copy (useful for staging)
3. Rebuild Environment: Refresh all servers with clean configuration
4. Configuration templates: Reuse settings across teams

7.1. Application Version Lifecycle Policy

1. The “Quota” Trap: AWS has a limit of 1,000 application versions per region. If you reach this, your CI/CD pipeline will suddenly Fail, and your developers will be stuck.
2. DevSecOps Strategy: Set a policy to keep only the last 25–50 versions.
3. Security Tip: Ensure that the S3 bucket storing these versions has Server-Side Encryption (SSE) enabled and “Public Access” blocked. Old code versions can contain sensitive logic; they must be protected even if they are “old.”

7.2. Cloning: The “Security Sandbox”

1. Creates a new environment with the same settings.
2. DevSecOps Tip: Use Cloning to perform Penetration Testing. Clone your production environment into a “Security” VPC, run your attack tools (like OWASP ZAP) against it, and then terminate it. This way, you find holes without affecting live users.

7.3. Rebuild vs. Drift

1. Configuration Drift: Over time, people might change a Security Group rule or an IAM permission manually in the console. This is “Drift.”
2. Periodically Rebuild your non-production environments. A rebuild forces Elastic Beanstalk to recreate every resource from scratch using your code. If the rebuild fails, it means you have “Drift” that needs to be fixed in your .ebextensions.

Real-World Challenges

8. Security Features

Integrates with IAM, VPC, SSL, and SGs to provide a secure application environment.

1. IAM roles for:
   • EC2 instance profile
   • EB service role
2. Supports VPC deployment
   • EC2 in private subnets
   • Load balancer in public subnet
3. HTTPS via ACM certificates
4. Security Groups for EC2 + ALB
5. Environment variables encryption

8.1. Identity & Access Management (IAM)

1. EC2 Instance Profile: This is the “Identity” of your server.
   • Never use the default AWSElasticBeanstalkWebTier. Create a custom role that follows Least Privilege. If your app doesn’t need to write to S3, remove that permission!
2. IMDSv2 (Enforced): By default, EC2 uses Instance Metadata Service v1, which is vulnerable to SSRF attacks. Enforce IMDSv2 in your EB configuration to require a session token for metadata access.

8.2. Virtual Private Cloud (VPC)

1. Putting everything in a Public Subnet is dangerous. so use
2. Private Subnets: Place your EC2 instances in a private subnet with no direct internet access.
3. Public Subnets: Only put the Application Load Balancer (ALB) here.
4. NAT Gateway: Use a NAT Gateway or VPC Endpoints for your instances to securely talk to other AWS services like S3 or DynamoDB.

8.3. HTTPS & Data Protection

1. SSL via ACM: Use AWS Certificate Manager for free, auto-renewing SSL certificates.
2. HSTS (HTTP Strict Transport Security): Use .ebextensions to add HSTS headers. This tells browsers: “Only talk to me over HTTPS, never plain HTTP.”
3. KMS Encryption: Ensure your environment variables and S3 logs are encrypted using AWS Key Management Service (KMS).

8.4. Security Groups (SGs)

1. Layered Defense: Create a “Chain.”
   • ALB SG: Allows traffic from the internet on port 443.
   • EC2 SG: Only allows traffic from the ALB SG. It should block everything else. This ensures nobody can bypass the load balancer to attack your servers directly.

DevSecOps Integrations

1. AWS WAF (Web Application Firewall): Attach WAF to your Beanstalk ALB. It acts as a “Smart Filter” to block hackers, bots, and SQL injection attacks before they reach your code.
2. Amazon Inspector: Run automated security assessments on your EB instances to find unintended network exposure or software vulnerabilities.
3. Secrets Manager: Stop using “Environment Properties” for passwords. Use AWS Secrets Manager to rotate your database passwords automatically every 30 days.

Real-World Challenges

9. Pricing

While EB has no direct cost, the “Hidden” costs of the resources it creates can surprise you if not managed with a DevSecOps mindset.

9.1. Compute (EC2) and the “Spot” Advantage

1. You pay for the hourly rate of the EC2 instance type you choose (e.g., $t3.medium$).
2. Spot Instances: For Dev and Staging environments, use EC2 Spot Instances. These can save you up to 90% on costs. Since DevSecOps encourages “Stateless” apps, your environment can handle a Spot instance being replaced without any drama.

9.2. Load Balancer – ALB / NLB

1. Cost Factor: You pay for the “Load Balancer Capacity Units” (LCU).
2. If your app is under a DDoS attack, your Load Balancer costs will skyrocket as it tries to handle millions of fake requests.
3. Use AWS WAF (Web Application Firewall). Although WAF costs money, it prevents the Load Balancer from processing “junk” traffic, often saving you more money in the long run.

9.3. Data Transfer

1. Moving data out of AWS to the internet or between different Regions costs money.
2. Keep your Elastic Beanstalk and your RDS database in the same Availability Zone whenever possible (for non-production) to avoid cross-zone data transfer fees.

9.4. Storage – S3 & EBS

1. S3: EB stores every version of your code as a ZIP file. If you deploy 10 times a day, you’ll have thousands of files soon.
2. EBS: Every EC2 has a “hard drive” (EBS volume). Even if you stop the instance, you still pay for the storage!

DevSecOps Strategy “FinOps” Integration

1. Tagging for Accountability: Use EB to “Tag” every resource with Project: Marketing or Environment: Production. This allows you to see exactly which team is spending the most money in the AWS Billing Dashboard.
2. Automated Shutdown: Use a “Cron Job” or a Lambda script to Terminate Dev/Test environments at 6:00 PM and Rebuild them at 9:00 AM. Since EB is PaaS, rebuilding is just one command (eb restore).

Real-World Pricing Challenges “Hidden” Costs

10. When to Use Elastic Beanstalk

Elastic Beanstalk is your “Fast Track” to the cloud. It is best for teams that have 10 developers and maybe only 1 DevOps person. You use it when your main goal is to ship features, not to spend weeks configuring Kubernetes clusters. It gives you the “Best of AWS” (Scaling, Security, Monitoring) by default, so you don’t have to be an expert to go live.

Best for: –

1. Small to medium apps
2. Teams who want simplicity
3. Fast deployment workflows
4. Docker apps
5. Background job processing (worker tier)

Not ideal for: –

1. Very large microservices
2. Highly customized networking
3. Full Infrastructure as Code (Terraform + ECS/EKS preferred)

1. Small Teams: If you are a startup or a small team in a big company, EB acts as your Automated DevOps Engineer.
2. Monolithic or Simple Microservices: If your app is a single “Node.js” or “Python” backend, EB is much faster to set up than ECS.
3. Rapid Prototyping (POCs): When you need to show a demo to a client by Monday, EB is the way. You can go from “Code on Laptop” to “Live URL” in 15 minutes.
4. Standard Docker Apps: If you have a simple Dockerfile, EB handles the deployment without needing to learn “Task Definitions” or “Pods.”

DevSecOps Perspective

1. Automated Patching: One of the biggest security risks is an outdated OS. EB has Managed Platform Updates that automatically apply security patches to Linux/Windows for you.
2. Standardized Security: It creates a “Repeatable” security pattern. Every time you deploy, the same Security Groups and IAM roles are applied, reducing the chance of “Human Error” (the #1 cause of data breaches).
3. Built-in Auditability: Because everything is managed by one service, your “Audit Trail” in AWS CloudTrail is much cleaner. You can see exactly when the environment was updated and by whom.

Real-World Challenges

Even though it’s “Easy,” Elastic Beanstalk has some “Vastav” (Real) challenges that can bite you later:

11. Elastic Beanstalk – Common Issues & Troubleshooting

1. Deployment & Configuration Issues

Issues where the application fails to launch or gets stuck during updates.

2. Runtime Health & Stability

Issues where the application is running but the environment health is poor.

3. Connectivity & Network Errors (5xx / SSL)

Issues related to the Load Balancer, Gateway, or Security.

4. Database & Worker Issues

Issues related to RDS connections or Background Workers (SQS).