Now I can set up my cloud infrastructure for each project. And when I forget about them, it will be easier to resurrect them again.

We Have DNS

My cheap ass didn’t want to pay another $15 to renew joshlillie.com for another year, especially since I have a track record of abandoning these sites/blogs a few weeks or even days after I get them fired back up. But my quest to get a serverless blog set up at least halfway correctly made a domain name necessary. There’s probably thousands of reasons not to run a website straight out of an S3 bucket or even with just the CloudFront domain name… but I’m not even going to bother with that discussion. Suffice to say that those names look like crap.

For my purposes, I stumbled upon a pretty sweet nugget. There is a domain called XYZ and GoDaddy offers domain names in this root domain for $1 a year. I did a little bit of research and couldn’t find a reason not to use one other than nobody uses them. Good for me! Seems like an untapped resource. I grabbled a few names and now we are off! The verification process in AWS Cert Manager was very easy. So now, joshlillie.com has moved to joshlillie.xyz. It’s really rather appropriate for an age where shitty reboots are all the rage.

So far this site has cost me $0.00, as opposed to the $50/month it was costing me to run an EC2 instance nonstop. Pretty saweeet. 🤘

I spent several hours on an AWS goose chase and have come to the conclusion that AWS has a faulty error. Some may feel that the fault is my own and that the problem should have been obvious, but even if this is true, it does not change the fact that AWS’s error, at the time of this writing, is wrong.

I ran into the problem while trying to accomplish a very simple task :

• Create an S3 Bucket
• Update policy on that bucket
• Create CloudFront Distribution linked to S3 bucket

There are two main ways to set up CloudFront origin with an S3 bucket: the S3 API and the S3 URL. There are a lot of tutorials that show how to set these types of configurations up. The latter method - setting CloudFront to point to the S3 website (not the API) - requires you to set the S3 bucket with a policy that looks something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13

{
    "Version": "2012-10-17",
    "Id": "Policy1522074684919",
    "Statement": [
        {
            "Sid": "Stmt1522074683215",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::blog.somewebsite.com/*"
        }
    ]
}

Now… if you are logged into the console as your root account, and you create a brand new S3 bucket and go straight to that bucket’s Permissions tab and enter in this policy, you will get the error you see above that reads : “You don’t have permissions to edit bucket policy. After you or your AWS administrator have updated your permissions to allow the s3:PutBucketPolicy action, choose Save changes. Learn more about Identity and access management in Amazon S3.” Now some of you are probably saying “NO, YOU MISSED A STEP”. And that is true. But it does not change the fact that this error is wrong.

The root user DOES have permission to update the policy. The s3:PutBucketPolicy action is not the issue at all in this case.

Creating serverless applications and websites with AWS can be very easy. I think the trickier parts, in my opinion, are weaving together all of the permissions and endpoints. You can create a static webpage super fast and easy with technically nothing but an S3 bucket. But this is very unsecure.

Amazon’s definition of CloudFront is “a fast content delivery network (CDN) service that securely delivers data, videos, applications, and APIs to customers globally with low latency, high transfer speeds, all within a developer-friendly environment.” This is what I put in front of the S3 buckets rather than simply leaving them open to the public. I’m still learning the finer points of how all this works.

More to come though… if I can master this I will have newfound super powers.

Ok… what to write about. A lot has changed since I last attempted this blog. It’s January 2021, and last year was considered by most to be the worst year in living memory. For me though, 2020 was a pretty good year.

But since it was such a shitty year for everyone else, I have to rethink what I will write about. The world has changed and the entire population has grown quite delicate and polarized and one must be careful what one broadcasts on the internet.

Will revisit this… soon.

I have very primitive markdown knowledge, and need to practive using it some (or a lot).

Let’s see if this one renders smaller.

=200x

Ok… that one didn’t seem to work.. how about we try embedding some HTML in our Markdown.

Let’s try…

1
2
3

<img src="/images/laquerhead.jpg" style="width:100px" >
<br>
<img src="/images/laquerhead.jpg" style="width:200px" >

How about a simple HTML Table?

How does it look?

What Comes Next?

Now that joshlillie.com has been reborn on Hexo, moved to GitHub, and is running serverlessly on AWS, I need to get some DNS set up. Then I can get Route53 set up and my site will be “real”.

Then what?

Time to start learning the ins and outs of Hexo and prattling out some thoughts I guess. I think it is also time to figure out how to add some media to this thing.

Is this thing on?

After a good bit of dickin around, I think I finally got Hexo deployed to my S3 bucket. I need to figure out how to properly lock this thing down meow. I should really get Terraform set up so I’m not fumbling thorugh the console as well.

TTFN

It begins again. Now we are experimenting with a blog platform called “Hexo”.

Let’s try to move this thing to AWS.