How to make requests from different IP addresses on Google Cloud Platform or AWS - amazon-web-services

I am building a software that will consume a third-party API which limits my connection at 1200 requests per minute (from the same IP address).
Since this limitation is very low for me, I've been wondering if there's a way to have a set of IP addresses (let's say 100 addresses) and manage the queue so that once an IP exceeds the limitation, the next request will be made from a new one.

Google Cloud Platform (GCP)
Your will need two or more VPC networks. If you only have the default one, create an additional one. Each network adapter will connect to one VPC network.
Create a VM instance with two or more vCPUs. While creating the instance, attach a second network adapter connected to the second VPC network.
In your software, instead of creating a socket on 0.0.0.0, you create a socket for each network adapter private IP address. Ping pong back and forth between adapters spreading your traffic across your public IP addresses.
You can do the same type of configuration on AWS.

Related

Compute Engine in VPC can't connect to Internet & Cloud Storage after establishing Cloud VPN

Assuming I have a custom VPC with IP ranges 10.148.0.0/20
This custom VPC has firewall rules to allow-internal so the service inside those IP ranges can communicate to each other.
After the system grows I need to connect to some on-premises network by using Classic Cloud VPN, already create Cloud VPN (the on-premises side configuration already configured by someone) and the VPN Tunnel already established (with green checkmarks).
I also can ping to on-premises IP right now (let's say ping to 10.xxx.xxx.xxx where this is not GCP internal/private IP but on-premises private IP) using compute engine created on custom VPC network.
The problem is all the compute engine instance spawn in custom VPC network can't communicate to the internet now (like doing sudo apt update) or even communicate to google cloud storage (using gsutil), but they can communicate using private IP.
I also can't spawn dataproc cluster on that custom VPC (I guess because it can't connect to GCS, since dataproc needs GCS for staging buckets).
Since I do not really know about networking stuff and relatively new to GCP, how to be able to connect to the internet on instances that I created inside custom VPC?
After checking more in-depth about my custom VPC and Cloud VPN I realize there's misconfiguration when I establish the Cloud VPN, I've chosen route-based in routing option and input 0.0.0.0/0 in Remote network IP ranges. I guess this routes sending all traffic to VPN as #John Hanley said.
Solved it by using policy-based in routing option and only add specific IP in Remote network IP ranges.
Thank you #John Hanley and
#guillaume blaquiere for pointing this out

GCP: Is traffic to a VM public IP encrypted within a single region?

I want to use a Cloud Run container that sends HTTP traffic to a Compute Engine VM via public IP address.
Internal IPs are not possible as Cloud Run does not support VPC.
Cloud Run is regional which means my container can run in any of the zones in a region.
Is the plain text HTTP traffic I send from the Cloud Run instance to my Compute Engine VM public IP encrypted within a zone, or between zones in a region?
https://cloud.google.com/security/encryption-in-transit#end_user_internet_to_a_customer_application_hosted_on_google_cloud
VM to VM traffic, using public IP addresses, is not encrypted by default and its security is provided at the user's discretion.
This is mentioned for connections from the end user over the internet, but its unclear if plain text traffic between zones is encrypted?
If your traffic is in HTTP, the traffic is not encrypted. However, your tcp packets won't go on the public internet and will stay on Google private network.
The zones in the same region are connected with Google private network and, I'm sure, with a low layer encryption (something like IPSec).
So, now, all depend your concern:
Is the traffic HTTP traffic encrypted? No
Is your tcp packet are in plain text on public internet? No
Is there a low layer transport encryption on Google private network? Yes

Allow a network connection between 3 different environments

I've 3 environments: AWS environment and 2 isolated on-premises environments. The on-premises environments have a VPN connection and can communicate properly together. One of these 2 on-premises environments has a VPN connection to AWS environment. However, there's an application that will be built on AWS that needs access to the on-premises environment that doesn't has VPN connection to the AWS environment.
How to allow the connection between these environments without having to establish a new VPN connection between them?
What you need is AWS Direct Connect: https://aws.amazon.com/directconnect/
"AWS Direct Connect lets you establish a dedicated network connection between your network and one of the AWS Direct Connect locations. Using industry standard 802.1q VLANs, this dedicated connection can be partitioned into multiple virtual interfaces. This allows you to use the same connection to access public resources such as objects stored in Amazon S3 using public IP address space, and private resources such as Amazon EC2 instances running within an Amazon Virtual Private Cloud (VPC) using private IP space, while maintaining network separation between the public and private environments. Virtual interfaces can be reconfigured at any time to meet your changing needs."
Before you set this up, you better plan out your ip ranges in your VPC since you don't want to use the ip ranges that your onprem network occupied.
If you want to use only VPN you can do it in two ways.
Option 1
From the picture below you have only VPN 1 and VPN 2.
In this case your application will be on C and it needs to access something on B.
A router on A will know how to communicate with both networks, B and C.
So it will be like this: C -> A -> B
More slow, but works fine, and probably it should already work today withou any new configuration/change.
Option 2
From the picture below you will crate the new VPN 3 between C and B.

How to setup VPN from on-premises to Google Cloud VPC

We want to be able to connect to my on-premise database from our google cloud kubernetes.
We are currently attempting to do so by using "Create a VPN connection" from within the google console.
In the field IP address, I am forced to create (or pick from existing) "External IP Addresses".
I am able to link a single VM-instance to this External IP Address. But I want my VPN connection/tunnel to be between my on-premises network and EVERYTHING within my Google cloud network.
This IP should not just work as External IP Addr. for a single instance. I need to make it a gateway to the network as a whole. What am I missing?
Thanks in advance.
Another way to frame the question:
How do I find the IP Address of the gateway to my Google cloud network (VPC) and how do I supply that IP to the VPN Connection creation ?
The Cloud VPN connects your on-premises to the VPC, that means every Instance, Cluster or other products that use Google Cloud Engine (GCE).
As mentioned in a previous answer from avinoam-meir the VPN has at least two components: Gateway and Tunnel but I will add a third one: Type of routing.
a) Gateway: This is where you can add an existing or reserve any static IP address (from the Google Pool of External IP Addresses).
b) Tunnel: Where the encapsulated and encrypted traffic will flow to reach the Local IP ranges.
c) Type of routing: Cloud VPN has three possibilities:
Tunnel using Dynamic Routing
Route Based VPN
Policy based VPN
Depending on the type you choose, the routing happens in a different way but in general terms, it will propagate your subnetwork(s) to your on-premises network and receive the routes from it.
Important: Remember to open your firewall on your GCP VPC to receive traffic from your on-premises IP Ranges as the default and implied rule for Ingress will block it.
The implied allow egress rule: An egress rule whose action is allow, destination is 0.0.0.0/0, and priority is the lowest possible (65535) lets any instance send traffic to any destination.
The implied deny ingress rule: An ingress rule whose action is deny, source is 0.0.0.0/0, and priority is the lowest possible (65535) protects all instances by blocking incoming traffic to them.
The answer was simpler than I thought.
My question was:
How do I find the IP Address of the gateway to my Google cloud network
(VPC) and how do I supply that IP to the VPN Connection creation ?
The answer is simply to fill out the "Create a VPN connection" page. It automatically sets up whatever IP you get/choose in the "IP Address" field as the gateway. I did NOT need to configure this IP address to work as a gateway. Simply getting it assigned in this step is enough. Google does the rest behind the scenes.
You need to distinguish between gateway IP address and local IP range of the VPN tunnel
The gateway IP address is the IP of the gateway where all the packets from your on-premises arrive encapsulated and encrypted.
The local IP range of the VPN tunnel is the range of IPs that can be reached through the VPN tunnel. By default this is all the
private IP addresses of your GCP network
Create a NAT gateway [1] with Kubernetes Engine and Compute Engine Network Routes to route outbound traffic from an existing GKE cluster through the NAT Gateway instance.
Use that NAT gateway IP address to create a VPN connection to remote peer gateway.
[1] https://cloud.google.com/solutions/using-a-nat-gateway-with-kubernetes-engine

Is internal traffic on Google Compute Engine secure

Is network traffic using internal ip addresses on Google Compute Engine secure? E.G. is communication between two VMs in different regions over internal (10.X.X.X) addresses really private to my project?
GCE uses a software-defined networking stack. This means that packets in your private network will only be delivered to the intended destination endpoint in your internal network. This is quite different to a traditional "bare-metal"/wired network and resembles authenticated API calls more than simply sending packets out on the wire.