POSTHORN: AWS

Technology

... toward an automated future

Amazon Web Services is a cloud solution mainly geared toward enterprises, although some hobbyists may find some use with it. New accounts get a year free of some services, so if server administration or cloud architechure seems like something you'd like to try, don't be afraid to get some resources online! You can sign up for a free tier here.

Why cloud computing?

The main draw of cloud computing is cost. From a business standpoint, you are able to transform what was previously static capital (in the form of on-premisis servers and datacentres) into variable capital; meaning you pay for exactly what you use, not a penny more or less. Hardware repairs, HVAC, electricity (to power the computers, at least), and some labour costs are taken out of your hands and put into the hands of, in this case, Amazon.


From a hobbyist standpoint, the cost factor allows joe schmoes like you and me to have access to some enterprise / research grade computing to tinker with for a few hours a week, without having to shell out the cash for actual servers and networking equipment. Additionally, you don't have to make space in your living quarters to put a rack or large server chassis somewhere (even though having one on prem would be cool). After a while I'm sure the cost of buying on prem equipment is cheaper than the cost of cloud resources, but a year of free stuff is a great way to get familiar with it so you don't make a mistake and brick your own equipment.


Another draw of cloud computing is instantanous deployment. You can spin up a new server in a matter of minutes, whereas with an on prem solution that could take hours, days, or even months to get up and running. Immediate flexibility for uncertain workloads. Also, if you're inexperienced like me, you can deprovision / reprovision servers instantly when you screw up. I'll admit, I'm new to server administration so I screw up quite a bit still.




Operation POSTHORN

... to collect and distribute information on the web.

Goal

The goal of this Operation is to distribute information / methodologies / thought processes in a publicly available fashion in a centralized place.

Phases

Design website
Aunt says that most professionals use some sort of creation tool.
NOTE: Ended up making everything from scratch.
Register domain
Use AWS R53 for direct integration into cloud services.
Deploy to cloud
S3 buckets might be good enough, basically free but no server side scripting functionality.
Lambda functions for scripting?

Opt. Phases

Deploy email server
Handled via AWS SES
NOTE: After review, this is NOT what the SES is for.
Deploy FTP for scripts and programs?
NOTE: for both Opt. Phases an EC2 server must be provisioned.

AWS Route 53


Route 53 is Amazons DNS service. You can transfer domains to it, but I bought this one through the service. The domains appear in the "Hosted Zones" section of the side menu. Clicking on a domain allows you to view and create new records for it. The interesting thing is that you can set endpoints to not only ip addresses, but also services within AWS itself. For example, this website is hosted inside of an S3 bucket. When you access this webpage, the DNS reads your request and returns the name of the bucket on Amazon's side. Pretty handy!


Here's how I did it. NOTE: This method doesn't support SSL


  1. Register the domain through R53
  2. Create two S3 buckets; a Domain bucket with your domain as its name (this is what actually holds the data) and a www. subdomain bucket (this will point to your domain bucket)
  3. Upload your webpages to your Domain bucket.
  4. In the Properties tab, scroll down to Static Website Hosting and click Enable.
  5. Specify your index (homepage) file.
  6. In the Subdomain bucket, go to Properties, Static Website Hosting, then select Redirect requests for an object.
  7. Back in the R53 dashboard, go to your Hosted Zones submenu and select your recently registered / transfered domain.
  8. Click Create record, Simple routing, A record type, Alias to S3 website endpoint, then chose the region your root bucket is in and the bucket itself
  9. Repeat the previous step for your Subdomain bucket, this time adding "www" in the subdomain box.
  10. Once you've defined both records, test it to see if it worked.

Basically, you're offloading the work of defining the ips into the DNS and pointing it to something more readable. I'm sure there's some sort of NAT going on behind the scenes that allows this functionality, but that's past the demarc so out of my hands.