Amazon Virtual Private Cloud Reviews

You cannot provision an EC2 server or an EFS instance in AWS without putting them inside a Virtual Private Cloud. If the EFS is connected to a Lambda, then the Lambda also has to be inside the same Virtual Private Cloud. By adding inbound rules to the Virtual Private Cloud's Security Group, you can tighten the security of the resources within it.

Amazon Virtual Private Cloud gives you security. If you put something inside Virtual Private Cloud, then you can add rules to that Virtual Private Cloud, and allow connections from IP addresses and allow connections to an IP address. The inbound and outbound connections can be limited based on IP address. Thereby it adds security. It's a feature of security groups, but that is another AWS service. We put a resource inside a Virtual Private Cloud and then connect a security group to that Virtual Private Cloud, in which we define the traffic rules. In the aforementioned manner, we can limit the IP address that we connect to, so it adds to security.

There is some difference between the route tables of public and private subnets, which is something that is not properly documented. Basically, if you add a route to an Internet Gateway in the private subnet's route table, then it should be able to connect to the Internet. But this doesn't happen. You have to use a NAT gateway instead.

I have been using Amazon Virtual Private Cloud for more than one year.

It is a very stable product.

The solution is used by only two people in my company. It is a very scalable solution.

We never had any issues with this tool.

The initial setup is easy. It is easier now, actually, since they have changed their UI.

There is no way for you to not use it. If you are using EFS or EC2, then you have to use Virtual Private Cloud. There might be other services too, but these are the two I can remember now. Also, it is safer to put things inside of Virtual Private Cloud because it is more secure. I would advise you to do it, but you have to configure it correctly. If it is not needed, then don't use it.

When I tried to modify the route table of a private subnet, it didn't become a public subnet.

I rate the overall solution a nine out of ten.

All our general workloads are being hosted in the AWS public cloud. Our analytics workload is in GCP. We have web servers, application servers, and databases in the general workload. Generally, three-tier architectures are hosted in AWS.

Within the solution, we use an Auto Scaling group to scale our EC2 instances based on CPU utilization or any other parameters we define. For some workloads, we have defined the minimum and maximum number of nodes we want.

We use AWS Firewall Manager. It provides options to control our outbound access. We can whitelist some of the domains that we access. Instead of opening outbound connectivity to the entire world, we are restricting some domains using AWS Firewall Manager, one of the services of Amazon Virtual Private Cloud.

We divide CIDR into multiple subnets. If we have a three-layer architecture, we dedicate a subnet to the web, application, and database. On the subnet, we host our workload. We define security controls on the subnet or at the instance level. We have NACL in the subnet. In instances, we use security groups, which are like firewalls at the host level.

The solution provides many functionalities. It is really easy to set up NACL and security groups. I have been using multiple cloud environments, and AWS is pretty straightforward. I'm very comfortable with it.

AWS is a bit costlier than other public clouds.

I have been using the solution for three years.

I rate the stability a nine out of ten.

I rate the scalability a ten out of ten. We have more than 1000 AWS accounts across the organization. Thousands of users are using internal and external applications hosted within AWS.

The support team is better than that of other public cloud providers.

Positive

The initial setup is easy and straightforward. If I follow the AWS documentation, I will have no doubts. Anyone can do it, but they must go through the documentation and the basics of networking. The documentation is very clear. We use Terraform. If I deploy the configuration using IaC, we can deploy the tool within minutes.

The Amazon Virtual Private Cloud has been designed to be comparable to other public cloud providers. I will recommend the product to others. Planning is very important before implementation. Organizations that want to deploy the solution must gather the requirements, plan it, go through the documentation, and then deploy the product or any other service within AWS. It would also help the customers. AWS is much better than its competitors. Overall, I rate the solution a ten 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.

We use VPC to create a virtual private network. They provide the IP address of each system on each mission. We can configure public and private subnets and modify the configuration of IP addresses for other VPN tunnels. We can also manage network subnets and other related resources with VPC.

We pay for AWS services as we go. Whatever we need, we can get it directly from Amazon without having to release it. This is sufficient for our needs.

I have been using Amazon Virtual Private Cloud for four years.

The product is stable.

The solution’s scalability is good.

We have 15+ accounts set up for VPC. We are managing the entire VPC setup.

The initial setup is not too much difficult. If you know very well about the network configuration setup, we can directly configure it.

VPC is a chargeable service. If you configure it incorrectly, you may be charged for unnecessary resources. Therefore, it is essential to understand the different VPC configurations before making any changes. VPC can be challenging to setup for someone new.

Amazon VPC pricing is based on the data transferred to your VPC. The cost varies depending on the specific resources we are using, such as instances and RDS databases. We have multiple AWS accounts, each paying around $400-500 monthly for VPCs. We have completed a lot of things in use because there is another configuration. If you don't want to do anything, the chargeable rate will apply. The configuration setup is very minimal, which means that the VPC pricing level is very good.

Many things are available in VPC. I don't know everything about VPC, so I must learn more first.

We have many things in VPC. Before setting up a configuration, we need the network thing. So, we are using the VPC. We are using private IP addresses because we need to arrange for multiple servers to be on the same network.

If you are configuring anything at a major level, you should use it. You should assign your IP address. Imagine you will be providing the default IP address, but it's not secure. You should consider your IP within your region.

If you go with the cloud, you should be able to network things.

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

Amazon EKS and a few particular services are used with the help of Amazon Virtual Private Cloud in our company. In our organization, we have a few dedicated services on Amazon Virtual Private Cloud.

The most valuable features of the solution stem from the security groups it provides. Network access control is also a beneficial feature of the product. With the security group as a part of Amazon Virtual Private Cloud, users can access any particular URL or IP address to which access has been assigned. The benefits provided by the product include enhanced security features along with customizable policies that can be adapted or changed whenever required.

From an improvement perspective, the product's initial setup phase should be easy for those who are not experienced in creating VPCs.

I have experience with Amazon Virtual Private Cloud.

Stability-wise, I rate the solution a ten out of ten.

Scalability-wise, I rate the solution a nine to ten out of ten.

The product's initial setup phase is easy if you have a certain amount of experience in creating VPCs.

In our company's cloud architecture, we have two Amazon Virtual Private Clouds used in multiple regions. Amazon Virtual Private Cloud also has multiple subnets, consisting of four public subnets and four private subnets. In public and private subnets, my company has multiple services. Our company's main database is maintained in the private subnet. The normal services are used on the public subnet. An internet gateway is present on a public subnet. If my company needs to access any data from the public subnet, we can use the internet gateway and access any services we want. If my company wants to access any database, then we will have to maintain it on the private subnet. In our company, we have to attach the NAT gateways to the public subnet. Within those NAT gateways, we can access the data in private subnets.

Scaling resources is not a part of Amazon Virtual Private Cloud. Resources would be a part of the services available in subnets.

In subnetting, that is, public subnets and private submits. Public subnets have internet access. Users can access any kind of data from the public subnet with the internet. In private subnets, users don't have any internet access. If you need to access data on the internet from private subnets, you can use NAT gateways.

It is easy to deal with the setup process of network ACLs and security groups in Amazon Virtual Private Cloud.

In terms of the integration of AWS services with Amazon Virtual Private Cloud, most of the services in our company are created inside Amazon Virtual Private Cloud. For any of the services that we use in our company, we select Amazon Virtual Private Cloud. My company has the option to choose the product's default and dedicated version, and we choose the dedicated Amazon Virtual Private Cloud. Whatever we use or create in our company is assigned to the dedicated Amazon Virtual Private Cloud chosen by us.

I recommend the product to others who plan to use it.

My company deals with many Amazon Virtual Private Clouds available in multiple zones. If we need to access data in an Amazon Virtual Private Cloud from a separate Amazon Virtual Private Cloud, the company can use VPC peering to connect them.

I rate the tool a nine out of ten.

Our company uses the solution to provide virtual private clouds for customers. It is the heart of AWS because it is the networking part of cloud services that includes a private subnet, public subnet, and private gateway. The solution represents everything from the network perspective. 

Within the solution, you create the network environment that includes provisions, services, the DB, the EKS, and zones. You set inbound and outbound traffic services. You enable security features and firewalls that are used by the solution. 

It is very easy to provision VPCs and build networks. 

The solution could have tighter security for traffic. 

I have been using the solution for four years. 

The stability is very good so is rated a ten out of ten. 

The scalability is good so is rated a ten out of ten. 

Technical support is highly supportive so is rated a nine out of ten. 

Positive

The setup is a little bit difficult. After creating the VPC, you have to create subnets based on your requirements for private or public. Then you have to create everything else including the NAT gateway. The final step is to configure both gateways for private and public subnets. The overall creation process takes about 40 minutes.  

The entire concept is networking. You have to figure out what things are important and create bridges. 

For example, one person with Vodafone services in the UK places a call to another person in India. The country and regional VPCs are in place and it takes permissions to cross them. The call's TCP response goes to the UK servers and the call is dialed using the VPC in the UK. It then hits the VPC in India where it is verified, pushed to the mobile network servers, and is rings through. 

Because the setup has complex steps, it is rated a four out of ten. 

We implement the solution for customers. 

The solution's pricing is on the higher side so is rated a five out of ten.  

The solution is a very, very good product and the heart of everything. I rate the solution a ten out of ten. 

Our primary use case for Amazon Virtual Private Cloud involves securely hosting our application and database servers within the private data center.

AWS services are quite convenient and user-friendly. Specifically, Amazon DynamoDB, EKS, and security features are easy to deploy and manage directly through AWS.

It would be beneficial to introduce more managed features and enhance customization options in the product. It could be more versatile and easy to use.

We have been using Amazon Virtual Private Cloud for two to three years.

I rate the platform's stability a nine out of ten.

I rate the platform's scalability an eight out of ten. Compared to Azure and GCP, there's room for improvement, particularly in managing aspects. 70% to 80% of our users have migrated to AWS.

We provide support directly to our customers. VPC's technical support team has been helpful. Their reliability has been particularly noteworthy, as they have effectively addressed any issues we've encountered, ensuring that solutions are implemented correctly. Our experience with customer service has been mainly focused on supporting development and operational aspects, where their assistance has been invaluable.

Positive

The initial setup was challenging but simple enough. It becomes easier to grasp if you approach it with a willingness to learn. It allows for a better understanding of the underlying architecture and how it's utilized.

Our work experience has mainly been with on-premises and cloud deployments, primarily within the AWS environment.

The deployment process for Amazon VPC typically involves initial planning and design discussions to understand the customer's requirements and ensure cost optimization. This planning phase may take some time as it involves coordination with various stakeholders and team members to finalize the architecture. However, once the design is in place, the actual deployment is relatively fast and efficient, depending on the setup's complexity and the project's specific requirements.

VPC tends to offer competitive pricing compared to other services. It's optimized and provides more personalized options, making it cost-effective.

The VPC's subnetting feature has significantly impacted our network design by enhancing security measures. It provides provisions to secure our network, ensuring it is not susceptible to manipulation by external users. Additionally, we leverage other security features such as the Web Application Firewall and AWS Network Firewall to enhance protection further. It is easy to set up security groups for the product.

Integrating it with other AWS services includes configuring VPCs and defining the subnet CIDR ranges. Then, we provision both public and private subnets, with sensitive databases typically placed in the private subnets. Additionally, we utilize features such as transit gateway and security groups to enhance network security. After deploying the servers within these subnets, we host our applications and manage traffic using load balancers and auto-scaling groups. Overall, the integration allows for an isolated network environment that we can efficiently manage via routing.

I recommend introducing Amazon VPC to others as it provides an excellent entry-level understanding of cloud computing and its relevance in today's world. Setting up on-premises clusters can be challenging, but its services offer a straightforward and accessible way to begin working with cloud computing. The users can gain a basic understanding of cloud computing concepts and gradually expand their knowledge to more advanced topics.

I rate it a nine out of ten.

The solution can be used to isolate a cloud within a cloud infrastructure. It allows us to have an isolated or air-gapped environment.

The product can be used to isolate environments. It's good for security. It is a very good feature irrespective of which cloud provider we use. It also allows us to connect two VPCs in different zones. We haven’t had any issues with the solution. It satisfies all our requirements.

The tool is not scalable.

I have been using the solution for around three years.

The tool is stable.

The number of users depends on each project. We might have three to four people from DevOps and more than 100 users from the project teams.

The initial setup is very easy and quick.

The solution is worth the money.

The pricing is okay. The solution is not very expensive. Compared to other solutions, it is fine.

The tool is used for the isolation of our environment. It is a set of rules within our cloud environment to separate whatever we have created as a virtual cloud. I highly recommend the solution. Overall, I rate the solution a ten out of ten.