AWS Config rules and resource timeline

Sign in and set up names:

cd C:\aws-lab
aws login --profile saat-admin
$env:AWS_PROFILE = 'saat-admin'
$v = Get-Content C:\aws-lab\saat-vpc.json | ConvertFrom-Json
$acct = aws sts get-caller-identity --query Account --output text
$bucket = "saat-config-$acct-ap-south-1-an"

1Create the Config bucket and service role

Paste this whole block:

aws s3api create-bucket --bucket $bucket --bucket-namespace account-regional --region ap-south-1 --create-bucket-configuration LocationConstraint=ap-south-1 | Out-Null
@'
{
  "Version": "2012-10-17",
  "Statement": [
    { "Sid": "AWSConfigBucketPermissionsCheck", "Effect": "Allow", "Principal": { "Service": "config.amazonaws.com" }, "Action": "s3:GetBucketAcl", "Resource": "arn:aws:s3:::BUCKET", "Condition": { "StringEquals": { "AWS:SourceAccount": "ACCT" } } },
    { "Sid": "AWSConfigBucketExistenceCheck", "Effect": "Allow", "Principal": { "Service": "config.amazonaws.com" }, "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::BUCKET", "Condition": { "StringEquals": { "AWS:SourceAccount": "ACCT" } } },
    { "Sid": "AWSConfigBucketDelivery", "Effect": "Allow", "Principal": { "Service": "config.amazonaws.com" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::BUCKET/AWSLogs/ACCT/Config/*", "Condition": { "StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control", "AWS:SourceAccount": "ACCT" } } }
  ]
}
'@ -replace 'BUCKET', $bucket -replace 'ACCT', $acct | Set-Content config-bucket-policy.json
aws s3api put-bucket-policy --bucket $bucket --policy file://config-bucket-policy.json
aws iam create-service-linked-role --aws-service-name config.amazonaws.com 2>$null | Out-Null
aws iam get-role --role-name AWSServiceRoleForConfig --query Role.Arn --output text

You should see something like this:

arn:aws:iam::111122223333:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig

The service-linked role lets Config read your resources. If it already exists, the create command fails quietly and the get shows it anyway.

2Start recording two resource types

Paste this whole block:

@'
{
  "allSupported": false,
  "includeGlobalResourceTypes": false,
  "recordingStrategy": { "useOnly": "INCLUSION_BY_RESOURCE_TYPES" },
  "resourceTypes": [ "AWS::EC2::SecurityGroup", "AWS::S3::Bucket" ]
}
'@ | Set-Content recording-group.json
aws configservice put-configuration-recorder --configuration-recorder "name=default,roleARN=arn:aws:iam::$($acct):role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig" --recording-group file://recording-group.json
aws configservice put-delivery-channel --delivery-channel "name=default,s3BucketName=$bucket"
aws configservice start-configuration-recorder --configuration-recorder-name default
Start-Sleep 60
aws configservice describe-configuration-recorder-status --query "ConfigurationRecordersStatus[0].[recording,lastStatus]" --output text

You should see this:

True    SUCCESS

Recording only security groups and S3 buckets keeps the lab to a few cents. A real account usually records all supported types, and excludes noisy ones only for a reason.

3Add two rules and break one on purpose

Paste this whole block (evaluations take a few minutes):

'{ "ConfigRuleName": "restricted-ssh", "Source": { "Owner": "AWS", "SourceIdentifier": "INCOMING_SSH_DISABLED" }, "Scope": { "ComplianceResourceTypes": [ "AWS::EC2::SecurityGroup" ] } }' | Set-Content rule-ssh.json
'{ "ConfigRuleName": "s3-versioning", "Source": { "Owner": "AWS", "SourceIdentifier": "S3_BUCKET_VERSIONING_ENABLED" }, "Scope": { "ComplianceResourceTypes": [ "AWS::S3::Bucket" ] } }' | Set-Content rule-s3.json
aws configservice put-config-rule --config-rule file://rule-ssh.json
aws configservice put-config-rule --config-rule file://rule-s3.json
$sg = aws ec2 create-security-group --group-name lab26-ssh --description "Config rule test" --vpc-id $v.VpcId --query GroupId --output text
aws ec2 authorize-security-group-ingress --group-id $sg --protocol tcp --port 22 --cidr 0.0.0.0/0 | Out-Null
do { Start-Sleep 30; $r = aws configservice get-compliance-details-by-resource --resource-type AWS::EC2::SecurityGroup --resource-id $sg --query "EvaluationResults[0].ComplianceType" --output text } until ($r -eq 'NON_COMPLIANT')
aws configservice describe-compliance-by-config-rule --query "ComplianceByConfigRules[].[ConfigRuleName,Compliance.ComplianceType]" --output text

You should see something like this:

restricted-ssh  NON_COMPLIANT
s3-versioning   NON_COMPLIANT

restricted-ssh caught lab26-ssh. s3-versioning flags your trail and Config buckets, which don’t have versioning. That is a real finding: many companies require versioning on log buckets. You’ll leave them as they are to avoid extra storage cost, and record the decision; an accepted exception is still a decision.

4Fix it and read the timeline

Paste this whole block:

aws ec2 revoke-security-group-ingress --group-id $sg --protocol tcp --port 22 --cidr 0.0.0.0/0 | Out-Null
do { Start-Sleep 30; $r = aws configservice get-compliance-details-by-resource --resource-type AWS::EC2::SecurityGroup --resource-id $sg --query "EvaluationResults[0].ComplianceType" --output text } until ($r -eq 'COMPLIANT')
aws configservice get-resource-config-history --resource-type AWS::EC2::SecurityGroup --resource-id $sg --query "configurationItems[].[configurationItemCaptureTime,configurationItemStatus,length(relatedEvents)]" --output text
$r

You should see something like this:

2026-10-20T19:31:44.120000+05:30      OK      1
2026-10-20T19:24:02.877000+05:30      ResourceDiscovered      2
COMPLIANT

Two versions of the group, each with the CloudTrail event IDs that caused it. In the console, open Config, then Resources, then lab26-ssh, and choose Resource timeline to see the rule appear and disappear.

✅ Checkpoint: The recorder is recording with status SUCCESS, restricted-ssh flagged lab26-ssh and then marked it COMPLIANT after the fix, and the timeline shows both versions. Keep everything for the break lab.