I don't know if I have a whole lot more to contribute, but I'll see what I can do.
Amazon Linux (1) is roughly the same as Red Hat/CentOS 6.
Amazon Linux 2 is roughly the same as Red Hat/CentOS 7.
The Red Hat philosophy (also used by "clones" like Amazon Linux), as best as I can tell, is that as an "enterprise" system stability is more important than features. Security patches are backported, but that's about it. (And they don't update the "main" version number generally, so it can be a bit of effort to track down exactly which patches are installed.) I think the idea is that if you want new features, you can upgrade to a newer version of the OS, and do so in a controlled tested manner (as one would update your dev/test environments first, and so forth), and "patching" should be as minimally-invasive as possible because any change has a chance to be incompatible with what you're running on the server.
Amazon Linux 2 offers a bit more flexibility in that they offer an "extras library" of more up-to-date things you can install, but of course when you update more often you're trading off getting less stability.
For openssl specifically, they do now have an "openssl11" package for Amazon Linux 2 (in the "normal" repo, not the "extras") which will install the library and binaries. You could then run "openssl11" instead of "openssl" to run the updated version. But nothing "built-in" links to it, so my understanding is that if you wanted to use nginx or apache or whatnot you'd have you recompile it against the openssl11 library yourself. (So for instance, for my personal mail server, I compile dovecot & postfix from sources against it.)
Extended (paid) support for Openssl 1.0.2 is still available, and my understanding is that Amazon (and/or Red Hat/CentOS) get such support and still backport security patches. So, for instance, you'll see openssl (and openssl11) patches in Amazon's Security Advisory list.
For Amazon Linux 2, in the "Long Term Support" section of the FAQ, they say that they will provide "security updates and bug fixes for all packages in core until June 30, 2023."
For Amazon Linux 1, while it's "end-of-life" their statement says that they have a reduced set of packages that they'll be supporting until June 30, 2023, including "Low-level system libraries such as glibc and openssl."
So I think anyone using Amazon Linux's openssl is "secure" in the sense of getting security patches (at least for the next year-and-three-quarters), but there doesn't look to be any easy way to get "system" packages using openssl 1.1.1, there's just a way to have the openssl11 library and binaries installed.
I had been assuming for quite some time that at some point, Amazon might release an "Amazon Linux 3" based on Red Hat / CentOS 8 (or some future version), especially as their OS that specifically is called out as having "Long Term Support" now only has less than two years left in promised support. But I haven't seen any such announcement or roadmap (though it may be out there, I've not spent much effort looking for it). And there's been a lot of turmoil in the Red Hat / CentOS world this year, so perhaps Amazon is planning something else entirely.
In the meantime, if sticking with Amazon Linux one needs to deal with having only OpenSSL 1.0.2 available. OpenSSL has announced that they are working on version 1.0.2zb that "will make it possible to build the release with added
-DOPENSSL_TRUSTED_FIRST_DEFAULT on the build configuration command line. That will make the
-trusted_first option enabled by default by the OpenSSL library." So, when they release that, if Amazon (or Red Hat / CentOS, I don't know where the decision would originate) decides to backport that fix, then the version used on Amazon Linux would have that "trusted first" logic that allows for more easily connecting to servers with the "default" chain rooted in DST Root CA X3. That's a big "if" there, as I don't know if the change would fit the "security patch" criteria they use to decide to backport patches, and in any event won't help for the immediate future.
So in the meantime, you'll have to find another workaround. Let's Encrypt made an intentional choice to prioritize old-Android compatibility over old-openssl compatibility when deciding what would be the default chain, and perhaps if they had decided the other way around just as many people would be just as unhappy (though it may have just been a different set of people).