Amazon Virtual Private Cloud Reviews

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.

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. 

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.

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.

My company runs multiple services on AWS EKS, and to create a network and communication between such services, we use Amazon Virtual Private Cloud. In general, my company uses the tool for multiple services.

The most valuable features of the solution are its security groups and NACL, which allows users to configure the routing tables and other related areas.

The overall integration capabilities of Amazon Virtual Private Cloud with third-party tools need to improve.

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

It is a stable solution. Stability-wise, I rate the solution a nine and a half out of ten.

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

Around 250 people in my company use the product.

Though Amazon Virtual Private Cloud is a leading tool in the market, Microsoft Azure's cloud services can be considered one of its competitors. Amazon Virtual Private Cloud is better than Microsoft Azure since it provides easy integrations, support, and multiple services.

The product's initial setup phase is simple since my company manages it with the use of Terraform.

When it comes to Amazon Virtual Private Cloud, my company had opted for a canary deployment.

Compared to the other products in the market, Amazon Virtual Private Cloud is available at a low price.

My company uses Amazon Virtual Private Cloud for our corporate data center.

There are some problems with the third-party tools that are used for integration, but I don't see many problems with the areas involving AWS and Kubernetes.

The product has enhanced our company's operations activities since its network configuration is very handy, and in a few steps, our company can set it up between the microservices.

It is easy to integrate Amazon Virtual Private Cloud with AWS services.

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

I rate the tool a nine out of ten.

We use Amazon Virtual Private Cloud for different requirements. When it comes to building a virtual cloud platform for our infrastructure, my team and I are interested in gateways because they are the foundation of VPCs. This is how you will access the internet or data. Gateways and subnets are the most important features. Subnets help you save network and routing traffic.

The solution provides the networking infrastructure of the organization.

Subnet is an important feature as it helps to save network and route traffic.

While creating a VPC, you can create a private and public subnet. If you forget to automatically assign a public IP address when creating an EC2 instance, the instance will not be able to access the internet. You can enable automatic public IP assignment for your public subnet to avoid this. This is something one always forgets while creating a VPC in infrastructure.

I have been using the Red Hat Ansible Automation Platform for four years. I use the latest version of the solution.

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

According to my knowledge of the network, I rate the solution’s scalability a nine out of ten.

The customer service and support are good.

Positive

The initial setup of Amazon Virtual Private Cloud is easy. It doesn't require the skills of a network manager. Someone who doesn't have any training on VPCs will find it hard.

The pricing is fair.

I advise you to go for it, and you can see what it's all about. I've been using this application because cloud computing is a big tool. I would definitely recommend cloud computing to people who want to start using it.

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

Compared to that of on-premises solutions, the performance of Amazon Virtual Private Cloud is much better.

Billing and technical support should be better.

There is a steep learning curve as well.

I've been using this solution for about three years. We are migrating all of our critical production applications, management information systems, and legacy on-premises applications to this solution. We have 80,000 to 90,000 users at any point in time.

Amazon Virtual Private Cloud has been stable after we resolved some of the issues during deployment.

Amazon's technical support has not been very helpful. I was left to figure things out on my own. Therefore, I would rate technical support at four on a scale from one to ten.

Neutral

I had to figure out the initial setup myself. The documentation is available, but technical support was not helpful. There was a lot of trial and error.

I have handled the maintenance of the solution myself. However, for proper maintenance, backups, backup tools, and CDNs, I would prefer a service that's not native AWS.

Amazon is not very transparent with pricing. It's quite complicated to see where you're spending and how you can track it. I was spending $30,000 a year and $3600 monthly on top of that initial payment. However, I have been able to bring the cost down for this year.

This is not a solution for large production environments that are implementing it for the first time. It is not very user-friendly, and there is a lot of documentation that you have to take the time to go through.

However, having the features hosted on AWS is so much better than having them on-premises. Therefore, compared to on-premises solutions but not Azure or GCP I would rate Amazon Virtual Private Cloud at nine out of ten.