Create a sub-domain using Amazon AWS vs Creating the sub-domain from within the server - What's the difference?

Question

I have an instance on Amazon AWS (Ubuntu server).

I want to create a sub-domain for my website: tools.example.com for people in the office I work in, and build tools (using PHP) so employees can work with. (code automation web-apps for ex).

I have never created a sub-domain on a Linux server myself (I usually worked with hosting companies with cPanel ect'), and I'm new to Amazon AWS, which I find very awesome, and working with a Linux server and doing everything by myself - Extremely awesome!

So I was starting to explore how to create a sub-domain on my website, and I got to a point that I know that I have 2 options, which I don't exactly know what are the differences between them, what will be the implications on my work ect'.

The first option is creating the sub-domain using Amazon Route53: http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html

and the second option I encountered was doing this using the Ubuntu server itself, ex: https://askubuntu.com/questions/463618/setting-up-subdomain-on-ubuntu-server http://kim.sg/index.php/ubuntu/17-how-to-setup-subdomain-on-ubuntu-server-14-04

Some things seem vague for me a little bit and I will be happy to have more enlightenment points from people who know a little bit more about the theoretic "stuff" and will know to guide me to the best choice for me.

Please feel free to ask me questions.

for @Stefano Martins (28.10.2015):

Ok, I did this:

<VirtualHost *:80>
    ServerName tools.example.com
    ServerAdmin walid@example.com

    ErrorLog /var/www/tools.example.com/logs/error.log
    CustomLog /var/www/tools.example.com/logs/access.log combined
    DocumentRoot /var/www/tools.example.com/public_html
</VirtualHost>

mkdir -p /var/www/tools.example.com/{public_html,logs}

sudo a2ensite tools.example.com.conf
sudo service apache2 reload
sudo find /var/www/tools.example.com/public_html -type d -exec chmod 755 {} \;
sudo find /var/www/tools.example.com/public_html -type f -exec chmod 644 {} \;
sudo adduser ubuntu www-data
sudo find /var/www/tools.example.com/public_html -type d -exec chmod 775 {} \;
sudo find /var/www/tools.example.com/public_html -type f -exec chmod 664 {} \;

My folder is the var one, not the srv. I changed everything from srv to var and now I don't get the 403 error anymore. but now I cant upload to /var/www/tools.example.com/public_html via FTP.

UPDATE: I used sudo chown www-data:www-data -R /var/www/ that solved my problem.

Thanks A LOT!

Answer 1

That's the thing with Amazon Web Services. You have a lot of options to construct your infrastructure, beginning with the simple EBS (Elastic Beanstalk) which provides an easy-to-deploy (a.k.a. quick-and-dirty way) environment.

Another option is to use EC2 and build it yourself, and since this is the way you've chosen so far, basically what you need is:

In your Route 53, create a CNAME or an A record pointing to your instance's IP address (you should use Elastic IPs to make sure your instance always get the same IP address). I would suggest a CNAME entry because you already has an A record in your zone. It makes your DNS resolution a little bit slower, but it's easier to manager through time. We can call that tools.example.com.

In your Apache configuration's directory (usually /etc/apache2/sites-available), create a file called tools.example.com.conf with the following content:

<VirtualHost *:80>
    ServerName tools.example.com
    ServerAdmin me@example.com

    ErrorLog /srv/www/tools.example.com/logs/error.log
    CustomLog /srv/www/tools.example.com/logs/access.log combined
    DocumentRoot /srv/www/tools.example.com/public_html
</VirtualHost>

Create the directory which will store your site/application with:

mkdir -p /srv/www/tools.example.com/{public_html,logs}

Enable the new virtualhost and reload Apache's service:

sudo a2ensite tools.example.com.conf
sudo service apache2 reload

A tip: in most cases, using AWS infrastructure and out-of-the-box solutions is cheaper.

Note: Basically, this is what you need, but this is not 100% ideal for a production environment.

Cya!

Answer 2

You need two things for your subdomain to work properly.

1. A DNS Record in a DNS Server. This Records should be created on the name servers that you have set up on your naked domain (yourdomain.tld). If you are already using Amazon Route53 for your naked domain that's fine you can also use it for your subdomain (Amazon Route53 is just a dns hosting service)

2. A virtual host in a web server.