- [Seph] When considering the topic of designing secure applications and architectures for real-world relevance, it shouldn't be too difficult to see how the areas I've discussed could apply. And, as I've stressed many times, security at every level isn't just a saying to help you on the exam, but a mindset to provide guidance when evaluating new and existing architectures. The areas that were discussed for this domain also follow with that mindset. Designing secure access to AWS resources provides clarification around who and what can access the resources in your account, how that access is allowed, and the methods around creating and managing that access. This could easily be considered the highest level of your environment, as secure access to resources is crucial to determining how secure the initial design and development will be, as well as how protected the continued management will remain. Just as many companies secure access to their buildings, rooms, and floors with badges and keys, you should be securing access to your accounts and environments. Moving to the next level, designing secure application tiers is what many think of when they think of securing an environment. Common questions that might come up are around how you'd protect web application and database tiers, and what firewalls you might use. You should also be thinking about how the individual instances and resources should be protected, such as the instances and interactions with the managed services that could be included, as well as how you are protecting the network environments that contain these elements. The VPCs that you use have various control mechanisms that enable granular management of traffic flow and monitoring within the network. And these should be utilized collectively to provide compounding protection for your applications. The last level I introduced involves selecting appropriate data security options. Data security requires understanding how the data is used, how it's accessed, and what services you're utilizing to properly house the data. Many of the services will have built-in protection tools, but there are also many other resources within AWS that can complement the functionality native to the service, provide additional insight and security, and add granularity to your control. So, how would that apply to different types of application environments? Security at every level doesn't have to only mean every tier. And considering the topics of access to resources, application tiers, and data, that mindset can be applied to both the smallest and the largest of environments. Actually, before I let you go, let's apply these concepts to a small application environment. For example, say you have an application that checks on development resources with specific tags, to verify whether they should still be running, or if they need to be terminated. It runs on a single instance, with an attached block storage volume within a single subnet and VPC, and access is provided over the company's VPN connection. Considering all the levels, what are some of the considerations that need to be accounted for? Well, starting at the resource-access level, there is, of course, the question of who might have access to stop or terminate this instance. But moving further from there, you would also need to consider what resources this application needs access to, and how that access would be provided. What calls does the application need to make, and how will it make those calls? And when will the jobs run? What path is the instance taking to make these calls? When it comes to the application tiers, this might seem pretty straightforward, but you need to make sure you're covering your bases. What do these security groups and network ACLs and route tables look like? And are there any gateways that need to be considered when evaluating the security? What does management access look like? What methods are available for updates to the application? And looking at data security, this would need to be evaluated based on the type of data being gathered and sent by the application. How is it holding the data? What are the security and/or compliance requirements? Is encryption necessary? And with the reports that are being sent, how is it sending those reports, and what types of in-transit protections need to be utilized? These are just some of the questions that you would be considering with this very simple application architecture. And this would need to scale out immensely when looking at larger, more complex environments. Focus on understanding how to implement security as you evaluate and design your architectures, and you will save yourself a lot of headaches down the road. This will involve utilization of features and tools within the AWS services you're implementing, but will also be aided by the use of security-specific services. Until next time.