Episode 2: AWS EC2 Advanced Topics & Exam Traps

Hey everyone, Baloo here, welcome back to Tech Talk with Baloo. So we have already covered the fundamentals of EC2 in our main episode, but there are some advanced topics and exam traps that we need to discuss. These are the things that trip up people on the actual AWS Solutions Architect exam, and I don't want you to be caught off guard. Today, we're going to cover some specific easy to features that show up on the exam all the time, things like EC2 hibernate, elastic network interfaces, spot fleet strategies, and some really sneaky exam traps that AWS loves to test. This is going to be quick, but super valuable. So let's jump right in. Alright, let's talk about elastic network interfaces or ENI for short. Now you might be thinking, wait, isn't this just a network card on my instance? And you're right, but there's way more to it and the exam loves to test this. What is an ENI? An ENI is essentially a virtual network card. Every easy to instance has at least one ENI. That's called the primary ENI and it's attached on it's zero interface. But here's what makes this interesting. You can create additional ENIs and attach them to your instance or even move them between instances. And this is where the exam scenarios come in. Key characteristics of ENI. Each ENI can have one primary private IPv4 address. One or more secondary private IPv4 addresses. One elastic IP for private IPv4. One public IPv4 address. One or more security groups and a MAC address. So remember, it can have one primary private IPv4 address. One elastic IPv4. Private IPv4. So let's go through a real world scenario. Let's say you're running a license. The software license is tied to the MAC address of the network interface. If you're easy to instance fails, you need to move that license to another instance. With an ENI, you can detach the networking interface from the failed instance and attach it to a new instance. The MAC address stays the same, so your license keeps working. Now that's powerful. Another real world example. You have a management network and a data network. You want your instance to be accessible from both networks, but you want different security groups for each. So the solution attached to ENI's to your instance. It's zero with the management security group and it's one with the data network security group. Each ENI can have different security groups giving you granular control. Exam trap and this comes up all the time. Question. An application requires a fixed IP address even if the instance is stopped and started. What should you use? People often think elastic IP, but that's a public IP. The answer is use an ENI with a specific private IP address. When you stop and start the instance, the primary ENI stays attached with the same private IP. ENI best practices for the exam. ENI's are bound to a specific availability zone. Remember that. You cannot attach an ENI from, for say, US East 1A to an instance in US East 1B. ENI's can be created independently and attached later. This is useful for failovers in our use. When you terminate an instance, the primary ENI is deleted, but the secondary ENI's can persist if you configure them that way. An exam question pattern. A company needs to implement a solution where a network interface with a specific MAC address can be moved between instances. What should they use? The answer is elastic network interface. ENI. So the keywords to watch out for here are MAC addresses, move between instances, multiple network interfaces or different security groups per interface. Now let's talk about EC2-hybenate. This is a feature that's becoming more popular on the exam. What is hibernation? When you hibernate an EC2 instance, AWS saves the contents of the RAM to the eBS root volume and then stops the instance. When you start again, the RAM contents are restored and your instance picks up exactly where it left off. Think of it like hibernating your laptop. You close the lid and when you open it again, all your applications are still running. Your browser tabs are still open. Everything is exactly as you left it. So why would you use this? Let me give you a real world scenario. You're running a data analysis job that loads a massive data set into memory. Maybe 50 gigs of data. The initial load takes two hours. You run your analysis for six hours, but then you need to pause overnight. Without hibernation, you had stopped the instance, lose all that RAM data and tomorrow you had spent another two hours loading the data again. With hibernation, you hibernate the instance overnight, started in the morning and boom, all that data is still in memory. You saved two hours of your time. How it works technically? When you hibernate, AWS takes the RAM contents and writes them to the eBS root volume, as we said, the instance enters the stop state. You're not charged for the instance, but you're charged for the eBS storage. Remember that. When you start from hibernation, AWS reads the RAM contents from the eBS root volume, restores the RAM, your instant now resumes with all the processes still running. Requirements, this is tested on the exam. Not all instances support hibernation. Here are the requirements. In these families, C3, C4, C5, M3, M4, M5, R3, R4, R5, notice a pattern. Mostly the general purpose, compute and memory optimized families. RAM size must be less than 150 gig. This is a hard limit. Root volume must be eBS, must be encrypted, and must be large enough to store the RAM contents. This is critical. You cannot hibernate an instance stored back to instance. The root volume must be eBS, and it must be encrypted. Operating systems applies for Amazon Linux 2, Linux AMI's, Ubuntu Windows. The instance cannot be hibernated for more than 60 days. If you hibernate for longer than that, the instance stops instead. So an exam trap question. The company wants to hibernate an i3-8x-slag instance to save costs overnight. Is this possible? There is no. The i3 family has instant store as the root volume, and you cannot hibernate instant store back instances. Also i3 instances aren't in the supported family list. Let's look at another exam scenario. An application loads 200 gig of data into memory. The company wants to use hibernation to save cost. What should they do? The answer is this won't work. When the application supports up to 150 gig of RAM, they need to redesign the application or use a different cost optimization strategy. When to use hibernation. Exam keywords. Long running process, large data set, load in memory, application with lengthy boot time, need to preserve in memory state. If you see these keywords, think hibernation. Now we're not to use hibernation. If the question mentions production workloads that need to run 24/7, don't hibernate. Use reserved instances instead. If it's a state less application, no need for hibernation. Just stop and start normally. Now let's talk about EC2 instance connect. This is relatively new and AWS loves testing new features on the exam. So what is EC2 instance connect? It's a way to connect your EC2 instances using SSH but entirely through the browser. No need for SSH keys, no need for putty, no need for a terminal. You just click connect in the AWS console and you're in. How does it work? When you click connect, AWS temporarily pushes a one time SSH public key to your instance. This key is valid for 60 seconds. You authenticate through your IAM so AWS knows who you are. Then you get a browser based terminal. The magic here is that you don't need to manage SSH key pairs. You don't need to worry about someone stealing your private key or the indication is handled by IAM. What are the requirements? So your requirements are your instance must be running Amazon Linux 2. This is important for the exam. It doesn't work with all AMIs just for Amazon Linux 2 and some Ubuntu versions. Your instance must have a public IP address or be accessible through a bastion host. The security group must allow SSH on port 22 from the EC2 instance connect service IP range. AWS publishes these IP ranges. So real world use case. You're in a large organization with hundreds of developers managing SSH keys for everyone is an nightmare. People lose their keys, leave the company or the laptop gets stolen. With EC2 instance connect you use IAM permissions. When a developer leaves you just revoke their IAM access no more SSH key management. Pretty good. Another exam scenario. A company wants to allow developers to SSH into easy to instances without managing their SSH key pairs. The solution must integrate with an existing IAM permission. The answer is easy to instance connect. Alternative answer, system manager, session manager. Now, here's where it gets tricky on the exam. Systems manager, session manager, also allows browser-based access without SSH keys. So easy to instance connect uses SSH protocol, requires public IP or Bastion, requires port 22 to be open, works with standard SSH tools. Session manager on the other hand uses AWS Systems Manager protocol, works in private subnets, no public IP needed, no inbound ports required, more secure, more versatile. For the exam, if they mention no inbound ports or private subnet or no Bastion host, choose session manager. If they just mention no SSH key management and the instances public, easy to instance connect works fine. Alright, we covered spot instances in the main episode, but let's talk about spot fleet because this is where you can really optimize costs and the exam tests this. What is spot fleet? Spot fleet is a collection of spot instances and optionally on demand instances. You define your requirements, target capacity, instance types, availability zones, and spot fleet automatically requests the right mix of instances to meet your needs at the lower cost. Why is this powerful? Let's say you need 100 CPUs of compute power. You don't care if it's 25m5x large instances or 50m5 large instances or a mix. You just need 100 virtual CPUs. With spot fleet, you say give me 100 virtual CPUs and define multiple instance types you're okay with, m5 large, m5x large, c5 large, c5 large, so and so forth. Spot fleet then looks at the current spot prices across all those instance types and launches the cheapest combination. Even better, if one spot instance gets interrupted because the price went up, spot fleet automatically launches a replacement from a different instance pool. Allocation strategies, this is heavily tested. Spot fleet has four allocation strategies. Number one, lower price, that's the default one. Spot fleet launches instances from the pool with the lower price, simple straightforward maximum cost savings. Use this when cost is your primary concern and you don't care much about availability. Number two, diversified. Spot fleet distributes instances across all the pools you specify. So if you specified four instance types across two availability zones, that's eight pools. Spot fleet spreads instances evenly across all those eight pools. Why? Resilience. If the spot price spikes in one of the pools and your instance gets interrupted, you still have instances running in the other seven pools. Use this for workloads that need higher availability like web servers or processing pipelines that control right too many interruptions at once. Number three, capacity optimized. This is the smartest strategy. Spot fleet analyzes which pools have the most available capacity and launches instances there. The logic pools with more capacity are less likely to get interrupted. AWS has plenty of capacity there, so the spot price is much more stable. Use this when you want to minimize interruptions. It might not be the absolute cheapest, but you get much better reliability. Now to number four, price capacity optimized. This is the newer strategy. It looks at both price and availability capacity trying to find the sweet spot. It's like capacity optimized, but with a preference for lower prices when capacity is similar. Now an exam scenario. A company runs a batch processing workload on spot instances. The workload can handle some interruptions, but should minimize them. Cost is important, but not the only factor. Which spot fleet location strategy should they use? The answer is capacity optimized or price capacity optimized. The keywords are minimize interruptions and cost is important, but not the only factor. If it said minimize cost, you would have chose lowest price. Spot fleet with on demand base. Here's a really smart pattern. You can configure spot fleet to maintain a minimum number of on demand instances as a baseline and then use spot instance for anything above that. For example, you need 20 instances minimum to run your application. Configure spot fleet with on demand base capacity. It's a five instances target capacity. You would choose 20 instances, spot instances, 15 instances of spot instance. Now you always have five reliable on demand instances running and you get 75% cost savings on the other 15 spot instances. A company needs to run a web application that requires a minimum of 10 instances always available with the ability to scale to about 15 instances. They want to minimize cost while ensuring the baseline capacity is never interrupted. What's the best approach? The answer is spot fleet with on demand base capacity of 10 and a target capacity of 50. Now let's talk about capacity reservations. This is something that confuses people so let's clarify that. So what is capacity reservation? It's a way to reserve easy to capacity in a specific availability zone. When you create a capacity reservation, AWS guarantees that you can launch that capacity whenever you need it. Wait, isn't that what reserved instances do anyway? Nope, this is a common exam trap. Let me explain the difference. Reserve instances give you a discount on compute. You commit to pay for compute for one or three years and you get up to 72% discount. But you're always paying for it, whether you use it or not. Capacity reservations on the other hand guarantee that capacity is available when you need it. You're not getting a discount and you're only paying for what you actually launch instances into that reservation. Think of it this way. Reserved instance is I'm committing to pay for this compute for a year, give me a discount. Reservation on the other hand is I need to make sure this capacity is available when I need it, but I'll only pay when I use it. You can actually combine them, by the way, this is a really smart pattern. Create a capacity reservation to guarantee capacity is available and buy a reserved instances to get the discount. Now you both guarantee capacity and cost savings. So when would you use capacity reservations? Imagine you're running a disaster recovery scenario. Most of the time your dear site is shut down. But if there's a disaster, you need to launch 100 instances immediately. What's the problem? What if that availability zone doesn't have the capacity for 100 instances when you need them? The solution is to create your capacity reservation for 100 instances. You're not paying for them until you launch them, but you're guaranteed they're available always. Another scenario. You're running a batch processing job that runs on the first of every month. You need 500 instances for 24 hours. The rest of the month you don't need them. Create a capacity reservation for 500 instances. Launch your job on the first day of the month, terminate the instances when you're done. You only pay for that one day, but you were guaranteed to have that capacity. Now let's go on to an exam question. A company needs to ensure capacity is available for a monthly batch job, but doesn't want to pay for instances when not running the job. The answer is on demand capacity reservation. Now common exam trap. A company wants to reduce costs for instances running 24/7. Should they use capacity reservations? Answer is no. Capacity reservations don't give you a discount. Use reserved instances or saving plans for cost saving. Alright then. Let's talk about the most common traps and gotchas on the actual exam. These are the questions that trip people up, so please pay close attention. Trapp number one. Elastic IP charges. Question. A company stopped all their development easy to instances over the weekend to save costs. They noticed they're still being charged. Why? People think stopped instances shouldn't cost anything, right? But the answer is they're being charged for the elastic IPs attached to those stopped instances. So here's the rule. If an elastic IP is allocated but not attached to a running instance, you're charged about $0.005 per hour. That's about $3.60 per month per unused elastic IP. The exam loves this trap. Remember stopped instances plus elastic IP attached? You are paying for that elastic IP. Now, trap two. Placement groups and instance types. Question. A company wants to launch T3 medium instances in a cluster placement group for low latency. Is this possible? The answer is no. Cluster placement groups require instances that support enhanced networking. Three T3 instances don't support enhanced networking. The example try to trick you by asking if you can use burstable instances T family in placement groups. The answer is usually no for cluster placement groups. Trap number three. EBS volume available to zone. Question. An instance in US East 1A needs to attach an eBis volume from US East 1B. Is this possible? The answer is no. eBis volumes are tied to a specific availability zone. You cannot attach a volume from US East 1B to an instance in US East 1A. The solution is to create a snapshot of the volume in US East 1B, then create a new volume from that snapshot in US East 1A. 4. Instant Store and Stop Start We covered this before, but it's so important I am just repeating it. The question. An instance with instant store volumes is stopped and then started. What happens to the data? The answer is all data is lost. Instant store data only survives reboots. Not stop or start. The example phrase this in tricky ways, they might say an administrator stopped the instance to upgrade the instance type boom, the instant store data is gone. Trapped number 5, public IP changes. The question is, an instance is stopped and started. What stays the same and what changes? The answer. Instance ID stays the same. Private IP stays the same. Public IP changes unless it's an elastic IP. Elastic IP on the other hand stays the same. Data on EBS stays the same, but data on the instant store is lost. Memorize this table. It comes up on the exam constantly. Trapped 6. Enhance Networking Question. An application requires network performance of the 25GB/s, which instance type should they use. The trap. People think just pick a big instance like M5 large and you'll find. But you need to check if the instance type supports Enhance Networking and if it supports the required network performance. Not all instances support 25GB/s. The answer is usually a current generation instance with Enhance Networking enabled like the M5N25x large or the C5N18x large. Trapped 7. Termination protection. An administrator accidentally terminated a production instance. The company wants to prevent this. What should they enable? People think termination protection. But here's a catch. Termination protection only prevents termination through the console, CLI or API. It does not prevent termination from an auto scaling group scaling events, spot instance interruptions or OS shutdown commands. For the exam, know that termination protection is limited. If they want full protection, they need IAM policies. Trapped number 8. Instance metadata versus user data. The question is, how can an application running on EC2 find out its own instance ID? The answer is query the instance meta service. Not use user data. User data is what you provide to configure the instance. The information about the instance. Common example. They ask you to get the instance ID region or availability zone. The answer is always instance metadata. Trapped number 5. Dedicated host versus dedicated instances. Question is, a company is to use existing Windows Server licenses. Answers dedicated host. Not dedicated instances. Here's the difference. Dedicated host will have the visibility into physical servers, sockets and cores. You can bring your own license BYOL. Dedicated instances. They run on dedicated hardware, but you don't control the physical server. You can't use the BYOL. For licensing questions, the answer is mostly dedicated host. Trapped number 10. The instance state table. This is the most tested concept. So let me give you the comprehensive table. If you rebooted your instance, what do you keep and what do you lose? You keep everything. Your instance ID, your private IP, your public IP, the elastic IP, the ebius root volume, the ebias data, the instance store, the billing, keeps continuing. If you stop the instance, what changes? The public IP changes. You lose your instance store. Your billing stops except the ebias that's attached. Now what happens when you hibernate? Your public IP changes. Your instance store loses, again very similar to stopping the instance. You get stopped for billing except the ebias volume that's attached. And if you terminate the instance, you lose your instance ID, you lose your private IP, you lose your public IP. You release the elastic IP. The ebias root volume gets deleted by default. The ebias data is optionally lost. The instance store is lost and the billing stops. Remember this table and write it down, tape it to your wall. You will see questions in various forms testing this on the exam. Trap number 11, sport instance pricing. The question is, a sport instance is running. The sport price goes from 0.03 to 0.06 dollars per hour. How much does the customer pay? People think they pay 0.06 because that's the current price, right? Wrong, you pay the sport price. But if you are interrupted by ebias, not if you terminate yourself by the way, you don't pay for the partial hour you used. But if you terminate the sport instance by yourself, you pay for the full hour. This is a very sneaky exam question. So trap 12, security groups are stateful. Question. Security group allows inbound SSH on port 22. What outbound rule is needed for SSH to work? Answer is none. Security groups are stateful. If inbound rule is loud, the response traffic is automatically allowed outbound. Compare this to the NACLs, which are stateless. You need both inbound and outbound rules. Alright, let's wrap this up with some rapid fire examples. Tip 1. When you see lowest cost and can be interrupted, think sport instances. Tip 2. When you see steady state or 24/7 or predictable, think reserved instances or savings plan. Tip 3. When you see licensing requirements or per socket, think dedicated hosts. Tip 4. When you see cannot lose data or persistent, think ebias, not instant store. Tip 5. When you see multiple instant types and lowest cost for sport, think sport fleet with diversified or capacity optimized strategy. Tip 5. When you see MAC address or move between instances, think e and i. Tip 7. When you see large data set in memory and long initialization, think hibernation, but check the 150 gig RAM limit. Tip 8. When you see no SSH keys and browser based, think easy to instance connect or session manager. Tip 9. When you see high IOPs and something greater than 16,000, you need IOTBs volumes, not GP3. Finally tip 10. When you see shared storage across instances, think EFS, not ebias. Alright, everyone, that's it for our EC2 supplement. We covered elastic network interfaces and went to use them, EC2 hibernate and its requirements, EC2 instance connect for browser based SSH. Sport fleet strategies for cost optimization, capacity reservations for guaranteed capacity and most importantly the common exam traps that trip people up. These topics come on the exam all the time and now you're prepared for them. In our next episode, we're going to dive into IAM, Identity and Access Management. This is the foundation of AWS security and you absolutely need to master it. Now if you found this helpful, make sure you're subscribed to Tech Talk with Baloo and Spotify and if you have questions, drop them in the show notes. Until next time, keep studying and I'll see you in the next episode. This is Baloo signing off. Bye.