In this article we’ll navigate through the creation of a Nested Stack in Cloudformation using the Java SDK. The child stack will be a lambda function, and the code will be uploaded with a zip archive.

What’s Cloudformation, and what’s a nested stack?

Cloudformation is the AWS offering of infrastructure as code. Instead of navigating the web UI adding and configuring resources, Cloudformation offers the capability of reading a user - supplied file (either JSON or YAML) containing the list of resources and their relationships and create them as the code states.
These resources must be grouped in Stacks, which is the parentmost object that Cloudformation can process.
Things get interesting when stacks reference other stacks, of course :-)

I promise this is not yet another tutorial on how to publish a static website using AWS S3, or at least not solely smashing the S3 content onto the web. I’d like to show you a GitHub project that uses Java to orchestrate Cloudformation when deploying the architecture of a static website.

The main purpose of this tool is going beyond the S3 out of the box website functionality, that is:

• Make the S3 bucket private (so, secure)
• Provide HTTPS certificates (secure, again)
• Serve the content via cloudfront cache (so, fast)
• Hide the complexities of working with Cloudformation

I’m in for fast and secure, but free…ish?

Not all the resources that need to be fired up for this architecture are within the AWS free tier, expecially the domain. Nevertheless, all the costs that I’ve seen after this website was published were only live costs. Let’s review them from the most to the least expensive:

• The domain: 20€ / year if hosted on Route53 (as marcoaguzzi.it) but you can host it elsewere (on cloudns, and it’s free)
• Route53 and Codepipeline: 1€ / month each. It’s one for the hosted zone and one for the pipeline. The pipeline comes with a good amount of free build / minutes
• Secret manager: less than 0.5€ / month (there’s a grace period when started)
• Cloudfront and S3: 0.01€ / month each

Of course these are starting costs, they can go a lot higher as the usage increase, but it should be a welcomed issue, I suppose

Hide the complexities of Cloudformation

Cloudformation migth be a burden to use, especially within the web UI. These are the main issue I addressed in the project:

• Have a self - contained architecture
• Be repeatable. Could it deploy the same architecture on another domain?
• Ease the deploy process, especially when the domain is not hosted on Route53
• The nested stacks are not automatically resolved by Cloudformation

The Java tool to the rescue

While experimenting with Java and Gradle, I wondered if I could use Java to mitigate the problems listed above by orchestrating the instructions that Cloudformation needs in order to deploy the website. This turned out as a Github project: https://github.com/maguzzi/s3_static_website_gradle. The Gradle build creates a distributable archive with all the needed jars.

The use case

This post comes from the fact that the token used by Codepipeline to connect to Github to download the source code of the website has expired. Hence, the automation “push and update the website” is not working. Here’s the error:

Let’s view how the secret is stored into cloudformation, and how codepipeline can connect.

The secret stack

The cloudformation stack is quite easy. It does not have any hard dependency on other stacks, and it’s used both to download code for dev and prod website.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

{
    "AWSTemplateFormatVersion": "2010-09-09",
    "Parameters": {
        "GithubOAuthTokenParameter": {
            "Description": "Github OAuth Token",
            "NoEcho": "true",
            "Type": "String"
        }
    },
    "Resources": {
        "GithubOAuthToken": {
            "Properties": {
                "Name": "GithubOAuthToken",
                "SecretString": {
                    "Ref": "GithubOAuthTokenParameter"
                }
            },
            "Type": "AWS::SecretsManager::Secret"
        }
    }
}

The next part of the post is dedicated on how to create and use this cloudformation template

Last cloudfront issue

Finally the marcoaguzzi.it domain is actually responding without pointing to dev.marcoaguzzi.cloudns.ph. The last issue preventing the production cloudfront distribution from working was:

• The lambda@edge function that was linked to development distribution was at version 5, while its cloudformation output value was pointing to version 1
• The cloudformation stack deployed with production distribution read the output value and pointed to version 1, which wasn’t quite ready yet.
• Changing the lambda@edge link in production distribution from version 1 to version 5, ending the arn for the lambda with “:5” instead of “:1”, did the trick.

Fire up staging pipeline

Now that both domains have their own distribution responding, it was time to facilitate testing.

Summary

This website is build with Hexo, a static NodeJS blog framework. It allows a developer to define pages, posts, and all the elements using markdown format. Then the framework compiles them into static html, and the website is ready to be deployed on an accessible repository.