---
title: "Security Disclosure Recommendation: Check for Anomalous AWS Access"
description: "Learn how to Security Disclosure Recommendation: Check for Anomalous AWS Access"
date: 2026-10-22T00:46:42.792Z
authors: ["Mykal Machon"]
category: "Engineering"
url: https://blog.railway.com/p/security-disclosure-recommendation-check-for-anomalous-aws-access
---

# Security Disclosure Recommendation: Check for Anomalous AWS Access

> This guide is part of Railway's response [to the security disclosure published on October 21, 2026](https://blog.railway.com/p/security-disclosure-wednesday-october-21st).

*If you use AWS access keys with Railway, deactivate any key that may have been exposed, review CloudTrail and billing for activity you didn't generate, and redeploy your services with a new key.*

If an AWS access key pair (`AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`) may have been exposed, or you see resources or charges you don't recognize, check for anomalous AWS access. AWS's guidance is to deactivate the key, replace it, review CloudTrail for what the key did, and delete anything it created.

This guide applies the guidelines from AWS's [What can I do if I notice unauthorized activity in my AWS account?](https://repost.aws/knowledge-center/potential-account-compromise), extended to include Railway-specific operations. Access keys are long-lived, so an exposed key works until you deactivate it.

## Deactivate the key

AWS lets each IAM user hold two access keys, which gives you an overlap window. Deactivate first rather than delete, so you can reactivate briefly if a service you forgot about breaks.

1. Open the [IAM console](https://console.aws.amazon.com/iam/) and enter the exposed access key ID in the search bar to find its user.
2. On the user's **Security credentials** tab, in the **Access keys** section, click **Create access key** to generate the replacement.
3. For the exposed key, click **Actions** and then **Deactivate**. Requests signed with the old key fail from this point.

See [Update access keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id-credentials-access-keys-update.html) for the full procedure.

## Update the key on Railway

An AWS access key on Railway is a pair of variables, so updating it is a variable edit and a redeploy.

1. Open the service that uses the key and click **Variables**. If the key is a [shared variable](https://docs.railway.com/variables#shared-variables), edit it once in **Project Settings** and every service that references it picks up the change.
2. Edit `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` to the new values, then deploy the [staged change](https://docs.railway.com/deployments/staged-changes).
3. Confirm the new deployment is active and its logs show successful AWS calls, with no `InvalidClientTokenId` or `SignatureDoesNotMatch` errors.
4. Update anything outside Railway that used the old key, such as local development or CI.

## Review for misuse

CloudTrail records every management API call made with a key for 90 days, and IAM tracks when each key was last used.

1. Open the [CloudTrail console](https://console.aws.amazon.com/cloudtrail/) and click **Event history**. Set **Lookup attributes** to **AWS access key**, enter the exposed key ID, and set the time range to the exposure window. See [Working with CloudTrail event history](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
2. Look for calls that aren't your application's: `RunInstances`, `CreateUser`, `CreateAccessKey`, `AttachUserPolicy`, `CreateRole`, `PutBucketPolicy`, and anything from a Region you don't use. Source IPs that aren't Railway's egress ranges point at the attacker.
3. Repeat the search in every Region. Event history is per Region, and attackers often launch resources in Regions you don't watch.
4. Download the [credential report](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html) from the IAM console and look for users, keys, or passwords you didn't create.
5. Open [Cost Explorer](https://console.aws.amazon.com/cost-management/home#/cost-explorer) and compare the exposure window against the previous month
6. Delete resources, users, roles, policies, and keys the attacker created. Snapshot anything you need for forensics first.
7. If AWS Support sent an irregular-activity notification, reply in the [Support Center](https://console.aws.amazon.com/support/) with the actions you took.

If you have any other questions, contact Railway support at <support@railway.com>.


---

Open this post in a browser: https://blog.railway.com/p/security-disclosure-recommendation-check-for-anomalous-aws-access