AWS Inspector is mostly about what happens on (inside) an instance: does the software there conform to various best practices, patches installed etc. For it to work, you need an agent runs on EC2 instances and checks operating system patches, known vulnerabilities, and common issues. AWS Inspector consequently surveys applications for presentation, vulnerabilities, and deviations from best practices. In the wake of playing out an evaluation, Amazon Inspector delivers a point by point rundown of security discoveries organized by the dimension of seriousness. These discoveries can be evaluated specifically or as a feature of itemized appraisal reports which are accessible by the means of the Amazon Inspector console or an API.
Inspector provides an agent that goes onto EC2 instances. It provides packaged rules to check for unintended network accessibility of your Amazon EC2 instances and for vulnerabilities on those EC2 instances. It can check the patch level of the OS. Amazon Inspector evaluations are offered to you as characterized rules bundles mapped to normal security best practices and helplessness definitions. Instances of inherent tenets incorporate checking for access to your EC2 occasions from the web, remote root login being empowered, or powerless programming variants introduced.
With AWS Config, you can’t check what’s going on inside an instance but you could check that it’s running approved AMIs, has all of its volumes encrypted, etc. There’s checks you can setup against lots of different types of resources. It’s intended to be a change management service.
Trusted Advisor helps customers follow general AWS best practices. E.g. are your EC2 instances over-provisioned and you’re wasting money as a result? Are you approaching any service limits? Is there MFA on root?
Trusted advisor does overlap with AWS Config rules a bit (they can both check things like open security groups for example, are RDS backups enabled etc). The big difference is with trusted adviser there is no customization (other than excluding resources): you just get the checks AWS has seen fit to add.
Config, on the other hand, can do cool things like reading CloudTrail logs and creating a timeline of changes made to tracked resources (so you can see how a resource like an S3 bucket has been modified over time). On top of it, you can create rules to detect whether your environment is in compliance with certain policies (e.g. all your EBS volumes are encrypted). You can also send notifications or take automated action with Lambda when a resource violates a rule.
With config there are no checks enabled out of the box — you have to select from the AWS managed rules what you want to enable (& most rules can be parametrized) and you can also develop your own lambda backed rules.
Here is useful info graphic from a LinkedIn post by Shekhar Londhe, Principal Cloud Architect at Hitachi Vantara:
If you need to know if you have any unrestricted ports opened on your EC2 instance (e.g Port 22 is opened to 0.0.0.0/0 and ::0/0 in your security group), you can use the AWS Config or Trusted Advisor.
If you need to know if your EC2 port configuration has been modified in the recent months, that’s something only AWS Config can do.
If you want to know if your EC2 instance is reachable over Internet Gateway or VWG or VPC peering on some ports, or if you need to know if your EC2 instance is connecting to another host for log-ins using insecure protocol instead of SSH, then you should use the AWS Inspector.