I have a Google Cloud Compute Engine Windows VPS. I wanted to know that if i try to upload files on Google Drive from VPS will it charge me network fees.
as per the chart below I thought it will not because google cloud VPS and Google Drive is from Google and utilizing other google services from VPS is free. Please tell me if i am wrong? just wanted to confirm
Yes, you are right.
Network Egress traffic to Google products (such as YouTube, Maps, Drive), whether from a VM in GCP with a public (external) IP addresses or private (internal) IP addresses has no charge
General network pricing.
I know it used to be a promotional price but now it's in the General network pricing list as 'No charge'.
Related
Does changing the network service tier for a project in Google Cloud change or otherwise interrupt existing, running network services such as load balancers and compute engine VMs or does it only apply to new things?
Documentation suggests the latter, but we don't want to mess with this setting without getting a definitive answer.
Does changing the network service tier for a project in Google Cloud
change or otherwise interrupt existing, running network services such
as load balancers and compute engine VMs?
Existing services will not be interrupted.
The network service tier affects how traffic is routed from the client into the Google Cloud Network. Premium Tier means that clients will connect to the closest entry point (POP) into Google's network.
This does not directly affect services but does affect routing and latency of traffic to services. I am not aware of any direct impact on your services in the cloud except for the pricing of network traffic.
If Premium Tier is not enabled some features are not available such as global IP addresses.
Always configure Premium Tier. There are no solid technical reasons to select Standard Tier.
I have seen the statement that "outbound traffic from GCP to other Google products (such as Google Drive) is free".
I would like to confirm if this statement is true？
This is only true, while transferring data on the internal network 10.0.0.0.
When using the public network (external IP), you'll be charged for the traffic.
You will find a list of all the use case for GCP to non-GCP product traffic costs at this page. Section "VM-to-Google service".
But your initial statement is correct, traffic from a VM in GCP to Drive is free regardless of if the VM has a public or private IP. That's because that traffic never leaves Google backbone
We currently have an on-site DNS server which manages what users can and can't access.
We would like to move this to Google Cloud, would this be possible? Or is Google Cloud DNS just for your own domain rather than a DNS server monitoring DNS requests and managing traffic?
Thanks
Google Cloud DNS doesn't provide any DNS-based blocking / filtering like SafeDNS, OpenDNS or similar solutions.
Have a look at the documentation Google Cloud DNS:
Google Cloud DNS is a scalable, reliable, and managed authoritative
Domain Name System (DNS) service running on the same infrastructure as
Google. It has low latency, high availability and is a cost-effective
way to make your applications and services available to your users.
Cloud DNS translates requests for domain names like www.google.com
into IP addresses like 74.125.29.101. Cloud DNS is programmable. You
can easily publish and manage millions of DNS zones and records using
our simple user interface, command-line interface or API.
We have all of our cloud assets currently inside Azure, which includes a Service Fabric Cluster containing many applications and services which communicate with Azure VM's through Azure Load Balancers. The VM's have both public and private IP's, and the Load Balancers' frontend IP configurations point to the private IP's of the VM's.
What I need to do is move my VM's to AWS. Service Fabric has to stay put on Azure though. I don't know if this is possible or not. The Service Fabric services communicate with the Azure VM's through the Load Balancers using the VM's private IP addresses. So the only way I could see achieving this is either:
Keep the load balancers in Azure and direct the traffic from them to AWS VM's.
Point Azure Service Fabric to AWS load balancers.
I don't know if either of the above are technologically possible.
For #1, if I used Azure's load balancing, I believe the load balancer front-end IP config would have to use the public IP of the AWS VM, right? Is that not less secure? If I set it up to go through a VPN (if even possible) is that as secure as using internal private ip's as in the current load balancer config?
For #2, again, not sure if this is technologically achievable - can we even have Service Fabric Services "talk" to AWS load balancers? If so, what is the most secure way to achieve this?
I'm not new to the cloud engineering game, but very new to the idea of using two cloud services as a hybrid solution. Any thoughts would be appreciated.
As far as I know creating multiregion / multi-datacenter cluster in Service Fabric is possible.
Here are the brief list of requirements to have initial mindset about how this would work and here is a sample not approved by Microsoft with cross region Service Fabric cluster configuration (I know this are different regions in Azure not different cloud provider but this sample can be of use to see how some of the things are configured).
Hope this helps.
Based on the details provided in the comments of you own question:
SF is cloud agnostic, you could deploy your entire cluster without any dependencies on Azure at all.
The cluster you see in your azure portal is just an Azure Resource Screen used to describe the details of your cluster.
Your are better of creating the entire cluster in AWS, than doing the requested approach, because at the end, the only thing left in azure would be this Azure Resource Screen.
Extending the Oleg answer, "creating multiregion / multi-datacenter cluster in Service Fabric is possible." I would add, that is also possible to create an azure agnostic cluster where you can host on AWS, Google Cloud or On Premises.
The only details that is not well clear, is that any other option not hosted in azure requires an extra level of management, because you have to play around with the resources(VM, Load Balancers, AutoScaling, OS Updates, and so on) to keep the cluster updated and running.
Also, multi-region and multi-zone cluster were something left aside for a long time in the SF roadmap because it is something very complex to do and this is why they avoid recommend, but is possible.
If you want to go for AWS approach, I guide you to this tutorial: Create AWS infrastructure to host a Service Fabric cluster
This is the first of a 4 part tutorial with guidance on how you can Setup a SF Cluster on AWS infrastructure.
Regarding the other resources hosted on Azure, You could still access then from AWS without any problems.
I read the hipaa doc from google, i'm no sure is the google cloud load balancer hipaa complince. google cloud hipaa
google says all the networks and regions are hipaa complince, i think this includes this products:
VPC
cloud DNS
cloud interconnect
cloud cdn
cloud load balancer
is this correct or i'm wrong?
I think it is because kubernetes engine uses cloud load balancer.
According to the documentation that you provided and in here network is covered by HIPAA.
"The Google Cloud BAA covers GCP’s entire infrastructure (all regions, all zones, all network paths, all points of presence)"
But lets not forget that you need to do your bit by securing the environment and applications that run on top of GCP, hence why it's called a shared security model.