Amazon Virtual Private Cloud Reviews

Our main use case for Amazon Virtual Private Cloud is that it is our main network solution. It is mainly used to connect our nodes and also connect our on-premise nodes to the AWS VPC using the site-to-site connection.

The most beneficial feature of Amazon Virtual Private Cloud for our use case is the site-to-site connection, allowing our data centers to connect to the AWS EC2 nodes, which is currently the most useful feature for us.

The Elastic Network Interface is the main component of our networking services within Amazon Virtual Private Cloud, allowing us to connect to our nodes and enabling all node-to-node communication, node-to-customer, and customer-to-node interactions. It is a really helpful feature for us.

Amazon Virtual Private Cloud allows the nodes to talk to each other, enhances our security with its security group feature, and the network access list can isolate attackers, while the subnet service organizes our nodes' network topology and provides access to customers. It is a really great feature, and I would highly recommend it.

It would be great if we could use the AWS Direct Connect in Mongolia. That is our only issue with Amazon Virtual Private Cloud; other than that, it works well.

Our company has been working with the Amazon Virtual Private Cloud service for two years now.

We haven't had any challenges with the initial setup of Amazon Virtual Private Cloud. Everything was set up smoothly with just a few clicks.

I don't have any issues with Amazon Virtual Private Cloud so far, as most of it has been really great.

We haven't had any issues with data breaches and DDoS attacks.

We haven't asked anything regarding the EKS from AWS customer support for the Amazon Virtual Private Cloud product.

We mainly talked about other billing solutions, and while we have discussed Amazon Virtual Private Cloud with customer support, there were no questions regarding EKS.

Positive

Our previous network infrastructure before moving to Amazon Virtual Private Cloud was based on the VSphere, the VMware solution.

We decided to switch to Amazon Virtual Private Cloud mainly because it's AWS's native networking solution, providing us with peace of mind and fewer issues in the future.

We haven't had any challenges with the initial setup of Amazon Virtual Private Cloud. Everything was set up smoothly with just a few clicks.

I find the pricing of Amazon Virtual Private Cloud reasonable.

We've looked into other cloud solutions before moving to Amazon Virtual Private Cloud, but we haven't considered the benefits and disadvantages of the networking services, just the main cloud as a whole.

We have considered using the AWS Direct Connect, but there isn't any available solution for AWS Direct Connect in Mongolia, so we've opted for the site-to-site connection through Amazon Virtual Private Cloud.

We are doing fine with our other services. Most of our services are performing well regarding any other products or solutions that we're working with.

For the Amazon Virtual Private Cloud service, we haven't seen any measurable improvements in our workflow; we just moved from one networking infrastructure to another, so we haven't had any challenges. The only upside I can think of is that we can easily migrate to Amazon Virtual Private Cloud from our data centers.

I'm not really familiar with the pros and cons of Amazon Virtual Private Cloud compared to other competitors on the market, as I think it's just a standard networking service similar to other clouds.

I would recommend Amazon Virtual Private Cloud to other organizations considering it for their environment.

On a scale of 1-10, I rate Amazon Virtual Private Cloud a 9 out of 10.

The main purpose of Amazon Virtual Private Cloud is to provide a virtual networking environment.

From a functionality perspective, the customization features in Amazon Virtual Private Cloud are really flexible for customers. The ability to define and work with subnets is particularly helpful in managing the networking environment.

Based on my experience, there are aspects of Amazon Virtual Private Cloud that could be improved to enhance the solution.

I have been working with Amazon Virtual Private Cloud for four years.

I would rate the stability of Amazon Virtual Private Cloud as nine out of ten.

The scalability and ability to expand within Amazon Virtual Private Cloud performs very well.

The technical support from Amazon has been excellent. I am totally satisfied with the quality of support they provide.

Positive

The initial setup process for Amazon Virtual Private Cloud was straightforward.

There are competitors to Amazon Virtual Private Cloud that I might have compared or used.

I consent to having my personal name associated with my review on PeerSpot, without contact details or company name. I understand that PeerSpot will publish my written review on peerspot.com for other users to access. I can edit my review at any time, and my review may be shared with third-party websites. If I choose to remain anonymous, my name will not appear with the review. I have opted to receive email notifications related to my review, which I can opt out of at any time. The use of my review is subject to PeerSpot terms of use.

I rate Amazon Virtual Private Cloud a 10 out of 10.

I'm working with EC2 and AWS S3 buckets. I have created an architecture featuring a whole VPC that contains EC2 instances and databases. It is a multi-tier architecture, including components such as security groups handling inbound and outbound traffic. 

I know where to direct the traffic. I have used AWS Guard, AWS Shield, and more in terms of security. I was creating an application for an events company, and we made a VPC with traditional infrastructure. 

We built instances connected via load balancers to manage traffic. We created security groups on different instances, including the EC2 instances using m3.large. We used T2.large for databases, managing traffic for a local infrastructure without needing CloudFront. Traffic was directed from portals to EC2 instance servers, and information was stored in the database. 

We set up lifecycle policies in the database for data retention, moving data to Glacier state when needed using S3 buckets. We transitioned objects from the initial stage to the Glacier stage. Our infrastructure included EC2, a database engine using MySQL, and security measures as described earlier.

In terms of the system, I love the functionality of a NAT Gateway. For instance, when I was using it, it was easy to refuse certain traffic from penetrating into my other availability zone. I had to use a NAT Gateway to transition traffic only to the desired portal. Due to using Amazon VPC, it was reliable, efficient in operations, and cost-effective. 

For scalability, it was beneficial when one instance was down in an availability zone, as we had a standby instance. This ensured that when an availability zone in South Africa went down, another one in the US was available. We used methods like backup, restore, and pilot standby to recover data, and AWS Trusted Advisor guided us on cost optimization. We achieved an average of 70% cost reduction through savings plans for reserved instances and Spot Instances for short-term development servers.

I would look at database options for improvements. There is a specific configuration where I was using a Windows Server, and I could not configure RDS Oracle on it. I believe they need to revise how we can configure different database and server dynamics.

I have been working with AWS Shield for a short time, primarily using Guard. For Shield, my focus has been on traffic. I have worked with the VPC for about two years, creating various architectures, including database and serverless architectures. Depending on the client's job, I have been working with the PTC system for four to five years.

In terms of reliability, it is stable because it enhances the protection of the EC2 instances we create. You end up seeing that at the subnet level, you define particular rules for traffic flow. The security aspect, while not overly critical, is very important.

When it comes to the scalability aspect, I find it scalable. For example, I used AWS for scaling my architecture and employed multiple availability zones. I considered disaster recovery as well, ensuring that if I had one architecture in one availability zone, there was another in a different zone.

I have not worked with support directly, however, whenever there are issues needing technical support, they consult me on what should be applied or adjusted. My role is to guide the infrastructure path to prevent incidents and support disaster recovery without delving into the technical details.

Neutral

Apart from AWS, I have not extensively used other solutions, however, I am somewhat knowledgeable about GCP. I understand virtual machines, storage, and security configurations in GCP, which helps me tackle GCP-related tasks due to my background as a cloud architect.

I find the initial setup virtually straightforward. When I was building my VPCs, including traditional and serverless architectures, there was no real complication when applying AWS services to an infrastructure. The process felt very manageable.

We had about three team members, including two DevOps engineers and myself, an AWS Solutions Architect. We created roles, assigning each person responsibilities—one for the production environment and another for development, and I managed the overall environment, with IAM roles assigned accordingly.

I rate the solution an eight out of ten.

Currently, I am in operations. We have clients that we support with their infrastructure and multi-cloud operations. We use AWS, Azure, and some parts of Google.

Mainly we are using EC2, RDS, S3, VPC Network components.

That depends on our role as we are supporting infrastructure. When clients are using applications, we are not involved with their applications, but we support them with infrastructure.

We use it for network fundamentals.

For security and ACLs, Routing Tables, route tables, subnet, and subnetting, these are very useful functions.

For public and private subnetting, we need subnets.

The good part is what I mentioned regarding security reasons and subnetting. I cannot think of any bad aspects of Amazon Virtual Private Cloud.

There is always a chance to improve.

I have been using it for around 7 years. I started working with AWS and Amazon Virtual Private Cloud in 2018.

When we use business support, the availability of the engineers is very good.

Positive

It is very simple compared to my previous experience. I used to work in a data center with virtualization where we handled VLAN and other network virtualization and storage virtualization. This has been simplified to the core on cloud.

The only alternative I can think of is Microsoft Azure.

They have developed a product that works for both large-scale and small-scale industries. The UI is very user-friendly. The services are very well defined in AWS, and newcomers will not get confused, unlike in Azure.

I have started exploring AI, and I am using cloud and ChatGPT. I can say I am using prompt engineering.

I rate Amazon Virtual Private Cloud a nine out of ten.

Whenever we launch an instance, it depends on the requirements of the customers. They might use a default VPC. We always recommend that customers or anyone customize the VPC. We'll want to create a VPC with subnets, routes, and an internet gateway.

We also use the AWS console, GUI, and CloudFormation to set it up. We can also trigger it from Terraform. Three methods we use.

Security groups are very useful. But their effectiveness depends on your specific requirements.

For example, we have a website using HTTP and HTTPS traffic. We configure security groups to allow those ports (80 and 443).

However, if we're configuring something like Grafana and Prometheus, the security groups will be different. Grafana might use port 3000, and Prometheus might use port 9090. These configurations depend on the client's needs.

That's the basic idea, but some applications have standard ports. For instance, Apache uses port 80 for HTTP and 443 for HTTPS. Security groups help secure these applications by controlling access.

We can also use security groups to restrict access to specific IP addresses. For example, instead of opening a port to the entire internet (0.0.0.0/0), we can define specific IP ranges that are allowed to access the instance through that port.

VPC itself is pretty good, but understanding it well is key. One of the challenges for beginners is understanding IP address ranges and subnet concepts. For example, why use a /16 CIDR block for a VPC versus a /24? It's important to understand these concepts before creating a VPC.

Once you understand the basics, you can leverage VPC features based on your architecture. For example, a three-tier architecture (web application, database, etc.) can benefit from public and private subnets. The web application can reside in a public subnet for internet access, while the database can reside in a private subnet for security, only accessible through the web application. This helps isolate resources and improve performance.

So, the first step is understanding VPC creation and then using subnets (public and private) based on your architecture. Public subnets can connect to the internet, while private subnets cannot by default. For internet access in a private subnet, you can use a NAT Gateway and route tables.

Other components include the internet gateway (for public subnet internet access), Elastic IPs (static IP addresses), and more advanced options like VPN connections, AWS PrivateLink, etc.

Once you grasp these basic concepts, you can explore the more advanced features.

My career started with this Solution, so I have about four years of experience in total.

Before coding, I studied Linux because my background was in mechanical engineering. Then, my cousin recommended these channels to learn, and that's how I got into the cloud, specifically AWS. From the beginning, I've been working on integration. Now, in the last year or so, I've been using Terraform.

Most stability issues come from Availability Zones. During VPC creation, if something goes wrong, it's usually related to zones or subnets. We can check these and troubleshoot them. 

For example, if an Availability Zone has an issue, it might not reflect properly in the admin console. We'd troubleshoot and fix the issue.

Scaling an Amazon VPC itself isn't really possible. You can't increase the VPC's capacity. But we can scale the resources within the VPC.

For example, I have a website using an Application Load Balancer. End users hit the website, and to handle the traffic, I use the Load Balancer to distribute the requests. But what if the request volume keeps increasing?

That's where Auto Scaling Groups (ASG) come in. They offer two types of scaling: horizontal and vertical. Horizontal scaling, or scaling up, adds more instances to handle the increased load. Vertical scaling wouldn't apply to VPC itself, but it can be used to change instance types within an ASG for more processing power.

Here's an example of horizontal scaling: Suppose your instance CPU usage reaches 100%. An ASG with a properly configured policy will automatically scale up by launching a new instance to share the workload.

These policies are customizable within the ASG. You can define how the scaling happens based on your needs. For instance, you might want to automatically scale up based on CPU usage and scale down based on memory usage to maintain optimal resource utilization.

There are many different policies you can configure within an ASG.

In auto-scaling policies, we can define actions based on metrics like CPU usage. For example, if CPU usage reaches 90%, the policy can automatically scale up by launching a new instance.

The customer service and support are good. Mostly, I can resolve networking issues myself. For some advanced services like WAF (Web Application Firewall), I might need to ask support for clarification. But for most things, like troubleshooting database endpoint connectivity issues, I can handle it myself.

VPC is the core networking component for AWS. You can't really do much without it. It's like Azure having VNets (Virtual Networks) - virtual networking is essential. You can't achieve much without those.

The initial setup is easy. I've deployed VPCs many times. However, if there are errors and something isn't configured correctly, then troubleshooting can be a challenge.

But overall, it's pretty straightforward and easy to handle. Moreover, integrating VPC is easy. We use VPC when launching EC2 instances. We can also integrate VPC with subnets for RDS databases. Mostly, I've integrated VPC with databases and instances across three VPCs.

The deployment time depends. If it is a basic VPC deployment, I will write the code and deploy. 

If you're using the AWS console GUI and you know what you're doing with CIDR blocks and network components, you can create a VPC, subnets, routes, and an internet gateway within five minutes.

With code, it takes longer. However, using the AWS CLI is faster than code. In my experience working with US customers, they often use CloudFormation templates (CFT) to create VPCs, load balancers, etc. CFT is very secure.

Overall, I'd rate VPC as a nine out of ten. It's a powerful tool, but understanding the fundamentals is crucial.

Here's my advice: If you're starting out, focus on understanding the fundamentals. Be strong in the basics, like CIDR ranges and classic networking concepts. With a strong foundation, you can troubleshoot issues more easily and find solutions.

Also, if you plan to use Terraform later, start by learning the GUI. Create a VPC, subnet, and internet gateway in the GUI first. This will help you understand what the Terraform code is doing. If you jump straight into writing Terraform code, it might be difficult to grasp what's happening behind the scenes. Learn the GUI first, then Terraform. That's my approach.

VPC is basically about networking and how you are setting up the networks.

VPC, or Virtual Private Cloud, is like a secure portion of AWS's public cloud. So, if you want to secure your dedicated network areas, we use VPCs. Traffic should be slow, and no unwanted people should enter your network, especially because we work at an enterprise level. That is why we must be thoughtful and careful about using VPCs.

We use VPC as a service provided by AWS. So, Amazon keeps enhancing the product.  

In Amazon VPC, there's a service called VPC Peering, where we can connect multiple VPCs from different accounts. However, AWS also introduced new tools like Transit Gateway, based on the Hub and Spoke model. At a single hub, you can route from multiple locations, and that is more efficient. So, this is how it goes.

The subnetting feature has impacted our network design. So, subnetting is very, very important and crucial when it comes to your infrastructure design and presentation. 

Subnetting is completely crucial. For example, suppose I'm an enterprise customer. I have to be very thoughtful and decide, like, "Okay, how many route tables am I going to have?" Let's say you are company XYZ, and you want to make sure that, out of one million IP addresses, let's say, 50,000 should be on a round table. Also, 50,000 IP addresses should go to external ones, and the rest should be for internal use only. Like, you have other third-party software that you have hosted as an enterprise customer. 

In this case, subnetting plays a vital role. You have to be thoughtful, like, "Okay, are you going to use 32 bits? How many IPs do you want to use?" And you have to be very thoughtful about choosing the application. For example, in Kubernetes, we are very thoughtful about using the IPs. They can easily exhaust the IPs. So we have to be very thoughtful about that. So,  subnet skills play a very vital role.

It's all about networking. So VPC, VPC peering, and those features. That's all about the networking aspect of VPC. I like it. 

For network security, Network Access Control Lists (NACLs). They work very well. For example, instead of leaving a resource open to the world with something like 0.0.0.0/0, we can use NACLs to be much more specific with our network traffic rules. It adds an important security layer to our infrastructure.

There is always room for improvement. It can be in support. 

I've been using it for more than three years. 

The stability of VPC itself is incredibly high. AWS guarantees 99.9999999% uptime; it's super reliable.

VPC is not about scaling up the world; it's about securing the infrastructure. For example, you start in AWS by creating an EC2 instance to deploy infrastructure for an application, which is good. 

But maybe not today or tomorrow, but in a year, you'll need to ensure security. Since you work in enterprise scenarios, you have to be very thoughtful. 

Whatever system you create on the cloud, the type of VPC we use will ensure that the infrastructure I create is accessible only by my team members and not by the outside world. We use a NAT gateway for part of the private cloud, which adds a lot of complexities to the model.

So, scaling up or down is handled by Auto Scaling groups and launch templates.

My company and the enterprise clients I work with all use it.  

I ran into some issues. I created a support ticket with AWS, and they set up a call with me on AWS Chime. Their networking architect helped me troubleshoot the errors. They were really helpful.

Positive

I use many tools, like infrastructure services, software services, and Platform as a Service. As a DevOps engineer, I have touched base with all the services. 

Starting from the basic ones like EC2, VPC, subnets, to Lambda functions, API gateways, CloudWatch, AWS Glue, Athena, SageMaker, DynamoDB—all these things I have used.

If you have knowledge of network ACLs and security groups, then you can easily set up network ACLs and security groups in VPC. 

In layman's terms: think of a security group as the front door of an EC2 instance. It controls what comes in and goes out of your EC2. A NACL is like security at the subnet level – it controls what can enter your subnet via the NACL. So, security groups are on EC2 instances, NACLs are on subnets.

The process of integrating VPC with other AWS services is easy and seamless. That's the beauty of AWS – the services are tightly integrated within the AWS console. You can switch between them easily and do what you need. You can manage it directly from the console or automate it with Terraform, it's up to you.

The pricing depends on usage. 

I would definitely recommend using it. If you're working at an enterprise level, or even if you're a startup building software or a website, and you want to ensure security and long-term stability, then absolutely use VPC and configure your network carefully.

Overall, I would rate the solution a nine out of ten. There is always room for improvement. 

We have hosted 400 applications with the help of Amazon Virtual Private Cloud.

The product’s most valuable feature is allowing us to control access for specific workloads or traffic within a particular region.

The product is restricted to a particular region. They should provide a global architecture. So that it will save a lot of time considering repeated configuration tasks.

We have been using Amazon Virtual Private Cloud for five years.

The product’s stability is good. I rate it a nine out of ten.

I rate the product’s scalability a nine out of ten.

The technical support team’s response time is good. We are an enterprise customer. They have appointed a dedicated manager to handle critical issues for us.

Positive

The product is easy to set up. Although, it is complicated for more features and configurations. It takes weeks for manual implementation. We have automation scripts. Thus, it takes 30 minutes to complete.

The product is expensive. But if you use AWS products consistently, the cost reduces by 30%.

It is an easy-to-use product, and I rate it a nine out of ten. I advise others to use the system in a sandbox environment. It helps them learn about the security and configuration of AWS, and after that, they can gradually shift to critical workloads.

I use Amazon VPC because whenever I need to isolate some services or components of the architecture, I start with the VPC. Then, I create some public or private subnets in it.

Amazon VPC positively impacts organizations by providing robust security and isolated environments, reducing the risk of security incidents and ensuring efficient network management.

I like that within the same AWS account, you can have different scenarios and workloads. You can isolate workloads using different VPCs, reducing the exposure of critical services. Another valuable feature is the capability to create both public and private subnets, allowing for enhanced security and segmentation of resources. Additionally, the integration of VPC with other AWS services is seamless, and setting up security groups and network ACLs has become easier over time.

I would like to see an improvement in the process of peering multiple VPCs. It should be easier to select different VPCs for peering. However, I need to revisit the platform to verify if these improvements have already been made.

I have been using Amazon VPC for approximately eight years, from the very beginning.

Personally, I have not had any issues with the stability of Amazon VPC. However, I have heard from colleagues that improper network configuration from the beginning can lead to complex issues over time. It is essential to set up the network correctly to avoid stability problems.

Amazon VPC offers excellent scalability. As long as the components are appropriately separated, you can create scaling groups or policies. Even if a particular feature does not support direct scaling, you can complement it with additional events and policies to achieve scalability. Though scalability might involve some downtime, it is generally straightforward within the AWS infrastructure.

AWS provides very fast customer service and support and is strongly committed to customer satisfaction. I have had the chance to talk directly with the product's developers when necessary, and they have been very responsive.

Positive

I find the initial setup of Amazon VPC to be very easy, especially over time. Initially, it was more complex, but now with proper planning and a logical diagram, setting up through the console is straightforward.

In some projects, clients specify what to include and exclude for internal use and public access. If the client is open to suggestions, I analyze the data flow and volumetry to determine the proper setup.

The cost of Amazon VPC depends on the components you put inside the VPC and the traffic volume. While the direct cost of the VPC is usually not problematic, the associated components and their traffic can influence the overall expense.

I'd rate the solution ten out of ten.

The main use case is that it's a virtual private cloud. We used it to create a private network. We created resources inside our VPC to isolate them from other public resources. 

We can create different subnets, like public and private subnets. We use private subnets to secure our resources and public subnets for publicly accessible resources.

Compared to other clouds, Amazon VPC excels at letting you create your own network and at load balancing. If we have created many resources in a specific Availability Zone, we can create resources in other zones and assign subnets. 

This makes it a good solution for a company network, especially if you need to isolate resources from other companies.

In Amazon VPC, there's room for improvement. For example, when we create security groups, I think we should be able to restrict outgoing traffic to secured websites. I know there's a method to restrict that, but we should also be able to design outgoing traffic restrictions at the system level. We should use that to deny ports instead of relying solely on network access controls at the subnet level. 

Another thing is that I think there should be restrictions within the security group itself, not just for the whole subnet. For instance, when we allow traffic into a specific EC2 instance within a security group, that's only allowing incoming traffic. It doesn't control outgoing traffic. 

Specific ports should not be allowed to export traffic outside, preventing anyone from getting that traffic. For example, if the port is allowed, it shouldn't allow traffic on port 82 or whatever specific port it is. It needs to control outgoing traffic.

I have used it extensively. The last time I actively used it was about two months ago. I configured it for our company.

Now, we are shifting towards Azure because my client is trained now, and they use Azure. 

It has been a stable product. I haven't seen any bugs so far. It's been good and reliable for security purposes. 

I'm pretty comfortable with it, but creating a VPC involves specific steps. That part could be easier.

The number of VPC users depends on how many people are on the team. In our team, maybe seven or eight people use it. That's because VPC access is usually for the engineering team to configure or access the VPC. Other people can't do that.

I have contacted the customer service and support regarding my account or for billing purposes, but not specifically for VPC support.

I use Azure Kubernetes Service.

If you're a beginner, then it can be somewhat difficult because you have to manually perform several steps to create a complete VPC. For instance, you need to create separate subnets, like an internet gateway, and attach them. This is a tedious task. 

There should be a method for preconfiguration, so we don't have to manually create an internet gateway, attach it to a public address, and then lastly configure private components. 

I think this presents a technical challenge for beginners because you have to remember specific steps and perform them manually. It would be better if there were preconfigured options so it's less manual. 

We shouldn't have to attach an internet gateway to a subnet and then configure permissions. This aspect should be simplified within the organization.

I'm an end-user. My clients are the primary users, and they ask me to configure their Amazon resources. So, I'm part of the team that uses VPC.

It is cheap compared to other clouds. 

My primary task was configuration. However,  Amazon VPC is generally affordable. There might be costs if you need to reserve specific IPs. Otherwise, it's easy and cheap.

For technical purposes, I would suggest using it because it's very capable, like other routing solutions. But if you want to configure it, I'll warn you that it's not as easy as it could be. 

You might want to find an easier way or alternative because configuring a VPC is not straightforward.

Overall, I would rate it a seven out of ten. I'm comfortable with it, and I can use VPC to secure my cloud resources. It offers public and private subnets, which allows for easy communication and protection of our resources. That's the reason for my rating.

Based on processing data, we find VPC is very important. Every network is isolated from the outside and private as well. 

Our plan involves the provisioning of a private network using a VPC. In this process, we will distinctly segregate private and public components. This includes the creation of private subnets and the integration of services such as Amazon RDS. The implementation of databases, be it for work or other purposes, will occur within these private subnets.

This configuration is designed to cater to various stakeholders—clients, the public, users, and applications. This architectural approach extends beyond public communication.   

So communicating could be within applications and via Net Gateway, or we will use some VPC endpoint as well. So this could be an architecture.

Benefits are like easy to implement, and then it could be cost-saving. And then my clients give a lot of features in that VPC. And then they're giving a lot of security as well for the VPC level. So this could be a benefit for the clients and me.

This solution is valuable to me because it gives me some security level, and it easy to implement as well.

There is room for improvement in UI. 

I have been using this solution for six years.

It is a stable solution. I didn't face any downtimes.

It is easy to scale up and scale down. It is a scalable solution. We can scale it according to our requirements. 

We are working on the VPC level, at that time, we can only able to fix that in, like, 30 days of logs, but we need up to 60 days. So, we raised a ticket to the AWS product. So they gave a solution.

Neutral

I have used GCP. Its console is more user-friendly and could be easier to implement.

For GCP, they have a firewall and then a virtual network. So, we can build a virtual network more easily compared to AWS. 

Also, they provide a lot of security, GCP. Also, they play an important role in the public cloud. 

But for me, I can go with AWS and GCP, both.

At a basic level, you need one VPC. In that, you need to implement private blocks. And then, based on your criteria, whether you are working in public or private, you need to create a subnet, including private or public. And then, based on your requirement, whether the VPC is appearing between them or you're only working on one VPC event, it could be more than enough to create a subnet. 

And then, based on the client level, you can implement the database in private and then apply it in public.

One person with capable knowledge can implement the solution. The time taken for deployment depends on the requirement. 

For example, at a single application level, it took only one hour. However, at the enterprise level, it can take a week. 

There is no maintenance required. AWS takes care of the maintenance. That's another benefit people go with AWS.

VPC is a free cost, and then subnet also is a free cost. So the only cost could be for the resources we implemented in that. 

That could be a cost for me.

First of all, try to study the CCNA and then try to understand the network flow, then study TCP and UDP protocols, and try to understand the OSI model. So, this could be very basic to understand the network traffic. So whether anything happens at this level, you'll be fully able to know what could be happening.

Overall, I would rate the solution a ten out of ten.