What you need to know to get started with AWS

AWS is one of the most popular cloud computing services. AWS is short for Amazon Web Services and boy, they have lots of services.

Lots of application we use every day are hosted on AWS. They include Netflix, Airbnb, Slack to name a few.

Maybe you're working in a company that uses AWS and you want to know more about it. Or maybe you want to deploy your application to AWS. Or you’re just heard AWS somewhere and can’t get it out of your head. Anyways, here's what you'll need to know.

Servers

Your application, whether it’s your own or your it belongs to the company you work for, is probably running on a server. While you develop your application you're running it on your computer. But when you deploy the application you want to run it on someone else's computer.

AWS can offer that computer. It is called EC2 or Elastic Compute Cloud.

Also, if you’re into Data Science you can run your Jupyter notebooks there.

Database

Your application probably uses a database. PostgreSQL, MySQL, even Oracle, it doesn’t matter. What you need to know is that AWS has a service for databases and it's called RDS (Relational Database Service).

You could run your database on another EC2 instance like you’re running on your personal computer but RDS has lots of advantages. Here are a couple:

• Cost-efficiency
• Automatic software patching
• Easy scaling
• Automated backups
• Monitoring

You can get familiar with the full list of features here.

Deployment

But how do you deploy your application? Well, there are many ways to do that on AWS. But if you're just getting started I would recommend using EB (Elastic Beanstalk).

It allows you to easily:

• create environments with all configuration you need (EC2, RDS) and some that you maybe don’t even need at the start but it’s still good to have (load balancers, monitoring, notifications)
• deploy to that environment
• check logs and ssh to the server

EB supports deploying different platforms starting from Docker to Java to Ruby. You can check out the full list of supported platforms here.

If you've used Heroku in the past, EB is pretty similar to it. EB is pretty easy to set up compared to configuring each AWS service you need separately. But it is still not as easy as Heroku is.

If you would like to start deploying after you push a commit to git you can check out AWS CodeDeploy.

HTTP routing

Once your application is deployed you need to route your domain traffic to it. You can use Route53 to do that.

Although when you deploy with EB you can get a pretty decent domain like http://your-application.elasticbeanstalk.com/ it still has that feeling that it's not yours. You can buy a domain for your application directly on Route53. You can also delegate it to Route53 if you've bought it on another service like GoDaddy or NameCheap or whatever. You can use a dig console command to check whether your domain is migrated to AWS.

dig your-domain.com

Once you have your domain on AWS you need to add an A alias record to either

• the domain EB gave you ([your-application.elasticbeanstalk.com](http://your-application.elasticbeanstalk.com/))
• or your EC2’s Elastic IP
• or your load balancer DNS name

If the term "A record" does not sound familiar to you I recommend reading this article about DNS.

Handling more traffic

At some point, your application will probably gain some traffic and your one EC2 instance will not be able to handle all the incoming requests. ELBs (Elastic Load Balancers) are already on AWS to rescue you.

Load balancers are routing incoming traffic to different servers. They are doing this using the “round-robin” algorithm. Round-robin algorithm is very simple — when a request comes in load balancer sends it to one server, a second request goes into a second server. And when all the servers received a request, load balancer starts from the beginning and sends a request to the first one again.

Making it secure (HTTPS)

If you want to add HTTPS to your website you would need to get a certificate. You can get certificates in ACM (AWS Certificate Manager). Once you get them you need to use them, they won’t automatically apply themselves. You can add the certificate to your EC2 instance. Or if you’ve deployed using EB you should’ve gotten a load balancer. In that case, you can apply the certificate to the load balancer and you now can serve requests via HTTPS.

However, in this simple case, people could still visit your application over HTTP. But you can force them to use HTTPS by redirecting them if they came from HTTP. Previously, you would need to set up NGINX or Apache redirection. But in some recent time, AWS released Application Load Balancers and they include an option to redirect using some custom rules. You can read how to set up HTTPS redirection using Application Load Balancers here.

Storing files

You often need to save files in your application. But storing them in the database may not be the most efficient solution. AWS has a service called S3 which stands for Simple Storage Service. It does what the name suggests — it simply stores data. You can write there anything you can think of. It's like a Google Drive or iCloud.

To store files on S3 you can use AWS SDK for your language. You can also look for other libraries because I’m sure there are more.

Sending emails

Another thing most applications do is sending emails. Emails have lost of uses: newsletters, system notifications just to name a few.

To send emails with AWS you need to use SES (Simple Email Service). You could use your personal email or register a new one for your application and send emails from those emails. And that's a pretty good starting point.

However, in the long run, sending emails from a personal email address is not a good choice. A better way would be to get a domain and send emails from it. To do that you need to verify your domain in SES. And after that, you can send emails using AWS SDK which supports multiple programming languages. Or you can find a library on your own or ever create one.

Conclusion

In this article, I've talked about the most popular AWS services and why and how they are used. Now you should know that you should

• Run your servers on EC2
• Run your database on RDS
• Deploy to AWS using EB
• Manage your domains in Route53
• Get SSL certificates in ACM
• Handle more traffic with ELB
• Store files on S3
• Send emails with SES

Of course, this list is just the tip of the AWS services iceberg but it should be enough to get you started.

If you liked this article be sure to leave your comments down below and follow me.

Comments

[Alex Barashkov]

Good article Nikita! Had experience with AWS, Google Cloud and Digital Ocean. Personal feeling - you should use AWS only if you were forced to use it, otherwise pick something better. AWS is a monster, tons of functionality, but wrapped in the interface with totally not a user friendly manner. It was good many years ago, but not all competitors provide much better user experience than Amazon does.

AWS is the service you should definitely obtain the "certificate" to use it

[Nikita Kholin]

Thank you! I'm working in a company that uses AWS so I guess I was forced to use it :)
But I have to agree, it has a lot of functionality and not a great UX.

[K]

I guess it depends on what you want to do.

If you want to serverless/cloud-native, you only need a fraction of services.

If you wanna do old school back-end stuff, you need to learn a different and probably bigger set of services to accomodate all your legacy requirements.

[Yash Dusing]

Great article! Could you provide more resources and add info for any of the remaining applications that AWS has?

[Nikita Kholin]

Thank you! Yeah, there is a one resource I really like — AWS in Plain English. It does not go that much into details but you can get a general sense of what's in there in "plain English".