3.3.2.4. Modifying Infrastructure Configurations in Response to Events
3.3.2.4. Modifying Infrastructure Configurations in Response to Events
Event-driven infrastructure modification closes the loop between detection and remediation — reducing mean time to repair from hours (human response) to seconds (automated response).
Common automated responses:
| Event | Automated Response | Service Chain |
|---|---|---|
| EC2 instance fails health check | Replace instance | ASG self-healing |
| Security group opened to 0.0.0.0/0 | Remove the rule | Config rule → SSM Automation |
| Unencrypted EBS volume detected | Enable encryption | Config rule → Lambda |
| High CPU for 10 minutes | Scale out | CloudWatch alarm → ASG policy |
| GuardDuty: cryptocurrency mining | Isolate instance | EventBridge → Lambda → modify SG |
| RDS storage approaching limit | Increase storage | CloudWatch alarm → Lambda |
Instance isolation pattern (security incident response):
def isolate_instance(instance_id):
ec2 = boto3.client('ec2')
# Create isolation security group (no inbound, no outbound)
isolation_sg = ec2.create_security_group(
GroupName=f'isolation-{instance_id}',
Description='Incident isolation - no traffic allowed',
VpcId=vpc_id
)
# Remove all egress rules (default SG allows all outbound)
ec2.revoke_security_group_egress(
GroupId=isolation_sg['GroupId'],
IpPermissions=[{'IpProtocol': '-1', 'IpRanges': [{'CidrIp': '0.0.0.0/0'}]}]
)
# Replace instance's security groups with isolation SG
ec2.modify_instance_attribute(
InstanceId=instance_id,
Groups=[isolation_sg['GroupId']]
)
# Tag for investigation
ec2.create_tags(Resources=[instance_id],
Tags=[{'Key': 'SecurityStatus', 'Value': 'Isolated'}])
Evidence order: capture memory first (it is lost on stop, reboot or terminate) by running a capture tool such as LiME through SSM Run Command, which needs no SSH (leave egress to the SSM VPC endpoints open in the isolation SG). Then snapshot every EBS volume, tag the snapshots with incident details, and share them to a separate forensic account. Record instance metadata too: IAM role, security groups, tags, launch details.
Stolen instance credentials (GuardDuty InstanceCredentialExfiltration): isolating the instance does not stop an attacker who already holds its role credentials. Revoke the role's active sessions (IAM "Revoke active sessions" attaches a deny for credentials issued before now, using aws:TokenIssueTime), then give the instance fresh credentials (e.g., an equivalent new role). The stolen copies stop working without taking the workload down.
Exam Trap: When isolating a compromised instance, don't terminate it — you need it for forensic investigation. Replace its security groups with an empty one (no inbound/outbound), take an EBS snapshot for evidence, and tag it. If the exam asks about incident response for a compromised instance, termination is wrong — isolation and forensics is the correct approach.