I am setting up a basic dev, qa and production environment for an app in EC2. A dsn string to connect the web app to the database looks something like
jdbc:postgresql://64.210.255.235:5432/mydb
But here is where things break down, to be secure, I need to add the elastic ip addresses of the web heads to the database's security group, in addition to elastic ips to connect to the database via dsn. However, EC2 apparently lets you only have 5 elastic ips? Help, what do I do? And please explain to me like a 6th grader, I am a developer with almost no system administration or AWS experience. For an answer I need concrete steps to make this work, not high level observations.
first of all, good handle. second, what Im trying to do conceptually is super simple. I have 3 environments, 6 servers. I want to have stable jdbc dsns that I dont have to change when the EC2 DHCP updates. I need my web heads to talk to my db boxes and be secure.
2 options:
use VPC, so that you can have persistent privat IP for your DBs.
Ask amazon to increase your EIP limit by filling up this form.
Related
I have a NodeJs web application running on amazon EC2 server.
Now from this node app in EC2, I have to access a database system (SqlServer) which is in the customer's in house network which can be accessed only with a VPN. What are the possible ways to do this?
Note:
- In house db cannot be exposed to public
There are a three options:
1) Expose your database publicly, and connect from your app using a secure protocol (i.e. ssl). This is probably a horrible idea, but is possible.
2) Set up a VPN between AWS and the data center where the database lives. This is a quick, easy way to set up a hybrid architecture.
3) Set up Direct Connect between AWS and the data center. This can reduce latency, provide network sovereignty, and depending on the amount of traffic between the app and the db may actually be cheaper than option 2.
You can setup a VPN between the VPC and the customers network.
ref : https://aws.amazon.com/premiumsupport/knowledge-center/create-connection-vpc/
Recently I have been considering using MongoDB Atlas for a deployment which is fairly heavy in the DB department and also on the Node.JS server side.
Whereas I am quite familiar with the normal NAT Gateway--> VPC layout on AWS, in all my research on Atlas I have been left terribly confused about some really important specifics.
I am incredibly confused as to how to implement a NodeJS server with MongoDB Atlas. If I set up my own NAT Gateway & VPC on AWS with all the servers, replicas, shards etc. then I know exactly where my entry point is, where my NodeJS server is on that zone and how to replicate etc. But if use this scenario then I lose all the comfort and time-saving which Atlas affords me, not to mention the headaches of scalability etc.
However, in all the Atlas documentation, I can only find how it sets up Atlas on a VPC. I cannot figure out, (maybe my brain cells are not working), where in all this configuration the Node server would go? Or can one set up a NAT Gateway and VPC and then place an Atlas controlled MongoDB setup behind it?
The architecture with Atlas has me confused. Where do you set up your servers so they are also secure? Do I need to create a second NAT Gateway and VPC just for my Node server app? If so do I require VPC peering?
If this is dumb, please excuse the question. But before I begin a setup which will cost the company a good deal of money, I need to be clear on exactly what the layout is.
Thanking all who can handle this question in advance as any and all pointers here would be greatly appreciated.
MongoDB Atlas
You can create a VPC Peering Connection from MongoDB Atlas VPC to a VPC in your AWS account where you have your NodeJS EC2 instances running. Check the documentation Introducing VPC Peering for MongoDB Atlas for more details.
Your Custom MongoDB Cluster
Setting up MongoDB with best practices will require creating public and private subnets in the VPC while placing the database cluster in the private subnet. It will also involve having a NAT server in the public subnet for the MongoDB cluster to forward egress traffic keeping it secure within the VPC.
Reference: AWS Quick Start for MongoDB
However this can be challenging if you are new to AWS. To simplify the work use a AWS Quick Start for AWS Quick Start for MongoDB which will create the required architecture with best practices.
After provisioning the MongoDB Cluster, you can provision a NodeJS Web Server using one of the following options,
Using Elastic Beanstalk to place the NodeJS Servers with AutoScaling and Load Balancing with Best Practices.
Setup an Application Load Balancer, AutoScaling Group and NodeJS EC2 instance Launch Configuration inside the VPC to manually.
Create a EC2 template (Newly introduced) with required configuration.
Manually setup a server inside the VPC.
Note: If you place your NodeJS Web Servers in Private Subnet, make sure you create a public load balancer and configure the subdomains where NodeJS We Servers are allowed for load balancer as well so that it can route traffic to any subnet where the automated provisioning places the NodeJS Web Servers.
For our SaaS app, we're allowing customers to point their domain name to our server.
The plan right now is to simply hand out one of our AWS elastic IP addresses for them to point their domain to. The elastic IP address would essentially be pointed to a EC2 instance web-server...and maybe a load balancer in time (if traffic demands it!).
The user would specify what their domain is in our app, and we'd be able to resolve the host name coming in as their app.
My concern is the longevity of this solution. This IP cannot change. And we'll certainly be tied to AWS if we go this route.
(Note: Being a 1-2 person startup, standing up a data-center is more than likely no-go, and we hope to use AWS or Azure).
What solutions would make this IP address -> SaaS Web Server concept last in the long run, with flexibility, and as minor of a tie as possible to a cloud provider?
With running the risk of asking "what is the best way to do this"...what's the best way to do this, keeping in mind longevity and small opt-in to a cloud provider?
You can't point an IP address to a load balancer, so this seems like a very bad idea. You need your own domain/subdomain that clients can point their domains/subdomains to via a CNAME record on their end. Then if the location of your service ever changes you just have to update your domain record and their DNS records will continue to be correct.
I have an elastic beanstalk app that uses a rethink-db instance as its database. The obvious thing to do would be to restrict access to the the database to only this application.
But if I set the relevant port in the security group of the Rethinkdb instance to anything other than 0.0.0.0, the application can't reach the DB.
The application is using the private DNS of the database for resolution and is in the same amazon region... as far as I understand, this alone should already get me passt the security group without any rules. Not in this case, apparently.
I have tried adding an exception for the applications security group to the databases security group on that port, as well as the security group of the load balancer of the application. I have also tried both at the same time. No dice.
The beanstalk-app is scalable, so it usually communicates from several instances that can change at a whim. Going over an elastic IP and allowing that in the databases security group is therefore not an option, unfortunately.
In the end, I'm forced to leave the security group of the rethink db on the driver port wide open at 0.0.0.0... Anything else I've tried made it unreachable for my own application.
Can anybody tell me what I'm doing wrong?
as far as I understand, this alone should already get me passt the
security group without any rules
That's not correct. You always have to have a security group rule to allow access. All inbound traffic is blocked by default.
I have tried adding an exception for the applications security group
to the databases security group on that port
That sounds like exactly what you need to do. You need to create an inbound rule in the security group assigned to the database server. In that rule you would specify the ID of the security group that the Elastic Beanstalk instances belong to.
If that isn't working, then you might need to post more information in your question, like the actual security group settings.
Also, you need to make sure your EB instances are trying to connect to the database server via the private IP of the DB server. Your issue sounds like maybe they are using the public IP of the DB server. I know you said they are using the private DNS of the DB server, but you need to make certain that is the case, and make certain that DNS is correctly resolving to the private IP, when referenced from the EB instances.
I need to set up a custom DNS server within EC2. I have one instance that acts as the DNS server, and N other instances that use this DNS server to connect to one another. Is this posible? Basically, I need to modify the DHCP settings for the N instances so that they connect to the DNS server. I can't find any good documentation on modifying the DHCP settings for an instance.
Note: I did find some documents, but they seem to only apply to Amazon VPC. Is there any way to do this without using VPC?
Short answer - no. You need a VPC. But once you have the VPC created - you can effectively do whatever you like with it.
Long answer - traditional AWS hosting gets an address directly from Amazon. This means you've got no control whatsoever of the IP addresses.
New accounts however come with a VPC by default, which means you can install a machine to act as a DNS server. (And I've done this in the past using Windows Active Directory)