Elastic Beanstalk

Developer Associate

  • Service for deploying and scaling web apps developed in many popular languages
  • Developers can focus on writing code and not underlying infrastructure to run that code
  • A provisioning service basically
  • You use the GUI to provision an environment with Elastic Beanstalk, unlike CloudFormation which is YAML/JSON based
  • You upload the code, Elastic Beanstalk handles deployment, capacity provisioning, load balancing, auto-scaling and application health
  • Definitely the fastest and simplest way to deploy your apps in AWS
  • You retrain full administrative control over the EC2 instances, or you can have Elastic Beanstalk do it for you
  • Elastic Beanstalk is technically a Compute service…
  • You can customize your Elastic Beanstalk environment using a config file
    • Written in YAML and JSON
    • Can be named whatever you want, but it must end with .config and be saved inside the folder .ebextensions
    • This folder must be at the top level directory structure of your application source code bundle
  • You can specify instance types for EC2 instances created by Elastic Beanstalk using either the Launch Configuration or the Environment manifest file

Updating Elastic Beanstalk (know this for the exam!!)

  • Elastic Beanstalk supports several options to update your deployment
  • All at once
    • Deploys the new version to all instances simultaneously
    • All instances are out of service while deployment takes place
    • You will experience an outage during deployment
    • If the update fails, you’ll need to roll back the changes by re-deploying the changes to your original instances
  • Rolling
    • Deploys the new version in batches
    • Each batch is taken out of service while deployment takes place
    • You environment capacity will be reduced by the number of instances in a batch during the update
    • Not ideal for performance sensitive systems
    • If the update fails, you will need to perform an additional rolling update to roll back the changes
  • Rolling with Additional Batch
    • Launches an additional batch of instances
    • Deploys the new version in the new batches
    • Maintains full capacity during deployment process
    • If the update fails, you need to perform an additional rolling update to roll back the changes
  • Immutable Deployment Policy
    • Deploys new version to a fresh group of instances in their own new autoscaling group
    • When instances pass health checkes, they are moved to the existing auto-scaling group and old instances are terminated
    • Maintains full capacity during deployment process
    • The impact of a failed update is far less, and the rollback process requires only terminating the new autoscaling group
    • This is the preferred option for mission critical production systems

RDS with Elastic Beanstalk

  • You can launch an RDS instance from within Elastic Beanstalk, which is fine for dev/test
  • However, not ideal for production because it means the lifecycle of your database is tied tto the lifecycle of your application environment. If you terminate the environment, you lose the database
  • For production environments, its preferred to decouple RDS from Elastic Beanstalk, i.e. just launch it directly from RDS
    • To do this, you need to create an additional security group to your app’s autoscaling group
    • You will need ot provide the connection string configuration to your app servers
< Previous: EC2 Next: Elastic Load Balancer >