I wanted to create a read replica of an existing RDS instance via AWS Websites.
However, I don't see option for selecting Availability Zone.
How can I configure RDS read-replica for specific availability zone?
The console seems to use the default option and that's it. Which means a randon az in the region.
You can create one in a specific Availability zone with aws cli.
The command to do it is
aws rds create-db-instance-read-replica \
--db-instance-identifier myreadreplica \
--source-db-instance-identifier mydbinstance \
--availability-zone mychosenaz
You can add other options to the command as you like.
More information can be found here.
Related
I've just created an ECS cluster via the AWS console. During that process, I specified the VPC I wanted it to use, as well as four subnets.
Now I can't find any indication--neither in the console, nor via the CLI--that this actually happened. I see that the cluster exists, but I cannot get any details regarding its network disposition.
I've tried using the aws client, with all of the arguments to --include that are accepted (SETTINGS, ATTACHMENTS, CONFIGURATION, et cetera), but aws ecs describe-clusters --cluster foocluster --include SETTINGS (for example) shows me nothing but the bare details.
Cluster is not specific to any VPC, thus there is no association between an ECS cluster and a VPC. VPC are specific to ECS tasks and services.
AWS console just helped you to create a VPC as a separate entity to cluster. This way you can lunch your tasks and services to that VPC. But you can lunch them to any other VPC as well.
When I use Network Load Balancer with Auto Scaling, everytime an instance is spawned it gets a new public IP.
I would like to have an EIP for each instance. I was hoping that when I assigned an EIP to availability zones in the Network Loadbalancer configuration would do the trick.
Is there a a way to have autoscale and static IPs for the instances spawned?
https://aws.amazon.com/blogs/aws/new-network-load-balancer-effortless-scaling-to-millions-of-requests-per-second/
According to this it looks it's not possible:
Unfortunately, there is no way to make autoscaling automatically
assign an Elastic IP address to newly launched instances
Static IP for Auto Scale in AWS
and according to this:
Assigning static IPs to auto scaled EC2 instance
Write a script and put it on your startup script in launch configuration for your autoscale group, that script can do anything you want, range from assigning the new EIP to check other services for the white/blacklist.
For more info read
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html
As others have mentioned this can be accomplished by provisioning new EIP and using UserData to associate the instance with newly issued EIP. However, following setup would have the following issues:
1) EIP have limits by default its 5 per VPC, and even you can increase the limit you need to know the maximum number of EIP your VPC will use
2) When instance gets terminated you will need to create a process to delete staled EIP or figure out how to reassociated previously allocated EIP
Having said that I do use a static EIP in my ASG but its only for HA rather than scalability, so in the following example I'm reusing existing EIP each time I launch a new instance
#!/bin/bash -xe
INSTANCE_ID=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)
aws ec2 disassociate-address --association-id ${OpenPVNEIP.AllocationId} --region ${AWS::Region} || true
aws ec2 associate-address --instance-id "${!INSTANCE_ID}" --allocation-id ${OpenPVNEIP.AllocationId} --region ${AWS::Region}
I created a Lambda inside a private subnet.
I linked the private subnet to a NAT Gateway and thus I managed to get a static IP for my Lambda. The limit of 5 EIPs was an issue for me.
https://aws.amazon.com/premiumsupport/knowledge-center/internet-access-lambda-function/
With EC2 & Auto scaling, You need using user data in EC2 to Auto Attach Elastic IP to EC2 Instance For Auto scaling
#!/bin/bash
aws configure set aws_access_key_id "XYZ..."
aws configure set aws_secret_access_key "ABC..."
aws configure set region "ap-..."
aws ec2 associate-address --instance-id "$(curl -X GET "http://169.254.169.254/latest/meta-data/instance-id")" --public-ip your_elastic_IP
Note: you should create new user & IAM have only permission associate-address to create/get aws key
Hope it be help you :)
I need to update a config file in a shared EFS drive with all of the private IP addresses of the current autoscaling group.
The approach I'm thinking is to run a user data script that queries the ASG for the private IP addresses then echo that into the config file. To do that the ec2 needs to have AWS CLI credentials and appropriate read-only access. Ideally, I don't want to store any credentials on this ec2.
Is there another way? Possibly VPC Endpoint or something?
Thanks!
You are asking two questions.
How do I provide credentials securely to an EC2 instance?
You use IAM Roles and assign the role to your EC2 instances. Then use the instance credentials in your code. The CLI examples below will automatically pick up these credentials.
Using an IAM Role to Grant Permissions to Applications Running on Amazon EC2 Instances
How do I get the private IP address of EC2 instances in an Auto Scaling Group (ASG)?
You need to get a list of instances attached to your ASG.
For each instance in your ASG call the describe API and extract the private IP address.
Example commands:
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-name my-auto-scaling-group
aws ec2 describe-instances --instance-ids i-1234567890abcdef0
You can filter the command output. For example add the following to the second command to just display the private IP address:
--query 'Reservations[*].Instances[*].PrivateIpAddress'
Recommendation:
I would use the Python SDK and write a simple program that provides these features and updates your config file.
Amazon launched a third availability zone in Frankfurt: eu-central-1c
From what I see, the third availability zone does not support all instance types that are available in the existing zones (eu-central-1a and eu-central-1b).
I always assumed that the available instance types may differ over regions but are identical over availability zones within the same region. From what I see that is not the case.
Is it true that you if an EC2 instance type is available in one region, you cannot make the assumption that it will be available in all availability zones?
The script that used for testing is:
aws ec2 describe-reserved-instances-offerings \
--query "ReservedInstancesOfferings[?AvailabilityZone=='eu-central-1c'] [InstanceType]" \
--output text --region eu-central-1 | grep c3.large
# c3.large not available on eu-central-1c
but
aws ec2 describe-reserved-instances-offerings \
--query "ReservedInstancesOfferings[?AvailabilityZone=='eu-central-1a'] [InstanceType]" \
--output text --region eu-central-1 | grep c3.large
# ... it is available on eu-central-1a
The availability of instance types can differ between availability zones in a region based on the documentation.
From the EC2 docs:
Some AWS resources might not be available in all regions and
Availability Zones. Ensure that you can create the resources you need
in the desired regions or Availability Zone before launching an
instance in a specific Availability Zone.
Although resource is a vague term, an instance type should be considered a resource. So, it's possible that a certain instance type is not available in a certain zone but available in other availability zones. There are also cases where an instance of a certain type cannot be launched because AWS does not have enough capacity in that zone at the time of request.
Another important thing to note here is that the availability zones are not fixed for all accounts as described here.
To ensure that resources are distributed across the Availability Zones
for a region, we independently map Availability Zones to identifiers
for each account. For example, your Availability Zone us-east-1a might
not be the same location as us-east-1a for another account. There's no
way for you to coordinate Availability Zones between accounts.
I'm new to Elastic Beanstalk and I have a "simple" problem with where the EC2 and RDS instances are created. For a couple of hours now of creating, deleting enviroments and googling for solutions I'm out of ideas.
The problem seems quite simple. I want the EC2 and RDS instances in the same Availability Zone so that I don't have to pay for the traffic between Availability Zones. But it seems the zones in which they are created are random (1a-1c). In the "Configuration" tab I see that under Instances "Availability Zones: Any" is configured. But when I edit the instance configuration there is no option to change it.
The actual zone doesn't matter. Important is only that all instances are created in the same zone.
Thank You.
The aws:autoscaling:asg:Custom Availability Zones option does not work for modern "VPC" Elastic Beanstalk environments.
You will get the error: Custom Availability Zones option not supported for VPC environments.
Instead, you must limit the subnets that you provide via the aws:ec2:vpc:Subnets option to only specify subnets in the AZ where you want your instances to run.
This is possible. You can specify a custom availability zone both for your EC2 instances and your RDS database. You can use .ebextensions to achieve this. Create a directory with name .ebextensions in your app source. Inside this directory create a file with name '01-rds-setup.config'. Config files in this directory are processed in lexicographical order of their name.
Assuming this is the only file it will be processed.
To configure the EC2 availability zone use the "Custom Availability Zones" option setting under "aws:autoscaling:asg" namespace. Documentation on this option setting is available here.
To configure the RDS availbility zone you can override the properties of the RDS Resource. For more documentation on overriding resource properties read this.
Contents of your file .ebextensions/01-rds-setup.config:
option_settings:
- namespace: aws:autoscaling:asg
option_name: Custom Availability Zones
value: us-west-2a
Resources:
AWSEBRDSDatabase:
Type: AWS::RDS::DBInstance
Properties:
AvailabilityZone: us-west-2a
Make sure you do not select the Multi-AZ option when launching an Elastic Beanstalk environment with RDS from the console. This should work for your usecase.