Say you want to host some files in an S3 bucket, under your own custom subdomain with nice short HTTPS URLs. For example, you own foo.com and you want files to be accessible at URLs like https://files.foo.com/bar.txt.

This is a lot more complex than it should be! It involves configuring 3 separate AWS services and I’m already forgetting the boring details, so let’s write them down for future reference.

Cloud is the future… wait, 3 separate AWS services?

YEP.

…

Creating the S3 bucket

Naming is important here - the S3 bucket must have the same name as the subdomain it will be accessed at. Open up S3 in the AWS console, and:

1. Create a new bucket named files.foo.com.
2. Disable “Block all public access”.
3. Under the bucket’s Permissions tab, add a bucket policy to make all objects public by default (replace files.foo.com with the name of your bucket):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AddPerm",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::files.foo.com/*"
        }
    ]
}

Certificate Creation+Config

Next up, we need to create a certificate in AWS Certificate Manager.

Hot Tip

Certificates must be created in the us-east-1 region to work properly with CloudFront. Learn from my mistake, make sure you’re in the right region when performing this step.

In my spare time I have been mucking around with 2 big Functions-as-a-Service (FaaS) offerings, AWS Lambda and Azure Functions. I’ve been meaning to write up a “The state of serverless development” post, but today Mike Roberts updated his overview of the market for serverless computing and it’s far more thorough than I could ever be.

The whole thing is well worth a read if you’re interested in the area, but these parts (emphasis mine) really resonated with me:

Serverless is not the correct approach for every problem, so be wary of anyone who says it will replace all of your existing architectures. Be careful if you take the plunge into Serverless systems now, especially in the FaaS realm. While there are riches — of scaling and saved deployment effort — to be plundered, there also be dragons — of debugging and monitoring — lurking right around the next corner.

Serverless services, and our understanding of how to use them, are today (May 2018) in the “slightly awkward teenage years” of maturity. There will be many advances in the field over the coming years, and it will be fascinating to see how Serverless fits into our architectural toolkit.

This is exactly right in my experience.

Lambda and Azure Functions let you write+deploy code quickly without an infrastructure team and an execution platform. However, the developer experience is often a big step backwards – Lambda doesn’t offer any remote debugging support, and just running+debugging functions locally is a big pain. Azure is further ahead in debugging, but things are still more complicated and less reliable than when debugging traditional apps. Integration testing is difficult on both platforms.

I’m a member of a nonprofit called Abundant Housing Vancouver, and as you can probably tell, I happen to do some programming too. In 2017 I was able to spend a lot of time combining these interests which was pretty great!

Over a few blog posts I’ll briefly outline the projects I worked on – they’re all open source and who knows, they might even be useful for other housing advocacy groups someday. First up: the Abundant Housing Vancouver Letter Builder.