Gain in-depth knowledge for passing your exam with Exam-Labs AWS Certified Solutions Architect - Associate SAA-C02 certification video training course. The most trusted and reliable name for studying and passing with VCE files which include Amazon AWS Certified Solutions Architect - Associate SAA-C02 practice test questions and answers, study guide and exam practice test questions. Unlike any other AWS Certified Solutions Architect - Associate SAA-C02 video training course for your certification exam.

AWS Fundamentals: IAM & EC2

12. Private vs Public vs Elastic IP

Okay, so we're getting into the very interesting concept of private and public IP that may be too basic for you; I'm sorry. That is, but some people need help with this, so I'd rather help everyone. So networking is two sorts of IP. IPV-4 and IPV-6 are the most common. IPV Four is what is mostcommon, probably, you know already. It's basically four numbers separated by three dots. IPV 6 is a bit less common. It has this very long strand stringof exotic symbol numbers and letters. And in this course, we will primarily use IPV4. But know that AWS has support for IPV 6 as well. IPV-4 is still the most common format used online right now. IP Six is more for IoT, or the Internet of Things. And basically, it solves a lot of problems, but not for us. We don't have any problems with IPV4 so far. IPV-4 allows for 3.7 billion different addresses in a public space, and that's almost running out of IP addresses. And basically, each number can vary between zero and 255. Where are the dots? So if you do the math, you get 3.7 billion different addresses. Now, let's have an example of what that means. If you have a web server and it's public, there could be an easy instance; it'll have a public IP, and we can have another server with another public IP. And using the public IP, these servers can talk to one another, which is great. Now, when we have a company, for example, my company, and it has a private network, the private network basically has a private IP range. And private IP is one of these very specific ways of being defined. But basically, that means that all the computers within that private network can talk to one another using the private IP. Whereas when you touch an Internet gateway, which is a public gateway, well, these instances will also get access to other servers and so on. So that's a common pattern in AWS. Now, basically, if you have another company, it will also have a private network. And within the private network, every computer can talk to one another and maybe also have an Internet gateway with an IP, so it can basically connect all over the Internet and talk to other servers. Okay? So basically, the difference I want to show you is that when you have a public IP, you're accessible over the Internet. And when you have a private IP, you're only accessible within your private network. So there are some differences. Public IP, as I said, means that the machine can be identified on the Internet. And the public IP must be unique across the whole Web. So no two machines can have the same public IP. and I think that makes sense. And an IP issue gives you an IP; you can just Google it and find a geolocation, whereas a private IP means that the machine can only be identified on the private network only.And the IP must be unique not only across the private network, but across two different private networks. So two different companies can have the same private IPS. That is absolutely not a problem. And machines, when they're on a private network, will connect to the Internet through a net device and an Internet gateway that will act as a proxy. Finally, only a specified range of IPScan can be used for private IPS. Finally, for Elastic IPS, basically when you start and stop in situations, it will change its public IP, and we'll see this in the hands on.And if you need to have a fixed public IP, for whatever reason, for your instance, what you are going to need is something called an elastic IP. So the elastic IP is what? It's a public IPV4 file, and you own it as long as you don't delete it. Basically, you can attach it to one instance at a time, obviously. And basically, when you have an IP address that's elastic, you can use it to mask the failure of an instance or piece of software by basically quickly moving it from one instance to another. But it's quite an uncommon pattern because you can only have five elastic IPs in your accounts. Now, you can ask TWS to increase that, but it's quite rare to use them overall. I would recommend avoiding using elastic IP. They're often referred to as very poor architectural decisions, and instead you should use a random public IP and assign a DNS name to it. DNS will now recognise them as root 53. It's something that's going to be much more in control for us and much more scalable, either now or later. as we'll see. We can also use a load balancer and not use public IP at all, which is the best pattern you can have for AWS. Now let's go ahead and do a quick hands on sowe can get a good feeling for all these things. By default, our EC2 machine will come with a private IP for the internal AWS network and a public IP for the www web, and then when we're doing SSsession to our EC2 machine, we cannot use a private IP because we're not on the same network. Unless you have a VPN, we can only use the public IP if you don't have a VPN, and if your machine is stopped and started, the public IP can change. So now let's go and observe all these behaviors.

13. Private vs Public vs Elastic IP Hands On

Okay, so we have now our first instance that we've been using all along, and as we see, this has a public IPV4, so let's make sure that it works. So if we do SSH, Easy to use at, and then the public IP, we can get into our instance, and if you're on Windows, you might be using Putty, and so on. So we are in our instance, we are SSH'd into it, and we can issue commands from within. But now we can also see the fact that it has a private IP on the left hand side. So this starts at 172.31.0.0, and I cannot use that private IP to access my instance. Let's make sure of that. So let's go and type SSH and do Ecuador at this private IP, and as we can see, nothing is happening. It's going to time out because this is a private IP and I am not on the private network of AWS. I'm on my own personal private network, and so this doesn't mean anything on my private network. So the private IP here does not work, but if we use the public IP to SSH into our instance and then we look at the name of our instance, it says easyto user at IP 107, 23133, and 195, so we can see that this private IP is helping our instance to be identifiable on the private network of AWS. We can also look at ifconfig minus A, which is going to give us some information about our network interfaces. And so we can see here, in this first line right here, it says that my F is zero. So this is the primary virtual interface for the network of my EC2 instance; it is showing the IPs 107, 23133, and 185, so this is the whole meaning of a private IP. So I used a public IP to access my EC2 instance from my own personal laptop. But then on the network, this machine for the private instructor has this private IP. So this is great. Now let's disconnect from our machine, and let's take a look at what happens to the public IPv4 address if we stop and restart the instance. So you have to stop it, okay? You cannot just restart it; you can stop it, and so it's going to lose its IPV 4. So right now it's 35, 180 something, and after I stop my instance, the public IP is going to disappear. So let's just wait a little bit. OK, so my instance has now stopped, so I'm going to start it, set the instance date, and then start it. And so something we can see is that the private IP has not changed, so it's still 107, 23133, and 185, so my private IP in this instance has not changed, but if we look at my IPV, there are four public IPs, and now if I refresh, I see that there is a new IP. So there's this 1351-819-6137. So that's slightly different from the one from before. So we have obtained a new public IP. And so if you get the same public IPS before, it's maybe because you've done this too fast, so stop it, wait a minute or two, and then restart it. You're going to get a new public IPV four.So it shows you that if you stop and start your instance, then the public IPV 4 will change. And that's a common beginner's mistake in AWS. So now that the public IPV4 has changed, if you want to SSH into your instance, you will need to update the SSH command or your party command with the new IP. So now we are able to get into our instance just like we did before. And now I'm in my instance. And if you do, obviously the same config as we had before is still in place, as we can see the private IP has not changed. So what we've shown here is that the public IP does change when you stop, wait a bit, and then start your instance. So it's not stable, but your private IP is obviously stable. So the last thing we've seen is about elastic IP. So how do we make sure that the public IP remains the same across reboots? Well, the way to do it is to go directly into the Elastic IP Network menu on the left-hand side under network and security. So we're going to allocate an elasticIP address, and we have three options. We can use one IPV-4 from Amazon, which we will do, or you can bring your own IPV-4 if you have it. So we click on "allocate." And now we have assigned a new public IPV4 address, which will be Elastic. And so now we have to associate that elastic IP with the Rec 2 instance. I'm going to click on Action and then associate an elastic IP address. And here we have to choose an instance to associate that IP with. So I'm going to choose an instance, and for the instance, I'm going to choose my first instance that is running, and then we are going to click on Associate. So now let's get back into our EC2 console and see what has changed. So back to instances. I am sitting with my first instance right here. And as we can see now, the IPV4 for public IP is the same as my elastic IP, and it has a little link here because it's special. And so if I wanted to SSH into my instance, what I would have to do is write the new IP into my SSH command, which is now done, and I am able to SSH into my instance. But even better, if I right-click, I'm going to stop my instance, as we can see, and we'll need to wait just a little bit for the instance to go down. So as we can see, even though the instance is now in a stopped state, there is still an IPV, four public IPs, and an elastic IP assigned to it because now we want to make sure that this remains stable. So that's the whole point of elastic IP. And so right now, if I go ahead and start my instance, it's going to keep the same private IP, obviously, but it's also going to keep the same IPV4 for the public IP because we have attached an elastic IP to our instance. And so now that our instance is running, what I'm able to do is just go and run the same SSH commands before, and I should just restart right now. And now it works. And now in my instance so it wasa connection refused because the SSH utility hasnot yet started onto my easy to instance. That's why you saw it, but it's nothing to be worried about. And that's it. So we've seen how elastic IP works, and so what we're going to do is just release the elastic IP. So if I right-click and do instance settings networking, and then I'm going to dissociate the elastic IP address, we're going to remove that IP address from my instance. And, as we can see, we now have a new public IP address as a result of this. And now if I go to my elasticIP, this is something you get charged for when it's not associated with the running instance. So we don't leave it here, otherwise it's going to cost us some money. So again, what you need to do is go click on this IPV, four public IPs from the elastic IPpool, and you're going to click on action, and then you're going to release that elastic IP address so you don't pay for it because it's being unused. And so, when it's been released, you're all good to go, and there will be no charges incurred on your account. So that's it for elastic IP, IP, and private IP. Hopefully, that was very helpful. Put a lot of things into perspective andI will see you in the next lecture.

14. Install Apache on EC2

Okay, so in this lecture we are actually going to use our EasyToInstance to launch an Apache server on it. So we'll install an Apache Web server, and we'll basically replay a web page. And for this web page, we'll just create something called index HTML that will show the host name of our machine. So pretty simple, but let's go ahead; it's going to be a bit of fun, and we'll get to practise our security groups. The first thing I have to do is get the public IP because I changed it too many times, and then I will go into my instance and SSH into it using Patty or SSH, whatever you have as an operating system. So now that I am into my machine, it's time to go ahead and run some commands. So the first thing I'm going to do is perform a pseudo-suando, which will basically elevate my rights on the machine. I am now the root account, and I can run any command I want without any problem. So the first thing I want to do is do a Yum update and a Minus Y update. This basically forces my machine to update itself, and it's really important to keep all the packages updated. The minus y was to basically allow the updates to go through without prompting me to say, "Yes, I want to update." Once you have an update, what we can do is start installing HTTPD. Okay? So to do this, we're going to do yaml install -m yhtpd x 86 64. So that's a little bit complicated, but I'm sure you'll be okay. Then we basically install HTTPD, and the minus y was used to basically say yes and not have a prompt. Now I can clear my screen. And to start the service, we do systemctl start HTTPDOT service, and this starts the service. And to ensure that the system remains enabled across reboots, we say "enable the HTTP" service. So these two commands basically allowed us to start the HTTP service and make sure it was enabled across reboots. Now let's go ahead and see what happens. If we do a curl on localhostad, we should see this entire page. So curl is basically there to load whatever is in this URL. So if we do curl localhost 80, then we get this giant HTML page that is not very friendly, but it's working. So we kind of want to have this in a web browser, right? So why don't we access it from our Web browser? We go to our DNS instance and look at our public IP address. So what we have to do is open HTTP and then the IP address right here, port 80, which is just the HTTP port, and press Enter. And as we can see now, we just wait and wait and wait. What does that look like? That looks like a timeout. So around timeouts, what do we say? We said that yes, anytime there's a timeout issue, it's probably an error with the security group. Yes, indeed. If we go to view the inbound rules of our security group, we can see that it only allows port 22. But our Apache server was started on port 80. So what we have to do is open up that port 80 so we can access it. So I go to my security group in the inbound rules. I can edit and add a rule here in the dropdown; there is already an HTTP rule read for us. So we create HTTP TCP on port 80, and the customer will just say zero, and we'll say allow HTTP traffic for Apache. Click on save, everything looks fine. And now if you go to our web page and reload it, So let's go ahead and stop this. And now paste it, we can see that we got through. So by changing that security group and allowing this role for Port 80, we are able to get to our test page. And our test page basically says that it is a proper installation of the Apache HTTP Server. And we basically now have to add some content to the VARW email. So let's go ahead and do this. For this, I'm going to clear my screen and go to HECO Hello World into varwhtml index HTML. So basically, now if I go to my web browser and refresh this page, we now see "Hello World." So that's awesome. We just displayed our first web page on our machine. Now because I want to make things a little bit more interesting for this tutorial, I'll do it. Hello, please weld from and then the dollar sign. And here we can enter a command hostname minus "f." And then we'll put this into the same file. Basically what this does is that we'll make sure it says "Hello World" and then the host name of our machine. If you run this command right here: hostname minus f, it should say IP. Then the public IP, the private IP, and the region you're in are computed internally. So now, basically, when we go back to our AWeb browser and reload this, it says Hello World from IP and the IP of our machine. And this is actually not the IP; this is the internal DNS. So that's about right now; we get a Hello World, and we know which machine we're talking to. That's pretty awesome. So this was a quick lecture to install Apache Web Server because in the next lecture we're going to automate this installation using easy-to-use user data. So let's get started.

15. EC2 User Data

Okay, so we are going to learn about EC-two user data. So it is possible to bootstrap our instances using the ECT to user data script. So what does bootstrapping mean? Bootstrapping means launching commands when the machine starts. So that script is only run once, when it first starts, and then will never be run again. So the easy-to-use data has a very specific purpose. It is to automate boot tasks, hence the name "bootstrapping." So what tasks do you want to automate when you boot your instance? Well, you want to install updates, install software, download comment files from the internet, or do anything you can think of—really anything you can think of. So it could be whatever you want. But just know that the more you add into your user data scripts, the more your instance has to do at boot time. Simple, right? By the way, the scripts that access user data easily run with the root user. As a result, any command you issue will have the sudo prefix. Okay, so let's get our hands on it, and what are we going to do with it? Well, we're going to make sure that our EasyToInstance, when we launch it, will have the Apache HTTP Server installed on it and will display the simple web page we've been having. So for it, we'll just pass in the userdata script, and this script, as I said, will be executed when the instance first boots. So let's get started. So what I'm going to do first is terminate our instance. Yes, we're in the cloud, so we can start and terminate instances as we wish. It doesn't really matter; we're not going to get billed. It is fine. So now that this instance is getting terminated, we'll go ahead and launch a new instance. And that's really the power of the cloud. So we'll use Amazon Linux 2 AMI and select it, and we'll still use T2 Micro, which is free tier eligible. And then we'll configure the instance details. Now that we're in there, everything looks fine, but we'll scroll all the way down, and there are some sneaky advanced details in the bottom left. If you click on it, you will see user data. I don't know why user data was hidden so much, but here it is hidden under advanced details. So we want to input user data, and we'll input it as text. So we need to basically paste a whole script in there to automate the startup of our instance. Thankfully, I have a script. So the first thing we have to do is copy the Bin Bash sign right here, otherwise things will not work. So we have Bin Bash at the top of the script, and then we can just copy all the lines from line 10 to line 15. So we'll go ahead and copy all these lines right here, and basically this is saying, okay, update the machine, install HTTPD, then start HTTPD, enable it across, reboot, and create that Hello World HTML page. So, basically, all of the commands we ran in the previous lecture will be automated at boot time using the user data. So when you do this, make sure to add that first line. It's very, very important. Okay? That input is basically going to get base 64 encoded. It's just for you to know a bit of trivia. But basically, this will get passed onto the machine, and the machine will run that script. So this looks good. We click on Add Storage, and this looks fine. Click on "Add Tags." This looks fine as well. And for the security group this time, we're going to select an existing security group, which is my first security group. Yes, even though we terminated our first instance, the security group was still there, so we can still reuse it. And this is perfect because it allows SSH and port 80, which we already configured before. So we click on Review and Launch, and then we click on Lunch. And I will say, "Oh, we can choose an existing key pair." Easy Two Tutorial And I take this box, saying yes, I do have access to that key pair. Now, click on Launch Instances, and the instances launching If we go back to our View Instances panel now, we can see that we have one instance that was terminated and this one, which I'll just name my second instance right here, It's named my second instance, and the instance date is pending. Okay, so we wait for it to start. And now my instance is running. So if everything goes well, rolling drums, we can go to this IPV 4 public IP, open a web browser, paste the IP, and press Enter. And yes, it worked. We get Hello World from IP, and we get our entire DNS name that we have for this EC2 machine we just started. Basically, what this proves is that the EC to user data script worked, was started at boot time, and installed the Apache web server for us right away, which is quite awesome, to be honest. Now, similarly to before, because we have set up the keys correctly, we should be able to SSH into a machine. So let's try that out. Say yes, and we will SSH into our machine learning system to verify if things were done properly. We can go to the cathevar.com HTML file and see the index.html, which says Hello World from the DNS name we have from before, the host name. So this is perfect. We have a machine. It was configured automatically at boottime using EC-2 user data. I wanted you to get a feel for what ECU user data is. It is extremely important when you start using EC 2 because it will be used everywhere. So I hope you liked it, and I will see you in the next lecture.

16. EC2 Instances Launch Types

Right now we're going to talk about the EC's two instance launch types, and they're very important for you to know. going to the exam to understand which type of launch will allow you to either provide the best cost savings or the most stability, and so on. So let's have a look. And there are so many of them, as we'll see. So there are on-demand instances, and these are the types of instances we've been using from the beginning. So when we create an instance and use it right away, they're on demand. And it's great when you have a short workload and, once you have predictable pricing, you get an hourly price ahead of time. But if you run some instances for a known amount of time, for example, you know that at least for one year you're going to need an easy instance because maybe you run a database on it, then you should use a reserved instance type. And so reserved, as I said, is a minimum of one year, and you have different types of reserved instances. So the first one is called "reserved instances," where you say, "I want that instance for one year; it's for a long workload," but then the next one is a "convertible reserved instance," in which instead of saying you want a M-4 X-large for one year, you're saying you want "something" for one year, and you can convert what that something is. So maybe it's a M-4 X-large today, but maybe it's going to be a C-5 large tomorrow. And finally, we have scheduled reserved instances. So, for example, you want to say, "Hey, I want to have that instance every Thursday between 306 and 7 PM." Because I know I'm going to run some jobs between now and then, but other than that, I don't need it. But I know I will need this for at least a year. So this will be a scheduled, reserved instance. Then we have spot instances where it's going to be for short workloads. They're going to be very, very cheap, but the risk is that you can lose the instance, and that makes spot instances less reliable. So we'll see all of those in detail, by the way. Finally, we have dedicated instances where we know that no other customers will share the underlying hardware on AWS and dedicated hosts where you actually book the entire physical server and you control instance placements. So that's just a high-level overview, but let's go and do a deep dive into each of those to really understand how they work. So the first one is on demand, and with on demand, you're going to pay exactly for what you use, and the billing is per second after the first minutes. So this is what we've been using, and when we start or stop an instance, we just pay for the amount of time we've used it, and that's the highest cost because it's on demand and there are no upfront payments, but there are no long-term commitments. And it's great, for example, for this course, but it's great when you have short-term needs or uninterrupted workloads, or when you can't predict how your application will behave over time. So they're great for elastic workloads. Now, reserved instances are more traditional. it because we know that we're going to need that instance for a long period of time. We can get up to a 75% discount compared to the on-demand pricing tier, so we need to pay upfront for what we use for the long-term commitment. So you can pay up front with partial reservations and so on, but keep in mind that you would pay upfront for one year and reserve for one or three years, and you would reserve a specific instance type. And then for example, if you have a database, that would be the perfect use case. So if you have a reserve instances database and you want to run it for three years, then this is great; this will be the type of answer that the exam will drive you towards. So we also mentioned convertible reserved instances where you can change the EC-2 instance type. So they're going to be a little bit more expensive, but you have more flexibility in terms of the instance type, so you can make it evolve over time, and that gives you up to a 54% discount. And then we have scheduled reserve instances, which come up a lot in the exam as well, which is when we want to launch within a time window that we reserve, and that's only when we require a fraction of the day, week, or month. So again, as we said before, maybe we only need an instance on Thursdays between three and 6:00 p.m. And next, we have easy-to-spot instances. And these spot instances are going to be discussed at great length in the next lecture. But for now, I just want to give you a high-level overview of it. So with spot instances, you can get up to a 90% discount compared to on demand. so huge cost savings. But the Spot instances are instances you canlose at any point of time based onthe price you pay for the spot instance. So there's something you call the "max price," which is how much you're willing to pay for that spot instance, and if it happens that the current spot price goes over the max price, then you will lose your spot instance. So as such, they make it very cost-efficient, but they are only helpful for your workloads that are going to be resilient to any kind of failure. So what types of jobs can be resilient to failures? Well, a batch job that you can retry or data analysis that you can use with distributed computing or image processing that you can retry, etc. and et cetera. So anything that is possible to retry and is resistant to failure can be used with Spot instances, but what cannot be used with Spot instances? Well, I would definitely not recommend running a critical job on your Spot instances or even running a database on your Spot instance because the database needs to be up and running for years and years, and your Spot instance again has the risk of being lost based on demand and effort. You can also use reserved instances for your baseline capacity, which is a great combination. For example, say you're running a web application, and you know that year-round you're going to need at least ten instances to run the web application. Then you can reserve all these instances and get the maximum amount of cost savings. Then, for anything unpredictable that is going to be based on demand or for peaks, you can use a mix of either spot instances or on-demand instances depending on whether your workload can fail or not. As a result, you will have more agility and cost savings to deal with these peaks. That is a fantastic combination. Next, a dedicated host So dedicated Host means you get a physical dedicated EC2 server to use and full control over the EC2 instance placement, giving you visibility into the underlying sockets or physical core of the hardware, which is great for licensing. And what you get is that Host, youget it for a three year period reservation. So you need to know in advance that you're going to need a server ahead of time and that you need access to the underlying sockets and physical colours of the hardware. and that's usually due to licencing stuff. So it's definitely going to be more expensive. And as I said, it's useful if you bring your own licence model. Some licenses, for example, will bill you based on the number of physical cores on the hardware or the number of sockets. As a result, this is the type of use case for dedicated hosts. or, for example, if you have strong regulatory or compliance needs and you want to make sure you have your own hardware and not share it with any other customers, then that would be the way. Now, for dedicated instances, these are instances that would be running on hardware that's dedicated to you, and it may share the hardware with other instances, but only within your account, and you have no control over the instance placements. As a result, you can only move the instance placement from hardware after a stop and start. So this would be the difference between dedicated instances and hosts in that right-hand comparison table. And as you can see, the dedicated host does give you per-host billing, visibility into sockets, cores, host IDs, and some affinity. And the dedicated instances give you per-instance billing. So based on how many instances you place on the dedicated instance, So in the exam, I've seen dedicated hosts to be a much greater use case for questions than dedicated instances. But still, here is the table in case you needed to better understand how they're different. So the question is, which host is different? For me, on demand is going to be when you want to, for example; let's take a hotel as an example to compare. like we have a hotel. On demand means that you can stay, come, and go whenever you want and pay the full price. It's just you arrive and you say, "I want a room." Yes, we have a room, sir, and boom, here we go. Reserved is when you want to plan way ahead of time and you want to say, "Okay, I want to stay for one week or a month," and the hotel says, "Okay, you won't get to stay for a long time, but we'll give you a good discount because you know in advance they're going to stay and they know the room is going to be booked." Spot instances is, for example, just before the night starts,they know they have some free rooms and they wantto allow people to get these free rooms and theywill let people bid over the empty rooms and givetheir rooms to the one who wants to pay themost money for that room. But if someone comes and say, that would be weirdfor a hotel, obviously, but if someone comes and say,I'm willing to pay more, then they will kick youout of your room and that would be extremely awkward,but that would happen in the cloud world. And finally, the dedicated host will say, "Okay, I want to book the entire building of that sort or maybe an entire wing of that building, and that should be dedicated to me." So, hopefully, that helps you see a little bit how they compare. Now, in terms of price comparison, I think it's interesting to see how they work, just to get a sense of how things might work for an M-4 large instance. So for On Demand, I would pay ten cents per hour, and that would be the base price. For spot instances, it would be between 0.3 and zero point 45, and that would be up to 90% off. And I probably made a typo here—zero point 45. I'll correct this offline spot block to be around the spot price. So a good discount, reserved instance, depending if you payno upfront or all upfront is going to be zero62 or 00:58, which is less than zero point 10%. Obviously, about 50% less If you reserve an instance for longer oftime, for example, three years, then you're goingto pay even less 0.0 43. Now, if you want it to be convertible, which means you want to change the instance type, then the price is going to be higher, but still less than on-demand, and dedicated a little bit higher as well. And then scheduled, which is something you should plan ahead of time. As you can see, it's only going to be five to 10% off. So it's still some savings, but obviously because you're not using the instance a lot, it could be less than usual. Finally, Dedicated Host will be priced on demand, with reservations discounted by up to 70%. To give you an idea, they won't ask you about the right numbers in the exam, but they will ask you about what discounts are available based on the launch type. Alright, that's it. I will see you at the next lecture.

Pay a fraction of the cost to study with Exam-Labs AWS Certified Solutions Architect - Associate SAA-C02 certification video training course. Passing the certification exams have never been easier. With the complete self-paced exam prep solution including AWS Certified Solutions Architect - Associate SAA-C02 certification video training course, practice test questions and answers, exam practice test questions and study guide, you have nothing to worry about for your next certification exam.

Hide