- BeanStalk supports almost all programming languages. If your language is incompatible with Beanstalk & doesn't use Docker then you can create your own custom platform.
- You will need to create your own platform using Packer (open source tool to create AMIs).
If the question mentions Packer then go for custom platform.
- We have a CLI specific to BeanStalk known as EB CLI. It can be helpful to automate the deployments.
- It helps us increase our efficiency when compared to the normal AWS CLI.
- You can run cron jobs in EB by defining a
cron.yamlfile and using the Worker Environment
All the source bundles (code zip files for deployment) are stored in S3.
We cannot configure Amazon Athena, AWS Lambda, and Amazon CloudFront on ElasticBeanstalk.
We can configure EC2, Load Balancers and CloudWatch.
- Application: An Elastic Beanstalk application is a logical collection of Elastic Beanstalk components, including environments, versions, and environment configurations. In Elastic Beanstalk an application is conceptually similar to a folder.
- Application Version: an iteration of your application code
- Collection of AWS resources running an application version (only one application version at a time)
- Tiers: Web Server Environment Tier & Worker Environment Tier
- You can create multiple environments (dev, test, prod, etc) in one application version.
- If you want multiple application versions running at the same time then you have to create multiple applications.
- Elastic Beanstalk can store at most 1000 application versions
- If you don't remove old versions, you won't be able to deploy anymore
To phase out old application versions, use a lifecycle policy
- Based on time (old versions are removed)
- Based on number of versions (when you have too many versions)
Versions that are currently used won't be deleted.
- Option not to delete the source bundle in S3 to prevent data loss. If the source bundle is present we can very easily restore a particular version.
- A zip file containing our code is deployed to Elastic Beanstalk for new environments.
- All the parameters set in the UI can be configured with code using files.
- In the
.ebextensions/directory in the root of source code
- YAML / JSON format
- Even though they are in YAML/JSON the file must with
.configextension (example: logging.config)
- In the
- We can modify some default settings using:
- Ability to add any resource such as RDS, ElastiCache, DynamoDB, etc which cannot be added using the UI.
Although it is not advised to create RDS using EB, you can create ElastiCache clusters using EB.
We can use
.ebextensions to provision any resource since ElasticBeanstalk uses CloudFormation under the hood.
- Resources managed by
.ebextensionsget deleted if the environment goes away
- We can clone an environment with the exact same configuration
- Useful for deploying a test version of your application
- All resources and configuration are preserved:
- Load Balancer type and configuration. So it cannot be used for changing the load balancer type.
- RDS database type (but the data is not preserved)
- Environment variables
- After cloning an environment, you can change settings.
Changing Load Balancer¶
- After creating an Elastic Beanstalk environment, you cannot change the Elastic Load Balancer type (only the configuration)
- If we want to change the Load Balancer type then we have to perform migration.
- To migrate:
- Create a new environment with the same configuration except LB (can't clone)
- Deploy your application onto the new environment
- Perform a CNAME swap or Route 53 update
- RDS can be provisioned with Beanstalk, which is great for dev/test
- This is not great for prod as the database lifecycle is tied to the Beanstalk environment lifecycle
- The best for prod is to separately create an RDS database and provide your EB application with the connection string.
- Decoupling RDS:
- Create a snapshot of RDS DB (as a safeguard)
- Go to the RDS console and protect the RDS database from deletion
- Create a new Elastic Beanstalk environment, without RDS, point your application (in the new EB) to existing RDS
- Perform a CAME swap (blue/green) or Route 53 update, confirm working
- Terminate the old environment (RDS won't be deleted since we have a delete protection)
- The CloudFormation stack won't be deleted since the RDS was protected from delete.
- Delete CloudFormation stack (in DELETE_FAILED state)
One AWS account to another¶
- The project manager of a team wants to migrate the Elastic Beanstalk environment from Team A's AWS account into Team B's AWS account.
- Create a saved configuration in Team A's account and download it to your local machine.
- Make the account-specific parameter changes and upload to the S3 bucket in Team B's account.
- From Elastic Beanstalk console, create an application from Saved Configurations
- You must use saved configurations to migrate an Elastic Beanstalk environment between AWS accounts.
- There is no direct Export and Import option for migrating Elastic Beanstalk configurations.
Beanstalk with HTTPS¶
- Idea: Load the SSL certificate onto the Load Balancer
- Can be done from the Console (EB console, load balancer configuration)
- Can be done from the code:
- SSL Certificate can be provisioned using ACM (AWS Certificate Manager) or CLI
- Must configure a security group rule to allow incoming port 443 (HTTPS port)
Redirect HTTP to HTTPS¶
- Configure your instances to redirect HTTP to HTTPS:
- OR configure the Application Load Balancer (ALB only) with a rule
- Make sure health checks are not redirected (so they keep giving 200 OK)
Last updated: 2022-06-10