Best Practices for Securing AWS Instances Behind a Firewall

Data Ingestion
1

Hey,

I have a number of AWS EC2 instances that I need to keep safe while still being able to access them for my apps.

I’m having trouble with things that happen to a lot of people, and I would love to hear your best tips:

How to set up firewalls (on-premises or in the cloud) so that AWS instances are safe without losing connectivity.

When hosting apps on EC2, which ports and services should be open and which should be closed?

The best ways to keep an eye on and stop attacks like DoS, brute-force attempts, or strange traffic.

For AWS environments, here are some good IDS/IPS rule sets, logging, and alerting strategies.

I’m looking for useful tips from anyone who has successfully protected AWS workloads. What mistakes should I avoid, and what worked best for you?

Thanks in advance!

3

Hey Allen!
Welcome to the community.

To clarify, is this in regards to AWS Observe Integration or are you generally interested in learning about securing AWS Instances?

Nikhil

4

Hey Thank you for welcoming me to the community!

My main question is about how to keep AWS EC2 instances safe in general.

This includes things like firewalls, which ports to open or close, monitoring for attacks, and best practices.

I’m not only interested in the Observe integration, but I’d also like to hear about any tips that have to do with monitoring tools or dashboards.

5

Got it. Regarding AWS EC2 instances in general, AWS blogs would be a good place to get specific updated info. Here’s one of the better articles: https://medium.com/@tahirbalarabe2/best-security-practices-for-amazon-ec2-1362d0c3b428

I’ve gathered some information from AWS best practices along with combining with Observe monitoring. To summarize:

  • Network segmentation & least privilege

    • Put public-facing workloads in public subnets and all backends (DB, caches, admin tools) in private subnets.

    • Use Security Groups (stateful) as your primary instance firewall; use Network ACLs for coarse subnet-level restrictions.

    • Follow deny-by-default: only allow the exact ports and source IPs necessary.

  • Ports & services (what to open / close)

    • Open only what the app needs. Typical examples:

      • Web apps: 80/443 open to the public only if needed.

      • SSH (22) / RDP: do NOT open to 0.0.0.0/0. Restrict to admin IPs or remove public access (see bastion/SSM below).

      • Management endpoints (DB, internal APIs): keep in private subnets and only allow traffic from application-tier SGs.

    • Close unused ports and disable unnecessary OS services on the instance.

  • Admin access patterns (avoid public SSH/RDP)

    • Use a bastion/jump host or AWS Systems Manager Session Manager / VPN / PrivateLink for admin access — avoid exposing SSH/RDP directly.

    • Use key-based SSH and disable password authentication. Rotate keys and prefer ephemeral credentials where possible.

  • Identity & credentials

    • Use IAM roles for EC2 to grant access to AWS APIs; never embed long-lived keys in instance files.

    • Enable MFA for privileged accounts and console/API access.

  • Patching & hardening

    • Harden AMIs (CIS benchmarks), remove unused packages, and keep OS/app patches up to date.

    • Use immutable patterns where practical — rebuild from a hardened AMI rather than patching live compromised hosts.

  • Logging, observability & dashboards (with Observe)

    • Centralize VPC Flow Logs, CloudTrail, and CloudWatch Logs into your observability platform. These are key for network/attack detection and auditing.
      • VPC Flow Logs — for network-level metadata (who talked to what, ports, bytes).
      • CloudTrail — for auditing configuration/API changes (security group changes, role changes).
      • CloudWatch Logs — for instance/application logs and alarms.
    • Ingest VPC Flow Logs, CloudTrail, and CloudWatch Logs into Observe (Observe supports AWS data collection patterns and has EC2-specific datasets and dashboards). Use the AWS quickstart or centralized ingestion patterns to feed those logs into Observe for correlation and dashboards
    • Build additional dashboards and alerts for:

      • spikes in inbound traffic / network throughput (possible DDoS)

      • repeated failed auth attempts (brute-force)

      • new or changed security group rules (unexpected exposure)

      • unusual outbound connections or high-volume data egress (possible exfil)

      • Prefer JSON-formatted application logs for easier parsing and dashboarding.

  • General Gotchas

    • Leaving management ports open to the internet (SSH/RDP to 0.0.0.0/0).
    • Relying solely on Security Groups without flow logs, auditing, or IDS.
    • Storing long-lived secrets on instances.
    • No centralized logging or no alerting on security group changes and auth failures.