I am sorry , I didnt see the code.My finished code is below, let me know if its good coding.

#!/usr/bin/perl

use warnings;
use strict;
use Text::CSV;
use JSON::MaybeXS;
use FileHandle ;
use IO::Handle;

local( $/, *FH ) ;
open( FH, '<', 'aws.json' );
my $text = <FH>;

my $data = decode_json($text);

my $csv = Text::CSV->new({auto_diag=>2,binary=>1, eol=>"\n", always_qu
+ote=>1 });

my @fields = qw/ Timestamp    Average         Unit /;
$csv->print(select, \@fields);
for my $datapoint ( @{ $data->{Datapoints} } ) {
    $csv->print(select, [ map {$datapoint->{$_}} @fields ]);
}
[download]

... let me know if its good coding.

What follows is in part my own personal preference, but a lot is current idiomatic Perl; I won't rigorously distingush between the two. My comments pertain to your

local( $/, *FH ) ;
open( FH, '<', 'aws.json' );
my $text = <FH>;
[download]

section of code; the rest is from the AnonyMonk's post and looks good to me. Caveat: I haven't actually tested any of the code on which I'm commenting.
•     local( ..., *FH ) ;
      open( FH, '<', 'aws.json' );
  local-izing package global variables is better than nothing and you're already using the three-argument open, but it's even better to use a lexical filehandle and check the success of the file open:
      my $filename = 'aws.json';
      open my $fh, '<', $filename or die "opening '$filename': $!";
  (You could also turn on autodie globally with a  use autodie; statement, but I prefer the flexibility of individual die clauses.)
•     local( $/, ... ) ;
      ...
      my $text = <FH>;
  To do this idiomatic file "slurp" read,  $/ must be undefined. Again, globally undefining this variable (and that's effectively what you're doing, even using local) is not preferred: local-ize in the narrowest practicable scope:
      my $text = do { local $/;  <$fh>; };
  
• With the previous two changes, the
      local( $/, *FH ) ;
  statement (and its possibly problematic global effects) goes away entirely. (Update: Actually, the  local( ..., *FH ) ; statement effectively has no semantic global effect WRT the  *main::FH glob because it is local-izing the glob at the top level of the script, where all globs come into existence anyway. The only practical "global" effect is on your expectations: you may be lulled into thinking that you have invoked some kind of magical protection for yourself when you have not.)

---

Give a man a fish:  <%-{-{-{-<

Just TIMTOWTDI...

AnomalousMonk already mentioned the issue with local. Localizing is pointless when it happens at top level - in the same way as my variables are global variables if declared at top level in a program that consists in just 1 file without imports.

So, local needs a place. A bare block is convenient:

my $text; # but see above ;-)
{
    local( $/, *FH ) ;
    open( FH, '<', 'aws.json' );
    $text = <FH>;
}
# $/ restored to default here
# FH is an empty typeglob in the symbol table
[download]

See also my/local, space/time (was: Re: The difference between my and local)

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

Just to pick a nit:

Localizing is pointless when it happens at top level

Not entirely, e.g. if you've got a file foo.pl that does local $/, and a file bar.pl that does do "foo.pl" (any of eval/do/require/use), then bar.pl is protected from the change to $/.

I know you also said "a program that consists in just 1 file", but I'd say foo.pl doesn't know if it's being run by perl foo.pl or by being done from another script, or perhaps being run in a persistent process. So localizing would be playing it safe.