Feature: AWS cloud infrastructure 🚀

[chriswilty]

Description

And here it is! Cloud infra has sat on this feature branch for a while now, but I finally got around to adding a pipeline for automatic deployment of the production app on merging to main.

Note that there are likely some minor tasks still to come, but the pipeline was deployed and tested as an independent "dev" application, which was available at dev.spylogic.ai, and I verified it did not interfere with any existing prod resources.

Resolves #920

Screenshots

Best I can do right now is to show the CloudFormation stacks for our prod deployment:

Notes

After merging to main, I will need to manually deploy the prod pipeline to our AWS account, after which, the pipeline will self-update and deploy all application resources on subsequent merges to main branch.

Concerns

The stack constructs are not unit tested, so there is a chance that untested changes to the CDK application stacks could cause the pipeline to break. For this reason, it is advised to test any stack changes by synthesizing locally and then deploying the application stacks without the pipeline (and then destroying them after testing). I have added info to the README about this, plus some extra package scripts to help with these tasks.

Checklist

Have you done the following?

• Linked the relevant Issue
• Added tests Tested deployment of stacks manually and through pipeline
• Ensured the workflow steps are passing

[chriswilty]

@pmarsh-scottlogic, @dhinrichs-scottlogic, @gsproston-scottlogic, @heatherlogan-scottlogic, @kclark-scottlogic, @AAloshine-scottlogic

This one may or may not be interesting to you! It's the culmination of the cloud infrastructure work resulting in our spylogic.ai application deployed in AWS. Once this is merged into main branch and the pipeline deployed to AWS, all future merges to main will trigger the pipeline to deploy the updated application.

There were some shenanigans around authorization, so I might even give a quick presentation to the Cloud COP if I have time.

[chriswilty]

@kscott-scottlogic FYI

[kscott-scottlogic]

I'm not sure but you might be able to use the openListener property on the ApplicationLoadBalancedFargateService construct to make its listener private. Also not sure how configurable that listener would be.
But the approach below works as well.

[chriswilty]

Yeah that didn't work nicely for me... One problem is around the Security Groups that construct generates, but additionally it creates a default rule on the listener that you cannot remove, and we want our default rule to deny access. So, I needed to do things the hard way 🙄

[kscott-scottlogic]

The api, auth and ui stack look good to me. Just a couple of minor comments, but I don't see anything that needs changing.

[chriswilty]

The api, auth and ui stack look good to me. Just a couple of minor comments, but I don't see anything that needs changing.

Thanks! I would like to add some extra rate-limiting protections, but that will add extra costs so it's on the back burner for now. I was hoping to be able to reduce costs by removing the NAT Instance in favour of an IPv6 egress gateway for our container, but it turns out api.openai.com does not have an IPv6 address yet so that's a no-go 🤬

[chriswilty]

Update: 13/09/2024

I've narrowed down the permissions for CloudFormation now, so that the pipeline no longer runs with full AdministratorAccess. I've created a set of IAM managed policies: see cloud/permissions/README.md