CloudAgent gives you AI agents that manage your cloud infrastructure. They handle tasks like security compliance, cost optimization, deployments, and monitoring. You remain in control as agents show you their plans, wait for your approval, then execute. Think of it as having a cloud operations team that works 24/7 without needing to hire an army of cloud experts.

How can AI agents be trusted with production cloud infrastructure?

You stay in control through approval workflows where every infrastructure change can require human approval before execution, custom security controls with granular access rules, complete audit trails of every action, self-hosted deployment options, and progressive trust models starting with read-only access.

How does it actually reduce costs?

CloudAgent agents delete unused resources, schedule non-production shutdowns, right-size infrastructure based on usage patterns, and recommend architectural optimizations. Early customers report 15-40% cost reduction within 90 days. Unlike dashboards, CloudAgent actually fixes the problems.

1. Assessment

Identify security groups with RDP open to the internet
Map open-RDP security groups to associated resources
User: Define approved sources for RDP access
User: Decide RDP removal or restriction for each affected resource

2. Configuration

Apply RDP rule removals and restrictions to security groups

3. Validation

Confirm no security group exposes RDP to the internet

1 Credits

Restrict RDP Security Group Rules to Approved Source IPs

Overview

Tighten RDP access across your AWS environment so that TCP 3389 is never exposed to the internet (0.0.0.0/0 or ::/0), while still allowing controlled access from approved sources like office networks, VPN endpoints, or bastion hosts.

The plan walks through:

Discovering all security groups that expose RDP to the internet and mapping them to the instances and resources they protect.
Guiding you to define which sources are allowed to use RDP and to decide, per resource, whether RDP should be removed entirely or tightly restricted.
Applying the agreed rule changes to the relevant security groups.
Re-validating the environment and producing a clear report that confirms no security group leaves RDP open to the internet.

Execution Details

Phase 1: Assessment

Identify security groups with RDP open to the internet

Review all in-scope AWS accounts and regions to find every security group that permits TCP 3389. This includes rules that:

Explicitly specify port 3389 or include it within a range.
Allow traffic from 0.0.0.0/0 or ::/0, including combined or nested CIDR configurations.

For each matching security group and rule, key metadata (IDs, names, descriptions, VPCs, accounts, regions, protocols, ports, CIDRs, referenced security groups) is collected and consolidated into a de-duplicated, structured list for later steps.

Map open-RDP security groups to associated resources

For every security group identified as having open RDP:

Enumerate attached network interfaces (ENIs) and capture their core attributes.
Determine which resources are associated with those ENIs (e.g., EC2 instances, load balancers, NAT gateways, or other AWS-managed services).
For EC2 instances, record useful details such as instance IDs, names, states, types, Availability Zones, and key tags (environment, owner, etc.).
Identify any open-RDP security groups not attached to any resource and flag them as unattached.

This produces a structured mapping from each open-RDP security group to its associated ENIs and resources, with enough metadata to support risk and business-impact decisions.

User: Define approved sources for RDP access

Guide the user through reviewing the list of affected security groups and resources, with emphasis on business-critical or production systems. The user is then prompted to:

Provide approved IPv4 CIDR ranges for RDP (such as corporate offices, VPN endpoints, or jump/bastion hosts).
Provide approved IPv6 CIDR ranges, if applicable.
Specify any allowed source security groups (for example, a bastion host security group).
Clarify environment-specific policies (such as disallowing direct RDP in production or requiring access through bastions).
Confirm whether any global policy bans direct RDP from the internet entirely, aside from documented exceptions.
Document any temporary exceptions, including justification, scope, and review/expiration criteria.

The result is a clearly documented, structured definition of all allowed RDP sources across IPv4, IPv6, and security-group–based access.

User: Decide RDP removal or restriction per resource

Using the mapping between open-RDP security groups and their resources, the user is guided to decide, for each resource or logical group:

Whether RDP should be removed entirely, ensuring alternative access methods (for example, SSM Session Manager or bastion hosts) are in place.
If RDP must remain, which of the approved sources (CIDRs and/or security groups) should be allowed for that specific resource or group.
Which resources, if any, require temporary broader access, with explicit justification and review conditions.

These decisions are translated into a target state per security group and per rule: which RDP rules will be deleted and which will be replaced with restricted rules. The outcomes are captured in structured form so that configuration changes can be applied consistently.

Phase 2: Configuration

Apply RDP rule removals and restrictions to security groups

Using the list of open-RDP security groups and the user-approved decisions:

For security groups where RDP is to be fully removed, identify every inbound rule that allows TCP 3389 (whether explicitly or via port ranges, and from any source) and remove them so that no inbound RDP remains.
For security groups where RDP is to be restricted:
- Identify and remove inbound rules that allow TCP 3389 from 0.0.0.0/0, ::/0, or from sources not in the approved list.
- Add or adjust inbound rules so that TCP 3389 is allowed only from the specified approved IPv4 CIDRs, IPv6 CIDRs, and/or source security groups.

If multiple resources with different RDP needs share the same security group, the plan applies rules that meet the strictest shared requirement and flags the group for potential future re-segmentation (without performing that re-design here).

After changes, each modified security group is re-checked to ensure:

No inbound rule allows TCP 3389 from 0.0.0.0/0 or ::/0.
Remaining RDP rules match the approved sources or documented exceptions.

Any security group that could not be updated as intended is recorded, along with its original and resulting RDP rules and the reason for deviation. A final change summary captures the before-and-after state for all modified groups.

Phase 3: Validation

Confirm no security group exposes RDP to the internet

Re-scan all in-scope regions and security groups after configuration changes to verify the final state:

Check all inbound rules for TCP 3389, including port ranges.
Confirm that no rule allows TCP 3389 from 0.0.0.0/0 or ::/0.
Identify any RDP rules that allow access from outside the approved sources and record them as exceptions or configuration drift.
Verify that every security group slated for complete RDP removal truly has no inbound TCP 3389 rules.
Confirm that security groups slated for restriction allow RDP only from the explicitly approved sources or documented exceptions.

A validation report is produced summarizing the scan, listing any remaining non-compliant rules or accepted exceptions, and clearly stating that RDP (TCP 3389) is no longer open to 0.0.0.0/0 or ::/0 for all in-scope security groups.