It's actually a bit complex, each has their own advantages the other lacks making it make sense for us to use both.
Fastly has insanely fast cache purging abilities which lets us purge stale content when a site is republished (or dynamic content modified with our new CMS features) instantly (in all ~30 locations throughout the world in less than 150 milliseconds)
Fastly also offers a number of other features we use for routing traffic that aws does not offer. However these are only critical for the initial page load and matter far less for the resources linked on the pages themselves - which is where we use cloudfront.
The reason we use cloudfront for assets as opposed to fastly are a bit more complicated - we could switch to using Fastly exclusively (and have discussed it internally at length) but it doesn't quite make sense at this time. The demands of a site's resources are slightly different than for the primary page requests (for example, "ugly" cloudfront url's are acceptable since they aren't visible to most users and are commonplace across the internet) and cloudfront is performing well for us as is, so the potential risks of switching that content is far outweighed by potential risks in doing so.