aws-amplify / aws-amplify/amplify-hosting
Publish AWS IP ranges used by Amplify Hosting for GitHub IP allow list configuration
- 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
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