Manage and Track Application and Infrastructure Configuration Changes using AWS Config
Manage and Track Application and Infrastructure Configuration Changes using AWS Config
Understanding the right tools to manage compliance for your application and infrastructure is critical to running operationally excellent workloads in the cloud. In this virtual workshop we will dive into the AWS Config service, and demonstrate some of the ways our customer’s use AWS Config to manage and track configuration changes in their environment.
Implementing Observability in applications is required for Operational Excellence. A well implemented Observability plan allows customers to react to operational events, run workloads effectively and gain insights into their applications. In this virtual workshop we will cover services and features our customer’s use to gain visibility into their workloads.
Learning objectives:
-Gain an understanding of the different components of the Config service, from config rules, config items, as well as remediation actions
-Gain hands on experience using the Config service to remediate non compliant items
-Learn how to use Config Advanced Query to quickly search for items that have a specific configuration applied
Learn more here: https://aws.amazon.com/products/manag… Subscribe to AWS Online Tech Talks On AWS:
https://www.youtube.com/@AWSOnlineTec…
Follow Amazon Web Services:
Official Website: https://aws.amazon.com/what-is-aws
Twitch: https://twitch.tv/aws
Twitter: https://twitter.com/awsdevelopers
Facebook: https://facebook.com/amazonwebservices
Instagram: https://instagram.com/amazonwebservices
☁️ AWS Online Tech Talks cover a wide range of topics and expertise levels through technical deep dives, demos, customer examples, and live Q\u0026A with AWS experts. Builders can choose from bite-sized 15-minute sessions, insightful fireside chats, immersive virtual workshops, interactive office hours, or watch on-demand tech talks at your own pace. Join us to fuel your learning journey with AWS.
#AWS
Content
2.15 -> [Music]
8.24 -> like to thank you for attending the
10.559 -> the next series of our workshop it's
13.04 -> entitled manage and track
14.559 -> applications and infrastructure
16 -> configuration changes
17.6 -> using aws config my name is isaiah
20.72 -> salinas i'm a senior specialist solution
22.8 -> architect for the cloud management
24.4 -> services here in aws
28.48 -> today we're going to talk about some of
30.08 -> the challenges that many have faced when
32.559 -> managing and tracking compliance changes
35.12 -> within our aws resources
38.16 -> we're going to go over as far as what
40.079 -> are the three lines of defense and how
42 -> can this help us
43.04 -> in managing and tracking compliance
45.76 -> we're then going to talk about
47.039 -> the aws services that can enable one to
50.239 -> track and manage
51.36 -> their configuration changes and keep in
53.6 -> a specific compliance state
55.84 -> then lastly we're going to go over a
57.199 -> demo on how we can utilize aws config
60.719 -> to help manage and track our aws
63.92 -> resources to run operational excellent
66.799 -> workloads within our aws environment
70.88 -> so first many customers tend to
74.479 -> ask themselves which service do i
77.52 -> use to help me with my compliance which
80.72 -> aws service
81.759 -> can i use to help me manage and track my
84.24 -> configuration changes
86.4 -> we have a wide range of aws services
90.24 -> but which one can help us manage and
92.88 -> track
93.36 -> our workloads within aws
98 -> to help us understand this we're going
100.079 -> to go through
101.28 -> what the institute of internal audit
103.04 -> provides us a guidance
104.32 -> called the three lines of defense as per
107.759 -> this model
109.2 -> the business unit frontline function
111.92 -> implementers
112.96 -> own and manage risk compliance this is
115.52 -> called
116.159 -> our first line of defense called manage
118.479 -> risk
119.84 -> our second line are the control
121.92 -> functions that set the guard wells
124.479 -> and controls and oversee that risk and
126.719 -> compliance are being effectively managed
129.84 -> this is our second line oversee risk
133.04 -> finally the third line assurance of risk
135.84 -> and management
136.56 -> are the functions that provide
138.959 -> independent insurance as to the
140.879 -> effectiveness of the risk management
143.12 -> and compliance we have mapped
146.319 -> the aws suite to these three lines of
149.12 -> defense model as a quick
150.879 -> reference of the service capability fits
153.84 -> with some overlap
155.76 -> the two use cases that we will drill
158.239 -> down more
159.04 -> in the following slide has also been
161.12 -> mapped to the three lines of defense
162.959 -> model
164.48 -> the first line manage risk these include
167.36 -> aws cloudtrail
169.12 -> aws config aws control tower
172.4 -> and aws license manager to help
174.56 -> customers to implement
176.319 -> operational controls of their cloud
179.12 -> resources
181.44 -> the second line oversee risks include
184.239 -> amazon cloudwatch
185.68 -> and aws security hub to help customers
188.48 -> to gain
189.04 -> a comprehensive overview of operational
192.319 -> health and security posture
194.56 -> across their aws accounts our third
198 -> line assurance of risk management
200.72 -> includes
201.36 -> audit manager to help customers to
203.28 -> assess their controls for security
206.159 -> change management software licensing and
208.879 -> business continuity
211.28 -> let's take a look on two specific
213.84 -> services
214.799 -> that can help us in the manage risk that
217.28 -> can help us
217.92 -> in our operational excellent workloads
222.72 -> the first one is aws config at the core
226.08 -> of these set of services
227.68 -> that can help you enable compliance and
230.4 -> monitoring
231.28 -> is one of our key detective control
233.519 -> platforms
234.72 -> aws config what is aws config
239.68 -> config is a service that enables you to
242.319 -> assess
243.36 -> audit and evaluate the configurations of
246.239 -> your aws resources
248 -> automatically aws config
251.2 -> allows you to automate the evaluation of
254.159 -> recorded configuration against
256.479 -> desired configuration using features
258.88 -> called
259.6 -> aws config roles for example
263.52 -> let's say you want to make sure that all
266.08 -> s3 buckets created are encrypted
269.44 -> you can deploy an aws config manage rule
273.44 -> that automatic evaluates that resource
277.44 -> right at the moment it is created or
279.919 -> modified
281.759 -> we provide a rich set of rules that
284.88 -> evaluate some of the most common
286.8 -> scenarios
288.56 -> those are called manage rules since they
291.199 -> are provided and managed by aws
294.4 -> but you also can have you also have the
296.639 -> ability of creating your own
298.479 -> custom roles powered by the aws lambda
301.68 -> platform
303.199 -> utilizing aws config can help you
306.24 -> manage and track your configuration
308.8 -> changes
309.68 -> on your aws infrastructure
313.12 -> another service that can help with
315.199 -> managing in
316.4 -> your operational excellent workloads are
319.52 -> is aws systems manager
322.56 -> aws system manager is the operation hub
325.919 -> for aws resources
328.16 -> it allows you to group resources in a
330.72 -> way that is
331.68 -> meaningful for your operation teams
335.199 -> it then provides you with rich
337.759 -> visualization that helps
339.36 -> simplify operation lastly
342.639 -> it allows you to take action on those
344.72 -> resources by providing
346.56 -> tools to automate workflows and ec2
349.759 -> instance management but it also plays an
352.88 -> important role
354.24 -> in enabling compliance and monitoring
356.88 -> within aws
358.96 -> how so aws systems manager
362.16 -> automation allows you to create
364.479 -> automation workflows to
366 -> manage aws resources you can design
369.44 -> remediation actions to fix
371.6 -> non-compliant resources detected by aws
374.88 -> config
376.319 -> automation provides a simple to use
378.72 -> control experience to
380.08 -> create automation workflows you can also
383.199 -> use our dsl to write your own python or
385.919 -> powershell
386.96 -> script to run the run command
391.919 -> is also another feature aws systems
394.8 -> manager run command lets you remotely
396.96 -> and securely manage the configuration of
399.28 -> your manage instance
401.36 -> run command enables you to automate
403.919 -> common administrative tasks
405.919 -> and perform ad hoc configuration changes
408.96 -> at scale you can use run command with
412.16 -> configuration management tools like
413.84 -> ansible
414.639 -> chef and even chef inspect
417.759 -> you can set the compliance state of ec2
420.24 -> instances based on configuration
422.16 -> management execution results
424.639 -> this data is rolled up into aws config
427.919 -> to provide you a centralized control of
431.039 -> your compliance states
434.8 -> we're now going to go over a demo on how
437.44 -> we can utilize
438.56 -> aws config to manage and track
441.84 -> our infrastructure resource changes
444.24 -> within our aws
445.36 -> environment let's go through this demo
448.8 -> so to begin our demo we first want to
451.12 -> deploy
452.08 -> some prerequisites that aws config will
455.039 -> use
455.68 -> within our demo and these are some im
458.56 -> roles that we're going to set up that
459.68 -> we're later going to use when
461.28 -> discussing a little bit about
462.319 -> conformance packs
464.8 -> so to start off with we'll go ahead and
467.199 -> use the cloud formation template that
469.039 -> was provided for this workshop
471.12 -> and we'll go ahead and deploy that by
473.12 -> going over to cloud formation
485.039 -> and we're going to go ahead and click
486.639 -> create stack
490 -> we're going to upload the templates
493.68 -> choose file
498.319 -> select the template which is our
500 -> workshop config prerequisites
507.599 -> and i go to select the name there
510.96 -> we'll click next we'll then give it the
514.159 -> name
515.2 -> workshop config prerequisites
518.399 -> and we'll click next
521.839 -> we'll keep all the defaults scroll down
524.32 -> and we'll click next
530.399 -> we'll scroll down to the very bottom and
532.88 -> last we want to go ahead and select the
534.8 -> check
535.12 -> box that i acknowledge that aws cloud
537.68 -> formation might create i am resources
539.76 -> with custom names
541.6 -> we'll go ahead and click create stack
545.92 -> this will then deploy the resources
548.48 -> needed
549.04 -> for our various labs we'll run within
551.36 -> this workshop
552.72 -> so we'll let the confirmation template
554.64 -> go ahead and deploy
556.399 -> while it's deploying we'll go over to
559.44 -> aws config
567.92 -> and now we're going to go ahead and
569.12 -> enable aws config
571.12 -> to start tracking and recording resource
574 -> changes within our account within our
575.68 -> region
576 -> within our aws account so to set up aws
579.04 -> config
580.16 -> we'll go ahead and click get started
583.92 -> and this is going to set up the aws
586.399 -> config recorder
587.76 -> and now with the aws config recorder
590.08 -> does it
590.959 -> allows us to allow aws config to
594.48 -> now start tracking and recording aws
597.92 -> resources that are supported with aws
599.92 -> config for any configuration changes or
603.04 -> new
603.6 -> resources being created
606.88 -> under the configuration of the recorder
609.839 -> you are presented with two options
613.04 -> you can record all resources supported
615.44 -> in this region
617.04 -> are you can specify specific resource
619.6 -> types
620.88 -> now aws config is a regional service
624.72 -> so you will need to enable aws config in
627.6 -> every region you want to
629.6 -> track and manage resource changes within
632.32 -> your aws
633.12 -> infrastructure a good best practice well
636.959 -> is to allow aws config recorder to
639.279 -> record all resources
641.04 -> supported within this region this will
643.6 -> allow you
644.16 -> greater flexibility when coming to
646.8 -> enabling
647.6 -> aws config rules to evaluate resource
651.04 -> changes
652.24 -> it'll also will allow you to include any
654.959 -> new
655.36 -> aws resources that are currently
658 -> supported within config
660.8 -> the next option within our config
662.399 -> recorder is the option to include
664.56 -> global resources this would be aws
667.36 -> services such as
668.48 -> iam resources we want to go ahead and
671.519 -> have this enabled
673.92 -> because we also want to track iam
676.399 -> resources that get created
678 -> are modified however do keep in mind
681.36 -> that when checking this box
683.279 -> you want to have this box checked for
685.12 -> only one region within your aws account
687.839 -> that you have
688.88 -> aws config enabled and the reason
692 -> this is that if you have this enabled in
694.079 -> multiple regions
695.68 -> you will be getting duplicate resources
698.399 -> that are recorded and tracked within aws
701.04 -> config
702 -> also doing duplicate incurring
705.36 -> additional charges for those duplicate
707.279 -> resources
708.32 -> so definitely you want to only have this
710.24 -> check for one region within your account
712.56 -> that you have aws config
714.839 -> enabled the next item is your aws config
718.32 -> role
719.04 -> you have the option to use an existing
721.6 -> database config
722.56 -> service link role or you can choose
726.079 -> an im role from your account
729.44 -> you can create an im role that is that
732.639 -> includes the i am policy defined within
734.959 -> our aws config documentation
737.44 -> that allows aws config to record and
739.839 -> track resources within our account
742.72 -> for this exercise we're going to go
744.079 -> ahead and leave it the default as use an
746 -> existing aws config service link role
750.48 -> the next option is our delivery method
753.12 -> as aws configs
755.04 -> tracks and records changes it will then
758.079 -> deliver those recorded changes
760.079 -> over to an s3 bucket here's where we'll
763.36 -> define
764.24 -> where that s3 bucket will be by default
767.12 -> we'll go ahead and create a new bucket
769.44 -> with a bucket name you also have the
772.32 -> option to choose an existing bucket from
774.8 -> your account
775.92 -> or also choose a bucket from another
777.839 -> account
779.12 -> if you have aws config enabled in
782.48 -> multiple regions and multiple accounts
785.6 -> then a good best practice would be to
787.519 -> choose a bucket from another account
789.76 -> this could be a bucket that resides into
792.32 -> a central
793.6 -> logging account our essential compliance
796.399 -> account where you're going to be keeping
798 -> this at these configuration items in one
801.04 -> central location for this exercise we're
803.92 -> going to go ahead and leave it as the
805.279 -> default in creating
806.639 -> a bucket and then we'll go ahead and
808.72 -> click next
811.68 -> it's then going to ask us to then and
814.32 -> choose
814.959 -> some of the aws manage rules for this
817.839 -> area right here we're not going to
818.959 -> select one we'll later discuss
820.56 -> aws manage rules and the following
823.76 -> and we'll go ahead and click next
826.88 -> it's then going to ask us to review our
830 -> settings
830.72 -> and we'll go ahead and click confirm
834.32 -> it's then going to enable aws config
836.56 -> recorder
837.44 -> and enable ads config to start tracking
840.639 -> and recording resource changes within
843.12 -> our accounts
844.8 -> it's been successfully enabled and now
847.04 -> take us back to our dashboard
851.36 -> where then we can now see aws config
853.519 -> reporter is now
855.04 -> recording various aws resources within
857.76 -> our accounts
859.279 -> so now let's take a look back at our
861.12 -> cloud formation template
862.639 -> to make sure it was deployed
863.76 -> successfully so we'll go back to cloud
868.839 -> formation
874 -> and we see our stack here workshop
876.88 -> config prerequisites
878.56 -> and if it deployed correctly we should
880.48 -> see a create complete
883.279 -> so this uh lets us know that the
885.44 -> resources were deployed that will be
887.199 -> needed
887.839 -> to utilize aws config for the various
891.12 -> uh labs we're going to go through within
892.8 -> our demo
894.48 -> so we'll go back over to config
908.48 -> now with aws config we have
912.24 -> aws config rules now what abs config
915.279 -> rules allows you to do is allows you to
917.04 -> set up a rule
918.32 -> that will then check a specific
921.44 -> rule evaluation against your aws
923.68 -> resources to make sure it's at a
925.68 -> desired configuration state aws config
929.279 -> has
929.6 -> two types of rules we have aws config
932.24 -> manage rules
933.12 -> and aws config custom roles and to
936.639 -> add a config role we'll go ahead and
939.04 -> click on add
940 -> role we then are presented with the two
943.92 -> types of rules that aws config supports
947.199 -> aws manage rules we currently have about
950.04 -> 171
951.199 -> aws managed rules these are
954.48 -> config rules that are managed by aws
958.32 -> when that could cover a variety of
960.16 -> different use cases
961.92 -> for example if you would like to
965.279 -> utilize an aws config rule to check on
968.72 -> your
969.759 -> compliance configuration compliance
971.6 -> state of ebs
972.88 -> volumes we can look up volumes
978.32 -> and one in particular is this one here
980.8 -> ec2 volume
982.079 -> in use check this will check whether an
984.88 -> ebs volumes are attached to an ec2
987.6 -> instance
989.279 -> this particular rule will help us
991.04 -> identify volumes
993.36 -> that are currently not attached to an
996.079 -> ec2
996.72 -> instance and mark them as non-compliant
999.12 -> resources
1000.56 -> this is helpful because it allows us to
1002.639 -> keep in track of our operational
1004.8 -> use of our ebs volumes if
1008.32 -> there is a volume that's not currently
1010.079 -> attached then we can take some action
1011.92 -> against that volume
1013.199 -> to perhaps see if it's needed and
1015.92 -> snapshot it
1017.279 -> to avoid any additional cost for unused
1021.04 -> volumes similarly if we take a look at
1025.12 -> elastic ips so we'll type in elastic ips
1028.559 -> here
1029.839 -> there is another role here that is
1032.319 -> called elastic ip attach
1034.4 -> and this one checks whether all elastic
1037.12 -> ip addresses
1038.24 -> allocated to a vpc are attached to an
1041.28 -> ec2
1041.919 -> instance this is another
1045.6 -> good use of an aws manage rule to help
1048.48 -> us
1049.28 -> identify specific aws resources within
1052.96 -> our accounts
1053.919 -> that may be incurring additional costs
1056.24 -> if we're not using them
1057.84 -> so we can actually use this manage rule
1060 -> to then mark any elastic ips
1062.64 -> non-compliant if they're not currently
1064.72 -> attached
1065.76 -> to a specific ec2 instance are an eni
1069.52 -> if they are not then we can then have
1071.44 -> the option to choose whether we want to
1073.2 -> release this
1074 -> ip to not incur additional charges
1078.4 -> however some other managed rules that we
1080.799 -> can look at
1081.6 -> for our operational uses is s3
1085.52 -> so we look at s3 rules we have a variety
1088.72 -> of s3 managed roles
1090.96 -> like for an example some of our
1092.96 -> operational best practices with
1094.64 -> s3 is not to have s3's buckets uh
1097.76 -> publicly available
1100.88 -> to have public access available on them
1103.44 -> and we have some managed rules here that
1105.28 -> will help you
1106.88 -> keep that configuration state within aws
1110.08 -> config
1110.96 -> here we have one here called s3 account
1113.28 -> level public access block
1115.76 -> this will check whether our
1118.799 -> if we're allowing public access at the
1121.36 -> account level
1122.72 -> additionally there is a rule that checks
1125.6 -> at the bucket level as well
1127.36 -> to check if public access is prohibited
1130.72 -> so these are some areas where we can
1132.64 -> utilize aws config
1134.32 -> rules to keep our operational use
1137.44 -> at a desired configuration state to keep
1140.16 -> into compliance
1142.24 -> our our workloads we're running within
1144.16 -> aws
1146.48 -> for this lab we're going to go ahead and
1148.32 -> utilize one of the aws
1150.08 -> config manage rules called
1155.36 -> restricted common ports what this aws
1158.799 -> manage config rule
1160.32 -> will allow us to check our security
1163.12 -> groups and make sure that
1165.039 -> it does not allow any public access
1168.16 -> for specific reports this would be good
1171.44 -> because when we have
1172.88 -> our workloads running and one of our
1175.679 -> operational best practices
1176.96 -> is not to have public access available
1180.32 -> on the internet for specific ports so in
1183.6 -> order to keep this desired configuration
1185.84 -> state
1186.64 -> we can utilize this rule restricted
1189.12 -> common ports
1190.24 -> to restrict specific tcp ports not being
1193.6 -> publicly accessible
1194.799 -> on the internet so we're going to go
1196.48 -> ahead and select this role
1198.96 -> and we'll click next
1202.96 -> the next window is going to show us our
1204.84 -> configuration for this role
1208.799 -> down below we have the trigger type
1210.4 -> which is set to win configuration
1212.159 -> changes
1213.12 -> this is going to enable the evaluation
1215.2 -> of this config rule
1216.799 -> whenever aws config recorder detects a
1219.44 -> change
1220.64 -> of a specific resource in this case it's
1224 -> monitoring ec2 security group resources
1227.679 -> so it's going to trigger a rule
1229.039 -> evaluation whenever
1230.799 -> it sees a change for that resource
1235.44 -> down below we have the parameters that
1237.679 -> this role is checking
1239.36 -> so this rule is by default checking
1241.36 -> these specific tcp ports
1243.919 -> so in our example in our lab here we're
1245.919 -> going to also check
1247.28 -> port 22 which is our ssh port so we're
1249.76 -> going to modify the first one here the
1251.52 -> value and change it to be
1253.36 -> port 22 well then go ahead and click
1256.159 -> next
1259.039 -> it'll ask us to review and then click
1261.6 -> add role
1265.84 -> our aws config rule is then deployed to
1269.039 -> aws config in which we can see it here
1271.679 -> restricted common ports now we're going
1274.48 -> to do is we're now going to go ahead and
1276 -> deploy
1276.72 -> an ec2 instance with a security group
1279.919 -> that actually has ssh open publicly to
1283.36 -> the internet
1284.64 -> so let's go over to our ec2 console
1302.799 -> and we'll click on our instances
1308.24 -> and we're going to click launch
1316.84 -> instances
1318.48 -> for this lab we're going to go ahead and
1319.84 -> choose amazon linux 2 ami
1322.159 -> we'll go ahead and select that
1327.52 -> we're going to choose an instant size of
1329.76 -> t3 small and then click
1332.72 -> next
1336 -> in this area we're going to go ahead and
1337.919 -> then
1339.36 -> under i am role we're going to go ahead
1341.76 -> and choose
1342.72 -> the workshop ec2 ssm role this was an im
1346.64 -> role that
1347.28 -> was created by that cloud formation
1349.44 -> stack we initially deployed
1351.6 -> this iam role will then allow it to
1353.76 -> communicate to ssm
1355.84 -> to further manage this instance
1359.039 -> and later in the lab we're going to see
1360.48 -> how this works together with remediation
1362.799 -> actions under our config rules
1365.039 -> so we'll go ahead and select workshop
1366.72 -> ec2 ssm role
1369.2 -> we'll click add storage
1372.4 -> we'll leave it to defaults and then
1374.08 -> click add tags
1377.12 -> we'll leave that those defaults and then
1378.799 -> we'll click next for configure security
1381.12 -> group
1382.799 -> so in this area here we're then going to
1384.559 -> configure our security group
1387.12 -> so we're going to go ahead and name our
1389.919 -> security group to be
1392.96 -> workshop security group and we'll do the
1395.52 -> same for the description
1398.32 -> we can see here by default it is
1400.08 -> enabling ssh
1401.76 -> port 22 publicly out to the internet
1406 -> so we're going to click on we'll leave
1407.36 -> it as that and click on review and
1409.039 -> launch
1411.679 -> it'll ask us to review our configuration
1414.159 -> and then we'll click on launch
1416.72 -> in this area here we're going to go
1417.919 -> ahead and click down the drop down box
1420.159 -> where it says choose an existing key
1421.84 -> pair
1422.72 -> and we'll go ahead and select proceed
1424.24 -> without a key pair
1426.32 -> we'll select the check box that says you
1428.08 -> acknowledge
1429.679 -> and then we'll click launch instance
1435.44 -> our instance will then get deployed and
1437.84 -> launch and we're going to click on view
1439.679 -> instances
1443.2 -> and our instance is still running and
1446.32 -> initializing so
1450.32 -> now we'll go back over to aws config
1470 -> now in aws config we'll go over to our
1472 -> rules
1474.96 -> and we'll click on the rule we just
1476.32 -> previously created to that's called
1478.32 -> restricted common ports
1481.679 -> now this rule since we deployed a new
1483.919 -> ec2 instance that had
1485.679 -> a new security group with the public
1490.08 -> access available for tcp port 22 which
1493.44 -> is one of the ports that we are checking
1495.76 -> within this role aws config will then
1499.6 -> evaluate the new resource and then once
1502.559 -> it detects that it's out of compliance
1504.4 -> it'll
1504.799 -> mark it here the resource and put it in
1506.88 -> a non-compliant state
1508.88 -> let's go ahead and trigger an evaluation
1511.039 -> manually by clicking on actions
1513.679 -> and we'll say reevaluate this will kick
1517.12 -> off the evaluation of that rule
1519.6 -> and we should then see the resource
1522.32 -> appear
1522.96 -> in under the non-compliance
1528.72 -> so as we see here our new resource that
1531.84 -> was just recently deployed with our ec2
1534 -> our security group
1535.44 -> was detected by our aws config rule
1539.44 -> and it marked it as a non-compliant
1542.48 -> if we click on this resource
1546.24 -> it then will show us details about our
1548 -> resource it'll
1549.52 -> show you the resource name which was the
1551.44 -> security group we just created
1554.64 -> and it also shows us the roles that are
1556.88 -> currently
1557.76 -> attached to this resource
1561.52 -> now one thing that aws config
1564.64 -> does provide you with the rules so we go
1567.2 -> back to our roles
1569.6 -> and we'll click on the rule again
1573.12 -> is whenever it detects a resource that's
1575.84 -> in a non-compliant state
1577.84 -> we can then implement what they what aws
1580.4 -> config
1581.36 -> rules have which is called remediation
1583.52 -> actions
1584.88 -> remediation actions allow you to
1588.24 -> use ssm documents that allows you to
1591.44 -> take
1591.84 -> action against that resource to put them
1594.32 -> back into
1595.2 -> a desired configuration state to keep
1597.52 -> them in compliance
1599.36 -> so to enable remediation action for this
1601.919 -> role
1602.72 -> we can click up on the top where it says
1604.559 -> actions
1605.919 -> and click on manage remediation
1609.12 -> this will then provide us the screen
1610.64 -> where we can actually enable remediation
1612.96 -> actions
1613.6 -> for this specific config role you have
1616.64 -> two areas
1617.52 -> two options when you can when you enable
1619.679 -> remediation actions
1621.36 -> you have the option to set it to be an
1623.36 -> automatic remediation
1625.36 -> what this is going to do is the moment
1626.96 -> it detects a resource in a
1628.48 -> non-compliance state
1629.919 -> it's going to trigger this remediation
1632 -> action automatically for you to put it
1634.24 -> back
1634.559 -> into a desired configuration state
1638.24 -> for this lab we're going to leave it as
1639.76 -> a manual remediation
1641.6 -> by leaving as a manual remediation you
1643.6 -> have to then within the config rule
1646 -> select the resource that is in a
1647.76 -> non-compliant state
1649.12 -> and manually trigger the remediation
1652.96 -> the next area is you want to go ahead
1655.2 -> and select
1656 -> what remediation action you want to
1659.52 -> choose to put this specific resource
1662.159 -> into a compliant state
1664.399 -> if you click on your drop down list
1666.32 -> you're provided provided a wide list of
1668.799 -> different remediation actions
1671.36 -> these remediation actions utilize aws
1674.64 -> ssm documents automation documents to do
1677.919 -> the remediation actions to put them back
1679.919 -> into a desired state so for this one
1683.44 -> we're going to go ahead and utilize
1685.44 -> a remediation action that's called
1689.919 -> aws disable public access for security
1693.039 -> group
1694.48 -> what this remediation action it will
1696.64 -> trigger an ssm
1698.08 -> automation document that will then go
1700.64 -> into the security group that was
1702.48 -> marked as non-compliance and remove all
1705.44 -> public access rules for that specific
1707.84 -> port so we're going to go and select
1710.799 -> that remediation action
1713.12 -> and then down below you then want to
1715.6 -> then pass the resource
1717.2 -> id to one of the parameters for that
1720.159 -> automation document
1722.08 -> so we'll go ahead and select the
1723.44 -> drop-down list and we'll choose it to be
1725.36 -> group id what it's going to be doing
1728.08 -> here it's going to pass the resource id
1730.24 -> of that resource that was in a
1731.679 -> non-compliant state to the group id
1734.24 -> parameter for that automation document
1737.12 -> we'll go ahead and click on
1738.399 -> save changes
1743.919 -> and then now our remediation action is
1746.08 -> set
1747.12 -> so we see it here remediation action and
1749.679 -> the automation document
1751.12 -> that was defined so let's go ahead and
1753.919 -> take a look at this resource
1756.799 -> so click on the resource
1760.72 -> up on the top you have a button that
1762.24 -> says manage resource this will open a
1764.159 -> new tab for you
1773.44 -> we look at inbound rules we can see that
1776.88 -> the resource
1777.679 -> does have an inbound role of port 22
1780.96 -> open publicly to the internet so this is
1783.6 -> the reason why the resource was
1785.279 -> marked non-compliant with that role
1787.12 -> evaluation
1788.88 -> now going back to aws config we can then
1791.76 -> go back to the rule
1794.32 -> and we'll see how remediation actions
1796.88 -> will be able to then put this
1798.64 -> specific resource into a compliance
1801.84 -> state
1803.6 -> so by triggering the remediation action
1805.919 -> we'll go ahead and
1806.799 -> select the resource that's in a
1808.799 -> non-compliant
1810 -> and we'll click remediate
1813.12 -> this is then going to kick off that ssm
1815.84 -> automation document
1817.2 -> that will then run against that security
1820.08 -> group
1820.88 -> and put that back in to a compliance
1823.36 -> state by removing
1824.64 -> those public access rules within the
1826.48 -> security group
1831.52 -> we see action executed successfully so
1834.08 -> let's go back into our other tab here
1836.24 -> that we have the security group open
1838.399 -> this is what we saw before so now let's
1840.559 -> go to refresh
1843.679 -> and as we see our remediation action
1846.799 -> worked that public access rule is no
1849.44 -> longer within our security group
1851.84 -> so the remediation action basically
1854.32 -> triggered
1854.88 -> the action where it now put that
1856.48 -> resource into a desired configuration
1859.6 -> state
1860.24 -> of not having those public access rules
1863.2 -> therefore when aws config
1865.2 -> now re-evaluates the security group it
1867.6 -> will then put it back
1868.799 -> into a compliant state so let's go ahead
1872 -> and trigger another
1876.84 -> reevaluation
1878.559 -> and we'll see this resource
1882.24 -> going into a compliance state
1889.76 -> as we can see when we refresh now the
1892 -> resource is no longer in a non-compliant
1894.48 -> state
1895.919 -> if i look at our compliance we now see
1899.12 -> that
1899.519 -> security group where that remediation
1901.519 -> action was successfully triggered
1904 -> and now the rule reevaluated that
1906.48 -> resource
1907.2 -> and now is marking it as compliance
1911.36 -> another thing i wanted to mention to you
1913.12 -> when it comes to the resource
1915.2 -> is if we click the resource up at the
1918 -> top
1918.48 -> we have a resource timeline
1921.519 -> the resource timeline is going to allow
1923.519 -> us to
1924.64 -> see a configuration history of our
1927.12 -> resource
1928.24 -> so let's go ahead and click on resource
1929.76 -> timeline
1933.76 -> so we look in under our resource
1935.679 -> timeline we see the configuration
1937.44 -> history of our security group
1939.84 -> so here we see some configuration
1941.919 -> changes we see
1943.44 -> rule compliance and also we see
1946.32 -> cloudtrail event changes too as well
1949.44 -> this is all supported within our
1951.12 -> resource timeline it will put in their
1953.519 -> three types of events our configuration
1955.519 -> events compliance events and cloudtrail
1957.679 -> events
1958.799 -> so within our security group here we
1960.96 -> have two configuration changes
1963.44 -> notice here this one is the one that is
1965.12 -> empty this is basically when that
1966.96 -> resource
1967.6 -> was created and then up above here
1971.039 -> we see a configuration change where it
1973.76 -> went from
1974.72 -> one area configuration now to another
1977.279 -> configuration
1978.96 -> within that resource
1983.279 -> then we see a rule compliance where then
1985.36 -> when it was evaluated
1987.039 -> it marked that security group against
1989.12 -> this secure this
1990.32 -> aws config rule to be non-compliance
1994.559 -> and then when we trigger that
1996 -> remediation action we see
1997.919 -> another configuration change where it
2000 -> then took the configuration
2001.6 -> of that rule having that public access
2004.799 -> uh rule with port 22 to be
2008 -> changed to now not including that
2012.399 -> we then see another event time event
2014.64 -> type within our timeline
2016 -> that it then re-evaluated the rule and
2018.64 -> put that role
2020.24 -> for that specific resource back into a
2022.32 -> compliance state
2024.08 -> so the resource timeline is a great
2026 -> resource where we can look at the
2027.76 -> configuration history
2029.76 -> of our aws resource are also within our
2033.279 -> application as far as
2034.799 -> how did the configuration change over
2036.96 -> time how was our configuration state
2039.519 -> how is our rule evaluation and it allows
2042 -> us also allows us to then
2044.159 -> uh additionally if we look at our
2046 -> configuration change
2048 -> we can click on view full record
2051.28 -> and this will also show us any
2052.96 -> relationships this specific
2055.2 -> security group has for example this
2057.599 -> security group is tied to a vpc
2060.079 -> which is tied to a specific elastic
2062.399 -> network interface
2063.679 -> which is also attached to a specific ec2
2066.48 -> instance
2068.48 -> so the resource timeline is a great
2071.119 -> resource
2071.839 -> to help us track configuration history
2074.399 -> against our resource
2077.44 -> so we're able to see within this lab how
2080.159 -> we can utilize
2081.28 -> aws config manage rules when
2085.919 -> when managing our infrastructure within
2088.24 -> aws
2089.2 -> and also help achieve operational
2091.52 -> excellency
2092.56 -> when it comes to our configuration
2094.879 -> states and our compliance
2096.8 -> and tracking and managing specific uh
2099.52 -> configuration
2100.48 -> changes within our aws infrastructure
2105.359 -> now we're going to look at another area
2107.52 -> of aws config
2109.04 -> that will help us and keep compliance
2112.72 -> for our configuration within our aws
2115.599 -> resources
2116.88 -> and these are aws config conformance
2119.2 -> packs
2120.56 -> so we click on aws config conformance
2122.56 -> packs
2124.079 -> and what aws config conformance packs
2126.48 -> are
2127.44 -> adbas config conformance packs are a
2129.68 -> group
2130.64 -> of config rules that are deployed
2134.079 -> within aws config but these config roles
2137.599 -> are
2138 -> immutable meaning that you cannot make
2140.8 -> any changes
2142.16 -> to these config rules
2145.2 -> when they are deployed they will be
2146.96 -> grayed out where you can't make any
2148.48 -> changes or modify
2149.76 -> these config rules to deploy a
2152.24 -> conformance pack
2153.599 -> you can click on deploy conformance pack
2157.599 -> you're then presented with an area where
2159.839 -> you can use a sample template
2161.839 -> our upload an existing custom
2164.079 -> conformance pack
2165.44 -> that you have created uh and this is
2168 -> created within a yaml
2169.839 -> format and we can define all the aws
2172.4 -> config
2172.96 -> rules that we want to define that's
2174.96 -> going to be grouped within this
2176.079 -> conformance pack
2176.96 -> and also any remediation actions we also
2180.24 -> would like to take within those config
2181.839 -> roles
2183.28 -> we are we do provide a variety of sample
2185.839 -> templates
2186.96 -> that encompass many different
2188.96 -> operational best practices when it comes
2191.119 -> to
2192.56 -> workloads within our aws infrastructure
2194.96 -> for example
2196.079 -> the operational best practices for
2197.839 -> amazon s3
2199.44 -> we have also sample templates that
2201.68 -> discuss operational best practices for
2203.839 -> compliance frameworks such as cis
2206.56 -> nist hipaa and so forth these are then
2209.92 -> provided to provide us
2211.839 -> a good sample template that we can use
2214.56 -> as a starting point
2216.24 -> to achieve operational best practices
2218.72 -> for specific aws services
2221.119 -> our specific frameworks if you notice
2224.079 -> down below you also have a link
2225.839 -> to our documentation where it then
2228.079 -> outline
2229.119 -> the various conformance packs that we
2231.52 -> have listed here
2232.88 -> and also point you to our github
2235.599 -> repository where you can actually see
2237.599 -> the actual
2238.16 -> yaml code where you can take and then
2240.4 -> customize your
2241.359 -> own conformance pack for this exercise
2244.72 -> we're actually going to use one of these
2246.64 -> conformance packs that we took
2248.48 -> in regards to our s3 our operational
2251.52 -> best practices for
2252.8 -> s3 so we're going to go ahead and upload
2255.68 -> the template that was provided for us
2257.599 -> in our workshop and we'll choose
2260.96 -> upload a template we'll choose a file
2266.48 -> we'll select our operational best
2268.64 -> practice for amazon s3 with remediation
2271.599 -> we'll open it
2274.72 -> and this this custom conformance pack is
2277.839 -> gonna incorporate all the aws config
2280.48 -> rules
2281.04 -> related to operational best practices
2283.2 -> for amazon s3
2285.599 -> but in additionally it's going to define
2287.44 -> some remediation actions to take
2289.68 -> into effect when it's when it
2293.28 -> detects these specific resources in a
2296 -> non-compliant state
2298.56 -> we're then going to go ahead and click
2301.2 -> next
2304.8 -> so we're now going to give it the
2306.079 -> conformance pack name and for the name
2308.16 -> we're going to go ahead and put in their
2309.68 -> operational best practices for amazon s3
2312.32 -> with remediation
2314.32 -> we're then going to click add parameter
2316.96 -> and we're going to add the parameter
2319.119 -> called
2322.16 -> s3 bucket name for enabling logging the
2325.28 -> value we're going to go ahead and get
2326.72 -> this value from our cloudformation
2328.16 -> template that was deployed in the
2329.68 -> beginning of this demo
2331.28 -> so we'll go over to cloudformation
2334.88 -> and we'll open that up into a new tab
2342.079 -> and we'll click on the stack that was
2343.44 -> deployed and we'll go over to resources
2347.359 -> and we're going to grab the name of the
2348.8 -> resource for the s3 logging bucket so
2351.28 -> we're going to go and select this
2353.599 -> and copy it we'll go back to our config
2357.04 -> console
2359.44 -> and we're going to go ahead and paste
2360.48 -> the value there
2362.64 -> we'll click next and then we'll
2366.32 -> click deploy conformance pack
2371.2 -> the conformance pack will then get
2372.64 -> deployed which is going to deploy
2374.4 -> the aws config rules that were bundled
2377.2 -> with this conformance pack together by
2379.28 -> setting also the remediations
2381.44 -> so we're going to let this conformance
2383.04 -> pack deploy
2391.119 -> all right our performance pack was
2393.599 -> deployed
2394.16 -> we see that it was completed and now we
2396.88 -> go and click on the actual conformance
2398.56 -> pack
2401.119 -> we'll see the various aws config roles
2403.28 -> that were deployed together with this
2404.64 -> conformance pack
2405.599 -> and the associated remediation actions
2408.88 -> one in particular these rules we'll go
2410.48 -> ahead and take a look at is
2412.079 -> the s3 bucket service side encryption
2414.319 -> enabled
2415.839 -> this rule is then evaluating making sure
2417.839 -> that all our s3 buckets that are
2419.52 -> deployed
2420.56 -> are together implementing the best
2423.04 -> practice of enabling server side
2425.119 -> encryption
2426.24 -> so if we click on this rule
2429.68 -> it's then going to show us the resources
2431.599 -> that are currently in a non-compliant
2433.599 -> state
2435.2 -> what we'll go ahead and do is we're
2436.64 -> going to go ahead and go to s3 and
2438.319 -> create
2439.119 -> a bucket and we'll see how this
2441.359 -> conformance pack together with the role
2442.96 -> that's bundled in there
2444.16 -> will then evaluate the new resource that
2446.72 -> we created
2447.52 -> and then trigger the remediation action
2449.68 -> for that resource
2451.28 -> so we're going to go over to s3
2464.4 -> and we're going to create a new bucket
2472.319 -> and we're going to create a name that's
2474.48 -> unique
2475.359 -> to our environment so we'll go ahead and
2477.2 -> call it workshop
2483.359 -> demo and then give it a unique
2487.119 -> number this way it's unique so i'm just
2489.92 -> going to go
2490.48 -> go ahead and put a random four digit
2492.839 -> number
2495.28 -> and then we'll go ahead and look at the
2497.44 -> various settings that this
2498.72 -> s3 bucket is going to be set we'll leave
2500.8 -> everything defaults
2502.319 -> if you notice the default encryption
2504.24 -> server side encryption is set by default
2506.16 -> to be disabled
2507.52 -> by doing that it should then trigger the
2510.319 -> rule evaluation of that rule where it's
2512.48 -> checking
2512.96 -> if server-side encryption is enabled
2516.88 -> so in this particular case it's not
2518.96 -> enabled so it should mark this resource
2520.88 -> as non-compliant
2522.4 -> we'll go ahead and click on create
2523.599 -> bucket
2528.56 -> and now we'll go back to our aws config
2534.839 -> console
2545.04 -> all right now we're going to go ahead
2546.16 -> and click on conformance packs
2551.04 -> and we'll click on the conformance pack
2552.56 -> we recently deployed
2556.4 -> and we will go ahead and click on the
2558.88 -> config role
2561.44 -> that is evaluating for server
2562.72 -> server-side encryption enabled
2569.2 -> so for this rule we'll go ahead and then
2572 -> trigger
2573.52 -> a re-evaluation this way it
2577.28 -> picks up that new aws resource s3 bucket
2580.96 -> that we just created
2582.56 -> so we'll give it a little bit for it to
2585.92 -> evaluate the rule and put the s3 buckets
2588.96 -> on the non-compliant list
2595.92 -> alright as you see we have our new s3
2598.96 -> bucket our workshop demo
2601.2 -> the name of the bucket it was marked in
2603.359 -> a non-compliant state
2605.839 -> it's then going to go ahead and then
2607.2 -> should trigger the remediation action
2609.839 -> and then put it back into a compliance
2612.4 -> state
2614 -> so let's go ahead and refresh
2618.079 -> as we see here the action execution
2620.319 -> successfully
2621.44 -> it went ahead and triggered that
2622.56 -> remediation action which then triggered
2624.48 -> that ssm document
2626.319 -> to then go ahead and enable server-side
2629.119 -> encryption on that s3 bucket
2631.599 -> so let's go ahead and do another rule
2632.88 -> evaluation
2636.4 -> and we'll then see that this bucket will
2638.64 -> then be put back
2639.92 -> into a compliance state
2644.64 -> i'm going to click refresh
2650.56 -> as we can see the s3 bucket is now no
2653.52 -> longer under the list of non-compliant
2656 -> if we go ahead and choose compliance
2659.52 -> we'll then see the s3 bucket that we
2661.599 -> just recently created
2662.96 -> is now in a compliance state it launched
2665.76 -> that remediation action successfully
2667.92 -> enabling service site encryption which
2670.24 -> enabled a rule evaluation reevaluation
2672.48 -> of the rule
2673.28 -> to put it back into a compliance state
2676.24 -> so we go back to our conformance packs
2679.04 -> so this is a good example of how we can
2681.28 -> utilize
2682.079 -> conformance packs to deploy
2685.119 -> config rules grouped together that are
2688.319 -> immutable but also we can also deploy
2691.04 -> together with these config rules
2693.52 -> remediation actions here we saw a good
2695.76 -> example
2696.64 -> how we can implement operational best
2698.88 -> practices when it comes to s3
2701.359 -> to keep our infrastructure within
2704.72 -> s3 into a desired configuration state
2708.319 -> according to best practices
2710.64 -> we were able to see how when we quickly
2712.48 -> enabled an s3 bucket that did not have
2714.72 -> server side encryption
2716.16 -> it automatically detected that
2718.16 -> configuration state
2719.28 -> and took a remediation action to enable
2722.4 -> uh s3 bucket encryption
2725.76 -> so another area that we want to look at
2728.16 -> that's going to help us
2729.44 -> have an operational insight to our aws
2732.96 -> infrastructure is aws config advanced
2736.24 -> queries
2737.2 -> so we're going to click on advanced
2738.64 -> queries
2742.16 -> aws event aws config advanced queries
2744.8 -> allows us to
2746.16 -> query our configuration of any active
2750.72 -> aws resources we currently have running
2753.52 -> where aws config
2754.8 -> is recording for an example we recently
2757.359 -> deployed
2758.079 -> a aws ec2 instance
2762.24 -> under advanced query we actually have a
2765.359 -> query which will show us
2767.76 -> some information related to the ec2
2770.16 -> instance so we'll go ahead and type in
2771.76 -> easy2 here
2775.28 -> and in here we see some of the various
2778.319 -> uh advanced queries sample queries we
2781.2 -> have related to ec2 instances
2783.68 -> so let's take a look at this one that's
2784.96 -> called ec2 instance by type
2788.079 -> if we select it it's automatically going
2790.72 -> to put in
2791.359 -> the sample query for the specific query
2793.68 -> to display
2794.88 -> all our ec2 instances by a specific type
2798.72 -> so the ec2 instance that we recently
2801.44 -> deployed was a t3 small so we're going
2803.68 -> to change this to
2804.88 -> t3 small
2810.88 -> and in order to run this query we'll go
2812.88 -> ahead and click on run
2817.92 -> if you notice down below it then outputs
2819.839 -> the information
2821.119 -> here we're able to query against a
2823.119 -> resource and bring back
2824.56 -> various configuration information
2826.4 -> related to
2827.92 -> this aws resource that abs config is
2830.8 -> currently tracking
2832.16 -> so in here we got the resource id the
2834.079 -> resource type the instant type
2836.48 -> if it had any tags enabled to it which
2838.8 -> availability zone
2840.559 -> it was deployed to so we can see how
2843.2 -> advanced query can give us that
2844.72 -> operational
2845.52 -> insight to our configuration state with
2848.96 -> running aws resources currently on our
2851.76 -> account
2853.119 -> let's go and take a look at another
2855.52 -> advanced query sample
2857.359 -> when it comes to relationships let's say
2860.48 -> for example we want to see
2863.28 -> all resources related to a specific
2866.559 -> instance so we'll go ahead and
2871.839 -> paste a sample query there
2876.88 -> and in here we're basically going to
2878.24 -> select all the attributes
2879.92 -> where the relationships include a
2882.24 -> specific resource
2883.359 -> id and so for that resource id we're
2885.04 -> going to grab this
2886.4 -> resource id of our instance
2889.44 -> and we're going to go ahead and paste it
2890.88 -> there so this should then return to us
2894.4 -> all the resources that currently have a
2896.559 -> relationship with this instance
2898.96 -> so we'll run it and if we notice down
2902.48 -> below
2902.88 -> it's showing us the various resources
2906.16 -> that are related to this specific
2908.8 -> instance
2909.839 -> similarly how we saw in our aws config
2912.88 -> resource timeline where it showed us
2914.96 -> relationships we have the same
2916.559 -> relationships here which shows us the
2918.079 -> eni
2919.2 -> the instance that this specific uh
2921.599 -> resource and the security group
2923.92 -> um also has some of our ssn managed
2926.24 -> inventory that is pulling
2928 -> application inventory as well from uh
2930.72 -> for the specific instance
2934.4 -> so let's go and take a look at another
2936.4 -> query that will give us an example of
2938.4 -> how we can use
2939.119 -> advanced query to also group together
2941.839 -> specific information
2943.04 -> and aggregate on specific information so
2945.839 -> we're going to go ahead and look at this
2947.28 -> query here
2948.72 -> this query here is basically going to
2950.319 -> show us an a grouping
2952.16 -> an aggregation of our compliance type
2956.24 -> and we're going to go ahead and filter
2958.079 -> it by specific resource compliance
2960.48 -> and we'll go ahead and run that query
2963.839 -> and we see the results here now it's
2965.68 -> showing us
2966.88 -> a group of compliant and non-compliant
2969.92 -> and how many of those resources we have
2972.96 -> so we see here we have seven
2974.8 -> non-compliant resources
2976.8 -> and two compliant resources again
2979.52 -> another example of how we can leverage
2981.68 -> advanced query to get
2982.88 -> operational insight to our running aws
2986.319 -> resources we currently have
2988.079 -> within our region so
2991.359 -> let's take an example of other areas
2994.48 -> let's say for example you want to see
2998 -> within your account any ebs volumes that
3001.44 -> are currently
3002.559 -> not being in use with advanced query
3006.16 -> we can also utilize another sample query
3008.8 -> that allows us to
3010.24 -> select the various properties against a
3012.72 -> resource
3013.359 -> of our ec2 volume and look for a
3016.24 -> specific configuration state
3018.079 -> and this one here it's it's basically
3019.92 -> wants to return
3021.28 -> any ec2 volume ebs volume that's
3024.319 -> currently
3024.88 -> not in use so i'm going to run this
3027.28 -> query
3030.16 -> and here it shows i do have one volume
3033.28 -> that is currently not in use meaning
3035.44 -> that's not attached to a specific ec2
3037.68 -> instance and gives us different
3040 -> information related
3041.28 -> to this volume additionally with
3044.319 -> any of these queries that we define
3046.079 -> within advanced query
3047.599 -> we have the option here to export as and
3050.48 -> you can export this information as a
3052.24 -> json rcsv file
3054.64 -> you also have the option if you want to
3056.8 -> go ahead and save this query
3058.48 -> where you can later then run it and be
3060.64 -> listed within your
3061.76 -> list of queries when within advanced
3064 -> query
3064.88 -> you can click on save as give it a name
3068 -> and then click save so
3071.44 -> this gives us an example on how we can
3073.28 -> use again advanced query to get that
3075.44 -> operational insight to our configuration
3077.359 -> state within
3078.48 -> our aws resources another method
3082 -> we can use these advanced query is also
3084.559 -> via the
3085.44 -> cli so let me show you real quickly how
3087.92 -> we can use the cli
3089.76 -> to return information from advanced
3092.16 -> query via
3093.04 -> our cli so for this we're going to go
3095.359 -> ahead and use
3096.96 -> cloud shell so we're going to open up
3099.28 -> cloud shell
3114.319 -> so cloud shell has loaded and we're in
3116.4 -> our terminal and so what we're going to
3117.92 -> do is we're going to give an example how
3119.28 -> you can use the aws cli
3122 -> to also query uh your
3125.119 -> resources within using aws config
3127.839 -> advanced query
3129.359 -> to output some information in regards to
3131.52 -> the configuration state of our resources
3134.4 -> so i'm going to go ahead and paste the
3136.8 -> command that's provided in the
3138.88 -> workshop this is going to query our ec2
3142.16 -> instances
3143.44 -> and it should output it in a yaml format
3149.68 -> as you can see the information was
3151.68 -> outputted it gave us the resource id
3153.76 -> as one of the results so it just gives
3155.839 -> you an example how
3157.04 -> also you can further leverage advanced
3158.96 -> query not only within the console
3161.04 -> but you can also do the same thing via
3162.72 -> the cli command and output it to yaml
3165.839 -> are you can you then further use
3167.76 -> different scripts uh
3168.96 -> to pull this information that aws config
3172.4 -> is tracking within your environment when
3174.319 -> it comes to your
3175.52 -> configuration state your infrastructure
3177.839 -> changes
3178.88 -> uh within aws
3184.72 -> so go back to config
3196.24 -> so as we saw within this workshop we
3199.28 -> were able to see
3200.64 -> how we can use aws config to manage
3204.4 -> and track our infrastructure changes and
3207.359 -> also
3208.4 -> how aws config could also track
3210.4 -> application changes too as well
3212.72 -> how aws config utilizes aws config
3216.8 -> roles to manage a configuration state
3220.24 -> for our resources we were able to go
3223.2 -> through a
3224.079 -> an exercise on how we used a managed
3227.359 -> config role to
3228.96 -> track our changes to our security groups
3232.48 -> and make those security groups in a
3235.76 -> state if it had public access roles to
3238.96 -> the internet on specific
3240.48 -> ports we then were able to see how we
3243.04 -> can utilize
3244.48 -> ssm automation documents together with
3247.119 -> aws config
3248.64 -> to remediate those resources that were
3251.92 -> in a
3252.72 -> non-compliant state to put them back in
3255.599 -> a desired configuration state
3258.8 -> we then were able to see how we could
3260.8 -> also utilize aws conformance packs
3263.52 -> how we were able to create a conformance
3266.559 -> pack that included
3268.319 -> various config rules in regards to s3
3271.839 -> operational best practices we also saw
3274.88 -> how we can build our custom conformance
3276.64 -> pack
3277.04 -> with remediation actions tied to those
3279.839 -> config rules
3280.88 -> and we saw how we were able to create an
3282.799 -> s3 bucket
3284 -> and automatically those conf those
3286.16 -> remediation actions took into place
3288.4 -> to put our s3 bucket back into a desired
3291.76 -> configuration state
3294.24 -> we then were able to see how we can
3295.68 -> utilize advanced query to gain
3297.68 -> operational insight to our active
3300.319 -> configuration
3302 -> state of our resources running within
3304.24 -> aws
3305.44 -> within our aws environment so now that
3308.72 -> we're finished with our workshop
3310.16 -> our next step is now we're going to go
3312 -> and clean up all these resources that we
3314.24 -> provision
3315.28 -> during our workshop so the first one we
3318.24 -> want to go ahead and do is we want to go
3320 -> ahead and first terminate that ec2
3322.64 -> instance
3323.68 -> that we deployed when we started the
3325.68 -> workshop
3326.72 -> so we'll go over to ec2
3334.4 -> and we'll click on instances
3339.599 -> we'll select the ec2 instance
3345.68 -> and we'll click instant state and choose
3349.119 -> terminate instance
3352.319 -> we'll click terminate this will then
3355.839 -> start shutting down
3356.799 -> and terminating the instance we'll give
3359.2 -> it a little bit for it to completely
3361.28 -> terminate before we proceed to the next
3374.839 -> step
3382.559 -> so our instance is now terminated
3385.76 -> so once our instance is terminated our
3387.92 -> next step we want to go
3389.119 -> over to security groups and we want to
3392.48 -> go ahead and delete that security group
3394.64 -> that was provisioned
3396.16 -> when we deployed our ec2 instance so
3398.96 -> we're going to select the workshop
3400.319 -> security group that was created
3402.559 -> we're going to click on actions scroll
3404.88 -> down
3406 -> and we're going to choose delete
3407.839 -> security groups
3410 -> we'll go ahead and confirm and click
3411.52 -> delete
3413.44 -> our security group is now deleted
3416.64 -> now we're going to go over to aws config
3426.64 -> and we're going to go first to
3428.4 -> conformance packs
3430.48 -> and we're going to delete the
3432.24 -> conformance pack that we deployed
3434.319 -> in regards to our operational best
3436.24 -> practices for amazon s3
3438.72 -> we're going to select the conformance
3440 -> pack click actions
3442.64 -> and click delete we'll then type delete
3447.599 -> and click delete
3450.799 -> this will then start the process of
3453.2 -> deleting the conformance pack that was
3455.04 -> deployed
3456.64 -> within aws config and so we'll give it a
3459.2 -> couple of
3459.68 -> moments to for it to delete
3467.52 -> so we see now our conformance pack has
3469.68 -> then been deleted
3471.359 -> so the next area you want to go ahead
3473.04 -> and remove is aws config rules
3476.88 -> and we're going to remove the rule that
3478.64 -> we initially created to restrict common
3480.88 -> ports
3481.92 -> but before we can delete this rule we
3483.76 -> want to first remove the remediation
3486.16 -> action that is currently tied to this
3488.24 -> config role
3489.44 -> to do this we'll click on the role
3494.079 -> and we'll under remediation actions
3497.04 -> we'll click
3497.839 -> delete we'll then type in deletes
3502.88 -> and click delete
3506.799 -> our remediation action is now removed
3508.96 -> from the config role
3510.64 -> so now we'll then click on actions
3513.76 -> and choose delete rule
3516.96 -> we'll type in delete and click
3520.72 -> delete
3524.799 -> our config rule will then be queued up
3526.64 -> to be deleted within aws config
3530.079 -> the next area we want to go ahead and do
3532.16 -> is under
3533.28 -> settings within aws config
3536.72 -> we want to go ahead and turn off the aws
3539.28 -> config recorder
3540.64 -> so it no longer will start recording any
3543.76 -> configuration changes of
3545.839 -> new resources that are new or updated
3548.559 -> resources within our aws environment
3551.119 -> to do this we'll go ahead and click on
3552.64 -> edits
3554.96 -> and we'll uncheck the check box for
3557.28 -> enable recording
3560.4 -> and then we'll click save
3564.24 -> our recording is now turned off
3567.599 -> now to delete the actual recorder we'll
3569.839 -> need to go into
3570.96 -> cloud shell and we'll use the aws cli
3574.64 -> to delete the default recorder so open
3577.52 -> up cloud shell
3586.88 -> click the default close
3589.92 -> we're in our terminal and now we're
3592.079 -> going to paste
3593.2 -> the cli command to delete the default
3598.839 -> recorder
3600.88 -> the comfort come the recorder is now
3603.2 -> deleted
3604.559 -> we'll go back to config to confirm that
3607.359 -> it has now been deleted
3609.68 -> so we're going back to aws config
3618.88 -> and we now see that aws config is now
3622.079 -> requesting to be set up again so this
3625.04 -> lets
3625.359 -> us know that all the resources within
3627.44 -> aws config the recorder is now
3629.76 -> uh deleted and no longer recording any
3632.319 -> additional information of resources
3634.24 -> being uh changed within your aws account
3637.839 -> so the next area we want to go and clean
3639.52 -> up is our s3 buckets
3641.2 -> so we'll go over to s3
3651.2 -> and we're first going to delete the s3
3653.28 -> bucket that we created for the
3654.64 -> conformance pack called workshop demo
3657.28 -> and then the a couple of digits that you
3659.52 -> put into the name to me unique
3661.359 -> so select that bucket and then click
3663.92 -> delete
3667.2 -> select the bucket name and type it
3670.24 -> to confirm and click delete bucket
3674.96 -> we'll then also delete the config bucket
3677.68 -> that was created when we initially set
3679.52 -> up
3679.839 -> aws config we'll first select that
3683.44 -> bucket and choose empty
3688.48 -> and we'll type in their permanently
3690.24 -> delete
3694.16 -> and hit empty now up on the top we can
3699.119 -> go ahead and click
3699.76 -> delete bucket
3702.799 -> and also put in the name of the bucket
3707.76 -> and click delete bucket
3711.359 -> the next bucket we want to go ahead and
3713.04 -> clean out is the s3 bucket that was used
3715.839 -> for
3716.16 -> server side logging so we'll select the
3718.16 -> s3 server side logging bucket
3720.799 -> and click empty
3724.079 -> and type in permanently delete
3728.88 -> and click empty
3733.68 -> now we're going to go over to our cloud
3735.2 -> formation
3739.359 -> and we're going to delete the stack that
3741.2 -> was deployed at the
3743.039 -> beginning of this workshop we'll select
3745.76 -> the stack
3746.96 -> and click delete and click delete stack
3758.48 -> so our clock formation stack has been
3760.48 -> deleted
3763.119 -> so within this workshop we were able to
3765.28 -> see how we can utilize
3766.96 -> aws config to manage and track
3770.079 -> our configuration changes for our aws
3772.72 -> resources
3774.4 -> by utilizing aws config we're able to
3778 -> track these changes and be able to run
3780.319 -> successfully are operational
3782 -> excellent workloads we do thank
3784.799 -> everybody for
3785.68 -> attending today's workshop and please
3788.319 -> let us know if you have any additional
3791.16 -> questions
Source: https://www.youtube.com/watch?v=oBuLtfGHETY