S3 TLS deprecation on June 28th - Need help

It's not clear to me exactly how your bucket is being accessed by clients, but if its inbuilt static website hosting is used then it connects via http so need to include that alternate condition statement shown in https://repost.aws/knowledge-center/s3-enforce-modern-tls:

"Condition": {
        "Bool": {
            "aws:SecureTransport": "true"
        },
        "NumericLessThan": {
          "s3:TlsVersion": 1.2
        }
      }

In other words, insert that into the main policy provided so you end up with:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceTLSv12orHigher",
      "Principal": {
        "AWS": "*"
      },
      "Action": ["s3:*"],
      "Effect": "Deny",
      "Resource": [
        "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
        "arn:aws:s3:::DOC-EXAMPLE-BUCKET"
      ],
      "Condition": {
        "Bool": {
            "aws:SecureTransport": "true"
        },
        "NumericLessThan": {
          "s3:TlsVersion": 1.2
        }
      }
    }
  ]
}

And change the EXAMPLE lines of course.

However a better approach is to front-end your bucket with CloudFront which can then use a secure connection to the bucket, and allow secure connections by clients to CloudFront. Doing away with http protects your users from main-in-the-middle attacks. Your CloudFront distribution can allow pre-TLS1.2 if needed but this should be avoided. See https://repost.aws/knowledge-center/s3-access-old-tls for example.

Note also that the "enforce 1.2" changes you're doing only apply if your bucket is being accessed over https (so not just via the inbuilt static website). And they don't need to be done before the deprecation date - they are in effect bringing that date forward, making TLS <1.2 break now instead of later. That can be a good thing to give you advance warning of what will break, you can then roll back while you fix what's broken.