aws-amplify / aws-amplify/amplify-hosting

Publish AWS IP ranges used by Amplify Hosting for GitHub IP allow list configuration

Open
#4,086 1 comment 3 reactions 0 assignees View on GitHub
feature-request
Dominant language
Dockerfile
Stars
481
Forks
123
PR merge metrics
No merged PRs in 30d

Description

### Before opening, please confirm:

- [x] I have checked to see if my question is addressed in the [FAQ](https://github.com/aws-amplify/amplify-hosting/blob/master/FAQ.md).
- [x] I have [searched for duplicate or closed issues](https://github.com/aws-amplify/amplify-hosting/issues?q=is%3Aissue+).
- [x] I have removed any sensitive information from my code snippets and submission.

### Amplify Hosting feature

Build settings

### Is your feature request related to a problem? Please describe:

When using GitHub Organizations with IP allow list enabled, customers need to whitelist the IP addresses that Amplify Hosting uses to clone repositories and perform other operations. Currently, there is no Amplify-specific service tag in the AWS IP ranges JSON (https://ip-ranges.amazonaws.com/ip-ranges.json).

Customers are forced to whitelist broad AWS IP ranges for their region, which can be hundreds of CIDR blocks.
This is impractical and defeats the purpose of IP whitelisting.

### Describe how you'd like this feature to work

Add an AMPLIFY service tag to the AWS IP ranges JSON file (ip-ranges.json) that includes only the specific IP ranges Amplify Hosting uses to interact with source control providers (GitHub, GitLab, Bitbucket).

Alternatively, document the exact IP ranges Amplify Hosting uses per region in the official documentation, so customers can configure minimal and precise IP allow lists.

Consider providing a built-in integration or one-click setup for GitHub Organization IP allow lists, similar to how other CI/CD services handle this.

**Additional context:**

Currently the only workaround is whitelisting broad AWS service IP ranges, which results in hundreds of entries — most of which are unrelated to Amplify.

A dedicated Amplify service tag would significantly improve security posture for customers using GitHub IP allow lists.

**Workaround**

As a workaround, we created a script that fetches broad AWS IP ranges and adds them to the GitHub Organization IP allow list using the GitHub GraphQL API. This works but is far from ideal:

```
#!/bin/bash

# Usage: GITHUB_TOKEN= ./add-ips-to-github.sh
ORG="your-org-name"
TOKEN="${GITHUB_TOKEN}"

if [ -z "$TOKEN" ]; then
echo "Error: Set GITHUB_TOKEN env variable"
exit 1
fi

# Get the org node ID
ORG_NODE_ID=$(curl -s \
-H "Authorization: Bearer $TOKEN" \
-H "Accept: application/vnd.github+json" \
https://api.github.com/orgs/$ORG | jq -r '.node_id')

echo "Org node ID: $ORG_NODE_ID"

# Remove all existing IP allow list entries
echo "Removing existing IP allow list entries..."
while true; do
ENTRIES=$(curl -s -X POST \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
https://api.github.com/graphql \
-d "{\"query\":\"{ organization(login: \\\"$ORG\\\") { ipAllowListEntries(first: 100) { nodes { id allowListValue } } } }\"}")
IDS=($(echo "$ENTRIES" | jq -r '.data.organization.ipAllowListEntries.nodes[].id'))
[ ${#IDS[@]} -eq 0 ] && break
DELETED=0
for ID in "${IDS[@]}"; do
VALUE=$(echo "$ENTRIES" | jq -r ".data.organization.ipAllowListEntries.nodes[] | select(.id==\"$ID\") | .allowListValue")
echo -n "Removing $VALUE ... "
DEL=$(curl -s -X POST \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
https://api.github.com/graphql \
-d "{\"query\":\"mutation { deleteIpAllowListEntry(input: { ipAllowListEntryId: \\\"$ID\\\" }) { ipAllowListEntry { allowListValue } } }\"}")
if echo "$DEL" | grep -q "allowListValue"; then
echo "OK"
DELETED=$((DELETED + 1))
else
echo "SKIPPED: $(echo $DEL | jq -r '.errors[0].message // "unknown error"')"
fi
done
[ $DELETED -eq 0 ] && break
done
echo "Existing entries cleared."

# Fetch and add AWS IP ranges
REGION="us-east-1"
AWS_IP_JSON=$(curl -s https://ip-ranges.amazonaws.com/ip-ranges.json)
IPS=($(echo "$AWS_IP_JSON" |
jq -r ".prefixes[] | select(.region==\"$REGION\") | .ip_prefix" | sort -u))

if [ ${#IPS[@]} -eq 0 ]; then
echo "Error: No IPs found for $REGION"
exit 1
fi

echo "Found ${#IPS[@]} IPs for $REGION"

for IP in "${IPS[@]}"; do
echo -n "Adding $IP ... "
RESPONSE=$(curl -s -X POST \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
https://api.github.com/graphql \
-d "{\"query\":\"mutation { createIpAllowListEntry(input: { ownerId: \\\"$ORG_NODE_ID\\\", allowListValue: \\\"$IP\\\", name: \\\"AWS Amplify $REGION\\\", isActive: true }) { ipAllowListEntry { allowListValue } } }\"}")

if echo "$RESPONSE" | grep -q "allowListValue"; then
echo "OK"
else
echo "FAILED: $(echo $RESPONSE | jq -r '.errors[0].message // .message // "unknown error"')"
fi
done
```

- This workaround results in hundreds of overly broad IP entries being added, which undermines the security benefits of IP whitelisting. A dedicated Amplify service tag would significantly improve security posture for customers using GitHub IP allow lists.

Contributor guide

Open the contributing guide

Research direction

Start with the AWS ip-ranges.json service-tag format and the GitHub Organization IP allow list requirements described in the issue. Confirm whether Amplify Hosting's source-control ranges can be published per region, then document the exact ranges or define the requested AMPLIFY tag; done means customers can configure a minimal allow list without broad regional CIDRs.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, bash, github
Domain
cloud, devops, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.