Permissions Management for AWS EC2 Servers

AWS does not have visibility or control of what's happening inside your EC2 instance, although there are service features and tools you can use to help. For your Windows service, for example, you will need to look in to something like creating additional users (maybe with administrative privileges) that your users can log in with, giving you the audit trail (in Windows logs) of who logged in and took which actions. Users who do not need to, for example, start and stop services, can be granted more restrictive permissions so they can do their job but not cause operational issues. These are all Windows configurations which you will need to perform using standard Windows features.

However, there's some AWS services which can help with these steps. At the most basic, you may be able to use EC2 UserData to supply a bootstrap script to create the needed users or join your server to a Windows Domain. A slightly more advanced approach would be to use AWS Systems Manager's State Manager, where you can define (or use pre-defined) runbooks to performs bootstrap and maintenance tasks. You can apply IAM permissions to the use of Systems Manager, so you could restrict who can log in to the host to the bare minimum, and have other users use Systems Manager to perform tasks on the host. This means they can only use the runbooks they're granted access to, and since the runbooks define all the steps to be taken on the host, users can't do other things instead. This activity (at least, the use of the runbook) will appear in CloudTrail, and the output of the commands can be captured in CloudWatch Logs or an S3 bucket.

You could also look at Session Manager, a feature of Systems Manager, which gives remote access (PowerShell command line, or RDP) to a host again using IAM permissions. The use of Session Manager is also captured by CloudTrail, and when used for command line access the commands/output performed by the user can be logged in CWL or S3. (RDP session content can't be logged, but CloudTrail will show who started a session.) You can combine this with the points in the first paragraph to have much more controlled and logged access to the host and inside it.

For the tagging issue, you have a couple of options. First, and most impactful, is that you can modify your IAM policies to require certain tags to be specified when an instance is launched. If the tags are not present in the request, it fails and the instance will not be launched. Be careful with this to make sure you understand all the ways instances could be launched in your environment and that all of them can provide tags on launch to ensure you don't break things! The other option is to use a compliance monitoring tool such as AWS Config, which doesn't prevent the launch of an instance without the right tags, but will flag it as non-compliant. It can automatically remediate this by adding tags (if the right ones can be inferred), or alerting you (either directly, or by you looking at reporting) so you can investigate and correct the instance.

You may also want to look at using CloudWatch Logs to store the Windows Event Logs, which gives you external visibility of what's happening on the host, and look in to monitoring services such as CloudWatch Synthetics to ensure your site(s) is/are available and working correctly.

Hi James Could you please provide us with an example of an IAM policy to require certain tags to be specified when an instance is launched? Thank you