In this blog you will learn Configuring an Environment Instance, AWS Regions, Tenancy , Configuring Instance Behaviour and Instance Lifecycle.
Configuring an Environment for Your Instance
Deciding where your EC2 instance will live is as important as choosing a performance configuration. Here, there are three primary details to get right: geographic region, virtual private cloud (VPC), and tenancy model.
AWS Regions
As you learned earlier, AWS servers are housed in data centers around the world and organized by geographical region. You’ll generally want to launch an EC2 instance in the region that’s physically closest to the majority of your customers or, if you’re working with data that’s subject to legal restrictions, within a jurisdiction that meets your compliance needs. EC2 resources can be managed only when you’re “located within” their region. You set the active region in the console through the drop-down menu at the top of the page and through default configuration values in the AWS CLI or your SDK. You can update your CLI configuration by running aws configure. Bear in mind that the costs and even functionality of services and features might vary between regions. It’s always a good idea to consult the most up-to-date official documentation.
VPCs
Virtual private clouds (VPCs) are easy-to-use AWS network organizers and great tools for organizing your infrastructure. Because it’s so easy to isolate the instances in one VPC from whatever else you have running, you might want to create a new VPC for each one of your projects or project stages. For example, you might have one VPC for early application development, another for beta testing, and a third for production (see Figure 2.1).
Adding a simple VPC that doesn’t incorporate a NAT gateway won’t cost you anything. You’ll learn much more about all this in , “Amazon Virtual Private Cloud.”
Tenancy
When launching an EC2 instance, you’ll have the opportunity to choose a tenancy model. The default setting is shared tenancy, where your instance will run as a virtual machine on a physical server that’s concurrently hosting other instances. Those other instances might well be owned and operated by other AWS customers, although the possibility of any kind of insecure interaction between instances is remote.
To meet special regulatory requirements, your organization’s instances might need an extra level of isolation. The Dedicated Instance option ensures that your instance will run on its own dedicated physical server. This means that it won’t be sharing the server with resources owned by a different customer account. The Dedicated Host option allows you to actually identify and control the physical server you’ve been assigned to meet more restrictive licensing or regulatory requirements.
Configuring Instance Behaviour
You can optionally tell EC2 to execute commands on your instance as it boots by pointing to user data in your instance configuration (this is sometimes known as bootstrapping). Whether you specify the data during the console configuration process or by using the –user-data value with the AWS CLI, you can have script files bring your instance to any desired state. User data can consist of a few simple commands to install a web server and populate its web root, or it can be a sophisticated script setting the instance up as a working node within a Puppet Enterprise–driven platform.
Related Product: AWS Certified Solutions Architect | Associate
Instance Pricing
Use of EC2 instances can be purchased using one of three models. For always-on deployments that you expect to run for less than 12 months, you’ll normally pay for each hour your instance is running through the on-demand model. On-demand is the most flexible way to consume EC2 resources since you’re able to closely control how much you pay by stopping and starting your instances according to your need. But, per hour, it’s also the most expensive. If you’re planning to keep the lights burning 24/7 for more than a year, then you’ll enjoy a significant discount by purchasing a reserve instance—generally over a term commitment of between one and three years. You can pay up front for the entire term of a reserve instance or, for incrementally higher rates, either partially up front and the rest in monthly charges or entirely through monthly charges. Table 2.2 gives you a sense of how costs can change between models. These estimates assume a Linux platform, all up-front payments, and default tenancy. Actual costs may vary over time and between regions.
For workloads that can withstand unexpected disruption (like computation-intensive genome research applications), purchasing instances on Amazon’s Spot market can save you a lot of money. The idea is that you enter a maximum dollar-value bid for an instance type running in a particular region. The next time an instance in that region becomes available at a per-hour rate that’s equal to or below your bid, it’ll be launched using the AMI and launch template you specified. Once up, the instance will keep running either until you stop it—when your workload completes, for example—or until the instance’s per-hour rate rises above your maximum bid. You’ll learn more about the spot market and reserve instances in “The Cost Optimization Pillar.” It will often make sense to combine multiple models within a single application infrastructure. An online store might, for instance, purchase one or two reserve instances to cover its normal customer demand but also allow autoscaling to automatically launch on-demand instances during periods of unusually high demand. Use Exercise 2.3 to dive deeper into EC2 pricing.
Instance Lifecycle
The state of a running EC2 instance can be managed in a number of ways. Terminating the instance will shut it down and cause its resources to be reallocated to the general AWS pool.
If your instance won’t be needed for some time but you don’t want to terminate it, you can save money by simply stopping it and then restarting it when it’s needed again. The data on an EBS volume will in this case not be lost, although that would not be true for an instance volume. Later in this chapter, you’ll learn about both EBS and instance store volumes and the ways they work with EC2 instances.
You should be aware that a stopped instance that had been using a non-persistent public IP address will most likely be assigned a different address when it’s restarted. If you need a predictable IP address that can survive restarts, allocate an Elastic IP address and associate it with your instance. You can edit or change an instance’s security group (which I’ll discuss a bit later in this chapter) to update access policies at any time—even while an instance is running. You can also change its instance type to increase or decrease its compute, memory, and storage capacity (just try doing that on a physical server). You will need to stop the instance, change the type, and then restart it.
Resource Tags
The more resources you deploy on your AWS account, the harder it can be to properly keep track of things. Having constantly changing numbers of EC2—along with accompanying storage volumes, security groups, and elastic IP addresses—all spread across two or three VPCs can get complicated. The best way to keep a lid on the chaos is to find a way to quickly identify each resource you’ve got running by its purpose and its relationships to other resources. The best way to do that is by establishing a consistent naming convention and applying it to tags. AWS resource tags can be used to label everything you’ll ever touch across your AWS account—they’re certainly not restricted to just EC2. Tags have a key and, optionally, an associated value. So, for example, you could assign a tag with the key production-server to each element of a production deployment. Server instances could, in addition, have a value of server1, server2, and so on. A related security group could have the same production-server key but security-group1 for its value. Table 2.3 illustrates how that convention might play out over a larger deployment group.
Applied properly, tags can improve the visibility of your resources, making it much easier to manage them effectively, control costs, and avoid costly errors. Service Limits By default, each AWS account has limits to the number of instances of a particular service you’re able to launch. Sometimes those limits apply to a single region within an account, and others are global. If necessary, you can request AWS to raise your ceiling for a particular service. As examples, you’re allowed only five VPCs per region and 5,000 key pairs across your account.
Questions related to this topic
- How do I find the IP address of an ec2 instance?
- How do I find my ec2 instance tags?
- Which IP address of an ec2 instance is used to connect from external?
- How do I access an ec2 instance in a private subnet?
You can find up-to-date details regarding the limits of all AWS services at https://docs .aws.amazon.com/general/latest/gr/aws_service_limits.html.
This Blog Article is posted by
Infosavvy, 2nd Floor, Sai Niketan, Chandavalkar Road Opp. Gora Gandhi Hotel, Above Jumbo King, beside Speakwell Institute, Borivali West, Mumbai, Maharashtra 400092
Contact us – www.info-savvy.com
