AWS re:Inforce 2022 - Design your firewall deployments to protect your internet applications(NIS301)

Поделиться
HTML-код
  • Опубликовано: 12 сен 2024
  • In this session, learn how to build the right network security architecture to protect your internet-facing applications. AWS offers a wide variety of security services to provide organizations with the ability to build a defense-in-depth strategy for security and inspecting traffic, but it can be daunting to put all the pieces together. Dive deep into the various use cases and reference architectures for stitching together AWS Shield, AWS WAF, Elastic Load Balancing (ELB), AWS Network Firewall, ELB Gateway Load Balancer, security groups, and NACLs to protect the edge of your AWS network from advanced intrusion and DDOS events.
    Learn more about AWS re:Inforce at bit.ly/3baitIT.
    Subscribe:
    More AWS videos bit.ly/2O3zS75
    More AWS events videos bit.ly/316g9t4
    ABOUT AWS
    Amazon Web Services (AWS) hosts events, both online and in-person, bringing the cloud computing community together to connect, collaborate, and learn from AWS experts.
    AWS is the world’s most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. Millions of customers-including the fastest-growing startups, largest enterprises, and leading government agencies-are using AWS to lower costs, become more agile, and innovate faster.
    #reInforce2022 #CloudSecurity #AWS #AmazonWebServices #CloudComputing

Комментарии • 6

  • @aireddy
    @aireddy Год назад +1

    It is very important to understand ingress and egress flow and how to protect your environment. Thank you Nick, Alexandra for very detailed explanation about how to detect, protect, investigate, automate, respond to incidents .

  • @navazdking
    @navazdking Год назад +1

    Great presen, Nick and Alexandra ! One question if you can clarify. I see Nick mentioned, centralized model is cost saving as it require fewer firewall appliances. But slide that Alexandra presented shows one of the cons of centralized model is increased cost in most of the cases. I believe distributed model is expensive compared to centralized.

  • @Gosu9765
    @Gosu9765 2 года назад +6

    The volume levels on those re:inforce videos are very low - have my headphones maxed out and it's still not a comfortable level. 😥
    Cool presentation tho.

    • @NR-bt7yz
      @NR-bt7yz Год назад

      You said it! AWS: Please adjust the audio levels before uploading to RUclips!

  • @srirajan1933
    @srirajan1933 Год назад +1

    Nice overview, Nick and Alexandra! I like the pairing concept of WAF-with-ALB and NFW-with-NLB to qualify natively supported integrated defense. A few questions and comments:
    1. At t=39:30, the "Cons" side for centralized Internet Ingress approach doesn't seem correct: it should be less complex and cheaper with fewer IGW components (need only 1 for the Edge VPC vs. 1 for each VPC), so 1 IGW component cost vs. 3. The transfer rate cost over centralized approach should be the same as distributed assuming Internet traffic is needed equally by all subscribing VPCs. If Internet traffic is not equally distributed among all subscribing VPCs, and if 1 particular VPC is known to be heavy-Internet-bound traffic, then that VPC can be separated with its own IGW with potential cost savings. But this seems to be an outlier scenario since net traffic transfer is charged by GB.
    2. At t=42 to 47 min, for future presentations it would be helpful to compare cost and latency in WAF service scenarios for distributed vs. centralized data plane.
    3. The PrivateLink option for centralize was helpful to illustrate comparison with Transit Gateway architecture in centralized WAF approach.
    4. At t=50:15, the Ingress routing scenario for GWLB, for the return path symmetry does the Target subnet routing table need to include a route to the Public subnet, which then will be forwarded to GLBWe for inspection, and onward to the Internet? Or, is there a particular aspect of the ELB that does not require an explicit return route from the target subnet to the Public subnet's GWLBe? In the MSR scenario, explicit return paths are defined in Target subnet route table to reach Public subnet via GWLB endpoint (GLWBE).
    5. At t=57:45, same question as #4 above but for AWS Network Firewall: does the Target subnet route table need return path to the Public subnet?
    6. Gateway LB "Appliance Mode" and AWS Network Firewall "Appliance Mode": With Transit Gateway, it should be noted that this setting needs to be *enabled* to guarantee flow symmetry to the originating AZ for return path traffic. But in this slide, no explicit Transit Gateway is shown. Perhaps it is implied, since this would be a natural way to scale-out VPCs. For future presentations, it would be helpful to address this critical "appliance mode" feature and how it applies to both non-Transit Gateway and Transit Gateway deployments.
    7. Separately, as pointed out below by Gosu, you should re-upload your presentation with audio-levels increased at the source; I had to enable close-captioned to follow the presentation. Thanks.

  • @okonkwochukwudalu9340
    @okonkwochukwudalu9340 2 года назад

    I don't understand why you would have a firewall in between a Loadbalancer and say an EC2 instance? The LB becomes redundant in that sense as it only shares workload across the FW and not the instances anymore