I created four EC2 free-tier instances of Windows Server 2019 to be used for a Windows Server lab. Two of those instances will be used as workstations. The other two instances will be a Domain Controller and a second server, possibly used as a File Server.
Since I am new to AWS, but not new to the cloud in general, how do I configure things so all four instances talk to each other? I do not see a need to connect them to my home network, but want to be able to connect remotely and run my lab scenarios that way.
Thanks!
Chris
First, please note that there is no such thing as an "EC2 free-tier instance". The AWS Free Tier is a pricing discount that gives 750 hours per month of free usage of certain Amazon EC2 instances. So, if you are running 4 instances for the entire month, only one quarter of the charges will be covered by the Free Tier. (But you can stop the instances when they aren't being used to reduce your costs.)
Amazon EC2 instances within the same VPC can communicate with each other. However, you will need to configure the Security Groups associated with each instance to permit this communication. The simplest way might be to assign the same Security Group to all instances, and then add an Inbound rule to the Security Group that permits connections from the Security Group itself. This is required because the rules of the Security Group apply to each instance individually, so there needs to a rule that allows inbound communications from the same security group when it is associated with another instance.
You mention that you want to be able to "connect remotely and run my lab scenarios". This will also require you to configure the Security Group to permit the necessary connections from your home IP address, such as ports for RDP and maybe HTTP/S.
Related
Given Amazon workplaces is built on top of ec2, amazon workplaces is less flexible and more expensive vs ec2. How do they compare in terms of internet security? If Amazon workplaces is more secured, is there a way to DIY enhance ec2 instance so that the security level will get close to amazon workplaces? many thanks.
They both run Windows server, so the OS security is the same.
In WorkSpaces, there are two network connections -- one for the user to connect via the WorkSpaces client, and one connected to a VPC. Therefore, both EC2 and WorkSpaces can use Security Groups, NACLs and VPCs to manage security.
So, no real difference in terms of security unless you require connections to only come from a particular network/VPN connection.
I have a t2.micro instance running, that is producing some data that needs to be written to a database. So, I created a RDS database with MySQL on it.
The issue I'm facing is, nonsurprisingly, getting the EC2 instance to communicate with the RDS database in any way/shape/form.
I'm been battling with it all day. I'm left with these bits of confusion:
I figured I've just add the public IP of the EC2 instance to the security group of the RDS. Turns out the RDS doesn't really have a security group, only a VPN. So how do I allow communication from the EC2 instance, then?
Speaking of security groups, do I need to se the EC2 up to require outbound connections?
The RDS has an 'endpoint' and not a public IP as far as I can tell. So I can't add it to any security group at all. Is this correct?
Am I going to have to figure out how to use Elastic Beanstalk or some other way to get these components to play together?
These are all the things I'm trying to troubleshoot but I'm not getting anywhere. There doesn't seem to be any good blogs / etc; mostly what I'm finding is stuff on how to get the RDS to be accessed by your local hardware, not an EC2 instance.
How should I set this up?
There are two ways to allow inbound connection to RDS database: CIDR/IP or EC2 security group.
You can go to VPC, at the left panel there is "Security Groups" (yes, RDS do have security group). Click that, and choose your DB security group (if you already have the RDS instance created) or create a new one.
Under connection type, choose either CIDR/IP or EC2 security group.
If you choose to go with CIDR/IP, you should know what IP address your EC2 instance is and put the address or range in e.g. "10.11.12.0/24".
If you choose to go with EC2 security group, you should know the security group nameof your EC2 instance and select it from the dropdown provided e.g. "my security group".
Please note that the EC2 instance and the RDS instance need to be able to "see" each other i.e. in the same region, VPC, subnets with proper NACL (network access control list) etc.
Speaking of outbound connection and security group, no, security groups only manage inbound connection.
Hope that helps, let me know if I can make my answer clearer.
Few questions:
Are us-east-1a, us-east-1b, and us-east-1d considered one or three availability zone?
Say I have two instances within us-east-1a, one has a mongodb server, the other has a nodejs app. Do I need to add permissions for port 27017 (mongodb) to the security group for the app server to connect to the mongo server?
Same question as above, but say one server is in us-east-1a and the other is in us-east-1b. Do I need to modify the security group?
Would the VPC or Subnet ID have any effects on communication between instances?
edit
moved to Server Faults
1) 3
2) Yes.
3) Yes
4) If you are using a VPC and trying to communicate outside of the VPC, you'll need to add a NAT box in that VPC. Then you'll obviously have to make security group changes. If you are trying to communicate inside of the VPC, it's easier since you won't need to create a NAT box, but you will still need to make security group changes. No matter what, you have to create security group changes if you want to communicate outside of ssh.
Side Note: You can use the instanceID in the security groups instead of IP addresses. This can be handy for a variety of reasons.
It takes several minutes for a newly deployed version to ElasticBeanstalk to become available, so I am hoping that someone can spare me all the testing/experimenting :-)
Scenario 1:
I need to connect to an EC2 instance running MySQL from another EC2 instance but belonging to a different security group. Do I use the public DNS or the private IP to specify the MySQL host?
Scenario 2:
Same as above except both instances belong to the same security group. I believe that I need to use the private IP in this case, correct? Would the public DNS also work?
Thank you!
You should always use the private IP when possible for ec2 instances communicating with each other.
Among other reasons, you will get charged money for using the public ip even though the machines are started in the same availability zone.
Also, the security group is just a set of inbound and outbound rules, it doesn't matter that the two machines are in different groups with different rules so long as your mysql server can accept traffic on the port from the other ec2 instance based on the ruleset.
If you're going to be starting and stopping instances frequently, you might benefit from creating an elastic IP and attaching it to instances as needed instead of constantly changing configuration files.
So for reasons Id rather not go into, my DB is on an EC2 instance in eu-west-1 and I have created a beanstalk app on us-east-1. Id like my app to talk to that EC2 instance on a MySQL port (3306).
Can anyone assist with how Id set this up, what ingress rules I need to setup on the EC2 security group? Given that I will have multiple versions of the app in beanstalk, the IP address may change regularly (after environment rebuilds etc).
The important concept regarding Security Group Rules you might be missing is, that you do not necessarily specify IP addresses as traffic sources alone, rather regularly will refer to other security groups as well:
The source can be an individual IP address (203.0.113.1), a range of
addresses (e.g., 203.0.113.0/24), or an EC2 security group. The
security group can be another group in your AWS account, a group in
another AWS account, or the security group itself.
By specifying a security group as the source, you allow incoming
traffic from all instances that belong to the source security group.
[...] You might specify another security group in your account if you're creating a
three-tier web service (see Creating a Three-Tier Web Service).
[emphasis mine]
Consequently you'll simply need to add the Beanstalk app instances security group as a traffic source for TCP port 3306 within the MySQL instance security group.
Taking this further
An additional concept to make oneself familiar with is, that you can have multiple security groups assigned to an instance, thus enabling (possibly dynamic) composition of the resulting firewall.
For example, a recommended practice for larger architectures suggests to specify a dedicated security group per 'role' your instances have (rather than accumulating several rules within one security group as usual), e.g. we have security groups like 'role-ssh' (TCP port 22) and 'role-mysql' (TCP port 3306), which are assigned to EC2 instances as needed in turn. You can read more about this concept in e.g. Security Groups - Most Underappreciated Feature of Amazon EC2.