How do I tell all my AWS EC2 instances to pull from git / codecommit?

For EC2 instances that are launched with an IAM role, you don't even have to bake in SSH keys. Git can get CodeCommit credentials from the EC2 instance metadata. Bake a Linux-based AMI with the latest AWS CLI package and the following lines in ~/.gitconfig:

[credential]    helper = !aws --profile default codecommit credential-helper $@    UseHttpPath = true

Launch the instance with an IAM role attached, and then you can clone your CodeCommit repo without any more setup.

You might want to look into Capistrano and Capify-EC2 if you want to run git commands across a fleet of EC2 instances based on tags.

Updated:If you're open to using AWS OpsWorks to deploy from CodeCommit, there's a recent blog article about how to do that. You can also use OpsWorks to run arbitrary commands across instances with Capistrano.

The closest you'll get to it with AWS managed services is CodeDeploy. With it, you can orchestrate deployment in EC2 instances via command line or web console. But CodeDeploy just pulls artifacts from S3 or GitHub, so far. By now, CodeCommit seems to be completely isolated from other related Amazon services, like CodePipeline and CodeDeploy, so it doesn't seem to be a good choice. But, off course, Amazon roadmap is to integrate all them (not doing this would be pointless). So, righ now, you would be better using GitHub than CodeCommit.

But, considering you are not using GitHub, then you need a CI (continuous integration) solution between you repository and CodeDeploy, pulling code from the source, possibly building or running tests, pushing it to S3 and telling CodeDeploy about it. There's CodeShip, for example, which can do that, and integrates with a lot of external services. Or you could even have your own CI server, like Jenkins, doing that "glue" role for you. (Jenkins will probably be the most flexible one because it's open-source and may have plugins for everything.)

So, breaking down a little bit, you workflow would be something like that:

• push code to your repository;
• whenever there's an event (a commit on some branch, or a new tag, it should be configurable), your CI pulls it, run whatever you want or need (builds, tests, packs it), and pushes it to S3 (as a tarball file, usually);
• depending on how you have set things, your CI tells Code Deploy to deploy it on your EC2 instances right away, or it just tells it there's a new version available, and lets you to trigger the deploy, manually, via CLI on web console, whenever you want.

(Actually, CodeDeploy doesn't push code to EC2 instances. Instead, each EC2 instance must run an agent which pools regularly CodeDeploy server in order to know if there's something new to be applied locally. Anyway, CodeDeploy coordinates and get feedback from the agents, so it just works as if it were 100% active on CodeDeploy side and 100% passive on the instances side.)

The most "clean" AWS solution would be CodeCommit -> CodePipeline -> CodeDeploy, or just CodeCommit -> CodeDeploy, but those services are not completely integrated by now.

In your case, the simplest and viable solution right now would be Github -> CodeDeploy. Anything different from that will demand some intermediate steps on the way, like the examples I provided (CodeShip, Jenkins, etc).