Secure snapshots S3 bucket behind CloudFront

[Mr0grog]

Since requests directly to S3 buckets can get expensive quickly, we should put our “data snapshots” S3 bucket behind CloudFront and disable public access. (This recommendation from @TylerHendrickson’s very helpful review of our AWS configuraiton.)

• Make writes to S3 atomic. Since writes can be slow (e.g. each availability_log file takes just under 20 minutes to write), there’s a reasonable concern that CloudFront could cache a partially written file. Write to a key with a prefix, then move the data to a key without the prefix (e.g. write to /in_progress/availability_log/availability_log-2022-12-12.ndjson.gz, then move to /availability_log/availability_log-2022-12-12.ndjson.gz). See https://github.com/usdigitalresponse/univaf/blob/main/server/scripts/availability_dump.js (Update: it turns out streamed, multipart uploads are already atomic, so we don’t have to do anything here.)

• Add a CloudFront distribution that reads from the bucket. It’ll need a domain name, so we should probably use archives.getmyvax.org or snapshots.getmyvax.org.

• Update code for loading data in https://github.com/usdigitalresponse/appointment-data-insights. (PR: Download UNIVAF data from new public URL appointment-data-insights#4)

• Make the bucket itself private instead of public.

[Mr0grog]

TIL multipart uploads to S3 are atomic — it doesn’t assemble the pieces into a GETable object until all parts are uploaded (see https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html). Single operation PUTs are also atomic (see https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html#ConsistencyModel)

So we actually don’t need to worry about item 1 (make writes atomic)!