2
A possible approach could be:
Put your instances in a private subnet
Route incoming traffic through a load balancer
Route outgoing traffic through a NAT
Outgoing traffic will then use the elastic IP assigned to your NAT as its source IP.
An added benefit of this approach from a security perspective is that your instances won't be directly reachable from ...
2
I think this is because your ECS service was created before tagging was available for ECS services.
See this blog post by AWS on how to migrate to the new ARN format. https://aws.amazon.com/blogs/compute/migrating-your-amazon-ecs-deployment-to-the-new-arn-and-resource-id-format-2/
1
I think the instance class is going to vary based on the kind of workloads you run. You might start out with X but next thing you know your running a bunch of random stuff. You can always run a cluster of different instance classes and then have the scheduler schedule your workloads to the right instance.
M5 and t3 are Nitro based instances. They have a ...
1
This is not a good practice. AWS docs explicitly mentions that
Each NAT gateway is created in a specific Availability Zone and
implemented with redundancy in that zone
That means that if all of your private subnets share traffic to a same NAT gateway, in case the AZ where the NAT is located goes down you are loosing your whole 'private environment'.
1
The only way to manage IAM users - using appropriate account with IAM Administrator privileges.
See AWS Identity and Access Management
If you lost your root account, you may contact an AWS support, see Recover Your AWS Account Password
Only top voted, non community-wiki answers of a minimum length are eligible
