There's a lot of bad info so far in the comments, and hopefully you're reading up on IAM documentation yourself so you can understand the implications of your options.

First, SCPs are not intended to be used as a granular control. They apply to all users and roles in the account they're attached to. They also override IAM policies and roles. This means that creating an SCP that denies the ability to create ec2 instances would prevent even a user with FullAdmin from creating one.

Second, as others have suggested, you could simply limit the ability to create a change infrastructure to a service account that's used by your CI/CD pipeline. There's some caveats though:

• You'll want to configure a firecall type role that users can be assigned to that grants them administrator type permissions. It would be used in cases where an admin needs to quickly make changes directly to production in order to recover from failure.
• give everyone ReadOnly for transparency, as well as diagnostic and investigative purposes

Another option would be to leverage ABAC, which effectively governs a users ability to perform actions based on tags that are applied to that user. It can even be extended to temporary credentials developers would use to access the environment via CLI. The advantage here is that instead of enumerating resources in a policy, you are checking for the existence of a tag. This means your policy would still pass as more resources get added, assuming the new resources are tagged properly. It's not a panacea however, since not all resources support tags.

You can read about it here: https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html