AWS Startups Blog

Launch Your App with the AWS Startup Kit

The AWS Startup Kit is a set of resources designed to accelerate startups’ product development on AWS. A core component of the Startup Kit is a set of well-architected sample workloads that can be launched within minutes. These workloads, which reflect best practices for reliability, networking, and security, are supported by AWS CloudFormation templates and code published on GitHub. They easily can be extended to create a wide variety of applications.

A previous Startup Kit blog post, Building a VPC with the AWS Startup Kit, described templates to create fundamental cloud infrastructure building blocks including an Amazon Virtual Private Cloud (VPC), a bastion host, and a relational database. This blog post presents a template that launches a sample app in AWS Elastic Beanstalk. All Startup Kit templates are available on GitHub at https://github.com/awslabs/startup-kit-templates. When the Elastic Beanstalk app template is used with the VPC, bastion, and database templates, together they create the following architecture:

app

Before you work with the templates, you should read the previous blog post and be familiar with basic VPC concepts. If not, please refer to the blog post referenced above and the VPC documentation.

To test out your VPC and database setup on AWS, or as a starting point for your own projects, you can deploy the Startup Kit Node.js sample workload using the Elastic Beanstalk app template. This Startup Kit sample workload is available on GitHub at https://github.com/awslabs/startup-kit-nodejs. However, it is not necessary to use a Startup Kit sample workload with the app template (for details, see the end of this post).*

Managing your app with Elastic Beanstalk

There are many different ways to deploy applications on AWS. One such deployment method is to use AWS Elastic Beanstalk, a complete application management service. Elastic Beanstalk supports many different technologies and stacks, including multi and single container Docker, Node.js, Ruby, Python, Java, Go, and .NET.  See the documentation for a complete list of supported platforms. For Dockerized applications, a fully managed alternative to Elastic Beanstalk is AWS Fargate.

Here are some of the benefits of using Elastic Beanstalk:

  • Automatically handles capacity provisioning, load balancing, and application health monitoring.
  • Automatically scales your application based on your application’s specific needs using easily adjustable Auto Scaling settings.
  • Keeps the underlying platform running your application up-to-date with the latest patches and updates.
  • Provides the freedom to select the AWS resources, such as an Amazon EC2 instance type, that are optimal for your application.

After you launch an app with the app template, you might find you need to adjust some of the Elastic Beanstalk configuration parameters provided by the template. For example, you might decide to increase the size of your Auto Scaling group to handle increased traffic as your user base grows. You can change these configuration parameters through the Elastic Beanstalk console. Simply go to the dashboard for your Elastic Beanstalk environment, and then click Configuration in the left pane. On the Configuration page, there are options to change parameters for scaling, instance type, environment variables, and more.

Other Startup Kit resources

We plan to expand the Startup Kit in the near future with additional resources. Here’s a list of some of the resources that have been published so far:

Stay tuned for the next Startup Kit release!

 

Special thanks to Itzik Paz for providing the architecture diagram at the top of this post

 

* How to integrate an app other than a Startup Kit sample workload:  If you want to launch your own app with the app template, your app should be based on one of the technologies currently supported by the template, such as Node.js, Ruby on Rails, and Java (Spring Boot). Also, database parameters are managed by environment variables in the app template, so your app’s database parameters should conform to the naming conventions in the template. Alternatively, you can fork the GitHub repository and modify the app template’s environment variables section to change the names as needed. Instructions for writing and modifying CloudFormation templates are beyond the scope of this post, but the app template has been written to clearly identify the relevant sections and to be as self-explanatory as possible. The CloudFormation documentation is comprehensive in case you need further guidance. If you’re not using Spring, you can delete the Spring environment variables section; likewise, if you’re using Spring, you can delete the environment variables section for Node.js and Rails.