A week ago, I decided to implement a cloudfront dirstribution for a static web hosting s3 bucket when setting up a CI/CD pipeline with Buddy. When changing this, I made sure to change my A and AAAA records in route 53 for my site, eckmantek.com, from their default to my distribution, which is d22tb0q1u7k32l.cloudfront.net. With this set up, I began using my pipeline, but I found that the domain kept serving my old version of the site, before I implemented cloudfront.
At first I thought it was just a matter of waiting for the dns to refresh, but it's been a week now.
When I manually check my s3 bucket, I see the latest build there, and if I navigate to the distribution directly, I can see the updated site as well. It's almost like the domain is being routed to a ghost bucket, like a hidden cache or something. Any help is welcome!
Not really a programming problem, but I'll give it a shot. My DNS lookup tells me that both your main domain eckmantek.com as well as d22tb0q1u7k32l.cloudfront.net return the same A-records, which is a good sign.
$ dig A eckmantek.com
; <<>> DiG 9.16.1-Ubuntu <<>> A eckmantek.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3984
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;eckmantek.com. IN A
;; ANSWER SECTION:
eckmantek.com. 60 IN A 18.66.2.121
eckmantek.com. 60 IN A 18.66.2.15
eckmantek.com. 60 IN A 18.66.2.17
eckmantek.com. 60 IN A 18.66.2.8
$ dig A d22tb0q1u7k32l.cloudfront.net
; <<>> DiG 9.16.1-Ubuntu <<>> A d22tb0q1u7k32l.cloudfront.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23164
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;d22tb0q1u7k32l.cloudfront.net. IN A
;; ANSWER SECTION:
d22tb0q1u7k32l.cloudfront.net. 60 IN A 18.66.2.121
d22tb0q1u7k32l.cloudfront.net. 60 IN A 18.66.2.15
d22tb0q1u7k32l.cloudfront.net. 60 IN A 18.66.2.8
d22tb0q1u7k32l.cloudfront.net. 60 IN A 18.66.2.17
That means traffic gets to CloudFront. Assuming that you've configured CloudFront correctly to use the S3 bucket as the origin, the problem may be that CloudFront caches the old site and the TTL is too long.
You can explicitly clear the cache in CloudFront using invalidations, but you have to pay for that.
Once you have done that, make sure to set a reasonable TTL.
If we check out the headers from your website, we can also see that caching seems to be disabled and the content hasn't been updated in a while:
$ curl -sD - https://eckmantek.com -o /dev/null
HTTP/2 200
content-type: text/html
content-length: 2051
last-modified: Fri, 22 Nov 2019 11:17:48 GMT
accept-ranges: bytes
server: AmazonS3
via: 1.1 a06e85a5c7853d2f85565a048a9d2609.cloudfront.net (CloudFront), 1.1 99d54fc6a14abf3079ffadd5aa7c99de.cloudfront.net (CloudFront)
x-amz-cf-pop: YTO50-C3
date: Wed, 17 Nov 2021 11:19:18 GMT
cache-control: public, must-revalidate, max-age=0
etag: "e8179ec55581b2082badf57315b368b8"
vary: Accept-Encoding
x-cache: RefreshHit from cloudfront
x-amz-cf-pop: TXL50-P1
x-amz-cf-id: ZlWuOHfa-TjS1tzL74oXFnRHaCfyPm118OhO5gOm6pXFIfOI1LdDeQ==
It's served from S3, but maybe you should check if it's using the correct S3 bucket.
As an aside: You should use an ALIAS-record or a CNAME record to point your domain to CloudFront, because the CloudFront IPs may change.