It allows attackers or anyone to see more easily you are using Amazon EC2, but that can't be hidden either even if just having the IP address.
The problem often around doing:
internal-service.example.com. CNAME some-provider-managed-instance.example.
is what happens "later" and if you stop needing this service but you continue having this CNAME record that should have been removed but often isn't.
This is called Dangling DNS records (or "DARE" for some reason), and you can find all details at https://scholarworks.wm.edu/cgi/viewcontent.cgi?article=1829&context=aspubs for example.
It boils down though to just good stewardship of your zone, and removing any DNS records you don't need anymore, as soon as you don't need them anymore. Because whatever provider you use may not verify properly the ownership and hence, once you stop using the resource yourself, some other customer may find a way to claim that resource at the provider and then it gains "control" of part of your zone because YOU have a record in the zone pointing to something that is now controlled by someone else than you.
Same, in other cases, where you have your CNAME still existing while not needed but pointing to a name under a domain name that doesn't exist anymore: anyone would be able to register that name and then gain control of part of your namespace because of your record.
The problem is exactly the same if you don't have a CNAME but directly an A/AAAA record pointing to some externally controlled IP address. So by itself just using a CNAME does not expose to more risks, except the standard ones with CNAME (loops, too long chains, impossible to use at apex, etc.)
PS: if your colleague claims something, you might want to ask him more about it and some argumentation at least to be able to search on your side and make your own conclusions. It is difficult exactly (with so little details in your question) what exact threat vectors he was thinking about and hence why he thinks so.
