Cloud Storage Security Help Docs
Release Notes
  • Introduction
  • Getting Started
    • How to Subscribe
      • Pay-As-You-Go (PAYG)
      • Bring Your Own License/GovCloud (BYOL)
      • AWS Transfer Family
    • How to Deploy
      • Steps to Deploy
      • Advanced Deployment Considerations
      • AWS Transfer Family
    • How to Configure
  • Console Overview
    • Dashboard
    • Malware Scanning
      • AWS
        • Buckets
        • Amazon EBS Volumes
        • Amazon EFS Volumes
        • Amazon FSx Volumes
        • WorkDocs Connections
      • Azure
        • Blob Containers
      • GCP
        • GCP Buckets
    • See What's Infected
      • Findings
      • Malware History
      • Results
    • Schedules
    • Monitoring
      • Error Logs
      • Bucket Settings
      • Deployment
      • Jobs
      • Notifications
      • Storage Assessment
      • Usage
    • Configuration
      • Classification Rule Sets
      • Classification Custom Rules
      • Scan Settings
      • Console Settings
      • AWS Integrations
      • Job Networking
      • API Agent Settings
      • Proactive Notifications
      • License Management
      • Event Agent Settings
    • Access Management
      • Manage Users
      • Manage Accounts
        • Linking an AWS Account
        • Linking an Azure Account
        • Linking a GCP Account
      • Manage Groups
    • Support
      • Getting Started
      • Stay Connected
      • Contact Us
      • Documentation
  • Product Updates
  • How It Works
    • Scanning Overview
      • Event Driven Scanning for New Files
      • Retro Scanning for Pre-Existing Files
      • API Driven Scanning
    • Architecture Overview
    • Deployment Details
    • Sizing Discussion
    • Integrations
      • AWS Security Hub
      • AWS CloudTrail Lake
      • AWS Transfer Family
      • Amazon GuardDuty
      • Amazon Bedrock
    • Demo Videos
    • Scanning APIs
    • SSO Integrations
      • Entra ID SSO Integration
      • Okta SSO Integration
  • Frequently Asked Questions
    • Getting Started
    • Product Functionality
    • Architecture Related
    • Supported File Types
  • Troubleshooting
    • CloudFormation Stack failures
    • Cross-Region Scanning on with private network
    • API Scanning: Could not connect to SSL/TLS (v7)
    • Password not received after deployment
    • Conflicted buckets
    • Modifying scaling info post-deployment
    • Objects show unscannable with access denied
    • Remote account objects not scanning
    • My scanning agents keep starting up and immediately shutting down
    • I cannot access the management console
    • Linked Account Out of Date
    • Rebooting the Management Console
    • Error when upgrading to the latest major version
    • I Cannot Create/Delete an API Agent
  • Release Notes
    • Latest (v8)
    • v7
    • v6 and older
  • Contact Us & Support
  • Data Processing Agreement
  • Privacy Policy
Powered by GitBook
On this page
  • OVERVIEW
  • PROCEDURE
  • VPC Endpoint Cross-region access
  • Service Name DNS Resolution
  • Services Needed
  • REMARKS
  • CONCLUSIONS
  1. Troubleshooting

Cross-Region Scanning on with private network

The goal is to avoid going to the internet and fetching everything from the AWS backbone. This is the AWS recommended solution, keep in mind that it is complex to configure, maintain, and costly

PreviousCloudFormation Stack failuresNextAPI Scanning: Could not connect to SSL/TLS (v7)

Last updated 1 year ago

OVERVIEW

For configuring cross-region access for AWS services without leaving the AWS Backbone first of all we need to follow the steps of leveraging endpoints for the console region mentioned in . Then we need to execute the same script in the desired region to interact with, allow communication through VPC endpoints and setup DNS resolution so the public url service endpoints get resolved to local ips instead of the public ones.

  • Console Region: us-west-2

  • Agent Region: us-east-2

PROCEDURE

AWS lines up what is needed in order to accomplish this task in the following two documents:

  • : despite it says one or the other both sections are needed.

VPC Endpoint Cross-region access

Above tutorials contain a lot of suppositions and don’t have the level of detail necessary to actually understand the needed changes. The following are some steps done in our development accounts in order to accomplish cross region:

  1. Apply CSS about leveraging VPC endpoints in the console’s and destination region.

  2. Configure VPC Peering Connections between the console and destination region VPCs. Ensure DNS settings are enabled for both:

  1. Configure route tables for both VPCs, in each of them add an entry containing the CIDR of the other region’s VPC and as destination the Peering connection:

  1. Validate no subnet contains access to a nat or internet gateway, meaning they can’t reach the internet. Create an Ubuntu instance that is in the Console’s region and subnet. Connect to it, probably using a bastion host (public instance within the same VPC but different subnet that can reach the private subnet).

So right now you are in the console’s subnet, validate you are able to reach the EC2 service belonging to the other destination region (in this case us-east-2) by running the following command with valid AWS Credentials:

ubuntu@ip-10-0-143-117:~$ aws ec2 describe-volumes --max-items 1 --region us-east-2 --endpoint-url "http://172.31.47.168"

Keep in mind the usage of the destination region and the local private IP of the EC2 VPC Endpoint of the us-east-2 region. This is necessary since there is no DNS resolution configured for the endpoint “ec2.us-east-2.amazonaws.com”.

Note also that without the endpoint specification the EC2 instance doesn’t know how to solve the service URL:

Service Name DNS Resolution

At this point we are able to reach the VPC Endpoint located in the destination region but without being able to automatically solve the EC2 service. Let’s get into it.

  1. Go to route 53 and add a new private hosted zone adding the console’s VPCs.

  1. Add an A record with Alias selected and the destination region VPC Endpoint as the target:

  1. Validate configuration by doing the Ec2 API call without endpoint specification:

Services Needed

Services that require this extra configuration since they are instantiated by the console in other regions:

  • EC2: For Networking stuff

  • ElasticFileSystem: To mount volumes

  • CloudWatchLogs: To build statistic results, protecting a bucket (creates CloudStorageSecurity.ECS.{EnvironmentVariables.AppConfigAgentApplicationId}.{serviceDescription} and handles retention policy)

  • CloudWatch (called monitoring): To create alarms.

  • S3 (interface + gateway): To gather bucket properties. Remember to add a wildcard for the global bucket access:

{bucket-name}.s3.{region}.amazonaws.com
  • SNS: To list topics

  • ECS: For ECS related tasks, like creating a cluster or a service

  • AppAutoScaling: for autoscaling policies triggered from CW Alarms

VPC Endpoints in the Agent Region

VPC Endpoints in the Console Region

Route53 custom endpoints configuration

REMARKS

  • The agent task running in the external region needs a proxy defined to reach DynamoDB or internet access to allow its resolution.

  • SNS notifications for the Agent will fail since it doesn’t know how to resolve the Console’s region SNS URL endpoint. A route53 entry resolution is needed for the console region associated with the agent region VPC and pointing to resolution for the VPC SNS Endpoint of the console. Also remember to add a rule to the Security Grouping allowing the VPC CIDR of the agent.

CONCLUSIONS

Using a private subnet allowing only a few services (Marketplace, AppConfig and Cognito) to go through the public internet (maybe behind a proxy) and then all the other services being accessed through VPC Endpoints is definitely doable, even for all the regions.

Pros:

  • Great reduction in the amount of traffic over the public internet.

Cons:

  • Increased infrastructure costs.

  • Increased infrastructure complexity, harder to configure and to maintain.

  • New AWS services usage from our part can break console functionality.

  • Costs: only the VPC piece cost around $10 daily for the Console region and $7 daily for each extra region.

our documentation
https://repost.aws/knowledge-center/vpc-endpoints-cross-region-aws-services
https://repost.aws/knowledge-center/vpc-peering-troubleshoot-dns-resolution
the CSS provided scripts