I have never struggled harder in my life than trying to get a very simple web API hosted on the cloud. When you try to implement something you have never used before, the task can be very daunting. Trying to figure out AWS is like walking through a corn maze, when you choose a direction you’re not totally sure it’s the right one. So, today I wanted to share some troubleshooting tips on Amazon Web Service’s Elastic Beanstalk environment to save you the struggle I had to go through trying to get things set up for my project.
VPC and Security Groups
Virtual private cloud. Security groups. Literally the bane of my existence. Let’s paint a story here. Pretend you’re hunkered down in a speakeasy in the 1920’s and you’re awaiting secret communication from your local congressman who resides at the town hall (because we all need an ice cold beer sometimes). Earlier, you had agreed with him that you would only accept a message if it came in a white envelope sealed with purple wax and three X marks on the bottom right corner. Oh, and this letter could only be delivered by his secretary Sally and she must say the password when she got there (“mustard”). The first letter gets there, but it only has TWO X marks and was delivered by Lucy (this must be the competing business trying to con you!). The next letter comes and it is just a plain white envelope with no wax seal delivered by George (must be the popo). Finally, Sally arrives with your white envelope with a purple wax seal, three X marks on the bottom right corner, gleefully shouting “mustard!”. Everything checks out and you let her in.
This is just how AWS operates. A virtual private cloud (VPC) is like the buildings containing the people (the speakeasy and the town hall). The VPC contains instances of your program (the people inside the building). The security groups are the rules established between the instances so they are allowed to communicate with each other (white envelope, purple wax seal, three X’s, Sally delivers the message, and mustard!). This is essentially how AWS establishes security between apps, only authorized machines are allowed to talk to the apps. So, when you have two apps that can’t communicate with each other, make sure they both have a common security group so they are allowed to communicate with each other (the security groups are configurable to define which communications are valid).
On the other hand, if your two apps are contained within the same VPC, then they will not need a security groups to communicate with each other (why would two people in the same room need a special form of communication if they can literally see each other).
Connection Strings
Another bane of my existence. If you ever want to talk with your database, you better make sure this is right! Hours of debugging led me to understand the nuances of connection strings and how they interoperate. In development (usually on your local machine), you should have a connection string to your local database. Then, when you are happy with that, use a production connection string when your application is running in a cloud environment that is pulled from a configuration file located in the file system (appsettings.production.json, web.config, etc.).
With production connection strings, you usually have two options. When you create a database instance within your Elastic Beanstalk environment, AWS will be nice enough to set environment variables for your program to pull from and build a connection string. If this doesn’t work (like it didn’t for me), you can manually build a connection string to put in your configuration file for your application to use. Just make sure to include your server name, username, password, and whatever else the database instance needs for connecting.
Logs
Troubleshooting a broken program is difficult in the cloud, you can’t just set breakpoints and edit your code on the spot when it is deployed in the cloud. The next best option would be to look at the logs and then relate that back to your local code to figure out what is going on. When you run into an error, download the last 100 lines of log from your Elastic Beanstalk instance and do a CTRL+F search for “error” or “exception” or some other error-type message. Just take the time to read through it and trace it back to your code to try and guestimate what is going on.
Conclusion
Luckily, AWS has a lot of documentation and there’s a lot of people online with the same problems as us. Use your Google-fu skills to accurately search and diagnose your problem and I know you’ll come out on top!
