Tips and Tricks to help with Administering an AWS Instance and helping getting infrastructure paid for in a clear way.
FAQS / Tips
- Account Separation and Billing – the most important thing to do in AWS is separate group’s by whom in the organization is willing to pay for said infrastructure. If you have a developer group, they get one account. If the group is in another continent, they get another account. etc. etc. If you don’t know how to chargeback costs, at least it can be paid back on an account level.
2. Use Tagging to allocate Billing by Tags – Whether this be done by project or organization code, anything that can cost a significant amount of money should use a tag. The use of AWS Config can we used to ensure all relevant resources are tagged properly.
3. Shutdown all Compute Resources after 2 hours if they do not have the correct tagging – Especially for unapproved resources, create a no tolerance policy on tagging. Shut down all resources that do not follow this tagging mandate.
4. Limit Accounts, especially is using AWS Organizations, by minimal service and Region Policies – Implement guardrails that allow users to not access IAM, limit to known services, limit to known deployment regions, and limit to known certain subnets as part of the VPC.
5. Implement guardrails from prevent users from disabling cloudtrails and cloudwatch at the AWS Organization level – As cloudwatch monitors resources and Cloudtrails monitors API Actions, it is most relevant to ensure these services are not turned off.
6. Mandatory Key Rotation – Keys will be associated to users and if those users are termed, processes must be in place to replace those keys with newer keys. Promote users to utilize Secrets Manager and make sure that it is accounted for in their workflow.
7. Limit Infrastructure provisioning Types to less expensive infrastructure in Testing/QA Environments – use IAM policies to limit users to only deploying resources for which are less expensive in a QA/Testing context.
8. Use AWS Organizations to create an Account Hierarchy with relevant Service Control Policies ( SCP’s) to limit access at the account level – Use Hierarchies, similar to Active Directory AD GPO’s, to apply organization to account groups and apply limitations at the account level. Use hierarchy.
9. In regards to using AWS Organizations, although you can define Service Control Policies at every level, it is more straight forward to apply certain limiting policies that apply to all instances at the root level and defining limitations at the account level – Since every level must allow the permission ( from Account to root ), it can get very confusing. Make it easier on yourself and deal with less abstraction by concentrating only on the root level and the account level. Its okay to define FullAdmin for every level in between.
10. Use resource groups to…group resources by Tag – this is mainly useful for splitting up costs by particular resources. Can also be used to apply automatons for these particular group of tags from System Manager.
10. Use Cost Allocation Tags – Generic tags are only usable in the Billing Explorer if they have been activated in the Cost Allocation Tag Menu. Otherwise they will now show up for Billing purposes.
11. Depending on project requirements, define a non-default KMS Key by default and enable encryption by default for each region – Allows for keys to be applied, regardless if the Admin/developer forgets to do this. Best practice is to encrypt it on a project-by-project basis.
12. Deny…User Creation, Key Creation, Attaching and Detaching IAM Policies to users, Creating Identity providers, Creating and Deleting VPC’s, Creating and Deleting Subnets, Changing IGW or Route Tables, Peering Connections to all non-admin users – The idea is to lock down networking, authentication, and sources of automation which are unintended. Imagine if a hacker had to slowly provision instances through the console…
13. Deny…creating Identity providers IAM permission – Not that they will care for permission federation after they have already accessed your account.
14. Deny…Resource Sharing – If you think they should not be allowed to share, well do make sure to make sure to send a letter to their mother.
15. Use Resource Access Manager to Share Subnets from the master account to the child account – You can lock down networking as a whole by sharing certain networks with certain accounts.
16. Using SNS Billing Alerts – This can either indicate overspending or an unusual amount of resource utilization in your instance. It Should give stakeholders an idea of how much resources really cost and if they are forecasted to go above their budget.
17. Require Tagging before instances can be ran or accessed – Use IAM policies to mandata certain tag fields be present and filled out. Otherwise, in the case of EC2, it will not run and in the case of S3, it can not be accessed.
18. IAM provides a feature called Service Last Accessed -Although you can see this in the console on a per policy basis, it would probably be better if you scripted this feature to see all the Last Service dates for all relevant services. This is supposed to help with the policy of users having the least privilege.
19. Deny…Inline Policies – It is neither scalable or obvious to audit these type of policies. Just don’t allow inline policies.
20. Have an onboarding questionaire – provision only what they think they need, and give them a month to change it again. It should at least get you going on the right track.
21. If developers are using Git, make sure they use GIT Secrets – it mainly scans for credentials and such and takes them out of any git repository.
