AWS gives you the flexibility of configuring your network as per your company’s security guidelines. In this article, we will explore some of the common types of network configurations and how to deploy and access the Deepfactor Portal in such network configurations.
Type of subnets #
In AWS you can setup different types of subnets, the most common being the following:
- Public Subnet
- Private Subnet
You can read more about how they behave and how you can set them up here: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html
Excerpt from the above article
The instances in the public subnet can send outbound traffic directly to the internet, whereas the instances in the private subnet can’t. Instead, the instances in the private subnet can access the internet by using a network address translation (NAT) gateway that resides in the public subnet.
Auto Assign Public IP #
For each subnet, AWS provides the option of auto assigning a public IP to the instance launched in that subnet.
You can read more about IP addressing in AWS VPC here: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html
Please note:
- The auto-assigned public IP come from a global pool and is subject change when the instance is restarted.
- Even if a public IP is assigned to an instance in the private subnet, it cannot be reached directly from the internet.
- If an instance in the public subnet is not assigned a public IP, it can be reached over its private IP using AWS VPN.
Accessing Deepfactor Portal for different configurations #
When you deploy Deepfactor Portal in your AWS environment using CFT, you are asked to specify the subnet and also a custom hostname for your portal. If you do not specify the custom hostname, the public-hostname of the EC2 instance is used. If public-hostname is not present (a public IP wasn’t assigned to the EC2 instance), then the private hostname is picked and if even that is not available, then the private IP address is used.
Note:
1. Deepfactor runtime, the piece that sits alongside your running application, that is responsible for sending telemetry to the Deepfactor portal uses this hostname to communicate with the portal. So, if you are planning to use an ELB in front of the Deepfactor Portal, please ensure you give the ELB hostname in this field so the runtime can connect to the portal through the ELB using HTTPS protocol.
2. If you provide a custom hostname, ensure that it can be resolved from your running application, so the Deepfactor runtime can connect to the portal and send telemetry.
Given below is a combination of different types of subnets and parameter values and how you can access the Deepfactor Portal in each scenario. CustomPortalHostName, PublicPortalUrl and PrivatePortalUrl can be found in the outputs section of the CFT stack creation screen.
Subnet Type | EIP assigned | Auto Assign Public IP | Portal Hostname specified | DNS entry required | DNS points to | VPN Required | Access Portal using |
---|---|---|---|---|---|---|---|
Private | x | x | Yes | Yes | Private IP | Yes | CustomPortalHostName |
Private | x | x | No | No | Yes | PrivatePortalUrl | |
Public | Yes | x | Yes | Yes | EIP | No | CustomPortalHostName |
Public | Yes | x | No | No | No | PublicPortalUrl | |
Public | No | Yes | Yes | Yes | Auto assigned public IP | No | PublicPortalUrl |
Public | No | No | Yes | Yes | Private IP | Yes | CustomPortalHostName |
Public | No | Yes | No | No | No | PublicPortalUrl | |
Public | No | No | No | No | Yes | PrivatePortalUrl |