title: Why should I use IAM roles?
body: <p>Please help me understand why AWS recommends assigning roles to EC2 instances ("role-based approach")
  over storing API keys in files on the instance ("file-based approach")?</p>
  
  <p>Consider three use cases:
  (i) There is a 'tomcat' account on the instance which runs a web application. The application makes no use of AWS API.
  There is another account ('support') on the instance which uses AWS API for housekeeping and maintenance
  (logs, metrics etc).</p>
  
  <p>With the file-based approach, if an attacker exploits the application and gets access to the filesystem (as 'tomcat'),
  they won't be able to read the credential file (readable only by 'support') and won't be able to make AWS API calls.
  The same is true if the attacker gets to execute arbitrary code under the 'tomcat' account.</p>
  
  <p>However with the role-based approach, if an attacker gets access to the filesystem, they gain nothing
  (as there is no credential file at all) and they cannot call AWS API. But if the attacker gets to execute arbitrary code
  they may call the API.</p>
  
  <p>(ii) There is a 'tomcat' account which runs a web application. The application calls AWS API for its operation.
  There is also another account ('support') which uses AWS API for housekeeping and maintenance.
  Both accounts need to access different resources (eg. 'tomcat' needs S3, while 'support' needs logs and metrics).</p>
  
  <p>In the role-based approach, the role assign to the instance will effectively contain the union of the permissions
  needed by 'tomcat' and 'support', which goes against the Least Priviledge principle. Even if the permissions were
  technically divided between two role, each account will be ultimately able to assume a role it doesn't really need.</p>
  
  <p>With the file-based approach, if an attacker gains access to the file system, they will be able to read 'tomcat'
  credentials and make API calls from another machine (this could be avoided by restricting the policies
  to a particular source IP, although it would be cumbersome to maintain). If the attacker gets to execute an arbitrary
  code, they will be able to make API calls from the EC2 instance. In both cases, the 'support' account will remain
  protected by the operating system.</p>
  
  <p>With the role-based approach, if an attacker gains access to the file system, the gain nothing in terms of API calls,
  as there is no credential file at all. However, if an attacker get to execute arbitrary code, they can make API calls
  from the instace on behalf on BOTH roles ('tomcat' and 'support').</p>
  
  <p>(iii) There is a 'tomcat' account which runs a web application. The application calls AWS API for its operation.
  No other API calls are made from the instance.</p>
  
  <p>With the file-based approach, if an attacker gains access to the file system, they will be able to read 'tomcat'
  credentials and make API calls from another machine (this could be avoided by restricting the policies
  to a particular source IP, although it would be cumbersome to maintain). If the attacker gets to execute an arbitrary
  code, they will be able to make API calls from the EC2 instance.</p>
  
  <p>With the role-based approach, if an attacker gains access to the file system, the gain nothing in terms of API calls,
  as there is no credential file at all. However, if an attacker get to execute arbitrary code, they can make API calls
  from the instance.</p>
  
  <p>So it seems that the recommended role-based approach actually increases the risk in cases (i) and (ii).</p>
  
  <p>What am I missing here?</p>