Getting Started with AWS Cloud and Terraform | Wahl Network

hello innovators and welcome to this course on getting started with both AWS cloud and terraform infrastructur code today we're going to be building an Enterprise likee Landing zone so that we have a safe place to learn terraform develop with terraform and not have to worry about having an insecure or horribly expensive environment we want to have a very lowcost environment to learn with here's the goals of today I'll be building the wall Network Enterprise Landing Zone and don't worry we're going to go over all these terms as the course unfolds and you'll be building your own Enterprise Landing Zone we're going to do that by setting up AWS control tower and the identity and access management or I am identity Center this will be used to construct a learning environment a place that we can build resources very simply and easily we can see them be constructed we can throw them away we can keep our costs very low once we have this initial setup created we're going to bootstrap or initialize our sandbox account with terraform and we're going to do that first using local state on our computer and then once we've created the resources in our sandbox account we're going to migrate that state to remote State running in the sandbox here's a few tips that I have for viewing this course first both you and I we're going to take it slow I'll try to make sure that it's easy to follow what I'm saying saying and my examples second I've got chapters for everything in this presentation you can skip around you can come back and view anything that you need by using the chapters third feel free to pause anytime that you need to and then fourth follow along with your environment so that you're creating your Enterprise Landing Zone and that the output of this course is having that ready for you to use for your AWS and terraform learning I do want to very clearly set expectations for what this course will be this is not going to be step-by-step every single instruction you need to follow this is not going to be me reading the documentation from AWS or Hashi Corp this is not going to be follow this exactly to recreate your environment you can thumbs it down you can say you hate the video but that's not my intent to make this course the purpose and what I do want you to potentially like this course for is to show you highle objectives on what to create to show you the desired outcomes and point out things that you should be thinking about and creating and ultimately to show you what good looks like because everything is going to change this video is going to age and I think if I show you the objectives and outcomes and what good looks like then you can tailor that to your specific needs and for whatever version of aw and Hashi Corp that exists when you watch this video part one the AWS Landing Zone this is going to be the foundation that we need to build in order for you to use it as an terraform learning environment let's get on the same page with the landing Zone Landing zones are just a place where we can create a kind of home for our applications and our data and our infrastructure what we do is we take all the controls for an environment such as who has access to audit things where do our logs go who can create accounts how do we View and monitor the activities going on within our environment and we split those controls into different AWS accounts and apply permissions to different roles to view and manage and operate those accounts the main goal for our purpose is to create a landing zone so we have a safe place we're going to call it a Sandbox to build that's because we're keeping security such as audit and logging and billing and organizational management isolated and separate from where we build and you're going to like that because it's a lot more comfortable when we can just have fun in an account in our sandbox and if something goes sideways we can just throw it away and make a new one without having to start the entire environment over from scratch I'd advise starting with a basic Landing Zone account structure and these five types of accounts when you use aw control tower it'll automatically make most of these for you using the organizational units and accounts that I'm showing you on the right side of the screen let's go through the different accounts first we have the management account this is the root account you don't get a choice in this account and it always exists this is where we're going to be able to pay our bills and see the cost of all of our accounts aggregated into one report the second account is something that like to create a network account this allows us to centralize all of our Network Ingress and egress resources such as having a Transit Gateway for all of our accounts to connect to and then additional resources such as an internet gateway or a natat gateway to control how our accounts get into and out of the internet there's also a log archive account and an audit account those are also created by control tower with the purpose of centralizing all of the law logs across our accounts so we don't have to maintain those on a per account basis we can aggregate all of our logs into one account and an audit account which is really a place where we can apply all of our security auditing and controls across our environments finally we have the sandbox account now we're not controlling anyone else's security or governance from this account it's just receiving the security and governance from those other accounts which means we can build things inside of it we can throw those things away we can even delete the whole account and make a new one and the entire organization is unaffected now that we have a basic understanding of the account structure that's going to be built and why those accounts exist let's move on to AWS control tower which is like a wizard that's going to make all of that stuff for us in the past we'd have to go make all these accounts and build the organization and just do a lot of work to construct a landing Zone fortunately today we don't really have to do any of it there's a wizard called AWS control tower that sets up all the governance for an AWS multic count environment for you and it takes less than an hour all the resources are automatically set up on your behalf and all of the guard rails sometimes called controls are going to be applied to keep your organization and your accounts from drifting which is really just saying the intent that you have for the security around your accounts will be in forced and you'll be notified if things start to change from what your intent is I'd say the moment you decide to move away from a single AWS account into a multi account architecture which is a good thing to do that's a very Enterprise likee environment that you're going to see in the real world using control tower is a great idea as your orchestration layer for all these accounts and controls this is the point where you're going to want to go into your AWS account access control tower and follow the wizard to create a basic multiac account architecture I'm leaving you a link to the official documentation in the description because AWS is going to evolve and iterate on control tower and I don't want this video to be about that specific process because honestly it's pretty boring to watch just follow the wizard create the organizational units and accounts that I've shown you and when you're done come back to this video who gets badges you get badges congratulations on your first two achievements for the landing Zone section we have the awesome architect which you are because you've built a multi- account well architected Landing Zone secondly we now have a Sandbox account so you're a Sandbox hero we're no longer going to be building in a single AWS account where everything is Under One Roof we now have the ability to to use a Sandbox to make building much more safe and therefore fun with control tower out of the way let's focus our attention on billing and cost management this is the thing that usually get people a little stressed out thinking about oh my gosh I have all these accounts and services how much is it going to cost me we're going to Wrangle that right now start by navigating to the billing and cost Management Service and then selecting budgets you won't have one but but we're going to build a monthly budget with a spending amount and alerts as we consume the budget for a monthly budget there's really two things that we're worried about one that it's a recurring budget which means we set a spending amount and then every month we spend up to that amount we alarm if we hit certain thresholds then a new month comes along and we reset the spend back to zero secondly the budget amount how much money do you expect to spend on a monthly basis this could be three or $5 if we're just very quickly building some things and throwing them away or not doing too much resource construction or in my case I have $10 because I tend to build things for a couple days or a week I tend to build larger things like kubernetes clusters and some ec2 instances and that's going to cost me a few dollars on a monthly basis we don't have to wait for the entire $10 in this case to be spent we can set up alert thresholds and we can set up multiple thresholds so I advise having at least one threshold in this case you can see when I hit 50% of the budgeted amount we get an alert and that emails whatever email that you want here I have an example email you can even have different emails set up for a 50% alert or an 80% alert something like that and this makes it really easy to see and visualize where we're at on spending the budget every every month once your budget is created you get a preview of the budget and you can see here not only do I have the first alert at 50% kind of the hey Chris you're spending half of your budget you might want to see if something's been left on or if you've been aggressively creating resources but also an 80% threshold which is the all right whatever is going on we need to stop it unless we're at the very end of the month because we're burning through a lot of that budget I ALS o have two different email addresses where the 50% alert just goes to my inbox whereas the 80% alert also notifies me and says hey this is a critical email you need to address it right now the other way that we can easily track spend is to set up a budget report this is also in the billing and cost management section under budget reports which is just underneath budgets and I like to make a weekly report that I get every Sunday just outlining how much of I I spent where am I at that way I don't have to wonder I don't have to wait for an alarm to go off I just get a summary every week my budget report is called the weekly spend update there's only two things you really need for a budget report first is you have to base the report on a budget so we already have the monthly budget I'm going to base my weekly report on that budget and then when do I want it I want it every week on Sunday again you can pick whatever you want whatever works best for your schedule and an email email address and again as a little bit of a tip make that email address unique and set up your inbox so that it won't get lost and that it notifies you and it's something that you're going to see every week so you can view it and go okay cool I've spent $2 or $3 that sounds about right this is what the email is going to look like and you can see I flagged it as an update and that it's a priority email coming into my inbox it just says hello here's your budget you have $10 in your budget at the time of this email I had spent $2.34 so on Sunday I wake up to this email and go okay great that sounds good to me look at you you're a budget Buster for setting up your first AWS budget and alarms and a report on your budget this is going to help you see and control costs and make sure there's no surprise bill at the end of the month it's now time to set up our single sign on using the I am identity Center start by creating your identity Source this is going to be where your users and groups and permissions are created and managed within your Landing Zone you'll be creating a direct identity source which means it's built and managed directly within AWS we're not relying on a third party or some other identity source to provide our user in groups as you create your identity Source I highly recommend going to the authentication Tab and set setting up MFA or multifactor authentication even though you are using this environment for learning you're going to have multiple user accounts to represent the different roles for the controls in your environment such as you as an administrator versus you as a developer this mirrors a real world environment because no organization out there should ever allow people to log in without MFA I have M set to an 8 Hour session duration which means Once I pass the MFA challenge my session is authorized for 8 hours with your identity Source configured you'll notice there's a lot of groups in there that exist already they all start with AWS and then some words after that such as the security audit power users or control tower admins we're going to make two additional groups I recommend an administrator's group for your user account that's going to go in and act against your logging account and your audit account and management type function and then a developers Group which is going to be the primary group that we're using for our development user that's going to be constructing terraform code and building resources in our sandbox limit the developer group to only accessing the sandbox account that means that it doesn't matter what kind of powers this user has it can only ever log into the sandbox account it can't get into your management account or your audit account or anything else the sandbox account has one permission set applied AWS administrator access permission set that means that if I log into a user that belongs to this group I can get into the sandbox account as an account level administrator finally I like to make two different users my Chris Wall account is my regular daily User it's only belonging to the developers group it only has administrative access to the sandbox account and for most days that's all I need I don't need any anything else across the other accounts they're working as intended when I do need administrative access to other accounts I have my Chris Wall admin user that belongs to the administrators group I pretty rarely log into this but if I need to access my billing controls or perform security auditing or just really see what's going on outside of the sandbox account I use that user by splitting my control across these two users I'm applying more a well architected approach to how I access and control my Landing Zone and with that you've earned the fourth and final Landing Zone badge the security Guardian cuz we're now using single sign on with a daily development user for our access needs the last thing we're going to take a look at for the landing Zone portion is AWS organizations this is going to allow us to set policies across the entire organization ation of all of our AWS accounts head to the organization service and then select policies you're going to see a list of policy types A lot of them are going to be disabled and that's fine the type of policy we're looking for is service control policies commonly just called scps scps are how we can set policy that goes across all the accounts that we have in an organization it should already be enabled because you have control tower but if not go ahead and enable service control policies your list of service control policies should look something like this where you see guard rails or controls from control tower being applied across all of your organization we don't want to touch those those are managed by control tower but we can see them here and we can see what they do if we're interested I like to add a custom SCP that makes sure that all of our S3 buckets are denying public access the concern over public S3 buckets is on everyone's mind every organization is worried about having a public S3 bucket meaning data they put in the bucket is now accessible by anybody on the internet that's usually how information is exfilled or stolen from an organization that's less of a concern these days but I like to make absolutely sure it's impossible by creating a deny rule as a service control policy so go ahead and click create policy and we'll be generating this deny public S3 access SCP that you see here go ahead and name your policy whatever you want I recommend deny public S3 access and we're going to apply that to our entire organization the content of an SCP is contained in Json code as you can see here and don't worry I'll have a link to the content that you see in the description so that you can copy it and paste it into your environment or update it if you want something slightly different within this SCP statement we're really saying two different things here the first is denying public S3 access which means if someone tries to take action on a bucket where they're putting an ACL or a policy meaning they're creating a policy or an access control list or an object ACL and we're trying to add public read to the header of that change we deny it so if at an API level we say nobody can apply the public read as an attribute to a bucket they can't make a public bucket additionally if someone tries to alter the put account public access block there's a block of code for Public Access with the bucket and the accounts it's denied as well so no one can make the change to the API no one can change the header no one can change the public Block it's all completely locked down those actions are denied that's it for the AWS Landing Zone portion let's do a quick summary before we move into the next part of this course we started by creating the landing Zone via control tower which gave us our awesome architect badge because we now have that multiac account well architected AWS Landing Zone that included a Sandbox account giving us the sandbox hero badge because we now have an account that is isolated and safe for learning within we then built our budget and became a budget Buster having alarms and thresholds and a weekly report so that we have our finger on the pulse of our spend finally we earn the security Guardian badge because we set up an identity source for AWS with single sign on and our daily development user that keeps ourselves isolated to our sandbox account and makes it so that it's safe to make changes just to that account and not worry about blowing up the universe across all of our other accounts welcome to part two we're now ready to build upon that Landing Zone by creating our terraform infrastructure as code let's get started if you are new to infrastructure as code I'm going to use the example of wanting to make a cake if you want to build a cake you need a recipe the same works for infrastructure as code you want to build server and networks you want to set up the resources that exist in your AWS Cloud environment well we need a recipe for that terraform is a tool that lets us both write those recipes as well as execute the creation of making a cake by reading those recipes it's a fairly simple language that pretty much everybody should be able to pick up it's written in a fairly plain English type of format and it's structured in a way that makes it pretty simple to declare what it is that you want made in your Cloud environment and you can let terraform do the heavy lifting of building it within a terraform plan you're going to describe what you want your infrastructure to look like here's the VPC that I want here's the networks that I want in that VPC here's the security groups that I want Etc much like a 3D printer terraform is going to read that recipe or plan and then create apply destroy or modify your resource so that they look just like what you've asked for in your plan for the example here let's say I need some web servers and a database not only can I create those from the terraform plan but I can create different flavors or versions such as for development staging production and other environments the goal is that we're now managing infrastructure using a much more easy and reliable method which is quintessential for doing this at scale the only way we're going to be able to make hundreds or thousands of cake identically every time and consistently every time is if we have a recipe and something like terraform that can read and execute those recipes I use VSS code as my integrated development environment or IDE and I'm going to cover how I set up vs code here if you use something different this should be roughly applicable and a lot of these tools you're going to need regardless of what IDE you use so follow along to begin with you're going to need these two tools they're Baseline tools that you're going to need regardless one is the AWS CLI and I have a link here as well as in the description of where you can find and install that tool it's how we interact with AWS but more importantly it's how we're going to authenticate ourselves against the single sign on user that we created for the developers group it's also pretty handy if we need to troubleshoot something with AWS with without having to First interact with terraform speaking of terraform that's the other tool that you're going to need the terraform CLI just like with the AWS CLI I have a link here where you can grab it and you're going to use that to run all of the terraform commands on your computer for my windows users fan out there I use a tool called scoop scoop lets me install many of the tools that I use for day-to-day development without having to worry about installation and management of the upgrades I show you here with a scoop list some of the tools that I have installed including the AWS CLI and the terraform CLI I make it a habit to update using scoop pretty much every time I log on for the first time in the morning I also love to make a shortcut for terraform because typing terraform requires nine letters every time that I type it and two just feels more efficient so I will use TF as an alias to terraform and you're going to see that throughout the demonstration coming up one way that you can do this in the windows environment is just creating a very small function within your user profile for Powershell called TF and Alias that to the terraform deex command line tool with the arguments that you pass to it every time that we work with vs code or whatever tool that you're using for your development you're going to need to authenticate to your AWS environment specifically your single sign on environment this requires using the AWS CLI tool with the AWS SSO login or configuration beforehand in order to establish your session if you're new to the tool I have a link in the description and on your screen showing you the latest user guide that explains how to set up the tool for single sign on an example of what that looks like is right here where I've issued an AWS SSO login command it then brings up a web page where I agree yes I'd like to authorize my AWS CLI tool to use this session with my single sign on user once completed you'll see successfully logged into start URL along with your particular start URL for your AWS organization I'm also including a screenshot of what the approval of the request looks like so when the browser pops up after you type AWS SSL login you're going to approve that request and then you'll see request approved along with this message saying you can go ahead and close the window the session has been established you're now connected and permitted to use whatever your role is entitled to Via SSO the last thing is just a little bit of homework I want you to log into your sandbox account and look at your IIM service you're going to want to go to the rol section as shown here and find your role principal name for example I've set it up so that my role is entitled to the AWS administrative access permissions and so I've gone and found the role called AWS reserved SSO AWS administrative access and then kind of a random string of characters at the end we're going to need that for later because that's how we're going to tell terraform hey guys this is the role I want you to use whenever we're interacting with the AWS environment in the terraform context that role information is ultimately going to be put into a tfvs file that we'll go into in just a bit so you want to find the inputs folder of the code go to the sandbox. tfrs file you're going to want to find the key called terraform State SSO principal name and then make the value equal to the name of that SSO role that you found in I am congratulations you got your first terraform achievement badge the tools of the trade badge because we've set up our vs code environment and the terraform CLI along with the AWS CLI before we start writing any code let's take a deep dive into the terraform files what they do how they work all that kind of jazz within the landing Zone folder you're going to see something like what I have on the screen and I want to start first by saying that the names and structure of these terraform files really aren't used by terraform very much they're for us as human beings we're going to organize and structure our files so that it's way easier to reference where the code is and structure it for other people that way someone that's never seen your code can open the folder have a pretty good idea of what's going on terraform however doesn't really care it's just going to find all the terraform files and sort of Squish them together into one giant pile of terraform and then interpret that to figure out what your plan is the primary kind of core files are here main.tf being Chief among them

this is the primary file that we're using to contain all of our main terraform code the resources that we want to build there's also an outputs file that contains terraform commands to Output information about resources that we've created and a provider file that tells terraform what provider is going to provide the code for the resources that we're building and in this case it's pretty much all going to be the AWS provider now the benefit here is that our plan is pretty straightforward we're really just building a handful of things the first first is a budget for our sandbox account so that at that account level we can understand how much we're spending and alert on that and kind of see and visualize what our spend is for the sandbox account we're going to create an S3 bucket to later on store our terraform state in this account we're going to construct a KMS key to encrypt data going into and out of our S3 bucket this is somewhat optional but we're going to do it because it's fairly common to see in a real world environment and then finally we're going to build a Dynamo DB table this is a traffic cop of sorts where we can lock and unlock changes being made to state so that when we're manipulating the state file we can lock it that way no one else can make changes while we're busy making changes moving on through the files we also have a backend file and this tells terraform how to reach the backend or location of where our state file resides and keep in mind when we start working with this plan our state file is going to be local actually in the folder on our computer locally held on the hard drive later we're going to move that to remote state where it's being stored in that S3 bucket corresponding to backend is an inputs folder with a sandbox. backend file that has all the answers to what the backend needs so the inputs to the backend file are stored in our inputs folder finally we have the variable file this tells terraform about the variables that we're going to use within the plan so their name a description of what they do the type of variables that they are then in the inputs folder we have the answers to those variables for our sandbox environment basically meaning that every time we have a variable the tfvs file is going to answer what is the value of that variable all right last step before we run the plan let's talk a little bit about why we creating these resources and our process to consume those resources so that we can move the plan from a local location to a remote location the Trinity of things that we need in order to have remote state are really the bucket the key to encrypt and decrypt information out of the bucket and the Dynamo DB table acting as our traffic cop we're going to use Terror formform to create these Resources with a local plan and then once they're created we're going to migrate the state over into these resources at a high level that just means that we're going to initialize our terraform plan using local state we're going to apply that plan by creating those resources again with local state once they exist we're going to adjust our plan and say actually we want you to use this remote State using these resources that you yourself have built then we're going to migrate the state over to the remote and now we're completely off of our local state file we are only consuming remote State at that point this is really to solve the Chicken and the Egg problem because we can't have remote State until we create the resources but I don't like creating these Resources by hand I'd rather use code to do it especially if we're going to do this for multiple different accounts do you really want to go into 10 or 100 accounts and have to make a bucket and a key and a Dynamo DB table again and again and again no we can just write a little bit of code and let it do it and in pretty sophisticated Enterprise environments we would even automate this so that every time a new account is created it's automatically running this code to bootstrap all right it's time let's run some terraform to go through this plan create the resources and actually look in the AWS sandbox environment to see that they've all been generated to begin navigate to the folder that we're working with the landing Zone folder and run terraform anit this is going to look at your backend which is currently local and you'll see something like this on your screen once we have that initialization complete we've got the provider plugins downloaded in this case we need AWS and you'll see terraform has been successfully initialized has some green text which looks happy and this just means that we're now ready to run terraform commands against the code once you initialize you'll notice some changes in the folder first there's going to be a DOT terraform folder that's created and this will contain information on your providers such as as you can see here it's downloaded the version 5.87 of the AWS provider that way every future time we want to run this plan we already have the provider here locally to execute against and again it's going to interpret the AWS resources that we've described in the terraform plan you're also going to see a lock file appear that contains information on this initialization the providers that we've downloaded and the versions of those providers we can now ask the crystal ball that is terraform what if we ran this plan and that's what the terraform plan command is all about what would happen if you were to execute on this plan we're also going to pipe in a parameter called- dv- file and we're going to point that at our sandbox. tfar file that lives in the input folder so we're saying terraform I want you to run a plan and just show me what would happen using the answers from this inputs folder specifically the sandbox. tfrs file when that runs it's going to read the information from this file and provide it as answers to our variables and then run through the plan when you run this command terraform will read through the plan see that you're looking to create resources and then tell you about all the different resources that it wants to create because we have haven't made anything in the past so there's nothing to modify or destroy now if you're really quick while running the plan you're going to see this terraform TF State lock info file up here that's the lock that I've been talking about you're only running locally at the moment so the lock is really just for you but in the future that lock is going to exist in the Dynamo DB table this file quickly appears and then disappears The Moment you're no longer running the plan so you might have to run it a few times just to see that it's there and then watch it disappear very quickly towards the bottom of your terraform plan is a summary basically saying this is what I'm going to do I'm going to make this many things I'm going to change or destroy this many things and in our case it should be eight things that are going to be added because we're creating those things for the first time you'll also see a changes to outputs remember we have an outputs file that describes the output information that we want from resources that terraform plans to create since we've never made these outputs before we only are going to know what the outputs will be once we've applied the plan once you're happy with your terraform plan and it looks like it's going to create everything that you want there's no errors you're ready to apply we're going to use basically the exact same command structure except this time we're saying I don't want to just pretend to see what's going to happen I actually want to do it so terraform apply with that same input of the VAR file for the sandbox.

tfvs the summary of the output will change we're still going to add things we're not going to change a destroy because we haven't made anything yet and we're still not going to know what the outputs are going to look like just yet either because we haven't made anything but now you're asked a question do you want to perform the actions that terraform is proposing to you do you want to make those eight things if you answer yes it will make the things if you answer anything other than yes it won't make the things here I've said yeah terraform I do want these things I say yes and now I'm ready for you terraform to make them and you'll notice it's arranged all the resources into the optimal order of creation because terraform under the covers has a graph that knows how to make the resources and in what order to reach your goal so you can see here we made the key the budget the Dynamo DB table the bucket Etc all of that gets created one after another and when we're done the resources are created we can see eight added zero changed zero destroyed as well as now we actually get the outputs we can see the Amazon resource name or ar for our budget and our table and our key and basically everything that God built additionally we have yet another new file that's located in our terraform Landing Zone folder the terraform dotf State file this is that state file I've been talking about the whole time because our backend is still local the state file is right here on our computer and it's a pretty critical file we want to protect it we want to keep it highly available and resilient and so keeping it local isn't the best idea but it's okay for right now because we're bootstrapping this account with the basics that are necessary for remote state if you dig into it like I have here you'll notice it's just a bunch of key value pairs for the version of terraform that we're running the outputs the resources all the information like a receipt is contained within this state file with your terraform plan run successfully and your resources created let's take a look let's log into the sandbox account you can see here by going to S3 that we have our new bucket the sandbox terraform State bucket which is where we're going to store our remote state if we drill a little bit deeper into the bucket we can see a few things one Public Access is blocked remember we have an SCP controlling that and we have never enabled public access to our bucket that's a good thing we don't want anyone going to this bucket but also that SSO principle that I had you gather earlier for the TF bars file is being applied as the only principle that we're going to allow to interact with this S3 bucket no one else in the account can touch the bucket additionally if we look at the Dynamo DB service we can see there's a new table there's our Landing Zone terraform State lock table that we'll be using to lock and unlock the terraform State once we locate it in a remote location and then finally I created the KMS key here to encrypt and decrypt information going into and out of our S3 bucket as a reminder we don't absolutely need this and it does cost a little bit of money I think it's about a dollar per month but you're pretty much always going to see this in a real environment and so I've included it here so that it can act a bit more realistic the use of the KMS key Alias makes it pretty easy to see what this key is being used for and I use the name of the state bucket as the Alias so that it's really easy for someone that may not know your environment what is this key being used for the last thing is a very simple budget that I have applied directly to the sandbox account set for $5 so we can see what our spend in this account looks like and alert if we start to exceed that congratulations you've achieved another badge you have the terraform Wizardry badge because you have run both a terraform plan and a terraform apply using local state now that we've created all the resources that we need in the sandbox account for remote State let's go ahead and go through the steps to migrate State into this account and then showcase what the terraform State file looks like when it's living in S3 to begin we need to update the backend. TF file now you don't really needed up until this point it can be completely blank but I left one that's commented out remove the comment so that we have a terraform block containing a backend of S3 just a note here you could put all the details that you need for your backend in the file but I like to keep my code dry and empty of configuration so all the configuration is going to be stored elsewhere specifically we store the configuration in the inputs folder under the sandbox. backend file just like we had a variables file answering all the variables information we have a backend file providing all the backend information so you can see here the backend file contains information that we need to reach that remote State like what's the name of the bucket we're going to talk to where do we want to put the state file which is the key so we're putting it into a folder called sandbox and then a child folder named Landing Zone and we're going to call the file terraform dotf State we're also letting terraform know what region we're working within the name of our Dynamo DB table and the fact that yes we do want encrypt traffic to this bucket with this set we can now change the configuration of terraform by running the initialize command again or terraform a nit we're going to pass a parameter of --back end- config and tell it where that backend configuration is in this case it's in the inputs folder in the sandbox. back and file when we

run this we're going to get a few questions kind of like a little wizard that terraform runs us through first it's going to say hey I already have state locally are you looking to move that state to this remote back end and it's pretty verbose about that it sees that we have an S3 backend that we have local state and that we don't have anything in this remote State and so yes put yes for that we do want to migrate the state to that remote State and we then go through the proc process all over again you see that S3 has been configured the backend configuration changes have been accepted we're checking to make sure we still have the providers that we need and at the end terraform has been successfully initialized once this is complete that terraform DTF State file that we had locally it's still going to be there but it's empty now because we're not using it we've pushed the state remote into the S3 bucket go ahead and log into your sandbox AWS account go to S3 and then navigate to your terraform State bucket here I've gone ahead and loaded it up I've opened up the sandbox folder inside of that and then the landing Zone folder inside of that you can now see terraform ttf State exists exactly where we told the key to put it proving that we now have remote State because that file didn't exist before now the other benefit is that we have versioning enabled on our S3 bucket every time we make updates to the terraform ttf State file we'll get a new version of the file in S3 which means we can restore from a corrupted version or if something happens to it we have that automatic versioning handled for us it's a very nice feature congratulations on your third terraform achievement badge the migration Mogul because you have now migrated local state to remote state after creating those resources in the sandbox account the last section of this course is a little bit of an exercise I want to give you a little bit of a challenge to go through to make a simple change see how you do let's change the budget value for the budget resource contained within terraform from $5 to $8 how would you make this change how would you test this change how would you then apply this change and where would you go to look to see the results of this change pause here give it a shot then resume when you've gone through it the value of the budget isn't stored in the code it's a variable and all the variables are stored in our tfvs file so first you'd want to find the budget amount in the tfvs file here I've shown you on line four the budget amount was five and so making it eight would be all you'd have to do to change the value from 5 to 8 testing the change involves a terraform plan where we'd want to tell it where those tfrs exist when we run this plan you'll see here the limit amount of our budget changes from 5 to eight it's the only change that's being proposed because it's the only change that we've made note that terraform knows this because it looks at the state file and says well it used to be $5 and now I see it's $8 that's a change and so one resource is going to change with this test complete we can now apply the change so running the terraform apply command will go through the same process and say I'm going to change the budget limit from $5 to $8 are you okay with this once you answer yes that change will be performed I've zoomed in a bit to make it easier to see and that the budget resource has been changed with a new budget amount assigned finally we verify the change just to see what that looks like and that's going to involve logging into your sandbox account navigating to the billing and management section and you can see here the monthly budget that we have assigned to that sandbox account now shows a budgeted amount of $8 instead of five as a bonus if you went to the S3 bucket as shown in the bottom left corner you can see we now have a new version of the state file because it is changed to reflect that $8 budget huzzah the fourth and final terraform achievement badge is yours you have the terraform innovator badge because you've made a change to an existing resource in AWS via terraform let's do a recap of the terraform and infrastructures code section of this course we started by setting up VSS code and downloading and configuring the terraform CLI and the AWS CLI from there we went through the terraform plan ran that locally and then applied it using local state after that we migrated that local state to remote State using those resources that we Creed with terraform and then lastly we made a change to one of those resources updating the remote state with a new version I have two questions for the comments below how did you do following through this course and what do you plan to build with your brand new Enterprise like AWS Landing Zone and your terraform learning environment this is my first time building a course like this I would love your feedback your comments below are awesome they help people find this course and give me the motivation to keep going and build more so if there's something you specifically liked let me know if there's something that needs improving cuz it wasn't so great also let me know I'm always open to ways to improve do you find a mistake comment below I'll do my best to fix it or at least make a hin comment so that others know about it and if you have ideas on future topics or just want to share Good Vibes again a like a subscribe a comment all of those things mean the world to me because I'd really like to keep going and make more courses like this to help beginners dive into the world of AWS terraform infrastructure is code and things of that nature thank you very much for your time hope you learned and enjoyed and I'll see you in the next one

2025-03-03 21:41

Other news