AccessGuard synchronizes a FraudGuard-managed list of approved public IP ranges into an AWS Organizations service control policy. Because an SCP can affect every identity in its target member accounts, deployment should be treated as a controlled security change—not a one-command convenience.

This article covers the rollout model and review points. Use the maintained AccessGuard CloudFormation template and README for current parameters and commands.

Before you deploy

Confirm all of the following:

  • the AWS organization has all features enabled and SCPs are available;
  • you are operating from the organization management account;
  • the target is a test member account or narrowly scoped OU;
  • approved administrative traffic exits through stable public IPv4 or IPv6 ranges;
  • automation, VPC endpoints, and AWS service-to-service calls have been inventoried;
  • a management-account recovery path and separate break-glass procedure exist;
  • CloudTrail is enabled and denial events can be reviewed.

AWS states that SCPs define permission guardrails; they do not grant permissions. They affect identities in member accounts, not users or roles in the management account. Read the AWS SCP documentation before continuing.

Architecture

The customer-deployed Lambda runs on a schedule, fetches the FraudGuard allowlist, normalizes addresses to CIDR notation, and generates the policy for the configured target. In enforcement mode, it creates or updates the SCP and attaches it to the selected root or OU.

Optional controls support:

  • dry-run output without organization changes;
  • principal or principal-tag bypasses for break-glass access;
  • preservation of AWS service principals;
  • CloudWatch logging, metrics, and alerts;
  • custom schedule and target OU configuration.

FraudGuard stores the customer-managed allowlist. The enforcement function and AWS policy remain in the customer’s environment.

Phase 1: prepare the allowlist

Use corporate VPN, SASE, bastion, or other controlled public egress ranges where possible. Avoid a long list of residential addresses; policy size is limited and home IPs can change without warning.

For every approved range, record an owner, business reason, and review date. Include IPv6 if administrators can reach AWS over IPv6. Removing an address from the FraudGuard list removes it from the next generated policy.

Phase 2: configure exceptions

AccessGuard supports principal-pattern and principal-tag exceptions. Keep the set small and independently monitored.

An exception should not be the only recovery method. SCPs do not restrict management-account identities, so preserve a tightly controlled management-account path for organization recovery and use that account only for required tasks.

When allowing AWS services, review how each critical workflow calls downstream services. AWS warns that network-specific context can be absent in service-to-service requests; a broad IP deny can unintentionally break those integrations.

Phase 3: deploy in dry-run mode

Dry-run mode retrieves the list and renders the policy without creating or attaching an SCP. Review:

  • target root or OU;
  • normalized IPv4 and IPv6 CIDRs;
  • policy size;
  • bypass principals and tags;
  • AWS service-principal handling;
  • schedule, log retention, and alert configuration.

Store the reviewed output with the change record. If the policy is larger or broader than expected, fix the allowlist before enforcement.

Phase 4: test in a member account

Do not test from the management account; SCPs do not affect it.

From a test member account:

  1. Verify a routine read-only AWS API call from an approved public IP.
  2. Repeat from an unapproved public IP and confirm the expected explicit deny.
  3. Test assumed roles, console sessions, automation, and emergency roles.
  4. Test workflows that use VPC endpoints; aws:SourceIp is not present for those requests.
  5. Verify service-to-service operations such as storage, encryption, deployment, backup, and monitoring.
  6. Confirm CloudTrail and alerting show enough context to investigate a denial.

Use the AWS global condition key documentation when a request path does not carry the source context you expected.

Phase 5: enforce and expand gradually

Enable enforcement on the test target first. Monitor for at least one normal operating cycle, including deployments and scheduled automation. Expand to additional OUs only after their access paths have been reviewed.

Watch for:

  • explicit SCP denials;
  • broken automation or AWS service integrations;
  • users bypassing approved egress;
  • allowlist growth and policy-size pressure;
  • stale exceptions;
  • unexpected IPv6 or VPC endpoint paths.

Rollback

Rollback should be rehearsed before enforcement. The immediate recovery action is to detach or remove the AccessGuard SCP from the affected target using the management account. Then return the stack to dry-run, review the denial, and correct the allowlist or exception logic before reattaching.

Do not disable the entire SCP policy type as a routine rollback. AWS notes that disabling and re-enabling SCPs can remove previous attachments.

Launch checklist

  • Target is a test account or narrow OU
  • Approved public IPv4 and IPv6 egress documented
  • Break-glass and management-account recovery tested
  • Automation and service-to-service calls inventoried
  • VPC endpoint behavior tested separately
  • Dry-run policy reviewed and within size limits
  • CloudTrail denial monitoring confirmed
  • Rollback owner and procedure documented
  • Expansion requires a second review

AccessGuard requires deployment review. Contact hello@fraudguard.io to validate architecture and current plan eligibility before production enforcement.